DEV Community: Drew Marshall

Road To KiwiEngine #6: I Don’t Hate AI — I Think We’re Teaching It Recklessly

Drew Marshall — Mon, 01 Jun 2026 15:30:00 +0000

One thing I want to make clear upfront:

I do not hate AI.

Honestly, I think AI is one of the most important technological shifts we’ve seen in decades.

I use it.
I study it.
I think it will dramatically change:

software development
infrastructure
operations
education
research
business workflows

But at the same time, I also think the current culture surrounding AI is becoming dangerously misguided.

Not because the technology itself is bad.

Because the mentality around it increasingly feels shortsighted.

⸻

The Current Conversation Often Feels Backwards

A lot of AI discussions right now revolve around:

replacing engineers
generating apps instantly
removing expertise
eliminating learning curves
“vibe coding”
shipping software without understanding systems

And honestly?
I think that framing is incredibly dangerous long-term.

Because software is not just text generation.

Software becomes:

infrastructure
operational systems
financial systems
healthcare systems
logistics systems
communication systems
ecosystems people depend on daily

The consequences of poorly understood systems become very real very quickly.

⸻

The “Vibe Coding” Mentality Worries Me

One thing that concerns me is how casually some people now approach building operational systems with AI.

There’s this growing idea that:

“If the application appears to work, understanding no longer matters.”

But operational systems are not just:

UI screens
generated routes
copied prompts

Real systems involve:

scalability
security
lifecycle management
deployment
observability
infrastructure
maintainability
operational boundaries
data integrity
runtime behavior

Those things still matter enormously.

And honestly, they may matter more now.

⸻

Earlier Prompts Already Feel Like Legacy Code

One thing I find fascinating is how quickly AI-generated workflows are already aging.

Prompts from:

earlier models
earlier workflows
earlier tooling patterns

already feel like operational legacy systems.

That should probably tell us something.

Because if the workflow itself changes every few months, then:

architecture matters
operational clarity matters
maintainability matters
foundational knowledge matters

Otherwise systems become extremely fragile extremely quickly.

⸻

Token Cost vs Engineering Quality Is a Real Conversation

Another thing I think people underestimate is the operational cost side of AI.

There’s a growing assumption that:

“AI is automatically cheaper than engineers.”

But in many cases:

debugging generated systems
correcting architectural mistakes
dealing with scaling failures
untangling hidden complexity
fixing poor runtime decisions

can become incredibly expensive operationally.

Especially when systems move beyond prototypes.

Sometimes paying experienced engineers to:

design systems properly
establish operational boundaries
create maintainable architecture
think through lifecycle implications

is dramatically cheaper long-term than repeatedly generating unstable systems quickly.

That’s not anti-AI.

That’s operational realism.

⸻

Tools Still Require Stewardship

One analogy I keep coming back to is this:

Just because someone has access to a powerful tool does not automatically mean they understand how to wield it responsibly.

And honestly, I think AI is one of the most powerful tools we’ve ever placed into people’s hands.

That means:

training matters
understanding matters
responsibility matters
operational thinking matters

Especially when these systems increasingly affect:

businesses
infrastructure
communication
financial systems
public systems

This is bigger than generating websites quickly.

⸻

AI Should Amplify Engineers — Not Replace Understanding

Personally, I think the healthiest future is one where AI amplifies:

engineers
architects
operators
creators
educators

instead of convincing people foundational understanding no longer matters.

Because understanding systems deeply still matters.

Maybe now more than ever.

Especially as generated complexity increases.

⸻

The Real Bottleneck Was Never Typing Speed

One thing I think the industry is slowly realizing is that software engineering was never primarily bottlenecked by:

typing speed
boilerplate generation
syntax production

The harder problems are usually:

architecture
operational clarity
responsibility boundaries
scalability
maintainability
communication
infrastructure
lifecycle sustainability

AI helps with implementation.

But implementation was never the entire problem.

⸻

This Is Why I Keep Thinking About Explicit Systems

A lot of my current thinking around:

WebEngine
KiwiPress
operational architecture
contracts
pipelines
blueprint systems

comes from this exact concern.

The more powerful generation becomes, the more important:

clarity
structure
observability
maintainability
operational boundaries

become.

Otherwise we risk generating operational chaos at unprecedented speed.

⸻

I Think We Need Better AI Culture

I don’t think the answer is fear.

And I don’t think the answer is rejecting AI.

I think the answer is developing a healthier engineering culture around it.

One that values:

education
stewardship
architecture
operational understanding
maintainability
responsible system design

instead of:

hype
shortcuts
replacing understanding
generating systems blindly

Because these tools are becoming too powerful to treat casually.

⸻

Final Thoughts

AI is not the problem.

The mindset surrounding it often is.

I think AI has the potential to become one of the greatest engineering accelerators we’ve ever seen.

But acceleration without understanding can become dangerous very quickly.

Especially when software increasingly powers:

businesses
infrastructure
operations
communication
daily life

The future shouldn’t be:

“nobody needs to understand systems anymore.”

If anything, I think the future requires deeper operational understanding than ever before.

Because the more powerful our tools become…

…the more responsibility comes with using them well.

Road To KiwiEngine #5: The Future of SaaS Might Be Operational Ownership

Drew Marshall — Sun, 31 May 2026 14:25:00 +0000

For a long time, software trends focused heavily on convenience.

And honestly, that made sense.

Cloud platforms dramatically lowered barriers for:

deployment
collaboration
scaling
accessibility

Businesses no longer needed to maintain entire server rooms just to operate online.

That shift changed the industry permanently.

But lately, I’ve been thinking about another question:

“What happens when businesses increasingly depend on platforms they don’t truly control?”

Because modern businesses often rely on dozens of external operational layers:

hosting providers
SaaS subscriptions
authentication services
payment processors
deployment platforms
analytics tools
communication systems
workflow software
infrastructure vendors

At some point, the business itself becomes deeply intertwined with external ecosystems.

And I think that reality is starting to reshape how people think about software ownership.

⸻

SaaS Solved Real Problems

I think it’s important to acknowledge that SaaS platforms solved enormous operational problems.

They made software:

more accessible
easier to deploy
easier to maintain
easier to scale
easier to adopt

That operational simplicity helped millions of businesses grow online.

And honestly, many companies would never have survived without those abstractions.

But abstraction also creates dependency.

And dependency becomes increasingly important as systems mature.

⸻

Operational Ownership Is Becoming More Important

One thing I’ve noticed is that businesses increasingly care about:

portability
infrastructure flexibility
deployment control
data ownership
operational continuity
ecosystem independence

Especially as software becomes more central to daily operations.

Because eventually businesses start asking questions like:

