What tech stack do you use?

We host on AWS, define that infrastructure in code with Terraform, and keep your code in GitHub. Stripe handles payments and Databricks handles serious data work, where a product needs them. The frameworks for the app or website itself are chosen per product in Discovery.

That last part is deliberate. A stack is a set of decisions, and the right ones depend on what you’re building.

What stays the same on most builds

AWS, Stripe, Databricks and Secureframe are our partners. That’s worth knowing, so you can weigh what we say about them.

Why Terraform matters more than it sounds

Terraform lets us write your cloud setup down as code instead of clicking it together by hand. Rebuilding an environment becomes a re-run rather than a weekend.

It also keeps development, staging and production identical. So the bugs that only appear in production mostly stop appearing. And the setup isn’t held in one person’s head, which is the usual arrangement and the usual problem.

For Ymobile, the UK’s first eSIM-only mobile network, we built their data pipeline infrastructure in Terraform. It feeds Databricks, giving the team real-time analytics on how customers use the network.

What changes from product to product

The rest is chosen for the job. Here are some of the choices our public work shows.

• Encryption on the phone itself. For Vault, reports are encrypted on the person’s own phone. The keys sit with them and their employer, so even Vault can’t read them.
• Location that keeps up. ExecSecure drivers use iOS and Android apps that report each car’s position continuously, to about three feet.
• No app to download. Electragram guests reply by email, SMS or WhatsApp. Every step works from a message they’ve already opened.
• Payments kept in step. Ymobile’s Stripe payments are wired into its billing system too. Our payments work shows the same approach across other products.
• Admin tools you don’t build from scratch. For The Home Help Company, we automated billing and payroll on Forest Admin. Invoices and PAYE now process with a single click.

We choose widely used, well-supported frameworks, so another team can hire for them. We don’t build on an in-house platform of our own, because you should be able to leave. Do I own the code and IP? explains why that matters.

Whether you need a native app or a web app is a separate question. Do you build apps for both iPhone and Android? covers it. Our development services page shows the wider range of what we build.

How we use AI to build

We’re AI-augmented. Our engineers use AI tools to write, test and document code faster. A senior engineer reviews every change and owns it afterwards. Nothing goes live that nobody has read.

That matters most when AI is part of the product itself. Most AI features don’t need a model trained from scratch. They need an existing model, your data, and a way to test the answers. Our guide to whether your data is ready for AI explains how we approach it. If the product already exists, see can you add AI to our existing product?

Do you need to care about any of this?

Mostly, no. If you’re not technical, the questions worth asking are simpler. Can another team pick it up? Can it grow? Is it yours?

The stack above is how we make the answer to all three yes. Growth gets its own article in can it scale if my business grows quickly?