DEV Community: Drew Marshall

Sig Is Becoming The Reactive Engine

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

In the last Road To KiwiEngine post, I talked about Juice getting close to version 1.0.

Juice has reached a point where I understand its responsibility pretty clearly.

It takes design intent, project configuration, and attribute-based styling rules and turns those things into the visual language of an application.

But interfaces aren't static.

Things change.

Users click buttons.

Data updates.

Components respond.

State changes.

Parts of the interface need to update without rebuilding everything around them.

That's where another KiwiEngine library has been quietly becoming one of the more complete pieces of the ecosystem.

Sig.

Juice Makes It Look Right. Sig Makes It Alive.

This is probably the simplest way I can describe the relationship.

Juice is concerned with presentation.

Sig is concerned with reactivity.

They're related because they both participate in the user interface, but I don't want them becoming the same system.

That's an important architectural boundary.

Juice shouldn't need to understand application state just because an element has styling.

Sig shouldn't need to understand a project's design system just because something on the screen changed.

They can work together without owning each other's responsibilities.

That's becoming a recurring theme throughout KiwiEngine.

Sig Is Signal-Based

At the center of Sig is the idea of signals.

A signal represents a value that can change.

Conceptually, something like:

const count = signal(0);

Now the interesting part isn't simply storing 0.

It's establishing that count is something the interface can react to.

If that value changes, the parts of the UI depending on it can respond.

That gives me a much cleaner mental model for reactive interfaces:

Something changed. Update what depends on it.

I like that.

It's small.

It's understandable.

And it doesn't require the entire application to become one giant state-management problem.

I Didn't Want Reactivity Everywhere

This is one of the architectural decisions I've become more confident about.

When you're building a framework, it's tempting to make every system aware of every other system.

The UI needs state.

The state affects rendering.

Rendering affects components.

Components have styles.

Styles have configuration.

Suddenly everything knows everything.

That's exactly the kind of coupling I'm trying to avoid.

Sig owns reactivity.

Juice owns styling.

Nectarine can own configuration.

Seltzer can own HTTP concerns.

WebEngine can coordinate the larger application lifecycle.

The pieces can communicate.

But communication doesn't require collapsing them into one enormous abstraction.

Sig Has Its Own JSX Runtime

This is where Sig becomes more than a tiny signals utility.

It also has its own JSX runtime.

That matters because JSX gives me a really expressive way to describe interfaces while Sig controls how those interfaces actually become reactive.

Instead of depending on another UI framework to interpret the application, KiwiEngine can have a rendering model that belongs to its own architecture.

That's a significant step.

Because now Sig isn't simply helping another framework manage state.

It's becoming the reactive UI runtime itself.

JSX Isn't The Architecture

At the same time, I don't want JSX to become the point of Sig.

Syntax is useful.

But syntax isn't architecture.

The important part is the relationship underneath it.

A component expresses an interface.

Signals represent changing values.

The renderer understands those relationships.

When state changes, the system updates what needs to change.

JSX gives developers a convenient way to express that.

But the real value is the reactive model underneath it.

That's the engine.

Reactivity Should Feel Boring

I mean that as a compliment.

When I click something and a value changes, I don't want to think about the rendering engine every time.

I don't want every feature to require another conversation about state synchronization.

I don't want to manually coordinate every DOM update.

The system should establish the relationship.

Then it should do its job.

That's where libraries start becoming infrastructure.

When they're new, you think about them constantly.

When they're mature, you think about the thing you're building.

Sig getting closer to version 1 means I want more of that second experience.

The Renderer Is Where The Abstraction Gets Tested

A reactive API can look incredibly elegant in isolation.

The real test happens when you start rendering actual applications.

Components nest.

State changes.

Lists change.

Elements appear and disappear.

Events fire.

Values depend on other values.

Cleanup matters.

Lifecycle matters.

The happy-path demo stops being enough.

That's where the implementation has to prove that the abstraction actually works.

And that's part of why building real KiwiEngine applications matters so much.

I'm not trying to design Sig from hypothetical examples forever.

The applications need to pressure-test it.

If something becomes awkward repeatedly, that's information.

If an abstraction only works in a demo, that's information too.

The application is part of the design process.

Sig Shouldn't Become Everything Either

The lesson I learned with Juice applies here too.

A library becomes more mature when I understand what doesn't belong in it.

Sig doesn't need to become a styling framework.

It doesn't need to become an HTTP client.

It doesn't need to become a configuration system.

It doesn't need to absorb every capability an application might eventually require.

Its responsibility is already substantial:

Make reactive interfaces work well.

That's enough.

Other KiwiEngine systems can handle the rest.

This Is Why Separate Libraries Matter

Sometimes it would be easier to put everything into one giant package.

Install KiwiEngine.

Get everything.

UI.

CSS.

HTTP.

Configuration.

Infrastructure.

Rendering.

All living inside the same enormous abstraction.

But that's not really the engine I want.

I want systems with understandable responsibilities.

Juice can mature independently.

Sig can mature independently.

Seltzer can mature independently.

Nectarine can mature independently.

Then WebEngine can compose those capabilities into something larger.

That means improvements to one system don't necessarily require redesigning everything else.

It also means developers can understand KiwiEngine one piece at a time.

Juice And Sig Show What KiwiEngine Is Becoming

This is where the architecture is starting to feel real to me.

Juice can answer:

How should this interface express its design?

Sig can answer:

How should this interface respond when something changes?

Those are different questions.

They deserve different systems.

But when they're composed, something interesting happens.

Now I have an interface that can express design intent and react to application state.

Neither library needs to become the other.

That's the kind of composition I've been trying to reach.

Getting Close To Version 1 Changes The Questions

Just like Juice, getting Sig closer to version 1 isn't making me ask:

What else can I cram into this thing?

I'm asking:

Is the responsibility clear?

Is the reactive model predictable?

Does the renderer behave consistently?

Are the lifecycle boundaries understandable?

Can I build real interfaces without constantly fighting the abstraction?

Those questions matter more to me than the size of the feature list.

Version 1 doesn't mean there will never be another feature.

It means the foundation should be dependable enough to build on.

Another Piece Of The Engine Is Settling Into Place

This is why I've been saying KiwiEngine is finally becoming an engine.

It's not because one giant package suddenly became capable of doing everything.

It's almost the opposite.

The individual systems are figuring out what they're responsible for.

Juice is becoming the design engine.

Sig is becoming the reactive UI engine.

And as those responsibilities stabilize, WebEngine gains dependable pieces it can compose instead of experimental ideas it has to compensate for.

That's progress I can actually build on.

Because eventually I don't want to spend all my time thinking about signals.

I want to think about the music application using them.

The storefront using them.

The artist platform using them.

The electronics dashboard using them.

The things I'm actually trying to create.

A good reactive engine shouldn't become the application.

It should make the application feel alive.

Juice Is Becoming a Design Engine

Drew Marshall — Sun, 27 Sep 2026 18:30:00 +0000

I've spent a lot of the Road To KiwiEngine series talking about architecture from thirty thousand feet.

Systems.

Abstractions.

Boundaries.

Intent.

Configuration.

Framework design.

But KiwiEngine is becoming more of an actual engine because the individual pieces underneath it are becoming more capable.

So I want to spend the next several posts looking at those pieces individually.

And there's probably no better place to start than Juice.

