DEV Community: Drew Marshall

Every Framework Eventually Becomes a Language

Drew Marshall — Sun, 21 Jun 2026 17:00:00 +0000

When most developers think about frameworks, they think about features.

Routing.

Components.

State management.

Authentication.

Data access.

Build tools.

All important things.

But I've started to believe that the longer a framework survives, the less important its features become.

Instead, something else emerges.

A language.

Not a programming language.

A language of ideas.

A language of patterns.

A language of intent.

And once that language forms, it often becomes more valuable than the framework itself.

Frameworks Start As Tools

Most frameworks begin life as solutions to technical problems.

How do we route requests?

How do we manage state?

How do we organize code?

How do we build interfaces?

The early focus is almost entirely mechanical.

The framework exists to make something easier.

The language hasn't formed yet.

At this stage, the framework is mostly a collection of features.

Then Patterns Begin To Appear

Something interesting happens once enough people start using a framework.

Certain approaches become common.

Certain solutions become preferred.

Certain conventions emerge.

Developers start recognizing patterns.

The framework begins teaching its users how to think.

Not just how to code.

How to approach problems.

This is where the framework starts becoming a language.

Good Frameworks Teach More Than APIs

Think about the frameworks and tools that have survived for years.

People don't just learn the APIs.

They learn the philosophy.

They learn the conventions.

They learn the assumptions.

Eventually they start speaking the language of the framework.

You can often tell when someone has spent years working within a particular ecosystem.

Not because of the code they write.

Because of the way they think.

The framework has shaped their mental model.

The Language Matters More Than The Syntax

Most developers assume the syntax is the important part.

I don't think it is.

Syntax changes.

Versions change.

Features change.

The underlying language tends to remain.

The language is what allows developers to communicate ideas efficiently.

Once a shared vocabulary exists, complexity starts shrinking.

A single term can communicate an entire concept.

A single convention can communicate an entire workflow.

The language becomes a form of compression.

Documentation Is Really Language Training

This realization changed how I think about documentation.

Documentation isn't just explaining APIs.

It's teaching vocabulary.

It's teaching concepts.

It's teaching patterns.

Good documentation helps users understand how the framework thinks.

Bad documentation simply lists features.

The difference is significant.

One teaches understanding.

The other teaches memorization.

Real Projects Shape The Language

One reason I believe every library needs a real project is because real projects shape the language.

Features can be designed in isolation.

Languages cannot.

Languages emerge from use.

They emerge from friction.

They emerge from repeated interactions with real problems.

The most useful concepts survive.

The awkward concepts disappear.

Over time the language becomes more refined.

More expressive.

More coherent.

Every Successful System Develops Vocabulary

This isn't unique to software.

Businesses develop language.

Trades develop language.

Music develops language.

Architecture develops language.

Communities develop language.

The larger and more complex a system becomes, the more important shared vocabulary becomes.

Without a common language, collaboration becomes difficult.

With one, entire ideas can be communicated in a few words.

Why This Matters To Builders

The longer I build software, the less interested I become in adding features for the sake of features.

Instead, I find myself asking different questions.

Does this fit the language?

Does this reinforce the philosophy?

Does this make the system easier to understand?

Does this create a more coherent experience?

Those questions often lead to better decisions than simply asking what feature should come next.

Final Thoughts

Most frameworks begin as tools.

Some evolve into ecosystems.

The most successful ones eventually become languages.

They create vocabulary.

They create conventions.

They create ways of thinking.

The APIs matter.

The features matter.

But over time, the language becomes the thing people truly adopt.

And once that happens, the framework is no longer just software.

It's a way of expressing ideas.

Why Most Software Is Built Backwards

Drew Marshall — Sat, 20 Jun 2026 17:00:00 +0000

One of the more uncomfortable conclusions I've reached over the years is that a lot of software is built backwards.

Not because developers are bad.

Not because teams are incompetent.

Because we're often rewarded for the wrong things.

Features get attention.

Architecture doesn't.

Announcements get attention.

Documentation doesn't.

New capabilities get attention.

Maintenance doesn't.

As a result, many projects begin with the visible parts of the product and only later discover they neglected the foundation.

We Start With Features

The typical software conversation goes something like this:

What features should we build?

What should the dashboard look like?

What integrations should we support?

What can we put on the roadmap?

What can we announce next?

These aren't bad questions.

They're just usually asked too early.

Because before discussing features, we should probably understand the system those features will live inside.

The Foundation Determines The Experience

Imagine building a house.

Most people don't start by choosing paint colors.

They start with:

The foundation
The structure
The plumbing
The electrical system

The visible details matter.

But they depend entirely on the invisible systems beneath them.

Software isn't much different.

The user interface is visible.

The architecture isn't.

The application is visible.

The workflows aren't.

The features are visible.

The systems supporting them aren't.

Yet those systems often determine whether the software succeeds.

Products Are Built. Systems Are Designed.

This is one reason I've become increasingly interested in systems thinking.

Features are built.

Systems are designed.

Features solve individual problems.

Systems solve categories of problems.

Features create functionality.

Systems create consistency.

When software focuses entirely on features, complexity tends to accumulate.

When software focuses on systems, complexity tends to organize itself.

Documentation Reveals The Truth

