Our Default Stack, and When We Throw It Out

The boring default, on purpose

For most web products we start with Next.js, Postgres, and whatever hosting gets us to a working staging URL fastest. None of that is exciting to write about, which is exactly why it's the default — it's the stack with the fewest surprises left in it. We're not choosing it to look modern in a case study; we're choosing it because three years from now, whoever inherits the code won't need us to explain it.

Where we deviate, and why

• Data-heavy internal tools — if the core of the product is reporting against a large relational dataset, we'll reach for Django before we'll bolt an admin panel onto a JS framework. The built-in ORM and admin save weeks we'd otherwise spend rebuilding what Django ships for free.
• Native-feeling mobile — cross-platform gets us 90% of the way for most apps, but if the product lives or dies on camera performance, offline sync, or platform-specific gestures, we'll scope native Swift/Kotlin work instead of fighting a compatibility layer for months.
• Truly real-time systems — trading dashboards, live collaboration, anything where 200ms matters — we'll bring in a language built for concurrency rather than stretch a request/response framework to do something it wasn't built for.

The part we won't compromise on regardless of stack

Whatever we pick, it ships with tests on the logic that would hurt to get wrong, a CI pipeline that blocks bad merges, and documentation written for the next engineer, not for us. The stack changes project to project. That baseline doesn't.