Vishwark

Posted on Apr 25

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

#webdev #backend #frontend

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:

Find the hardcoded component
Update the code
Run tests
Push to CI/CD
Wait for deployment
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

Feature	Pattern 1 Hardcoded	Pattern 2 Static Layout	Pattern 3 SDUI
Text controlled by	Frontend	Backend	Backend
Layout controlled by	Frontend	Frontend	Backend
Copy changes without deploy	No	Yes	Yes
A/B testing layouts	Hard	Limited	Excellent
Complexity	Low	Medium	High
Speed for marketers	Slow	Fast	Fast
Best for	Logic-heavy apps	Content-driven products	Dynamic consumer apps

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.