One thing I've noticed is that documentation exposes whether a system was designed or assembled.

A well-designed system tends to produce clear documentation.

A poorly designed system often requires increasingly complicated explanations.

If a workflow requires several pages of documentation to explain, the issue might not be the documentation.

It might be the workflow.

Documentation acts like a mirror.

It reveals architectural decisions that would otherwise remain hidden.

The Real Product Is Often Invisible

The longer I build software, the more I realize that users rarely experience individual features.

They experience systems.

Users don't experience:

Authentication
APIs
Database queries
Deployment pipelines

They experience:

Reliability
Speed
Simplicity
Confidence

Those experiences emerge from the system as a whole.

Not from any single feature.

Why Builders Fall Into This Trap

The reason software often gets built backwards is understandable.

Features are easy to demonstrate.

Systems are harder to showcase.

A feature fits in a screenshot.

A system doesn't.

A feature can be announced.

A system is usually invisible.

As builders, we naturally gravitate toward the visible work because it's easier to communicate.

The challenge is that invisible work often creates the most value.

Start With The System

I've started approaching projects differently.

Instead of asking:

"What features should this have?"

I try to ask:

"What system am I building?"

Once that becomes clear, many feature decisions become obvious.

The system creates constraints.

The system creates priorities.

The system creates direction.

Features become easier because the foundation already exists.

Final Thoughts

I don't think features are unimportant.

Far from it.

Users ultimately interact with features.

But features are only one layer of a larger structure.

The most successful products I've used weren't successful because they had the most features.

They were successful because the underlying system was thoughtfully designed.

The software felt coherent.

The workflows felt natural.

The experience felt intentional.

That's why I've started believing that many software projects are built backwards.

We start with the visible pieces.

Then scramble to create the system underneath them.

Maybe we should reverse that process.

Build the system first.

Then let the features emerge from it.

Documentation Is a Feature

Drew Marshall — Fri, 19 Jun 2026 16:00:00 +0000

One of the biggest mindset shifts I've had as a builder is realizing that documentation isn't separate from the product.

Documentation is the product.

Or at least part of it.

As developers, we often treat documentation as something that happens after the software is finished.

Build the feature.

Test the feature.

Ship the feature.

Document the feature.

Unfortunately, that's not how users experience software.

Users don't experience the code.

They experience the interface.

The workflows.

The onboarding.

The examples.

The documentation.

To them, documentation is not an accessory.

It's a feature.

The Curse Of Familiarity

One of the reasons documentation gets neglected is because creators already understand the product.

We know why decisions were made.

We know how the API works.

We know the intended workflow.

We know the shortcuts.

We know the assumptions.

The user doesn't.

What feels obvious to the author often feels mysterious to everyone else.

That's why documentation is difficult.

You're trying to explain something you've become too familiar with.

Every Question Is Documentation Debt

One way I've started thinking about documentation is this:

Every repeated question represents documentation debt.

If multiple people ask the same thing:

The product may be confusing.
The documentation may be incomplete.
Or both.

Sometimes the answer is improving the API.

Sometimes the answer is improving the docs.

Most of the time, it's a little of both.

Great Documentation Reduces Friction

Good documentation isn't about explaining every possible feature.

It's about reducing friction.

The user should be able to answer questions like:

What is this?
Why would I use it?
How do I get started?
What's the recommended approach?
What's the simplest example?

As quickly as possible.

The goal isn't completeness.

The goal is momentum.

The Best Documentation Teaches Philosophy

The most memorable documentation I've encountered doesn't just explain APIs.

It explains thinking.

It teaches conventions.

It teaches patterns.

It teaches intent.

When a framework explains why it works the way it does, developers become more effective users.

The documentation becomes more than a reference.

It becomes a guide.

Documentation Is Infrastructure

One reason documentation often feels less exciting than features is because it's infrastructure.

Nobody shares screenshots of documentation systems.

Nobody announces documentation rewrites with the same excitement as major feature releases.

But documentation quietly determines:

Adoption
Onboarding
Support load
Community growth
Developer experience

Its impact is difficult to see directly.

Its absence is impossible to ignore.

Future You Is Also A User

One lesson I've learned repeatedly is that documentation isn't only for other people.

It's for future you.

Months later.

A year later.

After you've forgotten the details.

Good documentation preserves knowledge.

It captures decisions.

It records patterns.

It protects you from having to rediscover the same answers over and over again.

Building Better Software

The longer I build software, the more I realize that product quality and documentation quality are deeply connected.

Confusing software requires more documentation.

Clear software requires less.

Good documentation reveals bad design.

Bad design creates documentation work.

The two constantly influence one another.

Which is why I no longer think of documentation as something that happens after the product.

It's part of the product.

It always was.

Final Thoughts

One of the easiest ways to improve a project is to improve its documentation.

Not because better docs hide weaknesses.

Because better docs expose them.

Documentation forces clarity.

Clarity improves design.

Improved design improves the product.

That's why I've started treating documentation as a feature rather than an afterthought.

Because from the user's perspective, it already is.

Why Every Library Needs a Real Project

Drew Marshall — Thu, 18 Jun 2026 14:01:00 +0000

One of the easiest traps to fall into as a library author is believing that examples are enough.

They’re not.

Examples prove that a feature works.

Real projects prove that a library works.

