Our stack, and why we don't chase every framework

We maintain software for clients for years, not weeks. That one fact shapes almost every technology decision we make. A framework that's exciting to try on a weekend project is a different bet entirely from a framework we're willing to still be debugging in production in 2029.

The filter: boring where it counts, modern where it matters

For the parts of a system that have to keep working quietly for years — the database layer, authentication, payment handling, background jobs — we default to tools with a long track record: PostgreSQL over whatever's newest, established frameworks over ones still finding their API. For the parts that directly shape how a product feels to use — the frontend, the AI integration layer — we're much more willing to use something current, because the cost of being wrong there is lower and the upside of being right is higher.

That's why you'll see React and Next.js across most of our frontend work, alongside PHP/Laravel or .NET for backends that have been running for years, and Python for anything touching machine learning. It's not indecision — it's matching the tool's maturity to the part of the system that has to be most boring.

What makes us actually adopt something new

• It solves a problem we've hit on at least two real projects, not a hypothetical one
• We can explain what happens when it breaks, not just when it works
• Hiring and onboarding a new engineer onto it won't take a month
• There's a credible migration path off it if the project outlives the framework

That last point is the one people skip. Every framework eventually stops being the exciting new thing. The question isn't whether that happens — it's whether moving off it later is a two-week project or a two-year one. We'd rather ship on something slightly less fashionable that we can migrate cleanly than something trendy that locks a client in.