“What happens if pricing changes?”
“What happens if this platform disappears?”
“What happens if we outgrow this ecosystem?”
“Can we migrate safely?”
“Who actually controls the operational layer?”

Those are infrastructure questions.
Not just software questions.

⸻

Modern Businesses Depend on Operational Ecosystems

One thing I think developers sometimes underestimate is how deeply operational software became.

A modern business platform often includes:

content systems
billing systems
infrastructure
deployment workflows
customer management
communication systems
analytics
authentication
automation pipelines
integrations

The software stack becomes part of the business itself.

That means operational decisions increasingly affect:

scalability
flexibility
sustainability
long-term survivability

⸻

This Is Why Portability Matters So Much to Me

A lot of the philosophy behind:

WebEngine
Citrode
KiwiPress
GrapeVine
blueprint systems

comes from thinking deeply about operational portability.

Not because I think businesses should host everything themselves.

But because I think businesses should retain meaningful control over:

infrastructure
workflows
deployment
operational evolution

whenever possible.

That changes how systems are designed.

⸻

I Think Infrastructure Awareness Is Becoming Critical

Historically, many businesses could treat infrastructure as something mostly invisible.

Modern operational systems don’t really allow that anymore.

Today infrastructure increasingly affects:

performance
scaling
deployment speed
reliability
observability
operational cost
customer experience

The operational layer became too important to ignore entirely.

That’s one reason I think infrastructure-aware development is becoming increasingly valuable moving forward.

⸻

The Future Probably Isn’t “No SaaS”

This is important:
I don’t think the future is:

“everyone hosts everything themselves.”

That’s unrealistic for many businesses.

What I do think is that businesses increasingly want:

flexibility
portability
composability
operational transparency
infrastructure awareness
reduced lock-in

The future may become more hybrid:

managed infrastructure
composable ecosystems
portable operational systems
infrastructure-aware platforms

instead of purely closed operational silos.

⸻

AI Makes Operational Ownership Even More Important

Ironically, I think AI increases the importance of operational ownership dramatically.

Because AI can accelerate:

development
automation
workflow generation
infrastructure orchestration

But the systems still require:

governance
operational clarity
deployment control
lifecycle management
infrastructure boundaries

Otherwise businesses risk becoming increasingly dependent on systems they don’t fully understand or control operationally.

That creates long-term fragility.

⸻

Businesses Want Stability More Than Hype

One thing I think gets overlooked in tech conversations is that most businesses value:

reliability
predictability
operational continuity
maintainability

far more than constant technological novelty.

The businesses that survive long-term usually optimize for:

sustainable systems
operational resilience
adaptability
ownership of critical workflows

not endless trend chasing.

⸻

This Is Part of Why I Keep Thinking About Operational Ecosystems

The deeper I get into platform architecture, the more I think software increasingly needs to optimize for:

operational sustainability
portability
observability
composability
infrastructure awareness
lifecycle flexibility

That’s one reason I’ve become increasingly interested in:

blueprint systems
deployment-aware platforms
contract-driven architecture
modular operational ecosystems

Because modern businesses increasingly depend on software operationally, not just functionally.

⸻

I Think the Industry Is Slowly Shifting

Interestingly, I think we’re already starting to see the industry move in this direction.

More conversations are emerging around:

platform engineering
internal developer platforms
infrastructure portability
self-hosting
composable architecture
operational resilience
lifecycle-aware systems

Not because SaaS failed.

But because operational dependence became more visible.

⸻

Final Thoughts

SaaS transformed the software industry.

There’s no question about that.

But I also think the next evolution of software may revolve less around:

“Who owns the application?”

and more around:

“Who controls the operational ecosystem surrounding the application?”

Because increasingly, software is not just a tool businesses use.

It’s infrastructure businesses depend on daily.

And the more central software becomes to operations, the more important operational ownership becomes over time.

Road To KiwiEngine #4: The Racecar Driver Analogy

Drew Marshall — Sat, 30 May 2026 16:00:00 +0000

One thing I keep coming back to when thinking about modern software is this:

A racecar driver shouldn’t need to manufacture every part of the car before racing.

They should be able to:

choose reliable components
assemble systems
tune performance
focus on operating effectively

But in software, we often expect businesses to do the opposite.

Before a company can even begin solving its actual operational problems, it frequently has to piece together:

hosting
authentication
databases
deployment pipelines
billing systems
analytics
infrastructure
APIs
admin systems
integrations
monitoring
workflow tooling

And by the time all of that is assembled, the original business problem sometimes becomes secondary to maintaining the technology stack itself.

That realization changed how I think about software architecture entirely.

Businesses Usually Don’t Want Technology Stacks

Most businesses do not wake up excited about infrastructure assembly.

They care about:

serving customers
operating efficiently
scaling sustainably
managing workflows
improving reliability
growing revenue

The software is supposed to support the operation.

But increasingly, modern systems require businesses to become partial infrastructure companies just to function effectively online.

That’s a huge shift from the earlier web.

Modern Software Has Become Operationally Heavy

One thing I’ve noticed is that the complexity of modern software often comes less from the business logic itself and more from the surrounding operational ecosystem.

For example:
launching a modern platform may involve:

frontend systems
backend systems
cloud infrastructure
CI/CD pipelines
environment management
container orchestration
observability tooling
CDN layers
API gateways
billing providers
authentication services

All before the business even begins delivering value.

That operational weight compounds quickly.

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:
endlessly rebuilding implementation details.

For example:

A restaurant platform shouldn’t need to reinvent:

ordering flows
delivery states
inventory workflows
customer notifications
payment systems
operational dashboards

A creator platform shouldn’t need to rebuild:

memberships
subscriptions
storefront systems
content delivery
audience workflows

Those operational patterns already exist.

So the interesting challenge becomes:

“How do we create systems that allow businesses to focus more on operating and less on rebuilding infrastructure repeatedly?”

This Is Where Platforms Become Interesting

I think this is one reason platform ecosystems became so influential historically.

Platforms reduce operational friction.

WordPress did this incredibly well for publishing.

Shopify did this for eCommerce.

Other ecosystems solved similar operational problems in different industries.

The common pattern is usually:

reduce setup friction
abstract operational complexity
provide extensibility
improve accessibility

That’s much bigger than simply “building apps.”

But Modern Systems Need More Than Simplicity

At the same time, modern operational systems increasingly require:

scalability
deployment awareness
observability
portability
infrastructure flexibility
lifecycle management

So now the challenge becomes balancing:

simplicity with
operational capability.

That’s not easy.

Especially as systems become larger and more interconnected.

The Infrastructure Layer Is Becoming the Real Product