Those are very different things.

Over the last few months, I’ve spent a lot of time thinking about frameworks, APIs, design systems, and developer tooling. Like many developers, I’ve built countless demo applications to test ideas.

A sample website.

A sample API.

A sample component.

A sample workflow.

Everything looked great.

Until I started building real applications.

That’s when the interesting lessons began.

Demo Projects Are Controlled Environments

Most examples are designed to succeed.

They showcase the happy path.

The ideal workflow.

The intended use case.

And there’s nothing wrong with that.

Examples are important.

Documentation is important.

Tutorials are important.

But they’re also controlled environments.

The developer already knows what the outcome should be.

The architecture is simple.

The requirements are predictable.

The scope is limited.

Real projects are none of those things.

Real Projects Create Real Pressure

The moment a library is used for an actual project, the rules change.

Suddenly you aren’t building a demonstration.

You’re trying to solve a problem.

You have deadlines.

You have changing requirements.

You have content to manage.

You have layouts that don’t quite fit.

You have edge cases.

You have mistakes.

And that’s where a library starts revealing its strengths and weaknesses.

Not in the demo.

In the pressure.

Reality Exposes Bad Assumptions

One of the most valuable things a real project does is expose assumptions.

Assumptions that seemed perfectly reasonable while designing the library.

Assumptions that looked elegant on paper.

Assumptions that made sense during development.

Then reality arrives.

A workflow feels awkward.

A configuration feels repetitive.

A component requires too much setup.

An API doesn’t feel natural anymore.

The problem isn’t that the design was wrong.

The problem is that it hadn’t been tested against reality yet.

Framework Authors Need To Become Users

I think one of the best things a framework author can do is become a customer of their own software.

Not occasionally.

Not for demos.

Every day.

Build websites with it.

Build applications with it.

Build businesses with it.

Depend on it.

Because the moment you depend on your own software, your perspective changes.

You stop thinking like a framework author.

You start thinking like a user.

And users care about very different things.

Users care about friction.

Users care about clarity.

Users care about getting work done.

Features Stop Mattering As Much

One surprising lesson is that many feature discussions disappear once you’re building something real.

The conversation changes from:

“What features should we add next?”

To:

“Why does this workflow feel awkward?”

Or:

“Why did this take longer than expected?”

Or:

“Why am I repeating myself?”

Those questions often lead to far more valuable improvements than adding another feature.

Real Projects Generate Better Ideas

I’ve found that some of the best ideas don’t come from brainstorming.

They come from building.

You’re working on a real project.

You encounter friction.

You solve the friction.

A pattern emerges.

An abstraction emerges.

A better API emerges.

Many of the strongest improvements I’ve made to software projects didn’t come from planning sessions.

They came from trying to get actual work done.

The project taught the lesson.

Every Library Needs A Home

This is one reason I believe every library should have a real project associated with it.

Not as a marketing example.

As a proving ground.

Something that forces the library to solve real problems.

Something that depends on the library succeeding.

Something that exposes weaknesses before users do.

The goal isn’t to prove the library is perfect.

The goal is to create an environment where the library can improve.

Building The Ecosystem

As I continue working on KiwiEngine and the surrounding ecosystem, one thing is becoming increasingly clear.

The websites.

The documentation.

The applications.

The tools.

They’re not distractions from the framework.

They’re part of the framework.

Every real project creates feedback.

Every real project exposes friction.

Every real project improves the underlying system.

That’s why I believe every library needs a real project.

Not because it validates the library.

Because it teaches the library what it still needs to become.

The Difference Between a Product and Infrastructure

Drew Marshall — Tue, 16 Jun 2026 17:30:00 +0000

One of the most interesting realizations I've had while building software is that products and infrastructure are not the same thing.

At first, that sounds obvious.

Of course they're different.

But I think many builders—including myself—confuse the two more often than we realize.

Products Solve Immediate Problems

Products are what users see.

They're the websites.

The applications.

The dashboards.

The storefronts.

The experiences people interact with directly.

A product exists to solve a specific problem.

Need a blog?

Use a CMS.

Need to manage projects?

Use a project management tool.

Need an online store?

Use an ecommerce platform.

Products are tangible.

They're visible.

They're easy to explain.

Infrastructure Enables Products

Infrastructure is different.

Infrastructure exists so products can exist.

Users rarely think about infrastructure.

In fact, the best infrastructure is often invisible.

Nobody gets excited about electrical wiring when they buy a house.

Nobody buys a car because of the manufacturing equipment that produced it.

Nobody visits a website because of its deployment pipeline.

Yet all of those things are essential.

Infrastructure creates the conditions that make products possible.

The Builder's Trap

One trap I've noticed is that builders often focus entirely on products.

The product gets all the attention.

The product gets all the marketing.

The product gets all the praise.

Meanwhile, the infrastructure quietly determines whether the product succeeds.

Documentation.

Tooling.

Architecture.

Testing.

Deployment.

Workflows.

Contracts.

Design systems.

These things rarely appear in screenshots.

But they determine how sustainable a product becomes.

Why This Matters To Framework Authors

This distinction became much clearer to me while working on KiwiEngine.

Originally, I thought about modules like Juice, Seltzer, and Nectarine as products.

Today, I think about them more as infrastructure.