Because Juice is getting very close to version 1.0.

Juice Started With A Much Smaller Idea

Juice started because I wanted a better way to handle common styling patterns.

Not replace CSS.

Not invent another enormous styling language.

Not recreate every CSS property as an attribute.

I wanted to express common design intentions directly in markup.

That eventually led to things like:

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

There's a lot happening in a very small statement.

I'm saying this element contains content.

I'm saying that content should adapt using a grid.

And I'm saying that on mobile, I explicitly want that layout to stack.

But I'm not describing every CSS declaration required to accomplish it.

That's Juice's job.

Intent Became The Important Part

The more I developed Juice, the more I realized that its value wasn't really about shortening CSS.

It was about communicating intent.

There's a difference between saying:

Apply these seven CSS properties.

and:

This content is a grid.

The first describes an implementation.

The second describes what I'm trying to accomplish.

That distinction became one of the core ideas behind Juice.

And it started affecting how I thought about KiwiEngine as a whole.

But Intent Can Become Another Trap

Once I started thinking this way, there was an obvious temptation.

Add more attributes.

And more.

Until eventually every CSS property has a Juice equivalent.

At that point I've accomplished something incredible:

I've reinvented CSS.

Except probably worse.

That's exactly what I don't want.

Juice needs to know where its responsibility ends.

If something is already expressive and easy to accomplish with CSS, I don't necessarily need to invent another abstraction for it.

Juice should handle the common intentions.

CSS should remain available for everything else.

That boundary has become part of the design.

Defaults Are Part Of The Product

Responsive design helped clarify this philosophy.

Take:

<div content adapt="grid">

I don't necessarily want developers to have to specify:

mobile = ...
tablet = ...
laptop = ...
desktop = ...

every single time they create a grid.

Juice already knows that grids usually need to adapt.

So it can provide sensible responsive behavior by default.

Then, when the developer actually wants different behavior, they can express it:

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

That's the relationship I want.

Good defaults.

Small intentional overrides.

Escape hatches when necessary.

I don't want configuration for the sake of configuration.

Then Juice Became Configuration-Driven

This was one of the bigger steps forward.

Juice can now consume project configuration and generate stylesheets from it.

That changes the relationship between the library and the project.

Instead of Juice defining the entire visual language, the project can define its own design decisions.

Things like:

colors
typography
spacing
borders
shadows
radius
other design tokens

Juice consumes those decisions and generates the stylesheet needed to support its attribute-based styling system.

It's effectively becoming a theme generator.

And I really like that direction.

The Project Owns The Theme

This is important to me.

I don't want every application built with KiwiEngine to look like a "KiwiEngine application."

The framework shouldn't own the brand.

The project should.

Blackwater Sound should look like Blackwater Sound.

A WebStore storefront should reflect the business using it.

An artist platform should reflect the artist.

A completely unrelated developer using Juice should be able to create something that looks nothing like anything I've built.

Juice provides the styling engine.

The project provides the identity.

That's a much healthier boundary.

Generated CSS Is Still CSS

There's another part of this architecture that I like.

The output is still stylesheets.

I'm not trying to create an alternate universe where the browser suddenly doesn't use CSS.

Juice can consume configuration.

It can understand its attributes.

It can generate the appropriate styling.

But eventually we're still speaking the language the browser understands.

That matters because Juice can't be everything.

And it shouldn't be.

If a project needs custom CSS, write CSS.

If something doesn't belong in Juice, don't force it into Juice.

The abstraction should help until it stops helping.

Then it should get out of the way.

This Is Starting To Feel Like An Engine

This is why I'm beginning to think about Juice differently.

Originally, it was a styling library.

That's still technically true.

But increasingly, it behaves like a small design engine.

It has inputs.

Project configuration.

Design tokens.

Intent expressed through attributes.

It has rules.

Defaults.

Responsive behavior.

Attribute semantics.

And it produces output.

Stylesheets.

Consistent styling behavior.

A design language that can be reused throughout an application.

That's more interesting to me than simply having a collection of CSS utilities.

Version 1 Is About Knowing What Juice Is

This connects back to what I wrote recently about Juice approaching version 1.0.

I don't think 1.0 means Juice has every feature I could possibly imagine.

Quite the opposite.

Getting closer to 1.0 has made me more comfortable saying:

No, Juice doesn't need that.

That's maturity.

The goal isn't maximum capability.

The goal is a clear responsibility.

I want to be able to explain what Juice does.

I want developers to understand its vocabulary.

I want its defaults to be predictable.

I want its configuration to make sense.

And I want its boundaries to remain visible.

If I can accomplish those things, Juice doesn't need to solve every styling problem.

It just needs to solve its styling problems well.

Libraries Becoming Engines

This is part of a larger change happening inside KiwiEngine.

The individual libraries are no longer just experiments asking:

What if I built this?

They're developing philosophies.

Boundaries.

Configuration.

Stable APIs.

Relationships with other parts of the ecosystem.

That's what makes WebEngine increasingly capable of behaving like an engine.

Not because I created one enormous framework that does everything.

But because the smaller systems underneath it are becoming dependable enough to compose.

Juice is one of the first pieces reaching that point.

And after all the experimentation, redesigning, questioning, and real-world use, I think I finally know what it wants to be.

Juice isn't trying to replace CSS.

It isn't trying to become another utility framework.

And it isn't trying to own the visual identity of an application.

Juice is becoming the design engine that translates project intent into styling behavior.

That's a much more interesting foundation to build on.

The Engine Is Finally Becoming an Engine

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

There's a strange moment in framework development when the individual pieces start becoming something larger.

You spend months building libraries.

You design APIs.

You work on configuration.

You improve routing.

You experiment with styling.

You rethink abstractions.

Then one day, you start connecting everything and realize you're no longer just building a collection of tools.

You're building an engine.

That's where KiwiEngine is starting to feel like it is now.

A Collection of Libraries Isn't an Engine

I've spent a lot of time thinking about the responsibilities of individual KiwiEngine components.

Juice handles attribute-driven styling.

Nectarine provides configuration-related capabilities.

Seltzer addresses HTTP.

Sig provides reactive capabilities.

Other parts of the ecosystem address data, infrastructure, and application concerns.

Each piece has its own reason to exist.

But having several useful libraries doesn't automatically create a useful engine.

The real question is how those pieces work together.

Can they share conventions?

Can they communicate without becoming tightly coupled?

Can they be assembled into applications without forcing developers to understand every implementation detail?

Can they remain independently useful?

That's where architecture starts becoming more interesting.

WebEngine Is Where the Pieces Meet

WebEngine is becoming the place where these ideas come together.

Instead of every application having to figure out how the libraries should interact, the engine can establish common lifecycle and integration patterns.

That doesn't mean every library loses its independence.

Quite the opposite.

I want each component to retain a clear responsibility.

The engine should coordinate those responsibilities.

Not absorb them.

That distinction has become increasingly important to me.

A library solves a particular problem.

An engine coordinates the systems needed to operate an application.

An application gives those systems a purpose.

The Engine Should Understand the Process

Think about what happens when an application starts.

Configuration needs to be understood.

Dependencies need to be established.

Routes need to be registered.

Services need to be prepared.

The application needs to become ready to handle work.

And eventually, it needs to shut down cleanly.

These aren't isolated features.