One thing I increasingly believe is that many modern software companies are actually infrastructure companies disguised as application companies.

Because eventually:

reliability matters
deployment matters
scaling matters
integrations matter
operational workflows matter
portability matters

The operational layer becomes the long-term challenge.

Not just the UI.

This Shift Changed How I Think About WebEngine

A lot of the philosophy behind:

WebEngine
KiwiPress
Citrode
blueprint systems
operational runtime architecture

comes from thinking deeply about this operational burden.

I became increasingly interested in:

deployment-aware systems
infrastructure-aware development
operational portability
composable runtime architecture
reusable business blueprints
lifecycle-aware systems

Not because technology itself is the goal.

But because reducing operational friction matters enormously for businesses.

AI Makes This More Important, Not Less

Ironically, I think AI increases the importance of operational architecture.

Because AI can increasingly generate:

code
interfaces
APIs
boilerplate systems

quickly.

But generated systems still require:

structure
workflows
operational boundaries
infrastructure
maintainability
lifecycle management

Otherwise complexity compounds at machine speed.

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

I Think the Industry Is Moving Toward Operational Abstraction

One thing I suspect we’ll see more of over time is software moving higher up the abstraction ladder.

Not just:

frameworks
components
libraries

But:

operational systems
infrastructure orchestration
lifecycle-aware platforms
composable ecosystems
business blueprints

Because businesses ultimately want operational outcomes.

Not endless infrastructure assembly.

The Goal Isn’t Removing Flexibility

This is important:
I don’t think businesses should lose flexibility.

I think they should gain better operational foundations.

The ideal system should allow:

extensibility
customization
scalability
portability

without forcing every company to become infrastructure experts before they can operate effectively.

That’s a very different architectural philosophy than simply:

“assemble everything manually.”

Final Thoughts

Software has become incredibly powerful.

But it has also become operationally heavy.

And increasingly, I think the biggest challenge isn’t:

“How do we build more technology?”

It’s:

“How do we reduce operational friction while still enabling powerful systems?”

Because most businesses don’t actually want to spend their lives assembling racecars.

They want to race.

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

Drew Marshall — Fri, 29 May 2026 16:00:00 +0000

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.

The Road to KiwiEngine — The Strange Feeling of Publishing Your Own Ecosystem

Drew Marshall — Thu, 28 May 2026 16:00:00 +0000

A weird thing happens when your side projects stop feeling like side projects.

For years, most of the CitrusWorx ecosystem lived privately:

local folders
architecture notes
unfinished repositories
half-working prototypes
diagrams that only made sense to me

A lot of it felt more like R&D than software.

But recently, after publishing more of the WebEngine ecosystem publicly through NPM, something started feeling different.

The projects stopped feeling theoretical.

That sounds obvious, but I don’t think I fully understood the psychological difference between:

“working on ideas”

and:

“maintaining public systems.”

Once packages become public:

naming matters more
consistency matters more
documentation matters more
versioning matters more
architecture matters more
stability matters more

You stop building only for yourself.

And honestly, that transition has been both motivating and intimidating.

The Ecosystem Problem

One thing I underestimated was how quickly individual projects start influencing each other once they become part of a visible ecosystem.

A small decision in one package suddenly affects:

naming conventions
runtime behavior
documentation structure
package organization
developer expectations

Even simple things become larger architectural decisions.

For example:

should configs use TOML or YAML?
where should runtime contracts live?
what belongs inside WebEngine versus outside of it?
how much should packages know about each other?
when does a utility become infrastructure?

Those questions sound small individually.

But at ecosystem scale, they start defining the personality of the platform itself.

Thinking Beyond “Just Shipping”

I think a lot of development culture focuses heavily on:

shipping fast
launching quickly
MVPs
growth loops

And those things absolutely matter.

But ecosystem development feels different.

You’re not just shipping features.

You’re shaping:

standards
expectations
architecture patterns
workflows
operational habits

That requires a slower and more intentional kind of thinking.

Especially as a solo founder.

What I’m Learning

One of the biggest lessons so far is that ecosystems are less about individual projects and more about relationships between projects.

That’s starting to become very real with:

Seltzer
Nectarine
Juice
GrapeVine
Sugar
KiwiPress
WebEngine

Each package matters individually.

But the real challenge is making them feel coherent together.

That’s the part I’m still actively learning.

And honestly, documenting that process publicly is becoming one of the most valuable parts of building KiwiEngine itself.

The Road to KiwiEngine — Why I Stopped Thinking in Frameworks

Drew Marshall — Wed, 27 May 2026 15:30:00 +0000

Over the last few years, I kept running into the same problem while building projects:

Every tool solved its own problem well, but the overall system kept getting more chaotic.

Frontend frameworks handled UI.
Backend frameworks handled APIs.
Cloud platforms handled deployment.
CMS platforms handled content.
IaC tools handled infrastructure.

But stitching everything together into one coherent system always felt fragile.

At some point, I realized I wasn’t actually interested in building “another framework.”

I was more interested in building:

contracts between systems
predictable runtime behavior
modular infrastructure
portable application architecture
reusable blueprints
and long-term maintainability

That shift in thinking eventually became the foundation for what is now evolving into KiwiEngine and the broader CitrusWorx ecosystem.

The Problem I Kept Seeing

Modern development often optimizes for:

speed
abstraction
convenience
shipping quickly

And honestly, those things matter.

But the longer I worked on larger ideas and multi-system projects, the more I noticed a different problem appearing:

The architecture itself was becoming secondary.

A lot of projects were effectively becoming:

dependency collections
plugin chains
framework lock-in
undocumented runtime behavior
implicit coupling between systems

Things worked...
until they didn’t.

And when they broke, debugging the system became archaeology.

The Shift Toward Runtime Thinking

Instead of asking:

“Which framework should I use?”

I started asking:

“What contracts should exist between these systems?”

That single question changed how I started approaching software entirely.

Instead of designing applications around frameworks, I started designing around:

contracts
adapters
pipelines
runtimes
boundaries
execution flow

That led to ideas like:

Seltzer
Nectarine
Juice
GrapeVine
Sugar
KiwiPress
WebEngine

All of them solve different problems, but they’re all connected by the same philosophy:

Systems should be composable instead of tightly coupled.

Why I’m Building in Public

Recently, over 10+ of these libraries became publicly available on NPM.

That’s exciting, but also slightly terrifying.

Because once software becomes public:

people inspect your decisions
your abstractions get tested
assumptions get challenged
architecture becomes visible

But honestly, I think that’s healthy.

I think more developers should share:

unfinished ideas
architecture experiments
runtime concepts
infrastructure thinking
long-term system design