Their purpose isn't to be the destination.

Their purpose is to make building destinations easier.

That's a different mindset.

When you're building infrastructure, success isn't measured by how many features you have.

Success is measured by how many problems become easier to solve.

Infrastructure Compounds

One reason I've become increasingly interested in infrastructure is that it compounds.

A product solves a problem.

Infrastructure helps solve many future problems.

A design system helps every future interface.

A deployment system helps every future application.

A documentation system helps every future developer.

The value accumulates.

The investment continues paying dividends long after the original project is complete.

The Most Valuable Work Is Often Invisible

Many of the most important improvements in a project aren't visible to users.

Better architecture.

Better tooling.

Better workflows.

Better abstractions.

Better conventions.

These improvements rarely make for exciting screenshots.

But they often create more long-term value than another feature.

That's one reason infrastructure work can feel strange.

You're investing heavily in something that many people will never notice.

And that's okay.

Infrastructure isn't supposed to be the star of the show.

It's supposed to make everything else possible.

Building Both

The longer I build software, the more I realize that great products and great infrastructure need each other.

Products reveal real-world problems.

Infrastructure creates repeatable solutions.

Products generate feedback.

Infrastructure captures lessons.

Products deliver value.

Infrastructure scales value.

Neither is enough on its own.

The strongest systems have both.

Looking Beyond Software

This idea extends far beyond software.

Businesses have infrastructure.

Studios have infrastructure.

Farms have infrastructure.

Schools have infrastructure.

Every successful system eventually develops layers that support the visible work.

The mistake is assuming the visible layer is the entire system.

It rarely is.

Final Thoughts

One of the biggest shifts in my thinking has been realizing that not everything I build needs to be a product.

Sometimes the most valuable thing you can build is the infrastructure that allows future products to exist.

Products are what people see.

Infrastructure is what makes them possible.

Both matter.

But they're not the same thing.

And understanding the difference can change how you approach building entirely.

Road To KiwiEngine #17: Why Using Your Own Software Changes Everything

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

One of the most important transitions a software project can make is moving from something you build to something you depend on.

At first, that distinction sounds small.

In practice, it changes everything.

Recently, I've been spending more time building user-facing applications with KiwiEngine. Not examples. Not demos. Not test projects.

Actual applications.

The CitrusWorx website.

The KiwiPress website.

Documentation.

Tools.

Projects that people will actually use.

And something interesting started happening.

The framework stopped feeling like a project.

It started feeling like infrastructure.

Building Software Is Different Than Relying On Software

When you're building a framework, it's easy to think like a framework author.

You focus on:

Features
APIs
Architecture
Future possibilities

You imagine how people might use the system.

You try to anticipate requirements.

You try to design for flexibility.

But when you become a user of your own software, your perspective changes.

Suddenly you're no longer asking:

"What features should this have?"

You're asking:

"Why is this taking so long?"

"Why does this feel awkward?"

"Why am I repeating myself?"

"Why isn't this easier?"

The conversation shifts from theory to reality.

Every Rough Edge Becomes Visible

One thing I've learned is that software always feels smoother from the author's side.

You know the shortcuts.

You know the assumptions.

You know the workarounds.

You know what was intended.

Users don't.

And when you become a user of your own software, you start experiencing those same frustrations.

The setup process that seemed reasonable suddenly feels cumbersome.

The API that looked elegant starts feeling repetitive.

The feature you thought nobody would need suddenly becomes important.

Every rough edge becomes impossible to ignore.

That's a good thing.

Documentation Stops Being An Afterthought

One unexpected lesson has been documentation.

When you're building a framework, it's easy to postpone documentation.

You know how everything works.

You wrote it.

The documentation can wait.

Then you start building a real application.

Suddenly you're constantly asking:

"How did I design this again?"

"What's the preferred pattern?"

"How should this component work?"

Documentation stops being something for other people.

It becomes something for future you.

That realization alone changes how you think about developer experience.

Good Software Removes Friction

Lately I've been noticing areas where KiwiEngine creates friction.

Not because anything is broken.

Because I'm actually using it.

The difference matters.

When software is theoretical, friction stays hidden.

When software becomes part of your daily workflow, friction becomes obvious.

You feel every extra step.

Every unnecessary configuration.

Every confusing convention.

Every repetitive task.

And that's where some of the best improvements come from.

Not feature requests.

Not planning meetings.

Usage.

The Framework Starts Teaching You

One of the most surprising parts of this process is that the framework starts teaching its creator.

You build something.

You use it.

You discover weaknesses.

You improve it.

Then you use it again.

The feedback loop becomes incredibly short.

The project begins revealing what it wants to become.

Patterns emerge.

Better abstractions emerge.

Cleaner APIs emerge.

The framework evolves because reality is constantly testing it.

Why Internal Projects Matter

This is one reason I believe strongly in building real projects with your own tools.

Not because it proves the tools work.

Because it proves where they don't.

A hundred demos won't teach the same lessons as one real application.

A thousand example snippets won't expose the same problems as daily usage.

Real projects create real pressure.

And pressure reveals weaknesses.

That's true for software.

It's true for businesses.

It's true for systems in general.

The Shift From Project To Infrastructure

The more I work on CitrusWorx, KiwiPress, and other user-facing projects, the more I realize KiwiEngine is crossing an important threshold.

