Brushed-steel workbench rails holding a closed laptop, an aluminium wedge stand and a folded grey cloth in a London studio at 3pm daylight

Technology stack guide

Comparing realistic development stacks for UK products

Software that earns its keep, built in London. Nine approaches we actually work with, what each is good at, and where each one gets awkward — so you can bring a sharper question to the call.

Talk through your stack See how we work

Nine approaches, no winner. Read the trade-offs, then argue with them.

Spec
Build
Test
Ship

Oblique view along two matte anodised aluminium rails with a folded pair of glasses and a steel tape measure resting between them

Where to start

Which framework is a question best answered with trade-offs

This page exists because "which framework?" is a question best answered with trade-offs on the table rather than enthusiasm for whatever shipped this month. Below are the approaches we work with, what each is genuinely good at, and where it gets awkward.

Use it to bring a sharper question to the call rather than to pick a winner. There isn't one. The nine approaches covered here are the ones that come up most often in UK product work — from React and Vue on the web through Kotlin Multiplatform, Jetpack Compose and .NET MAUI on mobile, and out into the no-code and cloud-build tooling that surrounds them.

The stack, in order

Nine approaches, each with a cheerful caveat

Each plate below pins under the same two rules. Read the one that matches your constraint — the caveat line is the part worth arguing about.

Next.js

And the React default

Next.js is a framework for building React applications with routing and server-side rendering built in, and it is commonly the default starting point for new React work. That is not marketing; it is because the routing, rendering and data-fetching pieces come configured rather than requiring assembly. It suits marketing sites, dashboards and content-heavy web apps especially well, and current coverage of the framework highlights AI-agent support and production-scale adoption.

Honest caveat: a small, simple site may not need the machinery.

Vue

And the approachable alternative

Vue is a progressive JavaScript framework for user interfaces, and it remains a major alternative to React in current web framework commentary. Where it wins is approachability and incremental adoption: you can drop it into an existing page rather than committing to a full rewrite, which matters to teams with a live product and no appetite for a big-bang migration. Its compiler-oriented direction is part of the current ecosystem discussion.

For smaller or more flexible web projects, that combination is often the deciding factor.

Kotlin Multiplatform

And shared logic

Kotlin Multiplatform is used to share business logic across platforms while keeping native UIs, and it shows up in current commentary as a fast-growing mobile option. It appeals to teams who want gradual code sharing rather than a full cross-platform UI commitment, and it is frequently described as a middle path between pure native development and frameworks that render the whole interface themselves.

If your organisation has Kotlin experience, the ramp is short. If it doesn't, that is a real cost worth pricing in.

Jetpack Compose

And native Android

Jetpack Compose is Google's modern declarative UI toolkit for Android, used with Kotlin for native Android development. It is the right answer when performance and Android-specific capabilities are the priority, and it is frequently paired with Kotlin in current mobile stack discussions. Native Android means the platform's own behaviours and updates arrive without a bridging layer in the way.

The trade-off is straightforward: you build for one platform well, and iOS needs its own work.

.NET MAUI

And the Microsoft route

.NET MAUI is Microsoft's cross-platform framework for building native apps with C# and XAML, and it is the evolution of Xamarin.Forms. It targets iOS, Android, macOS and Windows from one codebase, which is a genuinely useful reach if Windows matters to your users. It is best suited to teams already working in the Microsoft ecosystem, because the tooling, language and platform knowledge carry over.

If your developers live in Visual Studio already, the decision gets much easier.

Replit

And the browser-based option

Replit is a browser-based coding environment with AI-assisted features, used for full-stack applications and quick deployment loops. It appears in 2026 app-tool roundups as a practical cloud development platform, and it is popular for rapid iteration and collaborative builds where setting up local environments would slow everyone down.

The question worth asking is when browser-based development is enough for a real product. For prototypes, internal tools and early validation, often yes. For a regulated product with strict environment controls, less so.

Maestro

And automated UI testing

Maestro is a tool for automating mobile UI tests, highlighted in current tooling lists for app quality workflows. It validates flows on mobile interfaces, which is exactly the kind of work that gets skipped when a release is close. It is relevant to teams trying to keep release confidence high across many devices, because manual testing across a device spread does not scale past a certain point.

The reason mobile teams increasingly automate UI flows before launch is simple: it catches the regression nobody meant to introduce.

Bubble

And what no-code can carry

Bubble is a visual app-building platform with a built-in database and workflows, commonly used for marketplaces and business apps, and it represents the growing no-code segment in web application development. It is a mainstream low-code option in current tool roundups.

