2
1 Comment

Why I shipped 2 real modules instead of 50 pretty demos

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.

posted toAvatar for product Coreola
Coreola
  1. 1

    What stood out to me is that every "no" in your post is really a decision about who gets to say "yes" to the product. Refusing a workflow builder, a managed backend, or a custom design language isn't just reducing scope—it narrows the buyer until the product becomes much easier to understand. That line about a feature you didn't build being a positioning statement feels especially true.