Not just polished success stories.

What This Series Will Be

This series is going to document the real process of building KiwiEngine and the CitrusWorx ecosystem as a solo founder.

Some posts will be technical.
Some architectural.
Some operational.
Some probably about burnout and decision fatigue.

But overall, I want this series to explore a bigger question:

What would software ecosystems look like if they were designed intentionally from the beginning instead of assembled reactively over time?

That’s the road I’m currently exploring with KiwiEngine.

And this is the start of documenting it publicly.

Why I’m Exploring a PHP-Based KiwiPress

Drew Marshall — Tue, 26 May 2026 17:00:00 +0000

Over the last few years, I’ve spent a lot of time thinking about operational architecture.

Not just:

frontend frameworks
APIs
deployment pipelines
infrastructure

But how entire systems evolve over time.

That line of thinking eventually led me somewhere unexpected:

Back to PHP.

More specifically:
back to WordPress.

And honestly, I didn’t expect that.

Because like many developers, I spent years chasing:

newer stacks
newer runtimes
newer frontend ecosystems
newer architectural patterns

But the deeper I got into systems thinking, the more I realized something important:

Technology trends come and go.

Operational ecosystems survive.

And few ecosystems have survived and adapted as successfully as WordPress.

That realization became one of the foundations behind why I started exploring a PHP-based KiwiPress architecture.

This Isn’t About “Replacing WordPress”

One thing I want to make very clear:

I’m not interested in making:

“the WordPress killer.”

Honestly, I think that mindset usually misses the point entirely.

WordPress already succeeded at something many platforms never achieve:
it became operational infrastructure for millions of people.

That deserves respect.

The more interesting question to me is:

“What happens if we apply modern systems thinking to an ecosystem like WordPress?”

That’s a much more exciting architectural conversation.

WordPress Solved Real Problems

One reason WordPress became so dominant is because it solved real operational problems.

It gave people:

publishing tools
extensibility
business flexibility
ownership
affordability
ecosystem access

Small businesses could suddenly operate online.

Creators could publish independently.

Organizations could manage content without engineering teams.

That operational empowerment mattered.

And I think it still matters today.

But Modern Operational Complexity Changed the Landscape

At the same time, the operational demands of modern software increased dramatically.

Today systems often require:

APIs
distributed services
deployment orchestration
observability
infrastructure automation
scaling strategies
containerized environments
hybrid rendering
edge delivery
workflow systems
real-time communication

Modern systems increasingly behave more like operational ecosystems than isolated applications.

And that changes architectural priorities significantly.

This Is Where KiwiPress Started Becoming Interesting to Me

The more I thought about these ideas, the more I became interested in a question like this:

“What would happen if a WordPress-inspired ecosystem was designed around operational clarity from the beginning?”

Not just:

themes
plugins
pages

But:

contracts
pipelines
deployment awareness
observable systems
infrastructure portability
modular runtime behavior
blueprint-driven architecture

That eventually became part of the conceptual foundation behind KiwiPress.

Why PHP Still Makes Sense

Ironically, one thing this exploration made me appreciate more is how practical PHP still is for many operational scenarios.

PHP remains:

widely deployable
accessible
inexpensive to host
deeply supported
operationally mature

For millions of businesses, those advantages matter far more than whether a stack feels trendy on social media.

Operational simplicity is incredibly valuable.

Especially for:

small businesses
creators
agencies
organizations without massive engineering departments

I think developers sometimes underestimate that.

I’m More Interested in Operational Evolution Than Rewrites

One thing I increasingly dislike in modern software culture is the obsession with rewriting everything constantly.

Especially when existing ecosystems already solved meaningful operational problems.

I think there’s often more value in:

evolving architecture
improving operational clarity
modernizing infrastructure assumptions
introducing better system boundaries
improving extensibility models

than simply discarding ecosystems entirely.

That’s part of why KiwiPress interests me architecturally.

Not as:

“start over from zero.”

But as:

“explore how operational systems can evolve.”

Hooks vs Pipelines Changed My Thinking

One thing that influenced me heavily was thinking about the difference between:

flexible injection systems
observable operational pipelines

The WordPress hook ecosystem is incredibly powerful.

But modern operational systems increasingly benefit from:

predictable execution flow
observable stages
explicit contracts
infrastructure-aware behavior

That doesn’t mean hooks are “wrong.”

It just means modern operational complexity increasingly rewards explicit systems.

That idea became foundational in how I think about:

WebEngine
Seltzer
Nectarine
KiwiPress

and the broader CitrusWorx ecosystem.

I Think CMS Platforms Are Becoming Operational Platforms

One thing I keep coming back to is this:

The CMS is no longer just a publishing tool.

Modern platforms increasingly need to think about:

deployment
infrastructure
observability
scaling
workflows
integrations
portability
lifecycle management

In other words:
the operational layer is becoming just as important as the content layer.

That’s a major architectural shift.

And I think it changes how systems should be designed moving forward.

Why Blueprint Thinking Matters Here

One thing I’m especially interested in is how operational blueprints could integrate into systems like KiwiPress.

Not just:

themes
templates

But operational systems like:

restaurants
creator businesses
memberships
online stores
service companies
churches
educational platforms

Systems where:

workflows
permissions
infrastructure
deployment
operational states

are already thoughtfully modeled.

That’s a much more interesting abstraction layer to me than simply generating pages.

AI Makes Operational Architecture More Important

Ironically, I think AI strengthens the importance of structured operational architecture.

Because AI can generate implementation quickly.

But generated systems still require:

boundaries
contracts
maintainability
observability
predictable runtime behavior

Without architectural clarity, rapid generation simply creates rapid complexity.

That’s one reason I’ve become increasingly interested in explicit operational systems.

The Future Probably Isn’t “One Stack”

I don’t think the future of web architecture belongs to:

one framework
one runtime
one ecosystem
one deployment model

I think the future becomes increasingly:

hybrid
composable
operationally aware
infrastructure-aware
contract-driven

That’s ultimately the direction I’m exploring with:

WebEngine
KiwiPress
GrapeVine
Nectarine
Citrode

Not because I think I have all the answers.

But because I think these architectural questions are worth exploring deeply.

Final Thoughts

WordPress mattered because it empowered people operationally.

And honestly, I think that lesson still matters enormously today.

The interesting question now isn’t:

“Should older ecosystems survive?”

It’s:

“How should operational systems evolve as the internet becomes more complex?”

That’s the question I keep exploring with KiwiPress.

Not as a rejection of WordPress.

But as an architectural continuation of ideas that helped shape the modern web in the first place.

What Would WordPress Look Like If It Were Designed Today?