They're parts of a lifecycle.

Once you begin treating them as a coordinated process, the architecture starts feeling different.

Instead of asking every library to solve the entire problem, the engine can establish when and how each piece participates.

That's a more sustainable direction than turning everything into one enormous framework.

Boundaries Make Composition Possible

One of the recurring lessons from this series has been that abstractions need boundaries.

Juice shouldn't replace CSS.

An HTTP library shouldn't own the application's business logic.

A configuration system shouldn't decide what the application is supposed to accomplish.

An infrastructure tool shouldn't dictate the user experience.

Each component needs enough responsibility to be useful without becoming responsible for everything.

WebEngine is where those boundaries become practical.

If the pieces are designed well, they can work together without losing their identities.

That's what I want KiwiEngine to accomplish.

The CLI Is Part of the Experience

Another piece of this is the developer experience around creating projects.

I don't want starting a new KiwiEngine application to mean manually assembling a dozen unrelated components.

There should be a clear path from an idea to a working project.

The Kiwi CLI can help establish that path.

Creating a project.

Adding capabilities.

Assembling applications.

Applying conventions.

Reducing repetitive setup.

The goal isn't to hide how everything works.

It's to make the common path easier.

Developers should be able to understand the system without having to rebuild the system every time.

This Changes How I Think About New Projects

The practical benefit becomes obvious when I think about the things I want to build.

A Blackwater Sound application.

A storefront.

An artist platform.

A publishing system.

An internal workshop tool.

Those applications have different purposes.

But they don't need completely unrelated foundations.

They can share the same underlying architecture while expressing their own domains.

That's what I want WebEngine to enable.

Not identical applications.

Different applications built on dependable shared infrastructure.

A Framework Should Eventually Become Predictable

There's something satisfying about reaching a point where the architecture starts answering questions before I have to ask them.

Where should this responsibility live?

How should configuration be consumed?

How does this component participate in the lifecycle?

How should a new application be assembled?

The answers don't need to be identical for every situation.

But the system should establish enough consistency that developers aren't constantly inventing new conventions.

Predictability creates confidence.

Confidence makes experimentation easier.

The Engine Is Not the Destination

This is the part that connects to the previous posts.

I'm not building WebEngine because I want to spend the rest of my life maintaining a web framework.

I'm building it because I want a dependable foundation for the things I actually want to create.

Music tools.

Stores.

Creative platforms.

Publishing systems.

Business infrastructure.

Applications supporting physical products.

The engine should make those projects easier to pursue.

And the more its pieces mature, the closer I get to spending my time on those projects instead of rebuilding their foundations.

It's Starting to Feel Real

There's still work to do.

There are still things to refine.

There will always be improvements.

But the nature of the work is changing.

I'm spending less time asking what every individual library might become.

I'm spending more time thinking about how the ecosystem operates as a whole.

That's an exciting milestone.

Because KiwiEngine is finally starting to feel less like a collection of experiments.

And more like the engine I've been trying to build all along.

The Difference Between Delegating Code and Delegating Decisions

Drew Marshall — Fri, 25 Sep 2026 17:34:00 +0000

In my last post, I talked about why AI has become part of my workforce.

I have too many things I want to build and not enough hours to personally implement every little detail.

But there's an important distinction I want to explore.

Delegating code and delegating decisions are not the same thing.

And I think understanding that difference is going to become increasingly important as AI-assisted development becomes more common.

Writing Code Is Only Part of Engineering

When people talk about AI writing code, the conversation often centers on whether the generated code works.

Does it compile?

Do the tests pass?

Does the application run?

Those are important questions.

But they're not the only questions.

Software engineering involves deciding what should exist in the first place.

What belongs in a library?

What belongs in an application?

What should be configurable?

What should be opinionated?

What responsibilities should a component own?

What dependencies should it introduce?

What happens when requirements change?

Those decisions shape the system long before implementation begins.

And those are the decisions I'm not interested in blindly delegating.

KiwiEngine Has An Architectural Philosophy

Take Juice as an example.

One of my goals is to avoid recreating CSS.

I want Juice to provide a small vocabulary for expressing common design intentions while allowing CSS to remain CSS.

Something like:

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

communicates an intention.

It doesn't need to expose every possible responsive layout option.

Now imagine I ask AI to implement additional responsive functionality.

It might produce something that works perfectly well.

But what if it introduces twenty new attributes?

What if it creates a completely different configuration pattern?

What if it solves the immediate problem by making Juice responsible for something that should belong to CSS?

The implementation might work.

But it would violate the architecture.

That's why the distinction matters.

The Architect Defines The Boundaries

My preferred workflow starts with understanding the problem.

Before delegating implementation, I want to establish:

What problem are we solving?

Where does the solution belong?

What existing patterns should it follow?

What should remain outside its responsibility?

How will we know the implementation is correct?

Once those decisions are established, AI becomes incredibly useful.

It can implement an established pattern.

It can help create tests.

It can identify repetitive work.

It can help document the behavior.

It can examine edge cases I may have overlooked.

But it isn't automatically authorized to redefine the system.

That's a separate decision.

No Ghost Code

I've been very deliberate about this boundary while working on KiwiEngine.

AI doesn't get independent authority to commit code.

It doesn't get to rewrite architecture without approval.

It doesn't get to introduce dependencies simply because they're convenient.

And it doesn't get to silently make changes that I haven't authorized.

If a proposed implementation requires changing the architecture, that's a conversation.

Not an automatic next step.

I want to know what changed.

I want to know why it changed.

And I want to understand what I'm approving.

That doesn't mean I need to personally type every line.

It means I remain responsible for the work.

AI Can Challenge My Decisions

There's another important distinction here.

Retaining architectural authority doesn't mean refusing to listen.

I actually want AI to challenge my assumptions.

If there's a simpler implementation, show me.

If an abstraction introduces unnecessary complexity, explain why.

If an API creates a maintenance problem, point it out.

If my proposed design has an obvious weakness, I want to know.

But there's a difference between presenting an alternative and silently implementing it.

I can consider the recommendation.

I can compare the tradeoffs.

I can change my mind.

That's still engineering.

The important part is that the decision remains deliberate.

Review Is More Than Reading A Diff

As AI becomes more capable, I think reviewing generated code needs to become more sophisticated.

A diff can tell me what changed.

It doesn't necessarily tell me whether the change belongs.

I need to understand the behavior.

I need to understand the dependencies.

I need to understand the architectural consequences.

I need to know whether the implementation follows established conventions.

I need to know whether the tests actually validate the intended behavior.

And I need to know whether the solution creates more complexity than the problem requires.

A passing test suite is valuable.

It isn't a substitute for understanding the system.

Delegation Is A Skill

One thing I'm discovering is that using AI effectively requires becoming better at communicating engineering intent.

Vague instructions produce more room for assumptions.

Clear boundaries produce work that's easier to evaluate.

Instead of simply saying:

"Add a theme system."

I can explain that Juice consumes project configuration and generates stylesheets for its attribute-based styling system.

The project owns its design decisions.

Juice translates those decisions into reusable styling behavior.

CSS remains available for everything outside that scope.

Now the implementation has a direction.

That's a much better starting point.

I Still Want To Be An Engineer

Using AI doesn't mean I want to stop learning.

I still want to understand software architecture.

I still want to improve my programming ability.

