🧩 Frontend Architecture for Dynamic Content: Hardcoded UI vs CMS/BE vs Server-Driven UI

It’s 4:55 PM on a Friday.

Your marketing lead drops a message:

“The holiday banner is wrong. It still says Spring Sale. Can we fix it today?”

And suddenly, a simple text change becomes an engineering task.

To update one headline, the team now has to:

1. Find the hardcoded component


2. Update the code


3. Run tests


4. Push to CI/CD


5. Wait for deployment


6. Verify production

All this… just to change a sentence.

By the time it’s fixed, the campaign window is gone, everyone is irritated, and engineering time has been spent on something that shouldn’t have required code in the first place.

This is what I call the Content Bottleneck.

It happens when teams mix up two very different responsibilities:

• 
  Structure → Layout, components, flow, interactions


• 
  Content → Text, images, labels, banners, marketing copy

When content is tied to deployments, every small business request becomes a release cycle.

Let’s break down the three common frontend patterns companies use to solve this problem—and where each one makes sense.

Pattern 1: Hardcoded Frontend UI

This is the most common starting point.

How it works

Backend sends data, but frontend handles almost everything:

• Rendering UI


• Component logic


• Sorting and filtering


• Section visibility


• Labels and copy


• Images and banners

Sometimes even static text lives directly inside components.

const Banner = () => {

  return <h1>Happy Holidays!</h1>;

};

Flow

Backend Data → Frontend Logic + Frontend Content → UI

Why Teams Start Here

Because it’s simple.

Developers can move fast in the early stages. No need for CMS systems, no backend content models, no dynamic rendering setup.

For startups or internal tools, this is often good enough.

The Real Problems Appear Later

As the company grows, non-engineering teams need speed.

Marketing wants to update banners. Product wants to test new copy. Legal wants to change disclaimers quickly.

Now every small request becomes:

• Jira ticket


• Developer task


• QA cycle


• Deployment process

That slows everyone down.

Best Fit

This pattern works well for:

• Internal dashboards


• Admin tools


• SaaS products with heavy logic


• Small teams moving quickly

If the product logic is the real value, hardcoded UI is fine.

Pattern 2: Static Layout, Dynamic Content (The Sweet Spot)

This is where many teams find balance.

How it works

Frontend still owns:

• Layout


• Components


• Styling


• User interactions


• Section order

Backend owns:

• Titles


• Subtitles


• Images


• CTA labels


• Promo text


• Visibility flags

Frontend simply renders content into predefined components.

const HomePage = ({ data }) => {

  const hero = data.sections.find(x => x.type === "hero");



  return (

    <>

      {hero && (

        <HeroSection

          title={hero.title}

          subtitle={hero.subtitle}

          image={hero.image}

        />

      )}

    </>

  );

};

Flow

Backend Content → Frontend Components → UI

Why This Works So Well

This solves the original problem without overengineering.

1. Content Changes Become Fast

Need to fix typo?

Update backend data or CMS.

No code deployment required.

2. Frontend Remains Stable

Your layout and components stay controlled by engineering.

That means:

• Better maintainability


• Strong typing


• Cleaner codebase


• Easier testing

3. Better Ownership

This creates a healthier split:

• Product / Marketing controls messaging


• Engineering controls experience and quality

Everyone moves faster.

4. Reusable UI Still Exists

You still build proper components like:

• HeroSection


• FeatureGrid


• FAQBlock


• OfferBanner

Instead of building a generic JSON renderer.

Best Fit

This pattern is excellent for:

• Landing pages


• Marketing websites


• Investment dashboards


• Product education pages


• Seasonal campaign pages


• Fintech app informational screens

Honestly, for many businesses, this is the best trade-off between flexibility and sanity.

Pattern 3: Server-Driven UI (SDUI)

Now we move into more advanced systems.

How it works

Backend controls:

• Which components to render


• Order of components


• Props/data for each block


• Visibility rules


• Experiment variations

Frontend becomes a rendering engine.

[

  {

    "component": "HeroBanner",

    "props": {

      "title": "Start Investing Today"

    }

  },

  {

    "component": "FAQBlock",

    "props": {}

  }

]

Frontend maps names to components:

const registry = {

  HeroBanner,

  FAQBlock

};

Flow

Backend Layout + Data → Frontend Renderer → UI

Why Big Companies Use It

Because it unlocks speed at scale.

1. A/B Testing Layouts

Different users can see different structures.

One user sees:

• Video hero section

Another user sees:

• Static banner with CTA

No app release required.

2. Personalization

New users see onboarding.

Existing users see portfolio summary.

Dormant users see reactivation offers.

3. Faster Growth Experiments

Growth teams can test ideas rapidly.

4. Multi-platform Reuse

Same response model can power:

• Web


• Android


• iOS

Very useful for large consumer apps.

But There Is a Cost

This system sounds great until you build it.

Now you need:

• Component registry


• Strict schema contracts


• Version compatibility


• Analytics mapping


• Debugging tools


• Backend + frontend coordination

Without discipline, SDUI becomes chaos.

Best Fit

Use it for:

• App homepages


• Discovery feeds


• Experiment-heavy products


• Fintech onboarding flows


• Super apps


• Personalized consumer experiences

Clean Comparison

What Most Big Companies Actually Do

They don’t choose one pattern.

They combine all three.

Realistic Example

Dashboard Pages

Pattern 1

Heavy business logic, charts, filters, secure workflows.

Marketing Pages

Pattern 2

Fast updates, campaigns, SEO pages.

Homepage / Feed / Discovery

Pattern 3

Experiments, recommendations, personalization.

That hybrid approach is often the most practical architecture.

Important Engineering Lessons

Once backend controls content, reliability matters.

Loading States

Use skeleton loaders.

Missing Content

Hide empty sections gracefully.

Unknown Components (SDUI)

Never crash the app.

Show fallback UI.

Caching

Use tools like:

• React Query


• SWR

Analytics

Track impressions, clicks, conversions per section.

Because flexibility without measurement is useless.

Final Verdict

Many teams jump to Server-Driven UI too early.

But if your actual pain is:

• changing banner text


• fixing typo quickly


• updating campaign copy


• swapping CTA labels


• changing promo image

Then you probably need Pattern 2, not SDUI.

Pattern 2 gives you:

• Faster business iteration


• Stable frontend architecture


• Cleaner ownership model


• Lower engineering cost


• Less complexity

Use SDUI when you truly need:

• dynamic layouts


• rapid experimentation


• personalization at scale

A Simple Rule to Remember

Use this practical rule when deciding ownership between frontend and backend:

• If the layout stays the same, but content changes (text, images, CTA labels, banners, offers) while backend provides the data → Pattern 1: Hardcoded Frontend Layout + Backend Data


• If the layout stays the same, but content is managed dynamically through CMS/backend configs without code releases → Pattern 2: Static Layout, Dynamic Content


• If the UI structure itself changes (different section order, new components, personalized layouts, A/B tested screens) based on backend response → Pattern 3: Server-Driven UI

In Short

• Same frontend layout + backend data → Pattern 1


• Same layout + backend-managed content updates → Pattern 2


• Different layouts/components driven by backend → Pattern 3

The next time someone asks to change a headline, that request should not need a deployment pipeline.

It should need a content update.