Drew Marshall — Mon, 25 May 2026 16:30:00 +0000

WordPress was created during a very different era of the web.

An era where:

monolithic servers were normal
PHP applications lived directly on shared hosting
deployment pipelines were rare
APIs weren’t central to architecture
frontend and backend separation was uncommon
infrastructure complexity was dramatically lower

And despite that, WordPress grew into one of the most important platforms in web history.

That alone is impressive.

But lately I’ve been asking myself a different question:

“What would WordPress look like if it were designed around modern operational systems thinking?”

Not as a criticism of WordPress.

As an architectural thought experiment.

Because the web changed dramatically.

And modern systems operate very differently now.

The CMS Is No Longer the Entire System

One of the biggest changes in modern web architecture is that the CMS is rarely the entire platform anymore.

Today systems often include:

APIs
frontend runtimes
deployment pipelines
authentication providers
CDN layers
serverless functions
edge infrastructure
containers
analytics services
workflow systems
observability tooling
external integrations

The “website” became an operational ecosystem.

That changes what platforms need to optimize for.

WordPress Was Built Around Publishing First

And honestly?
That made sense.

Publishing was the problem.

WordPress excelled at:

content management
themes
plugins
extensibility
accessibility
business usability

Those strengths are still valuable today.

But modern systems increasingly need to think beyond:

“How do we publish content?”

Now platforms also need to think about:

deployment
scalability
infrastructure
observability
portability
runtime orchestration
operational workflows
API interoperability
lifecycle management

That’s a much larger problem space.

I Think APIs Would Be Foundational

If WordPress were designed today, I think APIs would likely exist much closer to the center of the architecture instead of being layered on later.

Not just REST endpoints.

But contract-aware operational systems.

Systems where:

plugins expose contracts
modules expose capabilities
services communicate predictably
workflows become composable
infrastructure becomes observable

In many ways, modern systems increasingly behave less like isolated websites and more like distributed operational runtimes.

Infrastructure Awareness Would Matter Much More

One thing I think modern platforms increasingly need is infrastructure awareness.

Historically, many CMS systems assumed:

a server exists
PHP executes
MySQL stores data
files exist locally

Modern infrastructure is far more dynamic now.

Applications may run across:

containers
Kubernetes clusters
serverless environments
edge runtimes
distributed storage systems
multi-cloud architectures

That changes deployment assumptions dramatically.

A modern operational platform likely needs to understand infrastructure as part of the system itself.

Not as an afterthought.

Deployment Would Probably Be a Core Feature

One thing I find interesting is how disconnected deployment still feels from many traditional CMS ecosystems.

Developers often stitch together:

CI/CD pipelines
hosting providers
CDN layers
environment systems
staging workflows
infrastructure tooling

outside the CMS itself.

But deployment is operational behavior.

And operational behavior increasingly matters just as much as publishing workflows.

If WordPress were designed today, I suspect deployment awareness would exist much closer to the core architecture.

Plugins Might Look More Like Contracts

The WordPress plugin ecosystem was revolutionary.

But I also think modern systems could benefit from stronger operational boundaries.

For example:

explicit contracts
versioned capabilities
typed integrations
predictable extension points
observable execution pipelines

One thing I’ve been thinking about heavily is:

“What if extensibility prioritized operational clarity as much as flexibility?”

Because flexibility without visibility can become difficult to maintain at scale.

Especially in large ecosystems.

Hooks Made Sense — But Pipelines Are Interesting

The WordPress hook system is one of the reasons WordPress became so adaptable.

It allowed developers to inject functionality almost anywhere.

That flexibility was incredibly powerful.

But modern operational systems are also becoming increasingly interested in:

pipelines
stages
explicit execution flow
observable runtime behavior

Not because hooks are “bad.”

But because predictable flow becomes increasingly valuable as systems grow more complex.

Especially when:

teams scale
infrastructure scales
integrations multiply
operational risk increases

Headless Probably Wouldn’t Be “Separate”

One interesting thing about modern architecture is that “headless” increasingly feels less like a special mode and more like a normal operational capability.

If WordPress were designed today, I suspect:

APIs
frontend separation
hybrid rendering
traditional rendering
operational workflows

would likely exist as first-class architectural concepts from the beginning.

Not bolt-on features.

The Real Challenge Is Operational Complexity

I actually don’t think the biggest challenge facing modern platforms is frontend rendering anymore.

I think it’s operational complexity.

Because modern systems increasingly require:

deployment orchestration
scaling strategies
observability
infrastructure portability
service interoperability
lifecycle management
security boundaries
runtime predictability

That’s where a lot of my current architectural interests come from with projects like:

WebEngine
KiwiPress
Nectarine
GrapeVine
Citrode

Not trying to “replace WordPress.”

Trying to explore what operationally-aware systems could look like moving forward.

I Think WordPress Still Has Important Lessons

Despite all of this, I think modern developers sometimes underestimate how many lessons WordPress still teaches extremely well.

Things like:

extensibility matters
accessibility matters
operational usability matters
ecosystems matter
community matters
lowering barriers matters

Those lessons are still incredibly relevant.

Even if the infrastructure landscape evolved dramatically.

The Future Probably Looks Hybrid

I don’t think the future is:

purely monolithic
purely headless
purely AI-generated
purely SaaS-driven

I think the future likely becomes increasingly hybrid.

Platforms that combine:

operational awareness
modular architecture
infrastructure portability
scalable deployment
strong publishing systems
composable workflows
runtime observability

And honestly, I think that’s a fascinating direction to explore.

Final Thoughts

WordPress was built for a different era of the internet.

But many of its core ideas were powerful enough to survive enormous technological shifts.

That’s worth paying attention to.

The interesting question now isn’t:

“Should WordPress exist?”

It’s:

“What architectural ideas should the next generation of operational web systems build upon?”

Because the web changed.

Infrastructure changed.

Businesses changed.

Operational complexity changed.

And the systems we build moving forward will likely need to reflect that reality.

Why I Think WordPress Still Matters

Drew Marshall — Sun, 24 May 2026 17:00:00 +0000

In tech circles, it’s become pretty common to dismiss WordPress.

People often talk about it like it’s outdated.
Old.
Legacy.
Something to “move beyond.”

And while I understand some of the criticisms, I honestly think a lot of developers forget what WordPress actually accomplished.

Because long before:

creator platforms
no-code builders
modern SaaS ecosystems
headless CMS products
AI website generators

WordPress helped millions of people publish on the web.

Not developers.

People.

Small businesses.
Churches.
Restaurants.
Creators.
Freelancers.
Families.
Communities.

That mattered.

And honestly, I still think it matters today.

WordPress Democratized More Than Publishing