It's no longer just something I'm building.

It's becoming something I'm relying on.

That changes the standard.

Features become less important than stability.

Possibilities become less important than usability.

Architecture becomes less important than experience.

The framework stops being a science experiment.

It starts becoming infrastructure.

The Most Valuable Feedback Loop

For all the discussions about testing, analytics, and user feedback, I think one of the most valuable feedback loops is still using your own software.

Not occasionally.

Not for demos.

Daily.

Depend on it.

Build with it.

Ship with it.

Live with it.

Because once your own software becomes infrastructure, every flaw becomes visible.

And every improvement becomes meaningful.

That's where great software starts to emerge.

Not from building it.

From depending on it.

Road To KiwiEngine is a series documenting the philosophy, architecture, successes, mistakes, and lessons learned while building KiwiEngine and its ecosystem one module at a time.

The Best Abstractions Arrive Late

Drew Marshall — Sun, 14 Jun 2026 15:30:00 +0000

One of the biggest mistakes I see developers make is trying to design the perfect abstraction before they've built anything.

I've done it myself.

You sit down to design a library, framework, API, or system and immediately start thinking about every possible future use case.

What if someone needs this?

What if they need that?

What if they need five different variations?

What if they need something I haven't thought of yet?

Before long, you're designing version five of a product that doesn't even have a version one.

The problem is that most good abstractions aren't discovered through planning.

They're discovered through friction.

The Temptation To Abstract Early

As engineers, we love patterns.

The moment we repeat something twice, we start thinking about abstractions.

Sometimes that's the right instinct.

Other times it's premature.

The challenge is that before you've built enough, you don't actually know what should be abstracted.

You only know what you think should be abstracted.

Those are not always the same thing.

Many abstractions begin as educated guesses.

The best abstractions begin as observed behavior.

Real Problems Reveal Better Solutions

Recently, while working on responsive layouts, I noticed myself thinking less about CSS and more about intent.

Not because I was trying to invent something new.

Because I kept running into the same friction.

The question wasn't:

"How should this element be styled?"

The question was:

"How should this content behave?"

That subtle difference led me toward an idea like:

<div content adapt="grid" mobile="stack">

What interested me wasn't the syntax.

It was the thought process that produced it.

The abstraction didn't come from a planning document.

It came from repeatedly encountering the same problem while building.

The friction exposed the pattern.

The pattern suggested the abstraction.

Most Frameworks Start With Solutions

Many libraries begin with solutions looking for problems.

Someone creates an abstraction because it feels elegant.

Because it looks clever.

Because it theoretically covers many use cases.

Then reality arrives.

Users do things the designer never anticipated.

Requirements shift.

Edge cases appear.

The abstraction grows.

Complexity accumulates.

Eventually the abstraction becomes harder to understand than the original problem.

We've all seen it.

Sometimes we've built it.

Friction Is Honest

The reason I trust friction more than planning is because friction doesn't lie.

Friction reveals what actually hurts.

Friction reveals repetition.

Friction reveals complexity.

Friction reveals awkward workflows.

Friction reveals where developers are spending mental energy.

When the same pain appears repeatedly, that's usually a signal.

Not that a feature is needed.

That a better abstraction may exist.

The Difference Between Discovery And Invention

I've started thinking about abstractions less as inventions and more as discoveries.

The pattern already exists.

The abstraction simply gives it a name.

Good abstractions feel obvious in hindsight.

You see them and think:

"Of course."

The reason they feel obvious is because they were already present in the problem.

Someone finally noticed them.

Libraries Develop Languages

One of the most fascinating parts of building libraries is watching them develop their own vocabulary.

Not because you planned every word.

Because certain ideas keep appearing.

Certain concepts keep returning.

Certain solutions keep proving useful.

Over time, the library starts developing a language.

A language of patterns.

A language of conventions.

A language of intent.

The best parts of that language are rarely designed in isolation.

They're discovered through use.

Let The Work Teach You

I've become increasingly skeptical of designing large systems entirely from diagrams and planning sessions.

Planning matters.

Architecture matters.

Vision matters.

But eventually the work itself becomes the teacher.

You build.

You struggle.

You notice.

You refine.

Then you build again.

Every cycle reveals something new.

The abstractions that survive those cycles are often the ones worth keeping.

Build First, Abstract Second

This doesn't mean avoiding abstractions.

It means earning them.

Build the thing.

Experience the friction.

Identify the pattern.

Then create the abstraction.

Not because it looks elegant.

Not because it feels clever.

Because reality has demonstrated that it deserves to exist.

I've found that the best abstractions rarely arrive at the beginning of a project.

They arrive later.

After enough mistakes.

After enough repetition.

After enough friction.

That's why I've started believing that the best abstractions arrive late.

Not because they're delayed.

Because they've been earned.

Declarative. Imperative. Intentional.

Drew Marshall — Sat, 13 Jun 2026 18:00:00 +0000

As developers, we spend a lot of time talking about programming paradigms.

Imperative programming.

Declarative programming.

Functional programming.

Object-oriented programming.

Event-driven programming.

Over the years, we've developed countless ways to describe how software should be written.

But recently I've been wondering if we're missing something.

What if there is another layer above all of them?