I still want to understand electronics, DSP, embedded systems, and the technologies behind the things I'm building.

But I don't need to personally perform every repetitive task to prove that I understand my work.

I can learn deeply while delegating appropriately.

Those ideas aren't mutually exclusive.

The Difference Matters

I don't want AI to replace my judgment.

I want it to extend my capacity.

I want to spend more time designing systems, solving interesting problems, making music, building electronics, and creating things that matter to me.

And I want the code supporting those ambitions to remain understandable and intentional.

That's the relationship I'm trying to build.

Delegate implementation where it makes sense. Retain responsibility for the decisions.

AI can help me build KiwiEngine.

But it doesn't get to decide what KiwiEngine is.

AI Is My Workforce, Not My Replacement

Drew Marshall — Fri, 25 Sep 2026 02:30:00 +0000

I've come to a realization.

I have to use AI as part of my workforce.

Not because I can't code.

Not because I don't understand what I'm building.

And certainly not because I want to surrender my projects to a machine.

I need to make progress.

I have a lot of things I want to build, and unfortunately, I still only have 24 hours in a day.

KiwiEngine.

Blackwater Sound.

Music software.

Artist platforms.

Stores.

Guitar pedals.

Amplifiers.

Electronics.

Games.

Writing.

Teaching.

And that's before we get into actually making music.

I can either spend the next several years trying to do every little thing myself, or I can use the tools available to me to start bringing these ideas to life.

I've made my decision.

I Don't Have The Luxury Of Being A Purist

There's a perspective in software development that I understand and respect.

Learn your tools.

Understand your language.

Write your own code.

Master your specialty.

Become exceptionally good at what you do.

There's nothing wrong with that.

But I think we sometimes make the mistake of treating one approach to professional development as though it's prescribed to everyone.

Not everyone is trying to accomplish the same thing.

Some developers want to specialize deeply in a particular area of engineering.

Some want to work for established companies.

Some want to become experts in a particular language, framework, or discipline.

Those are legitimate goals.

But they're not necessarily mine.

I'm a builder.

I have a vision for things that extend well beyond software development.

Software is one of the tools I use to bring those things into existence.

And if I'm spending all my time proving that I can personally implement every line of code, I'm not necessarily getting closer to those goals.

I'm just getting better at doing everything myself.

Those aren't the same thing.

I Can Put My Code Where My Thoughts Are

One thing I've learned about myself is that I'm a big thinker.

I see systems.

I see how things connect.

I see how one piece of infrastructure can support five different projects.

I can look at a music business, a software platform, a storefront, and an electronics workshop and start imagining how they could operate together.

And for the most part, I can put my code where my thoughts are.

I've been doing that with KiwiEngine.

The problem isn't that I don't know how to build things.

The problem is that I can't personally implement every idea at the speed I can envision it.

There are only so many hours available.

And I don't have an entire engineering department sitting behind me.

So why wouldn't I use technology that helps me extend my capacity?

AI Doesn't Design My Vision

This is where I think an important distinction needs to be made.

I don't hand AI a vague idea and tell it to go build my company.

I design the systems.

I establish the architecture.

I determine the responsibilities of the libraries.

I make decisions about how the pieces interact.

I write and develop the foundations.

Then I use AI to help with implementation, repetitive work, documentation, tests, and other tasks that would otherwise consume significant amounts of time.

That's delegation.

And delegation doesn't eliminate responsibility.

If anything, it makes responsibility more important.

Because now I have to understand not only what I'm building, but what I'm approving.

No Ghost Code

I have a very deliberate boundary when it comes to AI working on KiwiEngine.

AI does not have independent authority to commit code, change architectural direction, or make decisions on my behalf.

It doesn't get to decide that a library should be rewritten.

It doesn't get to introduce dependencies because it thinks they're convenient.

It doesn't get to change the design philosophy because another approach is more conventional.

And it doesn't get to silently commit code I haven't approved.

There is no ghost code.

If AI is going to take an action that changes the project, it needs my explicit authorization.

I review the work.

I approve the direction.

I remain responsible for the result.

AI can be part of my workforce without becoming the owner of my work.

The Grunt Work Is Still Work

Here's something I think gets lost in conversations about AI-assisted development.

Not every programming task requires the same level of creative investment.

Some tasks are genuinely interesting architectural problems.

Others are repetitive implementation work.

Writing another adapter.

Creating another set of tests.

Updating documentation.

Implementing a pattern that's already established elsewhere in the project.

Working through boilerplate.

Those things matter.

They still need to be done correctly.

But they don't all require me to spend hours personally typing every character.

If I've already established how a system should work, why wouldn't I use a tool to help implement that established pattern?

My time is better spent reviewing the result, improving the architecture, and moving on to the next problem.

That's not avoiding engineering.

That's managing engineering work.

AI Doesn't Eliminate The Need To Understand Your Code

There's a difference between using AI to extend your abilities and using it to avoid developing them.

I don't believe AI should become an excuse to stop learning.

If I don't understand a change, I shouldn't approve it.

If I can't explain why something belongs in the architecture, it probably doesn't belong there yet.

If AI generates code that violates the design principles of KiwiEngine, that code doesn't get a pass simply because it works.

Working code isn't automatically good architecture.

And generated code isn't automatically correct.

AI can make mistakes.

It can misunderstand requirements.

It can introduce unnecessary complexity.

It can confidently implement something that doesn't fit the rest of the system.

That's why oversight matters.

I want AI helping me move faster, not helping me accumulate problems faster.

I'm Not Trying To Win A Coding Endurance Competition

This is the part I've been thinking about the most.

What exactly am I proving by doing everything manually?

That I can work longer?

That I can memorize more syntax?

That I can rebuild the same implementation for the fifteenth time?

I already know I can build software.

I want to use that ability to accomplish something.

I want to create tools for musicians.

I want to produce music.

I want to develop physical products.

I want to experiment with electronics.

I want to build businesses around things I genuinely enjoy.

I want to spend more time creating cool things and less time getting bogged down in technical work simply for the sake of purity.

If AI can help me accomplish that while I retain ownership and oversight, I'm going to use it.

KiwiEngine Is Supposed To Create Leverage

This is actually very consistent with why I'm building KiwiEngine in the first place.

The whole point of a reusable framework is to avoid solving the same problems repeatedly.

Juice helps me avoid recreating common styling behavior.

Nectarine helps establish reusable configuration patterns.

Other libraries and engines provide foundations I can build upon.

AI fits into that philosophy as another form of leverage.

KiwiEngine reduces the amount of infrastructure I need to rebuild.

AI reduces the amount of implementation work I need to personally perform.

Together, they allow me to spend more time on the problems that are unique to what I'm creating.

And that's the entire point.

I Want To Build Things, Not Just Talk About Building Them

I have enough ideas to keep myself busy for several lifetimes.

What I don't have is several lifetimes.

I have this one.

And I would rather spend it bringing as many meaningful ideas into reality as I reasonably can.

I'm not interested in pretending that using AI somehow makes those ideas less mine.

The architecture is mine.

The decisions are mine.

The responsibility is mine.

The vision is mine.

The tools help me execute it.

That's how I see AI.

Not as a replacement for my abilities.

Not as an excuse to abandon craftsmanship.

And not as an autonomous authority over my projects.

It's part of my workforce.

