DEV Community: Drew Marshall

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.

Finding The Customer You Understand

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

One piece of startup advice you'll hear often is:

"Find a problem worth solving."

I agree.

But I think there's another question that's just as important.

Find a customer you genuinely understand.

For a while, I tried thinking about software markets in general.

Small businesses.

SaaS.

Enterprise.

Productivity.

Eventually I realized something.

I wasn't excited because of the market.

I was excited by the work itself.

Music.

Creative software.

Audio engineering.

Game development.

Design.

Those aren't hobbies sitting beside software.

They're the reason I build software.

Your Experience Is An Advantage

Every builder has accumulated years of experience in something.

Mine happens to include music production, songwriting, game development, design, and software architecture.

Ignoring that experience would be like ignoring a built-in competitive advantage.

Instead of trying to become an expert in industries I don't live in, I've decided to build for the communities I already understand.

Not because they're bigger.

Because I can genuinely contribute something valuable there.

You Don't Have To Build Everything Yourself

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

One misconception I had early on was believing that creating a framework meant creating every application that framework could support.

That's impossible.

If KiwiEngine can build hundreds of different kinds of applications, why should one person try to build all of them?

The answer is simple.

They shouldn't.

Open Source Is Multiplication

Open source isn't about creating every solution.

It's about creating more builders.

The framework provides the foundation.

The community provides the imagination.

Some people will build business software.

Others will build education platforms.

Others will build games.

Others will build entirely new ideas I haven't even considered.

That's far more exciting than trying to own every application myself.

Build The Blueprint

I've become increasingly interested in building blueprints rather than finished buildings.

A blueprint enables many buildings.

One application solves one problem.

A blueprint helps solve hundreds.

That's where I think the long-term value lives.

Not in trying to build everything.

But in making it easier for others to build anything.

Burnout Was Trying To Tell Me Something

Drew Marshall — Sat, 27 Jun 2026 12:53:07 +0000

For a long time, I assumed burnout meant I wasn't working hard enough.

Or that I needed better discipline.

Or better time management.

Looking back, I think something else was happening.

Burnout was feedback.

Every time I forced myself toward projects that didn't naturally fit my interests, progress slowed.

Everything became heavier.

Then I'd spend an evening designing a music application, thinking about plugin architecture, composing music, or sketching ideas for Blackwater Sound.

Hours disappeared.

The energy came back.

Passion Is Data

I don't think passion should replace discipline.

But I do think it's worth paying attention to.

If you consistently find yourself energized by one type of work and drained by another, that's information.

Not an excuse.

Information.

It tells you where your curiosity naturally lives.

Alignment Creates Momentum

Today I still believe KiwiEngine can power almost any kind of application.

What has changed is how I'm choosing to use it.

Instead of chasing every possible market, I'm building creative tools that I personally want to use every day.

Ironically, I think that will make KiwiEngine stronger.

Because software improves the most when its creator genuinely depends on it.

Sometimes burnout isn't telling you to stop building.

Sometimes it's telling you to build the right thing.

Why I Stopped Chasing Every Market

Drew Marshall — Sat, 27 Jun 2026 12:46:48 +0000

One of the biggest realizations I've had over the last year wasn't about software.

It was about focus.

When I first started building KiwiEngine, I wanted it to power everything.

Business software.

CRMs.

Inventory systems.

Scheduling platforms.

Accounting tools.

SaaS products.

If someone could build it, I wanted KiwiEngine to support it.

Technically, I still do.

But something changed.

I realized there is a difference between building software that can solve every problem and trying to solve every problem yourself.

Those aren't the same thing.

The Architecture Never Changed

KiwiEngine is still designed to power business applications.

Nothing about the architecture changed.

The modules.

The APIs.

The philosophy.

The engine remains general-purpose.

What changed was my focus.

Build What You Understand

I started asking myself a simple question.

Who do I actually understand?

Not as a developer.

As a creator.

The answer wasn't accountants.

It wasn't HR departments.

It wasn't inventory managers.

The answer was musicians.

Artists.

Game developers.

Creators.

Builders.

Those are the people whose problems I experience every day.

Those are the workflows I naturally understand.

Open Source Changes The Equation

One of the beautiful things about open source is that I don't have to build every application.

I can build the engine.

I can document it.

I can share the philosophy.

Someone else can build the CRM.

Someone else can build the scheduling platform.

Someone else can build the accounting software.

Meanwhile, I can focus on building the creative tools I genuinely want to use.

The Best Proving Ground

Today, KiwiEngine's proving ground is becoming:

Artist websites
EPKs
Music production tools
Digital storefronts
Creative workflows
Game development
Media platforms

Not because they're the only things KiwiEngine can build.

Because they're the things I care deeply enough to refine every day.

And I think that creates better software than chasing every possible market ever could.

The API Design Lesson I Learned From Building Nectarine

Drew Marshall — Fri, 26 Jun 2026 18:00:00 +0000