What if the future isn't just declarative or imperative?

What if it's intentional?

Imperative Languages

Most developers begin with imperative programming.

Imperative code tells the computer exactly what to do.

Step by step.

Instruction by instruction.

For example:

const users = database.getUsers();
const activeUsers = users.filter(user => user.active);
activeUsers.sort(sortByName);
render(activeUsers);

The focus is on the process.

The developer describes the sequence.

Do this.

Then this.

The computer follows the instructions.

Imperative programming is powerful because it gives precise control.

But it also means the developer carries the burden of describing every step.

Declarative Languages

Declarative programming moved the conversation forward.

Instead of describing how something should happen, you describe what should happen.

SQL is a great example.

SELECT * FROM users WHERE active = true;

You aren't describing indexes.

You aren't describing loops.

You aren't describing memory allocation.

You simply describe the result you want.

The database engine determines how to achieve it.

React, HTML, CSS, infrastructure tools, and many modern frameworks have embraced this idea.

Describe the outcome.

Let the system determine the implementation.

That abstraction has made software significantly more productive.

But I don't think it is the final step.

The Problem With Declarative Systems

Even declarative systems often require us to think in implementation details.

Consider responsive design.

Many solutions look something like this:

<div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3">

This is certainly more declarative than writing raw CSS.

But we're still describing implementation.

We're still talking about columns.

We're still talking about breakpoints.

We're still talking about layout mechanics.

The system knows what we're doing.

But it doesn't necessarily know why we're doing it.

Intentional Design

This is where I think things get interesting.

Imagine instead:

<div adapt="grid">

Or:

<div adapt="grid" mobile="stack" tablet="2x1">

Now we're no longer describing CSS.

We're describing intent.

The element is communicating its desired behavior.

It should adapt.

It should reorganize itself based on context.

The system becomes responsible for determining how that adaptation happens.

The focus shifts away from implementation and toward purpose.

Describing Goals Instead Of Mechanisms

The more I think about it, the more I realize many of the systems I enjoy building move in this direction.

Take SQL.

You describe the data you want.

Take infrastructure-as-code.

You describe the infrastructure you want.

Take Nectarine.

You describe schemas, APIs, and resources.

The system generates the implementation.

Now consider layout.

What if we described the experience we want instead of the CSS we want?

What if we described content behavior instead of breakpoints?

What if we described goals instead of mechanisms?

That's not simply declarative.

That's intentional.

The Library Starts Developing A Language

One of the fascinating things about building software libraries is that eventually they develop their own language.

Not a programming language.

A design language.

A way of expressing ideas.

A vocabulary.

A philosophy.

The best libraries don't just provide features.

They teach developers how to think.

Every API decision contributes to that language.

Every naming convention contributes to that language.

Every abstraction contributes to that language.

Over time, the library begins expressing values.

Not just functionality.

Intent Over Implementation

The more systems I build, the less interested I become in implementation details leaking into every layer.

Implementation matters.

Sometimes it matters a lot.

But most developers aren't trying to express implementation.

They're trying to express intent.

They know what they want the system to accomplish.

The challenge is communicating that intent clearly.

Good abstractions reduce implementation complexity.

Great abstractions make intent obvious.

Looking Forward

I don't think imperative programming is going away.

I don't think declarative programming is going away.

Both remain incredibly useful.

But I do think software is slowly moving toward systems that understand intent.

Systems that allow us to describe goals.

Systems that translate purpose into implementation.

Systems that focus less on mechanics and more on outcomes.

Maybe that isn't a new programming paradigm.

Maybe it's simply a design philosophy.

Either way, it's a direction I find myself increasingly drawn toward.

Not because it hides complexity.

But because it lets developers focus on what they actually mean.

And sometimes meaning is more important than mechanics.

Road To KiwiEngine #16: Why KiwiEngine Is Becoming An Ecosystem

Drew Marshall — Fri, 12 Jun 2026 17:00:00 +0000

One of the questions I get occasionally is:

"Why are you building so many different projects?"

It's a fair question.

At first glance, KiwiEngine can look like a collection of unrelated tools.

There's Juice.

There's Seltzer.

There's KiwiPress.

There's Nectarine.

There's Sugar.

Then there are conversations about AI, hardware, local-first computing, contracts, and architecture.

From the outside, it can seem like a lot of different directions.

From my perspective, it's actually the opposite.

They're all moving toward the same destination.

Most People See Products

Most people look at a project and see a product.

A website.

A framework.

A library.

A tool.

A plugin.

And that's understandable because products are the things users interact with.

But when I look at technology, I tend to see ecosystems.

I don't just see a website.

I see content management.

Authentication.

Data storage.

Deployment.

Design systems.

APIs.

Monitoring.

Infrastructure.

Documentation.

Workflows.

The website is only the visible portion of a much larger machine.

Ecosystems Create Leverage

A single tool can solve a problem.

An ecosystem can solve classes of problems.

That's a distinction that has become increasingly important to me.

If I build a UI library, that's useful.

If I build a UI library that works naturally with my server framework, content platform, data layer, and deployment workflow, that's leverage.

Every component becomes more valuable because it understands the others.

This is why operating systems are powerful.

This is why game engines are powerful.

This is why successful platforms tend to outlast individual products.

The value isn't just the pieces.

