From MVP to production
Every boilerplate makes a bet about what stage you are at. geenius-mvp bets you are pre-validation: the scarcest resource is the time between your idea and a live URL real users can react to, and everything else is negotiable. That bet explains what is in the box — and, just as deliberately, what is not.
What an MVP boilerplate should optimize for
Speed to validated. One stack decision made for you (React plus Vite, Convex or Supabase), one command to scaffold, one command to deploy, and enough real product surface — auth, billing, an admin, an MCP server — that your demo is not a toy. Opinionated defaults are the feature: every option we removed is a decision you do not spend a day on before you know whether anyone wants the product. The 100 designs exist so the MVP looks finished; the feature registry exists so the next screen costs an afternoon; the quality gates exist so the scaffold is never the bug.
What production needs instead
Then the product works, and the constraints invert. Production means meeting requirements you did not choose: the client's framework is Next or Nuxt, not yours. The data lives in the Postgres flavor the enterprise already runs. The design system has to be the company's, expressed in the UI library their team knows. You need i18n because the second market is Germany, billing that survives real scale, and packages you can upgrade independently instead of a template you scaffolded once. An MVP boilerplate that tried to carry all of that would be slower at its actual job.
Graduating without rewriting
This is where the design of geenius-mvp is honest about its lineage: it is the small sibling of the full Geenius boilerplate at geenius.dev — 4 frameworks, 5 or more databases, 15 UI libraries, and 50 production packages — and it deliberately shares that ecosystem's conventions. The ideas you internalized here are the same ideas there, at larger scale:
- Features as registered modules — the FeatureModule registry becomes a catalog of installable feature packages
- Theming as a CSS-variable token contract — the design/accent/mode axes become full design-system tooling across UI libraries
- Machine-readable tooling — JSON manifests, doctor checks that name their fix, and one-line parseable results run through the whole ecosystem
- Backend idioms respected per database — the Convex-versus-Supabase philosophy extends across the database matrix
- AGENTS.md as the canonical playbook — every repo is agent-drivable the same way this one is
So graduation is a step up, not a rewrite. Your domain logic — the schema blocks, the entity configs, the feature folders — is exactly the part that transfers, because it was always expressed in conventions the full ecosystem shares. What changes is the substrate underneath: more frameworks to target, more databases to choose, packages with real versioning instead of a scaffolded template. The mental model you built while shipping the MVP is the mental model production uses.
The honest boundary
There is no automatic converter, and we will not pretend otherwise — moving to a different framework or database is real work no tool absorbs completely. The claim is narrower and more useful: none of that work is undoing. You will not be unwinding architecture decisions that only made sense in a demo, because the MVP's architecture was a scaled-down version of the production one from the start. Plenty of validated products also just stay on geenius-mvp for a long time — a Convex app with billing, admin, and an MCP server is not a prototype.
Optimize the MVP for speed to validated; make sure what survives validation is the part you keep.
Build the MVP here. If it wins, the same conventions are waiting for you at production scale.