One of the most surprising lessons I've learned while building software is that APIs are not really about code.

They're about communication.

At first, that sounds strange.

After all, APIs exist so software can talk to software.

But every API is also a conversation between developers.

And like any conversation, clarity matters.

The First Version Is Usually Technical

Most APIs begin from an implementation perspective.

The database exists.

The endpoints exist.

The underlying logic exists.

The API becomes a reflection of those details.

It exposes how the system works internally.

The problem is that users often don't care about internal implementation.

They care about solving problems.

Intent Is Easier To Understand

One idea I've become increasingly interested in is designing around intent.

Instead of asking:

"How should users interact with the implementation?"

I try to ask:

"What are users trying to accomplish?"

The difference seems small.

The results are often significant.

Intent tends to produce simpler APIs.

Clearer workflows.

Better naming.

Better abstractions.

The Database Is Not The Product

One mistake many systems make is exposing internal structures directly.

Tables become endpoints.

Schemas become workflows.

Implementation becomes the interface.

This is understandable.

It's also limiting.

The API should represent the problem domain.

Not necessarily the storage mechanism.

Good APIs Read Like Conversations

The best APIs I've encountered often feel obvious.

Not because they're simplistic.

Because they're expressive.

You can often read the code and understand the intention behind it.

The API communicates purpose.

Not just mechanics.

Real Usage Changes Everything

Just like documentation, abstractions, and frameworks, APIs reveal themselves through usage.

The first version is rarely the final version.

Real projects expose awkward naming.

Unexpected workflows.

Missing concepts.

Confusing assumptions.

The API evolves as understanding evolves.

The Hidden Goal

I used to think API design was primarily about flexibility.

Now I think it's more about reducing misunderstanding.

Every confusing name creates hesitation.

Every unclear workflow creates friction.

Every implementation detail exposed unnecessarily creates cognitive load.

The best APIs reduce those costs.

Final Thoughts

The longer I build software, the less I think about APIs as technical interfaces.

I think about them as communication tools.

A good API helps developers understand a system.

A great API helps developers forget the system exists and focus on solving the problem instead.

That's the lesson I'm continuing to learn while building software.

And it's one that seems to apply far beyond APIs themselves.

Why I Stopped Adding Features and Started Removing Friction

Drew Marshall — Thu, 25 Jun 2026 16:55:37 +0000

Early in a project, adding features feels like progress.

A new capability appears.

A new screen gets built.

A new workflow becomes possible.

Everything feels like forward motion.

For a long time, I assumed that was the primary job of software development.

Build more features.

Solve more problems.

Expand the system.

Over time, I've started to think differently.

Some of the most valuable improvements I've ever made weren't new features.

They were reductions in friction.

Features Create Possibilities

Features matter.

Users need capabilities.

Products need functionality.

Without features, software doesn't solve problems.

The challenge is that every feature introduces complexity.

Every button.

Every setting.

Every workflow.

Every API.

Every configuration option.

The system grows.

Sometimes that's necessary.

Sometimes it's expensive.

Friction Is Easier To Ignore

One reason friction survives so long is because it often looks small.

An extra click.

An extra configuration step.

A confusing name.

A repetitive workflow.

None of these things seem important individually.

But software isn't experienced one interaction at a time.

It's experienced as a whole.

Small friction accumulates.

The User Feels Everything

As builders, we often focus on what software can do.

Users focus on how software feels.

The difference matters.

A powerful feature that creates frustration may deliver less value than a simple workflow that feels effortless.

The experience is part of the product.

Not just the functionality.

Real Projects Expose Friction

One reason I believe strongly in building real projects is because friction becomes impossible to ignore.

Features tend to dominate planning meetings.

Friction dominates daily usage.

You feel it.

Repeatedly.

The same awkward workflow.

The same repetitive task.

The same confusing decision.

Eventually the problem becomes obvious.

Removing Friction Creates Leverage

A feature helps users do something new.

Removing friction helps users do everything faster.

That's a different kind of value.

The improvement compounds.

Every interaction benefits.

Every workflow benefits.

Every future feature benefits.

The Hidden Metric

I've started paying attention to a question that rarely appears on roadmaps:

"How much effort does this require to understand?"

Not implement.

Not maintain.

Understand.

Understanding is one of the most expensive costs in software.

Reducing friction often means reducing the effort required to understand the system.

Final Thoughts

Features are important.

But they're not the only way software improves.

Sometimes the best feature is the removal of a problem users encounter every day.

The longer I build software, the more I find myself asking:

Not "What should we add next?"

But:

"What can we make easier?"

Because removing friction often creates more value than adding another feature ever could.

Why Constraints Create Better Software

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

When developers talk about software design, flexibility is usually treated as an unquestionable good.

More options.

More customization.

More configuration.

More control.

The assumption is simple:

More freedom equals better software.

I'm no longer convinced that's true.