I intend to use it that way.

The future isn't something I'm waiting around for.

It's already here.

And I have things to build.

The Best Framework Gives You Your Time Back

Drew Marshall — Wed, 23 Sep 2026 17:15:00 +0000

Frameworks are supposed to save time.

That's an obvious statement.

But I think there's a deeper version of it.

A good framework doesn't just help you write today's application faster.

It prevents tomorrow's application from making you solve yesterday's problems again.

That's becoming one of the biggest reasons I'm building KiwiEngine.

I've Already Solved This Problem

Every new project starts with excitement.

Then comes the familiar work.

Configuration.

Routing.

HTTP.

Styling.

Data.

Deployment.

Infrastructure.

Project structure.

All necessary.

But after you've built enough applications, something starts feeling strange.

You've solved many of these problems before.

Why are you solving them again?

Of course, applications aren't identical.

But many of the mechanisms underneath them are remarkably similar.

That was part of the motivation behind KiwiEngine.

Not:

"How can I eliminate programming?"

But:

"How can I spend more of my programming time on problems that are actually new?"

Repetition Isn't Always Bad

There's an important distinction here.

Repeating code isn't automatically a problem.

Sometimes two things merely happen to look similar.

Abstracting too early can create something worse than duplication.

I've learned that lesson repeatedly while building KiwiEngine.

But when the same problem appears across real projects over and over again, that's different.

Eventually a pattern earns an abstraction.

That's where libraries become valuable.

Build It Once. Improve It Everywhere.

Imagine I discover a better way of handling something while building a Blackwater Sound application.

If that improvement belongs in the underlying library, I can improve the library.

Now another application benefits.

And another.

That's leverage.

Instead of maintaining ten unrelated implementations of the same idea, I can improve the shared foundation.

The applications still remain different.

Their domains remain different.

Their users remain different.

But the boring problems underneath them don't have to be reinvented.

Time Is The Resource I'm Actually Optimizing

This has become more important as my interests have expanded.

I don't only want to build web applications.

I want to make music.

I want to produce records.

I want to teach.

I want to build pedals.

I want to experiment with amplifiers.

I want to build guitars.

I want to create stores.

I want to work with artists.

I want to write.

There are only so many hours available.

So if every idea requires me to rebuild an entire technical foundation before I can explore it, most of those ideas will never happen.

That's the real problem KiwiEngine can solve for me.

Infrastructure Should Compound

A framework becomes interesting when yesterday's work makes tomorrow's experiment cheaper.

Build a configuration system once.

Improve it across several projects.

Build an HTTP layer once.

Harden it through real use.

Build deployment tooling once.

Use it repeatedly.

Build a design system once.

Let projects configure it differently.

Each piece becomes another tool sitting on the workbench.

Eventually starting something new doesn't mean starting from zero.

It means assembling proven pieces and concentrating on what's different.

This Is Why Boundaries Matter

There's a danger here.

If KiwiEngine tries to solve everything, it eventually creates a different kind of burden.

Instead of saving time, I'll spend all my time maintaining KiwiEngine.

That's why I've become increasingly interested in boundaries.

Juice doesn't need to replace CSS.

A store package doesn't need to understand every business on Earth.

An API abstraction doesn't need to hide every capability of the underlying service.

Each piece should solve its problem well and then get out of the way.

Otherwise the framework becomes the project.

That's exactly what I'm trying to avoid.

The Goal Isn't Less Code

I'm not particularly interested in bragging about how few lines of code something requires.

Sometimes explicit code is good.

Sometimes configuration is good.

Sometimes abstraction is good.

The metric I care about more is:

How quickly can I get from an idea to working on the part of that idea that actually matters?

If I'm building a music tool, I want to spend my time thinking about musicians.

If I'm building a store, I want to think about products and customers.

If I'm building electronics, I want to think about circuits and hardware.

The framework should help me reach those problems sooner.

Eventually The Framework Should Become Boring

I actually think this might be one of the greatest compliments I could eventually give KiwiEngine.

I stopped thinking about it.

Not because development stopped.

Not because there aren't improvements to make.

But because the common pieces simply work.

I know how to start a project.

I know how configuration behaves.

I know how the pieces connect.

I know how to deploy it.

Then my attention can move somewhere else.

That's what infrastructure is supposed to do.

Give Me My Time Back

Building a framework requires an enormous investment of time.

So eventually it needs to repay that investment.

Not necessarily through subscriptions.

Not necessarily by becoming a huge software company.

It can repay me through leverage.

Through reuse.

Through faster experimentation.

Through shared improvements.

Through letting me pursue more ideas without rebuilding the same foundation every time.

The best framework isn't necessarily the one with the most features.

It might be the one that quietly gives you your time back.

That's what I want KiwiEngine to become.

I Didn't Build KiwiEngine Just To Build Software

Drew Marshall — Tue, 22 Sep 2026 16:15:00 +0000

I've spent years building software so I can eventually spend less time rebuilding software.

That sounds contradictory.

It isn't.

KiwiEngine was never supposed to become the thing I spend the rest of my life rebuilding.

It's supposed to become the foundation that lets me build everything else.

Music.

Artist platforms.

Stores.

Print-on-demand products.

Guitar pedals.

Amplifiers.

Electronics.

Games.

Whatever comes next.

The goal isn't to make KiwiEngine the center of everything I do.

The goal is to make it dependable enough that it doesn't have to be.

There's More I Want To Build Than Software

I love software development.

But I'm also a musician.

I write and produce music. I mix. I build things. I'm interested in electronics, guitars, amplifiers, pedals, recording equipment, games, design, publishing, and probably a dozen other things I'll discover along the way.

For a while, I treated those interests almost like separate worlds.

There was software development.

Then there was music.

Then there were physical products.

Then there was business.

But they're increasingly starting to look like parts of the same workshop.

Because almost everything I want to build eventually needs some kind of digital infrastructure.

Imagine Starting A Store

Let's say I want to start selling merchandise through Print on Demand.

The interesting part isn't building another login system.

It isn't figuring out routing again.

It isn't rebuilding configuration management.

And it definitely isn't creating the same application foundation for the twentieth time.

The interesting problems are things like:

How should products be represented?

How do I interact with a Print on Demand provider?

What happens when someone places an order?

How do I make switching providers possible?

What kind of storefront experience fits the brand?

How can products from multiple providers live together?

Those are the problems specific to the thing I'm actually building.

Everything underneath them is infrastructure.

That's where KiwiEngine starts becoming useful in a completely different way.

APIs Become Building Materials

This is one of the things I'm excited to explore.

There are APIs everywhere.

Print on Demand providers.

Payment processors.

Shipping providers.

Music services.

Distribution platforms.

Analytics services.

Cloud infrastructure.

Instead of treating each integration as a completely separate application, I can build adapters around those services and expose them through systems I control.

KiwiEngine provides the foundation.

The external API provides a capability.

My application decides what to do with it.

That's a very different relationship with software development.

I'm no longer starting with:

"What application can I build?"

I'm starting with:

"What am I trying to accomplish?"

Then software becomes one of the tools I use to accomplish it.

The Same Thing Applies To Music

Blackwater Sound gives me an enormous testing ground for this.

An artist might need an EPK.

A musician might need a storefront.

A studio might need a client portal.

A producer might need a way to transfer sessions.

