The 3 features I'm proud I didn't build

Every feature has gravity. The moment you add it, it pulls other decisions toward itself. The docs have to cover it. The code has to be maintained. The marketing page has to position itself around it. The buyer expects it to keep working forever.

So the actual work of the product is saying no.

Here are three features I refused to build into Coreola (a React admin foundation for founders and engineers), and what each refusal made clearer.

1. A visual workflow builder

The temptation was huge. Every dev tool trending right now has some flavor of "drag boxes around to define your business logic." It demos beautifully. It expands the addressable market. It makes the product look modern in screenshots.

I said no.

The reason: the buyer I'm optimizing for is technical, and technical buyers do not want a visual builder. They want code they can read, version, diff in a PR, and extend with confidence. The moment you add a no-code layer, you split your product in half — half the users build through the UI, half through the code, and neither half is happy with how the two interact.

What this refusal cost me: a feature that would have looked great on the landing page.

What it bought me: a clear answer to "who is this for?" — builders writing code, full stop. Not engineering managers wanting to delegate to non-technical staff. Not consultants building one-off configurations. Just builders who want one good way to write a workflow in code, not two awkward ways split between UI and source.

2. A backend

The product ships json-server for local development. That is it. There is no hosted backend, no managed database, no API as a service.

Some prospects ask, "Do you handle the backend?" and for them, Coreola is not the right fit. I could fix that by spinning up a hosted layer, picking a database, writing auth, dealing with multi-tenancy, rate limits, and uptime. It would meaningfully increase what I can charge.

I said no.

The reason: shipping a backend turns a one-time codebase purchase into an ongoing operational responsibility. The product becomes a service. The pricing has to become a subscription. The support burden goes from "answer questions about the code" to "your prod is down at 3 am." A different company. Not the one I want to run.

What this refusal cost me: a real revenue lane, and some buyers who needed a turnkey product.

What it bought me: a product I can support solo, indefinitely, without dragging anyone's production environment with me. The buyers who remain are the ones who already have, or want to write, their own backend. That is a sharper buyer to talk to.

3. A visual language from scratch

Coreola has a design system. There is a real layer on top of MUI — a tighter type scale (13px base, not 16), a 4px spacing grid, a fixed component vocabulary (Table, DataList, EditableField, ConfirmDialog, EmptyState, ActionMenu, status indicators), standardized empty/loading/error patterns, and three canonical page layouts for catalogs, details, and dashboards. That is a design system.

What I refused to build was a new visual language underneath it. No fresh palette grammar, no hand-rolled primitives, no motion language invented from zero. The foundation is Material Design. The opinions on top are Coreola's.

This was the hardest refusal because inventing a visual language is fun. It makes the product feel "premium", and it is the kind of craft developers notice. I could have spent three months on a fresh look with no MUI underneath.

I said no.

The reason: a brand new design language is a product of its own. It needs documentation, versioning, contribution guidelines, accessibility audits, dark mode, RTL, density variants, and a roadmap. The day I ship one from scratch, I have started a second company by accident. Meanwhile, MUI already has all of that, plus a large ecosystem and years of community testing.

What this refusal cost me: a more distinctive aesthetic. Coreola looks like Material Design — because that is the foundation it builds on.

What it bought me: every hour I would have spent on primitives, I spent on the layer that actually matters — the conventions, components, and page patterns that make admin products feel coherent. And buyers who specifically want MUI (a real and large group) self-select toward me.

The pattern

Each refusal narrowed the buyer. That sounds bad until you realize the alternative — saying yes to everything — produces a product that is for nobody in particular.

The discipline I keep relearning: a feature you didn't build is also a positioning statement. Often a stronger one than the features you did.

For other founders here — what's the feature you're proudest you didn't build? Curious what other people have refused on purpose.

— Coreola (coreola.com) is the product of the three refusals above. Code-first, bring-your-own-backend, MUI-native. Not for everyone, deliberately.