The value is how the pieces work together.

Why KiwiEngine Has Multiple Projects

Each project in KiwiEngine exists because it solves a recurring problem.

Juice

Design systems and user interfaces.

Seltzer

Communication between systems.

KiwiPress

Content management.

Nectarine

Data and backend management.

Sugar

Visual composition and development.

Viewed independently, they are separate projects.

Viewed together, they're pieces of a larger platform.

Each project reduces friction for the next.

Each project strengthens the others.

Each project contributes to the ecosystem.

Building The Infrastructure First

One thing I've learned over the years is that products come and go.

Infrastructure tends to stick around.

People remember applications.

Builders remember foundations.

When I create something today, I don't just ask:

"Can I build this?"

I ask:

"Can I build ten things with this?"

That question changes everything.

It pushes me toward reusable systems.

Reusable contracts.

Reusable architecture.

Reusable workflows.

Eventually, those pieces begin to resemble infrastructure rather than individual products.

Why This Matters Beyond Software

This thinking doesn't stop at software.

It applies to hardware.

It applies to AI.

It applies to education.

It applies to business.

A ranch isn't just land.

It's fencing, water, feed, equipment, maintenance, and operations.

A recording studio isn't just microphones.

It's acoustics, instruments, software, workflows, and people.

A business isn't just products.

It's systems that consistently create value.

The same principle appears everywhere.

Healthy ecosystems outperform isolated components.

The Long-Term Vision

The goal of KiwiEngine isn't to become the biggest framework.

The goal isn't to compete with every tool on the market.

The goal is to create a coherent ecosystem that helps me build things faster, maintain them longer, and understand them more deeply.

Some people build products.

Some people build companies.

Some people build ecosystems.

The longer I work on KiwiEngine, the more I realize that's what I'm actually building.

Not a framework.

Not a library.

Not even a collection of tools.

An ecosystem.

Road To KiwiEngine #15: Why I Care More About Systems Than Features

Drew Marshall — Thu, 11 Jun 2026 16:00:00 +0000

One of the reasons I often find myself disagreeing with modern software trends is that many conversations revolve around features.

How many features does it have?

How quickly can we add more?

What can we put on the marketing page?

What can we announce next?

Features matter.

But I care far more about systems.

Because at the end of the day, people don't buy features.

They buy outcomes.

And outcomes come from systems.

The Car Analogy

One of the easiest ways to explain my thinking is with cars.

A car is made up of thousands of individual components.

An engine.

A transmission.

Suspension.

Brakes.

Fuel systems.

Electrical systems.

Cooling systems.

Sensors.

Wiring.

Each component is important.

But nobody walks into a dealership and says:

"I'd like to purchase six pistons, a transmission housing, and a fuel injector."

They buy a car.

They buy transportation.

They buy a complete system.

The individual parts only matter because they contribute to the overall experience.

The customer doesn't want to think about every moving piece.

They want to get in, turn the key, and drive.

Drivers and Mechanics

This is where I think technology often loses its way.

Users are drivers.

Engineers are mechanics.

A driver should be able to:

Start the vehicle
Fill it with fuel
Check the oil
Wash it
Perform light maintenance

That's about it.

They shouldn't need to understand combustion timing, transmission gearing, or electrical diagnostics to get to work.

The mechanic, however, lives in the details.

They tune the system.

They replace parts.

They troubleshoot failures.

They recommend upgrades.

They understand how the pieces fit together.

Technology is exactly the same in my mind.

Users should be able to focus on their goals.

Engineers should focus on the machinery.

Features Are Parts

This is where I think software conversations sometimes become backwards.

A feature is a component.

A login screen is a component.

A dashboard is a component.

A database is a component.

An API is a component.

AI integration is a component.

Individually, they're useful.

But they're not the product.

They're parts of a larger system.

The product is the experience those parts create when they work together.

The product is the journey.

The product is the outcome.

The product is the system.

Why This Matters To KiwiEngine

When I'm working on KiwiEngine, I rarely think about individual modules first.

I think about the complete system.

Juice isn't just CSS.

Seltzer isn't just a server.

KiwiPress isn't just WordPress integration.

Sugar isn't just a visual builder.

Nectarine isn't just data management.

Each one solves a specific problem.

But together they contribute to something larger.

A system for building applications.

A system for building businesses.

A system for building products.

A system for building future systems.

That's a very different mindset than simply creating another library.

Good Systems Hide Complexity

One of the signs of a good system is that most people never think about it.

A person driving to work isn't thinking about fuel injection timing.

A homeowner isn't thinking about power generation when they flip a light switch.

A musician isn't thinking about signal processing every time they strum a guitar.

The system absorbs complexity so the user can focus on what they actually want to accomplish.

Good software should do the same.

The more complexity we can absorb into the system, the more value we create for the people using it.

Systems Compound

Features eventually become outdated.

Systems evolve.

Features get replaced.

Systems adapt.

Features come and go.

Systems persist.

This is one of the reasons I've become increasingly interested in architecture, contracts, local-first computing, hardware, and sovereign AI.

At first glance, these topics seem unrelated.

But they all stem from the same question:

"What kind of system are we building?"

Because once you start thinking in systems, every decision becomes connected.

Looking Beyond Features

The older I get, the less interested I become in chasing the newest feature or trend.