A band might need a merch system.

A release might need its own interactive website.

A musician might need a better music player.

A studio might need internal tools that don't exist yet.

These don't all need to become SaaS companies.

Sometimes they can simply be useful tools.

And because I already have a technical foundation, experimenting with those ideas becomes much less expensive.

Then There Are Physical Products

This is where things get especially interesting to me.

I've been spending more time thinking about electronics.

Pedals.

Amplifiers.

Cabinets.

Guitars.

Audio hardware.

At first glance, that seems completely separate from KiwiEngine.

A guitar pedal certainly isn't running a web framework.

But think about everything surrounding that pedal.

Documentation.

Component inventories.

Bills of materials.

Product pages.

Storefronts.

Warranty registration.

Serial numbers.

Build records.

Testing information.

Customer support.

Dealer tools.

Internal manufacturing utilities.

If I eventually sell physical products, software becomes infrastructure around those products.

KiwiEngine doesn't have to power the pedal.

It can help power the company that builds the pedal.

That's a much more interesting role for technology.

This Changes How I Think About Frameworks

Framework development can easily become its own endless hobby.

There's always another abstraction.

Another feature.

Another optimization.

Another rewrite.

Eventually you can spend so much time building tools for building things that you stop building the things.

I don't want that.

KiwiEngine needs to reach a point where parts of it become boring.

Stable.

Documented.

Predictable.

Dependable.

That's success.

Because then I can stop thinking about the engine every time I want to drive somewhere.

Technology Should Create Leverage

That's probably the biggest change in how I'm thinking about CitrusWorx.

Technology doesn't always need to be the final product.

Sometimes technology exists to create leverage.

A storefront helps sell something.

An internal application helps manufacture something.

A music platform helps release something.

A website helps communicate something.

Infrastructure helps operate something.

The software matters.

But it doesn't always have to be the destination.

The Road Is Starting To Look Different

The early Road To KiwiEngine posts were naturally about building the engine.

What should this library do?

Where should this abstraction live?

How should configuration work?

What should the API look like?

Those questions still matter.

But something interesting is starting to happen.

The engine is becoming capable enough that I can increasingly ask a different question:

What can I build with it?

That's the question I've wanted to reach all along.

KiwiEngine isn't supposed to become everything I build.

It's supposed to make everything else easier to build.

When Is a Library Ready for Version 1.0?

Drew Marshall — Mon, 21 Sep 2026 16:45:42 +0000

Juice is getting very close to version 1.0.

That's a sentence I've been hesitant to write.

Not because Juice isn't usable.

I've been using it.

Not because it doesn't have enough features.

If anything, one of the biggest lessons I've learned while building it has been knowing when not to add another feature.

The hesitation comes from what 1.0 represents.

At some point, a library has to stop being an experiment and start making promises.

I think Juice is getting there.

Version 1.0 Isn't "Finished"

I've never liked the idea that version 1.0 means software is finished.

Software is rarely finished.

There will be new ideas.

There will be bugs.

There will be things I haven't considered yet.

There will undoubtedly be things I look back at later and wonder why I designed them that way.

That's development.

For me, 1.0 means something different.

It means:

I understand what this library is now.

That's a much bigger milestone.

Juice Took Time To Find Its Identity

Juice started as a way to solve styling problems inside KiwiEngine.

Over time, its philosophy became clearer.

I didn't want another collection of utility classes.

I didn't want to recreate CSS with different syntax.

And I definitely didn't want Juice to become responsible for every possible design decision.

CSS is already extremely good at being CSS.

Juice needed its own reason to exist.

Eventually, I realized that reason was intent.

Instead of describing every implementation detail, Juice could provide a small vocabulary for common design intentions.

Something like:

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

doesn't attempt to expose every responsive CSS possibility.

It communicates what I want the content to do.

Juice handles the common behavior.

CSS remains available when I need something more specific.

That boundary became incredibly important.

Real Projects Designed More of Juice Than I Did

A lot of Juice didn't come from sitting down and trying to invent a design system.

It came from using it.

I'd build something.

I'd encounter friction.

I'd notice a repeated pattern.

Then I'd ask whether that pattern belonged in Juice.

Sometimes the answer was yes.

Sometimes it was no.

That's how features like adapt started taking shape.

The abstraction came after the problem.

That's a development philosophy I've become increasingly attached to:

Let abstractions earn their way into the system.

Then Configuration Changed Things

One of the more recent milestones has been getting Juice to consume configuration and generate stylesheets from it.

This pushed Juice closer to what I actually wanted it to become.

A project can define its own design decisions:

colors
typography
spacing
borders
shadows
other design tokens

Juice can then generate the stylesheet that supports its attribute-based styling system.

In other words, Juice can act almost like a theme generator.

That's important because I don't want applications to rely on Juice for their entire identity.

Juice can't be everything.

And it shouldn't try to be.

The application should still own its brand.

The developer should still own the application.

CSS should still be CSS.

Juice provides the system connecting those decisions together.

1.0 Is About Boundaries

Strangely, getting closer to 1.0 hasn't made me think about everything else Juice could do.

It's made me think harder about what Juice shouldn't do.

That's probably one of the clearest signs that the library is maturing.

Early development asks:

What else can I add?

Mature development increasingly asks:

Does this actually belong here?

A stable library needs boundaries.

Without them, every useful idea eventually becomes another feature.

And every feature expands the surface area that has to be understood, documented, tested, supported, and maintained.

The API Has To Become A Promise

Before 1.0, changing an API is relatively inexpensive.

After 1.0, I think the relationship changes.

If someone builds around:

<div content adapt="grid">

I want them to have reasonable confidence that I'm not going to wake up next month and decide the entire vocabulary should work differently.

That doesn't mean nothing can ever change.

It means change needs to become more deliberate.

Version 1.0 isn't only a milestone for the maintainer.

It's a commitment to the people using the library.

Documentation Matters More Now

That also means the work leading into 1.0 isn't just code.

Documentation matters.

Examples matter.

Defaults matter.

Naming matters.

Error behavior matters.

The installation experience matters.

The little things that were easy to ignore while experimenting suddenly matter much more.

Because a library isn't ready simply because its author understands it.

Other people have to be able to understand it too.

Juice Doesn't Need To Be Everything

This may be the most important thing I've learned while building it.

I don't want Juice to replace CSS.

I don't want it to contain every layout imaginable.

I don't want it to become a giant collection of options simply so I can say it supports everything.

I want it to make the common things expressive.

I want the markup to communicate intent.

I want sensible defaults.

I want projects to own their identities.

And when Juice isn't the right tool for something, I want developers to be able to use CSS without fighting the framework.

That's enough.

In fact, knowing that might be exactly what makes Juice ready for 1.0.

The Road To KiwiEngine Continues

Juice reaching version 1.0 isn't just a Juice milestone.

It's a KiwiEngine milestone.

KiwiEngine is an ecosystem, and ecosystems become real one stable piece at a time.

Juice becoming stable gives everything built above it a more dependable foundation.

And after spending so much time writing about systems, abstractions, constraints, real projects, documentation, and intent, it's satisfying to see those ideas materializing in an actual library.

There's still work to do before I put the 1.0.0 tag on it.

But for the first time, the question isn't:

What does Juice need to become?

I think I know what Juice is.

Now the job is making sure it does that well.

