new framework shows up every few months promising to make everything faster, simpler, more elegant. Some of them are genuinely good ideas. Almost none of them have been run in production long enough for anyone to know what breaks at year two — the upgrade path nobody wrote, the plugin ecosystem that quietly stopped maintaining itself, the one maintainer who moved on. You don't find that out by reading the launch post. You find out by being the client stuck migrating off it.
We'dratheryouownsomethingboringfortenyearsthansomethingexcitingfortwo.
text
Default stack, chosen for longevity over novelty: Web Next.js, TypeScript, Postgres iOS Swift, SwiftUI Backend Prisma, plain REST — no bespoke query layer Hosting Vercel / standard cloud, nothing exotic to operate
None of this is a hot take. That's the point. Every piece has a large community, a multi-year track record, and — crucially — more than one company you could hire if you ever needed to move off us. A product built on a tool only we understand isn't really yours; it's ours, and you're renting it. Boring, popular tools mean you could hand this codebase to a different developer next year and they'd recognize everything in it by lunchtime.
We'll reach for something newer when the boring option genuinely can't do the job — not because the new thing is interesting, but because there's no mature alternative yet. When that happens, we say so explicitly before you're committed to it, and we explain what the risk actually is, rather than quietly picking the fun tool and letting you find out later.
Maintainability is not an abstract preference for tidy code. It determines how safely another developer can change the product, how quickly a security update can be applied, whether common knowledge is written down, and how much of the original team must be reconstructed every time the business asks for something new.
- Supported dependencies with an active maintenance path and a clear reason for being included.
- Automated checks around the rules that would be expensive or embarrassing to break.
- A repository, deployment account, domain, analytics, and third-party services controlled by the client.
- Documentation for setup, environments, integrations, release steps, and unusual architectural decisions.
- A handover that lets a competent replacement team run and change the product without asking for hidden credentials.
The newest tool is not always risky, and an older tool is not automatically safe. The useful questions are whether the project depends on one unmaintained package, whether upgrades have a documented route, whether the team can remove the dependency if it fails, and whether the choice solves a real requirement rather than making the build more interesting.
Software cannot be durable if the client does not control the assets needed to operate it. The contract should say who owns the source code, designs, content, domains, data, and accounts after payment. Access should be transferred during the project rather than promised for a future handover. Backups and recovery matter too: a reliable stack without a recoverable database is still a fragile business system.