When you're building a product that needs both a mobile app and a web app, there's a decision point early on: do you build two frontends against one backend, or do you try to share more than that?
Most teams end up with two frontends, one backend, and a growing list of small inconsistencies between them. A field gets added on mobile and forgotten on web. A validation rule changes in one place and not the other. Nothing catastrophic, just a slow accumulation of drift.
I built Underpeaks around a different assumption: the schema shouldn't just define your backend, it should define your applications too.
How that plays out technically
A model in Underpeaks isn't just a database table definition. It carries enough information, field types, UI hints, relationships, validation, to generate a working page in both a Flutter app and a Next.js app. Change the model, regenerate, both applications reflect the change.
The generation isn't destructive either. Files you've customized are tracked via checksums and left untouched on regeneration. Only genuinely new pieces (a newly added field, say) get merged in. This matters a lot in practice, generated code you can't safely touch is generated code you'll eventually abandon.
The database layer
Underpeaks runs on five database backends (Supabase, Postgres, MySQL, MongoDB, Firebase) through one adapter interface. This was a deliberate choice: teams shouldn't have to commit to a database vendor just to use a code generation tool. Same schema, same generated output, regardless of which one sits underneath.
Self-hosted by default philosophy
Underpeaks Core is free, open source, and self-hosted. I built it this way first, before the hosted version, because I wanted the tool to work fully even for someone who never pays for anything. Underpeaks Studio (hosted) exists for teams that want managed infrastructure, not because the self-hosted option is deliberately limited.
Launching on Product Hunt today: https://www.producthunt.com/products/underpeaks?launch=underpeaks
Genuinely interested in hearing how other people have approached this same problem, shared schemas, code generation, monorepo strategies, whatever's worked or not worked for you.
