Coreola

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.

Most dev tools in the admin/template space are component galleries. You scroll the landing page, see 47 beautifully styled cards, charts, and modals, and think, yes, this will save me months.

Then you start building. The cards don't compose. The chart needs filters the demo didn't have. The modal opens fine, but nothing in the gallery showed you how to wire it to a real workflow. By week two, you're back to building from scratch — except now you also have someone else's design system to fight with.

Every demo is a snapshot. Your product is a movie.

When I started building Coreola, I had to make a call: ship breadth (a huge gallery of components and screens, like everyone else) or ship depth (two complete modules at production complexity). Breadth would have been faster, looked more impressive in screenshots, and gotten more "wow" reactions on Twitter. I went with depth anyway.

Two modules in the box:

• Assessments — a multi-step workflow with a backend-driven state machine, a queue view, detail pages with side panels and tabs, status transitions with permission checks, and all the surrounding workflow plumbing. This is the "your product has a process" module.

• Customers — a server-driven list with filters that live in the URL, saved segments, a detail page with related data, and bulk actions. This is the "your product has a lot of data" module.

The point was not to show every possible UI piece. The point was to prove that the same foundation survives different kinds of product complexity.

Why those two specifically? Because almost every admin-heavy product is some mix of those two shapes. A CRM is mostly Customers. A compliance tool is mostly Assessments. A support platform is both. If the patterns hold up for these two, they hold up for the product you're actually building.

The cost of doing it this way: months of extra work I couldn't show in marketing screenshots. A landing page with fewer flashy thumbnails. Some people will scroll past because they expect a huge gallery of cards and screens.

The payoff: every buyer who actually evaluates the product sees the same code patterns repeated at scale. The seams are visible before they pay. By the time they start from the codebase, they already know it doesn't fall apart on screen two — because they've seen it not fall apart on screen twelve.

The lesson I keep coming back to: in dev tools, depth is the only honest demo. Anyone can ship a card grid. Shipping a working product built with your own product is the actual proof.

For the indie founders here — when you're packaging your work, are you shipping screenshots or shipping proof? Curious where everyone has landed on this.

— I built a React admin foundation called Coreola (coreola.com) where this whole "two modules instead of fifty demos" thing is the central bet.

I've spent the last two years studying what goes wrong in admin-heavy products — internal tools, SaaS back offices, ops dashboards. The failure modes are weirdly consistent. Here are the five I'd avoid if I were starting fresh today.

1. Table state lives in component state

You build a table. It has filters, sort, pagination, maybe a search box. You put all of that in useState. Works fine on screen one.

Then a customer asks: "Can I share a link to this filtered view?" You can't. Then: "When I click into a row and back, my filters are gone." You're rebuilding the whole thing as URL-driven six weeks in.

Build it URL-driven from day one. ?status=open&sort=-createdAt&page=2. Filters survive reloads, links are shareable, the back button works, and you get bookmarking for free.

2. Permissions written inline, everywhere

if (user.role === 'admin') scattered across 40 components. By month 3 you can't answer "who can do what" without grepping the codebase. By month 6, you ship a permissions bug to production.

Pick a real authorization library (CASL is what I use) and define abilities in one place. Components ask "can this user do X?" and don't know about roles at all. Routes guard themselves. Adding a role becomes an admin/configuration change instead of a frontend audit.

3. No story for empty/loading/error states

Every founder I've worked with builds the happy path first, then bolts on spinners and "no data" messages screen by screen. The result is 14 different loading spinners and 8 different ways to say "nothing here yet."

Pick one Empty, one Loading, one Error component on day one. Use them everywhere. Boring, fast, consistent. It is not glamorous, but it compounds — every shared state component removes one more tiny product decision from every future screen.

4. Forms reinvented per page

Every page has its own form state, its own validation logic, its own "is the submit button disabled?" rule. By feature 5, two engineers handle the same edge case differently.

Pick a form library (react-hook-form + Yup is my default), build one set of input wrappers that handle the validation/error display contract, and never touch raw HTML inputs in feature code again.

5. The "details page" isn't a pattern; it's a one-off every time

Each new entity gets its own bespoke details layout. Tabs in different places, "edit" behaving differently, breadcrumbs reinvented, the activity log on the right one page and on the bottom the next.

A details page is a pattern: header + tabs + main panel + side metadata + activity. Build it once. Every entity uses the same skeleton. Customers stop being confused. Engineers stop debating layout.

The common thread: the cost of an admin panel isn't the first feature. It's the fourth. The patterns that hurt aren't the ones that look wrong on screen one — they're the ones that look fine until you have five entities and the codebase starts contradicting itself.

I'd love to hear from anyone here who's been through this. What was the pattern you wished you'd standardized earlier?

— I built a React admin foundation called Coreola that bakes these patterns in by default. Happy to link in a comment if anyone's curious, but the post stands on its own.

You have an idea. You know the customer. You know what would make them pay. You start building.

Three weeks later, you're not building your product. You're building:

• A login page. A signup page. A password reset flow. Email verification.

• A users table. A roles system. A way to invite teammates.

• A settings page. A profile page. Avatar upload.

• A table that paginates, filters, sorts — server-side, because your data won't fit in memory.