Instead, I'm interested in foundations.

Architectures.

Patterns.

Workflows.

Infrastructure.

Systems.

Because that's ultimately what customers interact with.

They don't buy code.

They don't buy frameworks.

They don't buy APIs.

They buy the result those things create.

Just like nobody buys a collection of car parts.

They buy a vehicle that gets them where they want to go.

And that's why I care more about systems than features.

Road To KiwiEngine is a series documenting the philosophy, architecture, successes, mistakes, and lessons learned while building KiwiEngine and its ecosystem one module at a time.

Road To KiwiEngine #14: Why Everything In KiwiEngine Starts With Contracts

Drew Marshall — Wed, 10 Jun 2026 10:57:40 +0000

Most software projects begin with frameworks.

I begin with contracts.

Over the years, I've watched countless projects become tightly coupled to:

frameworks,
databases,
cloud providers,
libraries,
and implementation details.

The result is usually the same.

Changing anything becomes expensive.

Replacing anything becomes painful.

Innovation slows down.

That's why I've become obsessed with contracts.

What Is A Contract?

A contract is simply an agreement.

Not code.

Not implementation.

An agreement.

It defines:

inputs,
outputs,
expectations,
behaviors,
and guarantees.

Without caring how the work gets done.

The implementation can change.

The contract remains stable.

Why Contracts Matter

Imagine replacing:

PostgreSQL with MySQL
WordPress with another CMS
Local AI with cloud AI
AWS with Azure

Most systems struggle because they were designed around implementations.

Not contracts.

The tighter the coupling, the more painful the migration.

The stronger the contract, the easier the replacement.

KiwiEngine's Philosophy

Every major component should communicate through predictable contracts.

Not assumptions.

Not hidden dependencies.

Not framework magic.

Contracts create freedom.

Freedom to replace.
Freedom to scale.
Freedom to evolve.

That's the foundation of KiwiEngine.

Road To KiwiEngine #13: Why I Think The Future Of Computing Is Local-First

Drew Marshall — Mon, 08 Jun 2026 16:45:00 +0000

For over a decade, the industry pushed everything toward the cloud.

Applications.
Storage.
Media.
Development environments.
Infrastructure.
Intelligence.

And for a while, it made perfect sense.

Centralization solved a lot of problems:

accessibility,
scalability,
synchronization,
deployment,
and collaboration.

But I think we accidentally created a new problem in the process:

Dependence.

The Cloud Changed Ownership

Modern computing often feels less like ownership and more like permission.

You don’t really own:

the platform,
the infrastructure,
the intelligence,
the workflow,
or sometimes even the data.

You lease access to them.

That changes the relationship between users and technology entirely.

When access becomes the product:

subscriptions become permanent,
lock-in becomes strategic,
interoperability declines,
and users slowly lose operational control.

I think we’re reaching the point where people are starting to notice that tension.

Local-First Does Not Mean Offline-Only

One misconception about local-first systems is that people assume it means:
“never connected to the internet.”

That’s not what I mean at all.

The future I envision is:

hybrid,
loosely connected,
and synchronization-driven.

A local-first system should:

work independently,
synchronize intelligently,
connect intentionally,
and degrade gracefully when services disappear.

The web should enhance the system.
Not become the system.

Why Resilience Matters

One thing I think the industry underestimates is resilience.

What happens when:

APIs change?
providers disappear?
subscriptions become unaffordable?
regions go down?
internet access becomes unstable?
platforms revoke access?

Modern systems often fail catastrophically because they assume permanent connectivity and permanent provider stability.

I think that assumption is dangerous.

Especially for:

businesses,
creators,
infrastructure,
education,
and AI workflows.

AI Makes Local-First More Important

Ironically, AI is one of the biggest reasons I think local-first computing is returning.

Because AI is becoming operational infrastructure.

If your:

workflows,
assistants,
automation,
documentation,
and business operations

all depend entirely on external platforms, then your operational intelligence becomes rented.

That creates fragility.

I think local AI combined with selective synchronization will become incredibly important over the next decade.

Not because cloud AI disappears.

But because hybrid intelligence becomes more practical.

The Edge Computing Renaissance

I think we’re entering a new edge computing era.

Smaller systems are becoming more capable:

mini PCs,
local servers,
ARM devices,
AI accelerators,
embedded systems,
and home infrastructure appliances.

The line between:

server,
desktop,
router,
AI appliance,
and media system

is beginning to blur.

That’s extremely interesting to me from both a software and hardware perspective.

Why This Shapes KiwiEngine

A lot of the philosophy behind:

KiwiEngine,
KiwiHome,
WebEngine,
and the broader CitrusWorx ecosystem

comes from this exact line of thinking.

I’m increasingly interested in systems that are:

modular,
portable,
repairable,
composable,
and user-owned.

Not because I’m anti-cloud.

But because I think healthy systems should preserve user sovereignty wherever possible.

The Future Isn’t Centralized Or Decentralized

I actually think the future is neither fully centralized nor fully decentralized.

I think it’s coordinated.

A mesh of:

local systems,
cloud systems,
edge infrastructure,
AI workers,
and synchronization layers

working together intentionally.

That’s the future I want to help build.

Not computing that belongs to platforms.

Computing that belongs to people.