In many cases, the opposite seems to happen.

The most successful systems often become successful because of their constraints.

Every System Has Rules

Whether we acknowledge them or not, every system operates within constraints.

Programming languages have syntax.

Frameworks have conventions.

Databases have schemas.

Operating systems have permissions.

The question isn't whether constraints exist.

The question is whether they're intentional.

Good constraints guide behavior.

Bad constraints create frustration.

Constraints Reduce Decisions

Every decision requires effort.

Every configuration option requires understanding.

Every customization path requires maintenance.

One reason good software feels simple is because it removes unnecessary decisions.

The system makes sensible choices so users can focus on solving problems.

Not configuring tools.

Consistency Creates Trust

One of the hidden benefits of constraints is consistency.

When developers encounter the same patterns repeatedly, they begin building intuition.

The system becomes predictable.

Predictability creates confidence.

Confidence creates speed.

The result is often greater productivity than a completely unrestricted system.

Languages Depend On Constraints

Languages work because of grammar.

Without shared rules, communication becomes difficult.

Frameworks are similar.

The more a framework grows, the more important consistency becomes.

Conventions become vocabulary.

Patterns become expectations.

The system develops a language.

And languages require rules.

Real Projects Reveal Useful Constraints

The best constraints rarely emerge from theory.

They emerge from usage.

A real project exposes confusion.

A real project exposes repetition.

A real project exposes complexity.

Over time, useful constraints begin to emerge naturally.

Not because someone imposed them.

Because reality demanded them.

The Goal Is Progress

I've started thinking about software design differently.

The goal isn't maximum flexibility.

The goal is maximum progress.

Sometimes progress requires freedom.

Sometimes progress requires constraints.

The challenge is knowing the difference.

Final Thoughts

Good constraints aren't limitations.

They're guidance.

They help developers focus on what matters.

They reduce cognitive load.

They create consistency.

They improve communication.

And over time, they help transform a collection of features into a coherent system.

The longer I build software, the more I find myself asking:

Not "What should this allow?"

But:

"What should this encourage?"

Building a Design System Without Recreating CSS

Drew Marshall — Mon, 22 Jun 2026 23:17:44 +0000

One of the easiest traps to fall into when building a design system is accidentally recreating CSS.

At first, it seems harmless.

You add a few utility classes.

Then a few responsive options.

Then a few layout helpers.

Then a few exceptions.

Before long, you've built an entirely new syntax for doing the exact same thing CSS already does.

I've become increasingly interested in a different approach.

Not replacing CSS.

Not hiding CSS.

Creating a layer above CSS that focuses on intent.

The Problem With More Options

Developers love flexibility.

I do too.

The challenge is that flexibility often comes with complexity.

Consider responsive layouts.

Many systems solve this by exposing every possible breakpoint and layout combination.

The result is powerful.

But it's also easy to end up with markup that spends more time describing implementation details than communicating purpose.

The system becomes harder to understand.

Not because it's incapable.

Because it's trying to describe everything.

Intent Versus Implementation

Lately I've been thinking less about how a layout is built and more about what the layout is trying to accomplish.

For example:

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

This isn't trying to replace CSS.

It's trying to express intent.

The content should adapt as a grid.

On mobile, it should stack.

The implementation details can remain inside the design system.

The goal isn't more abstraction.

The goal is better communication.

Strong Defaults Create Simplicity

One lesson I've learned from building software is that good defaults are often more valuable than endless configuration.

Most layouts follow common patterns.

Most responsive behavior follows common patterns.

Most developers aren't trying to create entirely new layout systems.

They're trying to organize content.

A design system can help by providing thoughtful defaults rather than exposing every possible option.

The Danger Of Recreating CSS

The moment a design system attempts to expose every CSS capability, it starts competing with CSS itself.

That's usually a losing battle.

CSS already exists.

CSS is already powerful.

CSS is already standardized.

The job of a design system isn't to replace CSS.

The job of a design system is to reduce cognitive load.

To create consistency.

To communicate intent.

To make common patterns easier.

Designing For Readability

One question I increasingly ask when designing APIs is:

"Can I understand this six months from now?"

Not:

"Can I configure everything?"

Not:

"Can I support every edge case?"

Simply:

"Can I read this and understand what it is trying to do?"

Readability scales.

Complexity doesn't.

The Goal Isn't Less Power

Sometimes simplicity gets mistaken for limitation.

I don't think that's true.

The goal isn't to remove power.

The goal is to place power where it belongs.

Common workflows should be simple.

Advanced workflows should remain possible.

The design system should help developers move quickly without preventing them from solving unique problems.

Final Thoughts

I've become increasingly convinced that the best design systems don't try to replace CSS.

They try to create a shared language around common design decisions.

A language focused on intent rather than implementation.

A language that helps developers communicate purpose.

Because at the end of the day, most developers aren't trying to build layouts.

They're trying to build products.

The layout is simply one part of the system.