• A dashboard with some KPIs because investors/customers/your mom want to see "the dashboard."

• A permissions layer because of course not every user can do everything.

• Empty states. Loading states. Error states. A toast system.

• Dark mode because someone will ask.

None of this is your product. None of it is why a customer would pay you. None of it is in your pitch deck. And it's somehow four months of work.

Then you ship your second real feature and realize half of what you built doesn't generalize. The table component was fine for the first screen, dies on the second. The permissions check you wrote is now in 14 places. You're rebuilding things you already built.

This is where most solo founders lose six months of runway. Not on the hard problems. On the floor.

I built Coreola because I watched this happen — to me, to other founders, to entire teams at companies that should have known better. It's a working React admin foundation with all of the above already done: auth, RBAC, server-driven tables, dashboards, workflow states, the lot. Two real modules in the box so you can see how the patterns hold up past screen one. You fork it, you own the code, you start day one with the boring six months already behind you.

The pitch isn't "look at my pretty UI." The pitch is: the first sprint of your product should be the feature your customer is paying for, not the login page.

For anyone here building operational SaaS, internal tools, or admin-heavy products — what did you wish you'd skipped in month one? I'm trying to learn where the pain is sharpest.

Website: https://coreola.com
Demo: https://demo.coreola.com
Docs: https://docs.coreola.com

I launched Coreola — a React admin foundation for founders building SaaS products faster

I launched Coreola on May 22.

Coreola is a React admin foundation for SaaS back offices, internal tools, and product workflows.

Website: https://www.coreola.com
Demo: https://demo.coreola.com
Docs: https://docs.coreola.com

The simple idea behind it is this:

Most products do not fail because the first dashboard screen was hard to build.

They slow down because of everything that comes after it.

Permissions. Tables. Filters. Feature flags. Settings. Routing. Loading states. Empty states. API errors. User management. Documentation. Repeated UI decisions. Repeated architecture decisions.

The boring things that are not exciting on day one, but become expensive very quickly.

That is the problem I am trying to solve with Coreola.

Why I built it

When you start a new SaaS product, it is tempting to focus only on the public-facing part first.

The landing page. The signup flow. The main feature. The dashboard.

But very soon, every real product needs an admin layer.

You need to manage users. You need roles and permissions. You need tables that can handle real data. You need filters. You need feature flags. You need settings. You need workflows. You need a structure that will not collapse after the next 50 features.

And if you are an indie hacker, this is painful.

Not because you cannot build it.

You can.

But should you spend weeks rebuilding the same admin foundation again and again?

That is where Coreola comes in.

What Coreola is

Coreola is not just another React dashboard template.

A dashboard template usually gives you screens.

Coreola is meant to give you a product foundation.

It includes patterns and structure for things like:

• admin layouts

• authentication flows

• protected routes

• roles and permissions

• feature flags

• advanced tables

• filters and saved states

• settings and profile flows

• real workflow modules

• reusable UI patterns

• mock API

• documentation

• maintainable React architecture

The goal is not to give you one pretty screenshot.

The goal is to give you a base that can survive real product development.

Why this matters more now

AI can generate UI screens faster than ever.

That is useful. But it also creates a new problem: it is now easier than ever to generate messy, inconsistent product code.

For me, that makes structure more important, not less important.

Coreola is designed as a foundation that both developers and AI tools can extend safely. Instead of asking AI to invent your admin architecture from scratch, you can start with a real structure, clear conventions, and working product patterns.

AI can help you move faster.

Coreola gives it somewhere sane to move.

Who it is for

Coreola is for people building products where the admin side matters:

• Indie hackers building SaaS products

• founders building back-office tools

• developers building internal products

• agencies that repeatedly build admin panels for clients

• small teams that want to start from a serious foundation instead of a blank repo

It is especially useful if you want to move fast, but you still care about architecture, consistency, and long-term maintainability.

Pricing for the first 100 buyers

For the first 100 buyers, I am offering early pricing:

• Personal license: $199

• Team license: $599

The idea is simple: early buyers get the best price while Coreola is still growing, and their feedback will directly shape the next versions.

What launched on May 22

May 22 was the first public launch of Coreola.

The core foundation is ready, the demo is live, and the documentation is available:

Website: https://www.coreola.com
Demo: https://demo.coreola.com
Docs: https://docs.coreola.com

I am starting with the core admin experience and will keep improving it based on feedback from real builders.

Right now, I am especially interested in learning:

• What do you rebuild in every SaaS/admin product?

• What part of admin development wastes the most time?

• Do you prefer starting from a foundation like this, or building from scratch?

• What would make a product like Coreola immediately useful for your next project?

Why I think Indie Hackers is the right place to share it

Coreola is not built for people who want to collect another UI kit.

It is built for people who want to launch products.

That is why I think Indie Hackers is the right audience.

If you are building a SaaS product, the admin side is probably not your main business idea. But you still need it. And if you build it badly, it will slow everything else down.

Coreola exists to help you skip the repeated foundation work and get to the actual product faster.

What’s next

I am going to share more about the product, the architecture, the decisions behind it, and the launch process.

For now, I would love honest feedback from other founders and builders:

Would you use a React admin foundation like this for your next SaaS product?

And what would it need to include for you to trust it?