I think one reason WordPress became so influential is because it lowered the barrier to participation on the internet.

Before platforms became heavily centralized, WordPress allowed people to:

own websites
run businesses
publish ideas
create communities
sell products
build brands

without needing massive engineering teams.

That changed the internet permanently.

A local business could suddenly compete online.

An independent creator could suddenly publish globally.

A small organization could suddenly operate like a much larger one.

That’s not a small contribution to the web.

Developers Sometimes Forget the Operational Reality

One thing I’ve noticed over the years is that developers often evaluate platforms very differently than businesses do.

Developers tend to focus on:

framework elegance
architecture purity
performance benchmarks
modern tooling
ecosystem trends

Businesses usually focus on:

reliability
operational simplicity
affordability
maintainability
flexibility
content workflows
getting things done

WordPress succeeded because it solved real operational problems for real people.

Not because it was architecturally perfect.

And honestly, very few systems operating at WordPress scale are architecturally “perfect.”

The Plugin Ecosystem Changed the Web

I also think people underestimate how revolutionary the plugin ecosystem really was.

The idea that businesses could extend functionality without rebuilding entire systems from scratch was incredibly powerful.

Need:

eCommerce?
memberships?
forms?
SEO?
bookings?
forums?
analytics?
custom workflows?

Install functionality.
Extend the system.
Adapt the platform to the business.

That level of extensibility helped WordPress evolve far beyond blogging.

It became operational infrastructure for a massive portion of the internet.

But the Web Changed

At the same time, I also think the operational requirements of the web evolved dramatically.

Modern systems now involve:

APIs
distributed infrastructure
containers
edge networks
CI/CD pipelines
observability
headless architectures
multi-service ecosystems
real-time systems
infrastructure automation

The internet became operationally more complex.

And naturally, that creates pressure on older architectural models.

Especially systems originally designed during a very different era of the web.

This Isn’t About “WordPress vs Modern Development”

One thing I want to make clear is:
I don’t see this as:

“old vs new.”

I think WordPress still has enormous strengths:

accessibility
ecosystem maturity
publishing workflows
operational flexibility
community support
business usability

But I also think there’s value in exploring:

modern runtime architecture
contract-driven systems
infrastructure-aware platforms
deployment-aware CMS ecosystems
observable operational workflows
modular infrastructure

Not to erase what WordPress built.

But to evolve ideas around how operational systems can function moving forward.

WordPress Taught the Industry Something Important

I actually think WordPress proved something many developers still underestimate:

Businesses care deeply about operational empowerment.

People don’t just want:

frameworks
codebases
tooling

They want:

systems that help them operate
systems they can extend
systems they can afford
systems they can manage long term

That’s one reason WordPress survived so many technology shifts.

It solved operational problems for millions of people.

And systems that solve real operational problems tend to survive longer than trend cycles.

This Is Part of Why I Started Exploring KiwiPress

A lot of my thinking around:

WebEngine
blueprint systems
operational architecture
lifecycle-aware platforms
infrastructure-aware development

eventually brought me back to WordPress in an unexpected way.

Not because I think WordPress “failed.”

But because I think there’s an interesting question worth exploring:

“What would a WordPress-inspired operational engine look like if designed around modern systems thinking?”

That question eventually became part of the foundation for KiwiPress.

Not as:

“the replacement for WordPress.”

But as an exploration of:

operational architecture
deployment-aware systems
contracts
pipelines
infrastructure
modular runtime behavior
long-term maintainability

while still respecting many of the things WordPress got incredibly right.

The Future Might Be Hybrid

I don’t think the future of the web is purely:

monolithic
headless
SaaS-driven
no-code
AI-generated

I actually think the future will likely be hybrid.

Systems that combine:

operational flexibility
strong publishing workflows
infrastructure awareness
portability
modular architecture
scalable deployment
composable systems

And honestly, I think WordPress still has an important place in that conversation.

Final Thoughts

WordPress isn’t perfect.

No platform operating at that scale is.

But I think dismissing WordPress entirely misses something important about the history of the web.

It empowered millions of people to participate online.

It enabled businesses.
Creators.
Communities.
Organizations.

And in many ways, it helped shape the modern internet long before many current platforms existed.

That deserves respect.

The interesting question now isn’t:

“Did WordPress matter?”

I think history already answered that.

The more interesting question is:

“What lessons should we carry forward as we design the next generation of operational web systems?”

Blueprints Might Be More Important Than Frameworks

Drew Marshall — Sat, 23 May 2026 17:00:00 +0000

The longer I work on software systems, the less I think most people actually want frameworks.

What they really want is outcomes.

They want:

a business
a storefront
a booking system
a restaurant platform
a creator ecosystem
a course platform
a membership site
an operational workflow

But somewhere along the way, the software industry started treating infrastructure assembly like the product itself.

Developers spend enormous amounts of time stitching together:

frameworks
authentication
databases
deployment pipelines
admin systems
permissions
integrations
analytics
workflows
infrastructure

before they can even begin solving the actual business problem.

And honestly, I think that model is starting to show its age.

Most Businesses Don’t Need “Another Stack”

A local pizzeria owner usually does not wake up thinking:

“I really hope my ordering platform uses the perfect frontend framework.”

They care about:

taking orders
tracking deliveries
managing inventory
customer retention
loyalty systems
reliability
operational simplicity

The business problem is operational.

Not technological.

But modern software development often forces people to reconstruct the operational layer from scratch every time they build something.

That’s one reason I became increasingly interested in blueprint-driven systems.

What I Mean by “Blueprints”

When I say blueprint, I don’t mean:

a template
a starter kit
a theme

I mean:

a pre-architected operational system.

Something that already understands:

workflows
permissions
business states
infrastructure patterns
scaling concerns
operational requirements
deployment structure
integrations
lifecycle management

For example:

A pizzeria blueprint might already understand:

ordering flows
“making” status
“baking” status
“out for delivery” status
inventory management
driver systems
customer notifications
analytics
payment workflows

Not just page layouts.

Operational behavior.

Frameworks Usually Start Too Low in the Stack

Most frameworks start by helping developers build components and routes.

That’s useful.

But eventually I started wondering:

“Why are we rebuilding the operational layer every time?”

Because many industries already have recognizable patterns.

Restaurants have patterns.

Creator businesses have patterns.

Churches have patterns.

Retail stores have patterns.

Course platforms have patterns.

Print-on-demand businesses have patterns.

Yet software teams repeatedly reconstruct these systems from scratch around generic tooling.

That creates enormous duplication across the industry.

Businesses Are Really Collections of Flows

One thing that changed my thinking significantly was realizing that businesses are mostly operational pipelines.

