Clients often arrive with a stack already in mind — usually whatever a previous developer used, or whatever’s trending on programming forums that week. Sometimes that’s the right call. Often it isn’t. Here’s the actual decision process we go through, in order.

1. Who has to maintain this after we’re done?

If you have an in-house team, or plan to hire one, the stack needs to match the talent pool you can realistically recruit from — and what your existing developers already know. A technically superior but obscure framework is a liability if nobody can maintain it in eighteen months.

2. What does the product actually need to do?

A content-heavy marketing site has completely different requirements from a real-time collaboration tool or a data-heavy internal dashboard. We map out the actual technical requirements — real-time updates, offline support, heavy computation, SEO — before picking anything. The requirements should choose the stack, not the other way round.

3. How fast do you need to move, and for how long?

Some stacks are optimised for getting an MVP live in weeks. Others are optimised for handling millions of users cleanly at the cost of a slower start. Knowing whether you’re validating an idea or building infrastructure for the next five years changes the answer completely.

4. What’s the total cost, not just the build cost?

Hosting, licensing, third-party integrations, and the hourly rate of developers who know the stack all add up differently depending on what you choose. A “cheaper” framework can end up more expensive once you account for scarce, highly-paid specialists.

5. Is there a genuine reason to avoid the boring, well-supported option?

Boring technology — mature frameworks with large communities, good documentation, and a deep hiring pool — is usually the right default. We only recommend something newer or more specialised when there’s a concrete technical reason the boring option can’t deliver.

In practice, this is why our own stack list stays fairly consistent — React and Next.js for most front-ends, Laravel or Node for back-ends, Flutter or React Native for cross-platform mobile — not because we’re not curious about newer tools, but because these are the options that hold up once “what did we build” turns into “who has to run this.”

Every week we speak to a UK small or mid-sized business that wants “AI” somewhere in their product, without a clear idea of what problem it should solve. That’s not a criticism — it’s the natural result of a lot of noisy marketing. So here’s the honest version, based on what we actually see work.

Where AI genuinely earns its place

Repetitive, judgement-light tasks with a lot of volume. Sorting inbound enquiries, drafting first-pass replies to common support questions, extracting structured data from invoices or forms — these are places where an AI agent can save real hours every week, because the task doesn’t change much and mistakes are cheap to catch.

Search and retrieval over your own content. If your team spends time hunting through documentation, past tickets, or product specs to answer questions, a retrieval-augmented system built on your own data can turn that into an instant, sourced answer — far more useful than a generic chatbot.

First-draft generation, with a human still signing off. Product descriptions, meeting summaries, report drafts — AI is good at getting you 70% of the way there, fast. It’s not good at being the final word.

Where it’s usually the wrong fix

A broken process, not a missing brain. If your team is drowning in manual work because two systems don’t talk to each other, the fix is usually integration and automation — not a language model. Adding AI on top of a broken workflow just makes the failure smarter.

Anything where a wrong answer is expensive. Financial calculations, legal wording, medical guidance — these need deterministic logic and human review, not a model that’s occasionally, confidently wrong.

“AI because competitors have it.” This is the most common reason we hear, and the weakest one. If you can’t describe the specific hours or errors it will save, it’s not ready to build yet.

A simple way to test the idea

Before commissioning any AI feature, we ask clients one question: if a very organised junior employee did this task manually, would it be worth their time? If yes, AI is probably a good fit for automating it. If the honest answer is “not really, it’s rare” or “the risk of a mistake is too high,” that’s a sign to look elsewhere first — usually at the underlying process.