DEV Community

Cover image for Road To KiwiEngine #3: Why Businesses Don't Want Frameworks
Drew Marshall
Drew Marshall

Posted on

Road To KiwiEngine #3: Why Businesses Don't Want Frameworks

One thing I’ve been realizing more lately is that most businesses are not actually searching for frameworks.

They’re searching for operational outcomes.

A restaurant owner doesn’t wake up thinking:

“I need the perfect frontend framework.”

They think:

  • “I need online ordering.”
  • “I need delivery tracking.”
  • “I need customer retention.”
  • “I need inventory management.”
  • “I need my business to operate smoothly.”

A creator usually isn’t thinking:

“What rendering engine should I use?”

They’re thinking:

  • “How do I sell content?”
  • “How do I build a community?”
  • “How do I manage subscriptions?”
  • “How do I grow sustainably?”

The operational problem is the real problem.

The technology is usually just the vehicle.

And honestly, that realization changed how I think about software architecture entirely.


Developers Often Start Lower in the Stack

One thing I’ve noticed over the years is that developers naturally tend to think from the bottom upward:

  • frameworks
  • libraries
  • databases
  • APIs
  • rendering systems
  • deployment tools

That makes sense.

Those are the tools we work with directly.

But businesses usually think from the top downward:

  • workflows
  • operations
  • customer experience
  • reliability
  • sustainability
  • scalability
  • revenue generation

They care about whether the system helps them operate.

Not whether it uses the newest runtime.


This Is Why Operational Systems Matter So Much

At some point, I stopped seeing applications as isolated software products.

I started seeing them as operational ecosystems.

A modern business platform often includes:

  • content systems
  • deployment workflows
  • billing systems
  • analytics
  • authentication
  • infrastructure
  • integrations
  • notifications
  • customer management
  • operational pipelines

The UI is only one layer.

The operational system is the real product.


Frameworks Solve Important Problems

To be clear:
frameworks are valuable.

They solve:

  • developer experience
  • rendering
  • routing
  • state management
  • tooling consistency

Those are real engineering problems.

But eventually I realized something:
frameworks alone don’t solve operational architecture.

And operational architecture increasingly determines:

  • scalability
  • maintainability
  • portability
  • lifecycle sustainability
  • deployment complexity
  • organizational clarity

That’s a different layer of thinking entirely.


This Is Part of Why Blueprint Thinking Became Important to Me

The more systems I worked on, the more I became interested in:

  • reusable operational systems instead of:
  • reusable implementation alone.

For example:

A restaurant blueprint might already understand:

  • ordering workflows
  • delivery states
  • inventory systems
  • payment handling
  • operational roles
  • customer notifications

A creator blueprint might understand:

  • subscriptions
  • memberships
  • media delivery
  • storefront systems
  • audience workflows

That’s much closer to how businesses actually think.

Not:

“Please assemble 40 disconnected technologies before you can operate.”


Modern Software Is Becoming Infrastructure

One thing I think the industry is slowly realizing is that software increasingly behaves like infrastructure.

Businesses depend on platforms operationally now.

That means systems increasingly need:

  • observability
  • deployment awareness
  • infrastructure awareness
  • lifecycle management
  • scalability
  • portability
  • operational clarity

Not just:

  • nice UI
  • fast rendering
  • trendy frameworks

Those things matter too.

But operational sustainability matters more over time.


This Shift Changed How I Think About WebEngine

A lot of the philosophy behind:

  • WebEngine
  • KiwiPress
  • Citrode
  • Nectarine
  • GrapeVine

comes from thinking deeply about operational systems rather than isolated apps.

I became increasingly interested in questions like:

  • How do businesses deploy systems more sustainably?
  • How do we reduce operational friction?
  • How do we improve portability?
  • How do we make infrastructure more understandable?
  • How do we model workflows more clearly?

Those questions eventually become much larger than frontend frameworks alone.


AI Makes This Even More Interesting

Ironically, I think AI reinforces this shift.

Because AI can generate implementation increasingly quickly.

But generated implementation still requires:

  • architecture
  • workflows
  • operational boundaries
  • infrastructure
  • lifecycle planning
  • maintainability

Otherwise complexity compounds rapidly.

That’s one reason I think operational systems and blueprint-driven ecosystems are becoming increasingly important.


I Think the Industry Is Moving Higher Up the Stack

One thing I suspect we’ll see more of over time is abstraction moving increasingly toward:

  • operational systems
  • workflows
  • lifecycle management
  • infrastructure orchestration
  • ecosystem composition

Not just:

  • components
  • pages
  • routes

Because businesses ultimately care about operating effectively.

Not assembling technology indefinitely.


Final Thoughts

Frameworks matter.

Great tooling matters.

Developer experience matters.

But increasingly, I think the real challenge modern software needs to solve is operational complexity.

Because most businesses are not trying to become framework experts.

They’re trying to:

  • serve customers
  • operate reliably
  • scale sustainably
  • manage workflows
  • build long-term systems

And the more I think about it, the more I believe the future of software may revolve less around isolated frameworks…

…and more around operational ecosystems that help people actually run things.

Top comments (0)