What it can carry: validation, early marketplaces, internal tools, products where the workflow is the interesting part and the engineering is not. What it cannot replace: unusual performance requirements, deep integrations, and the point where your product's value is the software itself.

Native or cross-platform

And an API-first backend

The decision usually comes down to how much of the product depends on platform-specific behaviour. Cross-platform with one codebase covers most business apps well and keeps the effort from doubling. Native is worth the extra work when camera, sensors, background processing or UI performance sit close to the core value. Kotlin Multiplatform is the middle road, sharing business logic while each platform keeps its own UI. React Native and Flutter both sit in the cross-platform space too, and the choice between them comes down to the team's existing language skills more than any benchmark.

For an API-first product, the backend choice is often less about language fashion and more about who will maintain it. An API-first approach means the contract between frontend and backend is defined and versioned before either side is built, which keeps web, mobile and any future client in step. That pattern matters most when you expect more than one client, because it prevents the frontend quietly becoming the source of truth. It also makes testing easier, since the contract can be verified independently.

The maintainability question

A stack decision is really a bet on who maintains the code in two years. Hiring availability, documentation quality and how the ecosystem handles updates all matter more than how pleasant the first week feels. Here is how we read those bets — the honest version, row by row.

Who will actually be hiring for this in two years

Hiring pool

React and Node sit in the largest pool; Kotlin and C# are smaller but still deep enough for London

How well updates are handled upstream

Update cadence

Frameworks with an opinionated release process age better than ones assembled from many small parts

Whether documentation survives contact with a new developer

Docs quality

Well-run docs mean a new hire is productive in days, not weeks; a weak wiki means every change carries risk

What we ask before recommending anything

Our question

Who owns the code long-term? The answer usually changes the recommendation more than any benchmark

The most common version of a bad call is choosing a framework the team cannot hire for or keep current. The second most common is picking something pleasant in week one and quietly expensive in year two.

"None of this is a recommendation until we know your constraint. The call is where the list gets short."

How we run a scoping call — the three questions that usually eliminate most of the options on their own

Quick reference

When each approach tends to fit

A short reading of the nine above. Nothing here is a verdict — it is a starting point for a conversation with the team.

Approach Best suited to Where to be careful

Next.js

Marketing sites, dashboards, content-heavy React apps

Small, simple sites that do not need the built-in machinery

Vue

Live products needing incremental adoption, flexible smaller web projects

Testing whether incremental adoption actually stops the migration

Kotlin Multiplatform

Teams wanting shared logic with native UI on both platforms

Pricing in the ramp for teams without existing Kotlin experience

Jetpack Compose

Android-first products where performance is close to the core value

iOS being a separate piece of work, not a compiler flag away

.NET MAUI

Microsoft-ecosystem teams that also need Windows in the same codebase

Teams that do not already live in Visual Studio paying a tooling tax

Replit

Prototypes, internal tools, early validation, collaborative builds

Regulated products that need strict environment controls

Maestro

Mobile teams wanting regression coverage before a release

Treating automated UI tests as a replacement for exploratory testing, not a partner to it

Bubble

Marketplaces and business apps where the workflow is the point

Products whose value is the software itself, or need deep integrations

API-first backend

Products with more than one client, or a web and mobile pair to keep in step

Letting the frontend quietly become the source of truth

Straight answers

Things people ask before the call

Four of the questions that come up most often in scoping conversations. The full set is yours on the call.

Is Next.js still the default choice for modern web apps?

For React work, it is commonly the starting point because routing and server-side rendering come configured. It is not automatically right for every site.

Should we choose native or cross-platform for mobile?

Cross-platform covers most business apps. Native is worth the extra effort when platform-specific capabilities sit near the core of the product.

When is React Native better than Flutter?

In practice, when your team already works in JavaScript or TypeScript. The language fit tends to matter more than framework benchmarks.

Can we start on Bubble and move to code later?

Yes, and it is a common path for validating a marketplace or business app. The migration works best when data and behaviour are understood before the move.

How we use this in a scoping call

Bring the constraint, not the wish list

On a call we will ask what stage the product is at, whether there is an existing codebase and who maintains it, and which platform matters most to your users. Those three answers eliminate most of the options on their own. The rest is a short written recommendation with reasons you can argue with.

Start a project enquiry Ask about a specific framework

Studio

BLUEHORIZON INNOVATIONS
1 Canada Square
London, England, E14 5AA

Reach us

+44 20 7837 4011
[email protected]
Mon–Fri, 9:00–18:00