The Artist Is Taking the Reins

Drew Marshall — Fri, 04 Sep 2026 13:50:32 +0000

For a long time, I treated my interests in technology and creativity like they belonged in separate rooms.

There was the technical side of me:

Software engineering.
Web development.
Systems architecture.
Game engines.
Infrastructure.
Electronics.
Security.
Tools.

And then there was the creative side:

Music.
Songwriting.
Guitars.
Sound.
Stories.
Design.
Worldbuilding.
Making things simply because I wanted them to exist.

I kept trying to figure out which one I was supposed to be.

Was I a software engineer who happened to make music?

Was I a musician who knew how to code?

Was CitrusWorx the "serious" technical work while Blackwater Sound was the creative side project?

Eventually I realized that the question itself was wrong.

They were never supposed to be separate.

Technology Was Becoming My Identity

I love technology.

That hasn't changed.

I love opening something up and figuring out how it works.

I love understanding systems.

I love asking why an architecture was designed a certain way, why a circuit behaves the way it does, why a programming language made a particular tradeoff, or why an old amplifier sounds different from a modern one.

I can happily spend hours thinking about software architecture, operating systems, networking, electronics, programming languages, rendering engines, distributed systems, or some obscure piece of computer history.

But somewhere along the way, technology went from being something I used to becoming something I felt obligated to center my identity around.

And that distinction matters.

Because I'm not interested in technology simply for technology's sake.

I'm interested in what technology allows people to make.

That realization changed how I think about nearly everything I'm building.

The Artist Gets to Drive Now

I've started thinking about myself differently.

My artistic and creative side gets to take the reins.

My technical side doesn't disappear.

It becomes the superpower.

Instead of asking:

What technology should I build?

I'm more interested in asking:

What do I want to create, and what technology would make that possible?

That might sound like a small difference.

For me, it isn't.

It changes the entire direction of the work.

The destination is no longer dictated by the technology.

The destination is dictated by the thing I want to make.

The engineer figures out how to get there.

Blackwater Sound + CitrusWorx

This realization also helped me understand something about the different projects I've been building.

Blackwater Sound and CitrusWorx aren't competing identities.

They belong together.

Blackwater Sound is where a lot of the musical and creative work lives.

Within that world are projects like:

berylaudio — audio software, plugins, pedals, and tools
WINK Guitar — guitars, basses, mandolins, education, and instrument making
LIME Amplification — guitar amplifiers and cabinets

And then there is CitrusWorx, where much of my engineering, software, systems thinking, research, and technology work lives.

Those worlds don't need a wall between them.

In fact, separating them makes both of them weaker.

An amplifier is art and engineering.

A guitar is art and engineering.

A pedal is art and engineering.

A synthesizer is art and engineering.

A recording studio is art and engineering.

An audio plugin is art and engineering.

Even the modern music industry itself is inseparable from technology.

The history of music is full of people abusing, modifying, misusing, inventing, rebuilding, and reimagining technology in the pursuit of a sound that didn't exist yet.

That is much closer to the kind of technologist I want to be.

Kiwi Engine Still Matters

This doesn't mean I'm abandoning software.

Quite the opposite.

I'm returning to Kiwi Engine with a clearer reason for why I want it to exist.

Kiwi Engine is my web application engine.

The goal is for the sites, tools, applications, and digital experiences throughout this ecosystem to be built on technology that I understand and can shape.

But Kiwi Engine no longer needs to be the center of the universe.

It is infrastructure.

It is a workshop.

It is a toolbench.

It is something I can use to build the experiences surrounding the things I actually care about.

Maybe that means building software for musicians.

Maybe it powers an interactive guitar-building course.

Maybe it becomes the foundation for an amplifier design notebook.

Maybe it runs tools for organizing recording sessions.

Maybe it powers documentation for an open hardware project.

Maybe it becomes part of an ecosystem for musicians who want more ownership over their creative tools.

Maybe none of those ideas look exactly the way I imagine them today.

That's fine.

The important thing is that the technology is serving the creative work instead of the creative work becoming an excuse to build technology.

I Want to Talk About Things That Make Noise

I also realized something about what I actually enjoy writing and talking about.

I don't want every article I write to be:

"Here are ten JavaScript tricks."

"Here's another framework comparison."

"Here's how I configured Kubernetes."

There's nothing wrong with those articles.

I'll probably still write some of them.

But I also want to write about why a particular guitar pickup sounds the way it does.

I want to explore what happens inside a tube amplifier.

I want to talk about distortion circuits.

I want to tear apart pedals and understand their topology.

I want to study recording techniques.

I want to explore the history of instruments.

I want to talk about the technology that changed music.

I want to study the technology behind famous recordings.

I want to understand why certain pieces of gear became culturally important.

I want to build audio software and then explain exactly how it works.

I want to make instruments.

I want to write songs.

I want to create sounds that didn't exist before.

And yes, somewhere in the middle of all of that, I will probably write a ridiculous amount of code.

That sounds much more like me.

Creative Engineering

Maybe the best term I have for all of this is creative engineering.

Engineering without creativity becomes optimization without direction.

Creativity without execution can remain an idea forever.

Put the two together and things start happening.

You can imagine a sound and then design the circuit that creates it.

You can imagine an instrument and then learn the woodworking, electronics, acoustics, manufacturing, and design required to build it.

You can imagine a piece of software and then write the engine underneath it.

You can imagine a world and then write the stories, compose the soundtrack, create the artwork, and build the systems that let someone experience it.

That's the intersection I want to live in.

Not purely art.

Not purely technology.

Making things.

Technology Is an Instrument

A guitar player doesn't usually build their identity around the screwdriver they used to adjust the bridge.

A carpenter doesn't wake up every morning wondering whether they are primarily a table-saw person or a bandsaw person.

The tool matters.

Mastery matters.

Understanding the tool deeply matters.

But the tool exists in service of the work.

I'm starting to think about software the same way.

Programming languages are tools.

Frameworks are tools.

Cloud platforms are tools.

AI is a tool.

Electronics are tools.

CAD is a tool.

Manufacturing is a tool.

Kiwi Engine is a tool.

And I absolutely want to understand my tools.

I want to modify them.

I want to build my own when necessary.

I want to know what is happening underneath the abstraction.

That curiosity isn't going anywhere.

But the tool doesn't get to decide what I make.

I'm Still an Engineer

There's a funny thing about saying that technology isn't my identity anymore.

It doesn't make me less technical.

If anything, I think it gives me permission to become more technical.

Because now the learning has somewhere to go.

DSP isn't just mathematics.

It's how I create an audio plugin.

Electronics isn't just circuit theory.

It's how I design a pedal or amplifier.

Web development isn't just another application stack.

It's how I build the platform around my creative work.

Embedded programming isn't just firmware.

It's how I make physical objects respond to musicians.

Acoustics isn't just physics.

It's how I understand an instrument.

Manufacturing isn't just production engineering.

It's how an idea becomes something another person can hold in their hands.

Those connections make me want to learn more, not less.

Coming Back Different

I took some time away from developing Kiwi Engine.

I took some time away from writing.

At first, that felt like I had stopped.

Now I think I was recalibrating.

I'm coming back with a different hierarchy.

The artist decides what should exist.

The designer determines what it should feel like.

The engineer figures out how to make it work.

The researcher figures out what we can learn from everyone who came before us.