Orders move through states.

Content moves through states.

Customers move through states.

Products move through states.

Teams move through states.

Infrastructure moves through states.

Once you see that, software architecture starts looking very different.

You stop thinking:

“How do we build pages?”

And start thinking:

“How do we model operational movement?”

That’s where blueprint thinking becomes powerful.

Blueprints Create Higher-Level Abstraction

One thing I think the industry is slowly moving toward is higher-order operational abstraction.

Not:

“generate a button”
“generate a CRUD app”

But:

“generate a business system”
“generate an operational workflow”
“generate a scalable runtime”
“generate infrastructure-aware applications”

That’s a completely different level of abstraction.

And honestly, I think it’s where AI becomes genuinely useful long-term.

Not replacing architecture.

Accelerating structured architecture.

This Is Part of Why I Built WebEngine Around Systems

A lot of these ideas heavily influenced how I think about:

WebEngine
KiwiPress
Nectarine
GrapeVine
Citrode

The goal was never:

“make another framework.”

It was:

“create repeatable operational ecosystems.”

Systems where businesses can focus more on:

execution
products
customers
workflows
creativity

instead of rebuilding infrastructure repeatedly.

The Infrastructure Layer Is Becoming the Product

One thing I think modern software increasingly proves is this:

The operational layer often matters more than the UI layer.

Because eventually businesses care deeply about:

reliability
scaling
deployment
portability
integrations
observability
lifecycle management

That’s why I think engines, platforms, and blueprint systems are becoming increasingly important.

Not because frontend no longer matters.

But because operational complexity keeps increasing.

AI Makes Blueprint Thinking Even More Important

Ironically, I think AI strengthens the case for blueprints dramatically.

Because AI can generate implementation quickly.

But implementation without structure creates chaos.

Blueprints provide:

boundaries
architecture
contracts
operational patterns
predictable flows
maintainable systems

In other words:
they give generated systems shape.

And I think that’s going to matter enormously moving forward.

I Think Developers Are Becoming Operational Architects

One thing I’ve noticed is that modern development increasingly requires developers to think beyond code itself.

Today developers often need to understand:

infrastructure
deployment
scaling
observability
security
workflows
operations
business logic
lifecycle management

That’s much closer to systems architecture than traditional app development.

And I think blueprint-driven ecosystems fit naturally into that evolution.

The Future Might Be More Composable

I don’t think the future is:

“one giant platform that controls everything.”

I actually think the future may become more composable.

Where:

engines provide runtimes
blueprints provide operational systems
adapters provide interoperability
contracts provide predictability
infrastructure remains portable

That’s a much healthier ecosystem than locking businesses into isolated black boxes.

Final Thoughts

Frameworks changed software development dramatically.

And they still matter.

But increasingly, I think the industry’s bigger challenge is no longer:

“How do we build applications?”

It’s:

“How do we build sustainable operational systems?”

Because most people aren’t trying to build frameworks.

They’re trying to build businesses.

And businesses need more than components and routes.

They need blueprints.

The Hidden Cost of “Move Fast and Break Things”

Drew Marshall — Fri, 22 May 2026 16:00:00 +0000

For a long time, the software industry rewarded speed above almost everything else.

Ship faster.
Scale faster.
Prototype faster.
Iterate faster.

And to be fair, that mindset helped create an incredible era of innovation.

A lot of amazing products probably never would have existed without teams willing to move quickly and experiment aggressively.

But over time, I think the industry accidentally normalized something dangerous:

Treating long-term maintainability like someone else’s future problem.

Speed Solves Early Problems Very Well

When you’re building something from nothing, speed matters.

You need:

validation
momentum
iteration
feedback
traction

Perfect architecture on day one is usually unrealistic.

I don’t think most developers disagree with that.

The problem starts when temporary shortcuts slowly become permanent operational realities.

Because eventually:

startups become platforms
prototypes become production systems
side projects become businesses
internal tools become critical infrastructure

And suddenly the codebase everyone rushed together six years ago is now responsible for:

customer operations
revenue flow
infrastructure
compliance
integrations
scaling
reliability

That’s where the real cost begins appearing.

Complexity Accumulates Quietly

One thing I’ve noticed is that bad architecture rarely explodes immediately.

It accumulates.

Slowly.

Almost invisibly.

At first it looks manageable:

one workaround
one patch
one duplicate system
one hidden dependency
one rushed integration

Then years later:

onboarding becomes difficult
debugging becomes painful
deployments become risky
systems become fragile
teams become slower
technical debt becomes operational debt

Eventually the system itself starts resisting change.

Not because the developers are bad.

Because complexity compounds over time.

The Industry Sometimes Confuses Motion With Progress

One thing I’ve become increasingly cautious about is how often modern development culture rewards visible activity over sustainable architecture.

There’s enormous pressure to:

constantly ship
constantly announce
constantly pivot
constantly rebuild
constantly chase trends

But sustainable systems usually aren’t built through chaos.

They’re built through:

consistency
clarity
operational thinking
maintainable architecture
disciplined iteration

A system surviving for ten years is often more impressive than a system shipping ten features in one month.

But the industry rarely celebrates that kind of engineering patience.

Operational Problems Eventually Become Human Problems

This is the part I think we underestimate the most.

Poor architecture doesn’t just affect servers.

It affects people.

Eventually:

developers burn out
teams become frustrated
businesses become dependent on fragile systems
customers lose trust
organizations become afraid to change anything

I’ve seen situations where:

simple deployments become terrifying
nobody fully understands the system anymore
critical infrastructure relies on undocumented behavior
replacing one feature risks breaking five others

At that point, the problem is no longer technical.

It’s organizational.

AI Is About to Amplify This Problem

I actually think AI makes sustainable architecture more important, not less.

Because AI is extremely good at producing:

implementation
boilerplate
repetitive patterns
rapid iteration

But speed without structure can generate enormous amounts of hidden complexity very quickly.

Generated code still needs:

boundaries
contracts
operational clarity
maintainability
observability
lifecycle planning

Otherwise we risk creating systems that grow faster than humans can realistically understand them.

That’s not acceleration.

That’s architectural debt at machine speed.

“Move Fast” Isn’t the Real Problem

To be clear:
I don’t think speed itself is bad.

Some of the best engineering breakthroughs come from experimentation and momentum.

The real issue is when:

architecture becomes an afterthought
operational clarity disappears
maintainability stops mattering
systems are optimized only for immediate output

Because eventually every fast-moving system slows down.

The question is whether the architecture supports evolution when that happens.

Why I’ve Become More Interested in Explicit Systems

The longer I work on systems like:

WebEngine
KiwiPress
Nectarine
Seltzer
Juice

