Why Every App I Ship Starts As a Piece of the Same Engine

I'm one person. I run a whole company's worth of production apps — invoicing, chargebacks, no-show recovery, a receptionist, and a shelf of other nouns that would each be a startup somewhere else. People assume I have a team hiding behind that, or that I ship shallow toys. Neither is true. The trick isn't headcount and it isn't cutting corners. It's that none of these are separate apps in the way they look. They're all pieces of the same engine.

The engine has a name — Kynth Core. Every app I ship starts as a piece of it, not as a project next to it. That one decision is what makes the math work.

The default way is a company per app

If you build software the normal way, each product is its own world. Its own auth. Its own billing wiring. Its own way of sending an email or a text, its own database conventions, its own idea of what a "record" is and what an "action" on that record looks like. Every new product means re-deciding all of it, then maintaining all of it forever.

That's fine when a product funds a team. It's fatal when the product is one of many and the team is one person. The cost isn't the first build — it's that every app you own is a standing tax. Ten worlds means ten sets of auth bugs, ten billing edge cases, ten places a vendor SDK can break. You don't scale that. You drown in it.

So I refused to have ten worlds.

One engine, many views

Here's what's actually shared. Auth is one thing — a single sign-in path, one gate that decides whether you're allowed into a workspace, wired once. Billing is one thing. The shell — the sidebar, the page header, the command palette, the way a list of records renders with sortable columns and filter tabs and keyboard navigation — is one set of primitives that every app imports. The way an app sends an email or a text or makes a call doesn't go through that app's own code; it goes through a shared capability layer, so "send a reminder" means the same thing everywhere and I fix it in one place.

What's left — the part that's genuinely different between invoicing and chargebacks — is small. It's the domain: what a record is, what the daily money action is, how the review queue reads. That's the app. Everything under it is the engine.

So a new app isn't a new codebase. It's a new view onto Core. I write the domain-specific labor and inherit the rest already built, already debugged, already shipping.

The economics of one-of-everything

The reason this compounds is boring and real: I only get to have one of each hard thing.

One auth flow. One billing integration. One list view. One review queue loop. When I improve any of them, every app improves at once. When I add keyboard navigation to the shared list, it's live in every app the next deploy. When I fix an edge case in how batches get sent, it's fixed everywhere. There is no "port it to the other apps" step because there is no other copy.

• Marginal cost of a feature drops toward zero. A shared primitive is written once and amortized across everything that renders it.
• Marginal cost of an app drops too. Most of an "app" already exists before I start it.
• Maintenance stops being linear. I'm not maintaining a company's worth of apps. I'm maintaining one engine and a thin domain layer per app.

That's the whole business model, honestly. Not "work faster." Build such that the work only happens once.

What it actually costs

I won't pretend this is free. Sharing has a price, and I pay it in discipline.

Every change to a shared primitive has to be additive — a new option, a new module, never a break. The moment I break a shared thing, I've broken every app that uses it. So the deploy is the gate: one build compiles and type-checks all the tenants together, and a broken one fails the build before it ever reaches production. That's on purpose. I want a cross-cutting change to either ship everywhere or fail loudly, never rot silently in one corner.

The other cost is taste. When one design system drives everything, a bad decision is also everywhere. So I don't get to be sloppy in a shared file the way you can be sloppy in a throwaway app. The blast radius keeps me honest.

And not everything wants to be shared. Some apps carry their own weird surface that doesn't generalize. The rule I hold to is: pull it into the engine only when a second app actually needs it. Sharing on speculation is how you get an abstraction nobody fits into. Two real users of a thing, then it graduates to Core.

Why I'd do it this way again

The honest summary: I'm not smarter or faster than a team. I've just arranged things so the expensive work is done once and reused, and the cheap work — the actual domain of each app — is all that's left to do per product.

That's why every app starts as a piece of the same engine. Not because it's elegant, though it is. Because it's the only shape of this that one person can actually carry. A whole company's worth of apps, one shared engine underneath, and me on top writing the part that's genuinely new. Everything else, I only had to build once.