The craftsperson builds it.

And sometimes all of those people happen to be the same person.

That's the part I'm finally learning to embrace.

I still love software.

I still love systems.

I still want to build Kiwi Engine.

I still want to explore strange technical rabbit holes.

But I also want to build guitars.

I want to make amplifiers.

I want to design pedals.

I want to create plugins.

I want to write songs.

I want to study music history.

I want to understand why things sound the way they do.

I want to make things that are technical, artistic, useful, strange, beautiful, complicated, simple, loud, quiet, digital, analog, physical, and occasionally completely unnecessary.

Because sometimes "I wonder if I can build this" is reason enough to start.

Technology isn't going away.

It just isn't sitting in the driver's seat anymore.

The artist is driving now.

The engineer is riding shotgun.

And I think we're going to build some interesting things.

Why Juice Generates CSS Instead of Owning It

Drew Marshall — Wed, 01 Jul 2026 19:21:27 +0000

One design goal I’ve had for Juice from the beginning is that it shouldn’t try to replace CSS.

CSS already exists.

It’s incredibly capable.

The web doesn’t need another styling language.

Instead, I wanted Juice to answer a different question:

How can a design system express intent while still producing plain CSS?

Configuration Becomes The Source Of Truth

Recently I added support for configuration-driven stylesheet generation.

Instead of shipping every possible style with Juice, the framework consumes a project configuration and generates stylesheets from it.

Think of it as a theme generator.

The configuration defines things like:

Colors
Typography
Spacing
Shadows
Borders
Radius
Animations
Design tokens

Juice then generates the stylesheets those decisions require.

Why This Matters

One concern I have with many frameworks is that applications slowly become dependent on the framework itself for every design decision.

Eventually the framework becomes responsible for everything.

That wasn’t the direction I wanted.

Instead, I wanted the project to own its design language.

Juice simply helps express it.

The Framework Shouldn’t Own Your Brand

Every application has its own identity.

Its own colors.

Its own typography.

Its own spacing.

Those things belong to the project.

Not the framework.

Juice shouldn’t tell you what your design system looks like.

It should help you implement it consistently.

Configuration Is Documentation

An unexpected benefit is that the configuration becomes documentation.

Instead of searching through dozens of CSS files, you can understand an application’s design language by reading a single configuration.

The project becomes easier to reason about.

The styling becomes intentional.

Final Thoughts

I don’t want Juice to become another framework that tries to solve every styling problem.

I want it to become a design system engine.

The project defines the language.

Juice helps enforce it.

That’s a much more sustainable relationship than asking a framework to own every design decision.

Why Juice Generates CSS Instead of Owning It

Drew Marshall — Wed, 01 Jul 2026 19:21:27 +0000

One design goal I’ve had for Juice from the beginning is that it shouldn’t try to replace CSS.

CSS already exists.

It’s incredibly capable.

The web doesn’t need another styling language.

Instead, I wanted Juice to answer a different question:

How can a design system express intent while still producing plain CSS?

Configuration Becomes The Source Of Truth

Recently I added support for configuration-driven stylesheet generation.

Instead of shipping every possible style with Juice, the framework consumes a project configuration and generates stylesheets from it.

Think of it as a theme generator.

The configuration defines things like:

Colors
Typography
Spacing
Shadows
Borders
Radius
Animations
Design tokens

Juice then generates the stylesheets those decisions require.

Why This Matters

One concern I have with many frameworks is that applications slowly become dependent on the framework itself for every design decision.

Eventually the framework becomes responsible for everything.

That wasn’t the direction I wanted.

Instead, I wanted the project to own its design language.

Juice simply helps express it.

The Framework Shouldn’t Own Your Brand

Every application has its own identity.

Its own colors.

Its own typography.

Its own spacing.

Those things belong to the project.

Not the framework.

Juice shouldn’t tell you what your design system looks like.

It should help you implement it consistently.

Configuration Is Documentation

An unexpected benefit is that the configuration becomes documentation.

Instead of searching through dozens of CSS files, you can understand an application’s design language by reading a single configuration.

The project becomes easier to reason about.

The styling becomes intentional.

Final Thoughts

I don’t want Juice to become another framework that tries to solve every styling problem.

I want it to become a design system engine.

The project defines the language.

Juice helps enforce it.

That’s a much more sustainable relationship than asking a framework to own every design decision.

Architecture Doesn’t Care What You Build

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

One of the biggest realizations I’ve had while building KiwiEngine is that architecture doesn’t really care what you’re building.

An authentication system doesn’t know whether it’s protecting an artist website or an accounting platform.

An API doesn’t care whether it’s serving a CRM or a music player.

A routing system doesn’t know if it’s powering an e-commerce store or a game launcher.

Good architecture solves engineering problems.

The domain simply gives those solutions a purpose.

That realization completely changed how I think about KiwiEngine—and more importantly, how I think about the software I want to build.

Architecture Solves Engineering Problems

The longer I’ve worked on KiwiEngine, the more I’ve realized that many of the problems we solve are universal.

Authentication.

Authorization.

Routing.

Caching.

State management.

Content management.

Documentation.

These challenges exist regardless of the application.

A music platform still needs users.

An online store still needs payments.

An artist website still needs content.

A game launcher still needs updates.

The engineering principles don’t suddenly change because the audience does.

Domains Give Architecture Purpose

If architecture doesn’t care about the domain, people certainly do.

For a long time, I assumed that because KiwiEngine could support business applications, I should be the one building them.

CRMs.

Inventory systems.

Scheduling platforms.

SaaS products.

The architecture was capable.

But I slowly realized something important.

Capability and calling aren’t the same thing.

Curiosity Is A Better Compass

Looking back over the projects that energized me, a clear pattern emerged.

I kept returning to creative technology.

Music production.

Artist websites.

Plugins.

Media platforms.

Game development.

Digital publishing.

Those weren’t distractions from KiwiEngine.

They were the best proving ground for it.

Every time I worked on those projects, I naturally discovered improvements to the framework because I genuinely depended on it.

The software wasn’t theoretical anymore.

It became part of my own workflow.

Open Source Changes The Equation

One of the greatest strengths of open source is that it removes the pressure to build everything yourself.

KiwiEngine doesn’t need me to build every CRM.

Or every scheduling platform.

Or every business application.

If someone wants to build those things, I hope KiwiEngine becomes a solid foundation for their work.

My role is to build the engine.

Document the philosophy.

Share the blueprints.

Teach what I’ve learned.

The community can take those ideas in directions I would have never imagined.

The Best Software Comes From Understanding

I’ve come to believe that software improves when its creator genuinely understands the people using it.

I understand creators because I am one.

I write songs.

I produce music.

I mix and master.

I build games.

I design graphics.

I enjoy creating things.

Building software for those communities isn’t narrowing KiwiEngine’s vision.

It’s giving it a better proving ground.

Final Thoughts

KiwiEngine hasn’t changed.

Its architecture hasn’t changed.

Its philosophy hasn’t changed.

What has changed is my understanding of where I create the most value.

Architecture doesn’t care whether you’re building software for musicians, accountants, educators, or game developers.

People do.

And the better you understand the people you’re building for, the better your software becomes.

That’s why I’m no longer chasing every market.

I’m choosing the one I understand best—and letting the architecture do what it was designed to do.