the more I care about:

explicit contracts
predictable pipelines
observable systems
modular architecture
lifecycle-aware infrastructure
operational readability

Not because those ideas are trendy.

Because systems eventually outlive the excitement phase.

And when they do, maintainability becomes one of the most valuable engineering features imaginable.

Software Is Becoming Infrastructure

I think one reason this matters so much now is because software increasingly is infrastructure.

It runs:

businesses
logistics
healthcare
education
communication
finance
utilities
media
governments

We’re no longer just building experimental web pages.

We’re building operational ecosystems people depend on daily.

That changes the responsibility attached to architecture decisions.

I Think the Industry Is Slowly Shifting

Interestingly, I think we’re already starting to see signs of a shift.

More developers are talking about:

platform engineering
system design
observability
contracts
maintainability
portability
infrastructure ownership

Not just:

shipping faster
rewriting everything yearly
chasing frameworks endlessly

I think people are starting to realize that sustainable systems matter.

Especially as applications become larger and more interconnected.

Final Thoughts

I still believe experimentation matters.

I still believe iteration matters.

I still believe speed matters.

But I also think sustainable engineering deserves far more attention than it gets.

Because eventually:

every shortcut compounds
every hidden dependency matters
every unclear system creates friction
every architectural decision affects real people

And the longer software becomes part of everyday life, the more important long-term thinking becomes.

Maybe the future isn’t:

“move fast and break things.”

Maybe the future is:

“build clearly enough that things don’t have to break constantly in the first place.”

Why I Got Tired of Class-Heavy UI Code and Started Building Around Attributes

Drew Marshall — Thu, 21 May 2026 16:00:00 +0000

One thing that slowly wore me down over the years of frontend development wasn’t JavaScript.

It wasn’t components.

It wasn’t CSS itself.

It was the increasing amount of visual noise in the markup.

At some point, UI code started feeling less like structure and more like string management.

You’d open a component and see something like:

<div class="flex flex-col items-center justify-between gap-6 rounded-2xl border border-zinc-800 bg-zinc-900/50 p-8 shadow-lg backdrop-blur-md">

And while utility-first systems absolutely solve real problems, I eventually realized something:

I was spending more time parsing styling syntax than understanding the component itself.

That started bothering me.

A lot.

I Wanted the Markup to Read Like Structure Again

Over time, I became increasingly interested in making UI code feel:

readable
semantic
intentional
composable
expressive

Not just:

“technically efficient.”

That thinking eventually led me toward building Juice — an attribute-driven UI system I’ve been experimenting with as part of the broader WebEngine ecosystem.

The goal wasn’t:

“replace CSS.”

And it wasn’t:

“reinvent HTML.”

It was:

“make components readable again.”

Here’s an Example

This is a pricing section component written using Juice-style attributes:

<section type="pricing" id="pricing" paddingY="roomy">
    <div container>
        <div section-header>
            <h2>Pricing That Scales With You</h2>
            <p>Start free and grow at your own pace. No hidden fees, no surprises.</p>
        </div>

        <div grid="3x1" gap="comfortable">
            <div card="pricing">

Even before reading the implementation details, the structure is understandable.

You can visually identify:

sections
layout intent
spacing
grouping
component purpose

without parsing long utility chains.

That distinction matters to me.

Because I think frontend architecture should optimize for human readability just as much as browser rendering.

The Problem Wasn’t Utility Classes

To be clear:
utility-first frameworks solve legitimate problems.

They:

improve consistency
reduce CSS sprawl
accelerate development
encourage reusable spacing systems

I completely understand why they became popular.

But after building larger systems, I noticed a tradeoff emerging.

The markup itself became increasingly overloaded with implementation detail.

Eventually components started feeling visually dense.

Not structurally expressive.

Structure and Styling Started Blending Together

One thing I kept asking myself was:

“Can I quickly understand the purpose of this component?”

Not:

“Can I understand the CSS?”

But:

“Can I understand the architecture?”

That’s a different question entirely.

Because when UI systems scale, readability becomes incredibly important.

Especially when:

teams grow
components evolve
systems become long-lived
onboarding matters
design systems expand

The easier a component is to mentally parse, the easier it becomes to maintain over time.

I Wanted Styling to Feel More Declarative

One thing I love about attributes is that they naturally feel declarative.

Instead of:

<div class="pt-24 pb-24">

You can express intent more directly:

<section paddingY="roomy">

Now the component describes meaning instead of implementation detail.

That subtle difference changes how the code feels to work with.

Components Start Reading More Like Systems

As I kept experimenting with the approach, I noticed something interesting.

The markup started feeling less like:

“a pile of styled divs”

and more like:

“a structured UI language.”

For example:

<div card="pricing" featured>

immediately communicates:

this is a card
it’s specifically a pricing card
it has a featured state

without needing:

multiple utility chains
conditional class merging
long style abstractions

The component becomes easier to reason about visually.

The Goal Was Never “Less CSS”

Ironically, this approach actually made me think more about CSS architecture.

Because now the system itself needs:

scalable tokens
predictable patterns
strong conventions
reusable layout primitives
intentional naming

The complexity doesn’t disappear.

It shifts downward into the design system layer instead of living directly in every component.

And personally, I think that’s a healthier separation of concerns.

I Think Modern UI Has a Readability Problem

One thing I rarely hear discussed is how mentally exhausting frontend markup can become at scale.

Not because developers are bad.

Not because frameworks are bad.

But because modern UI systems often optimize heavily for:

flexibility
speed
composability

while readability becomes secondary.

That tradeoff accumulates over time.

Especially in large applications.

This Isn’t About “Winning” Frontend Development

I don’t think there’s one perfect way to build UI.

And I’m not interested in framework tribalism.

Honestly, most frontend ecosystems have good ideas worth learning from.

This is more about exploring:

readability
semantic structure
maintainability
expressive architecture

and asking:

“What should UI systems feel like five years from now?”

Because I don’t think frontend architecture is finished evolving yet.

Not even close.

Why This Matters to Me

The longer I work on systems like:

WebEngine
KiwiPress
Juice
Sig.js

the more I care about creating software that:

scales operationally
stays understandable
remains expressive
reduces hidden complexity

I want components to feel approachable.

I want systems to feel intentional.

And I want markup to communicate structure clearly again.

Final Thoughts

I still appreciate utility-first systems.

I still appreciate modern frontend tooling.

But personally, I’ve found myself increasingly drawn toward UI architectures that emphasize:

intent
structure
readability
semantics
declarative design

Because eventually frontend code stops being just implementation.

It becomes part of the language teams use to communicate architecture to each other.

And I think that language matters more than we sometimes realize.