Services / Web / Web apps & SaaS

From a prototype to a product people pay for

Software products are not websites with logins. They have accounts, plans, permissions, upgrade paths, a support burden and a roadmap. We build them the way they have to be built to survive their own success. Starting with the smallest version that could earn money.

Start the conversation →See the technology

Why it matters

The cost is the wait

The riskiest thing about building a software product is not the engineering. It is spending a year building the wrong thing beautifully. Most failed products were technically fine; they simply answered a question that fewer people were asking than the founder believed, and the money ran out before anybody found that out.

So the shape of the work matters as much as the code. We build the narrowest version a real customer could use and be charged for, put it in front of people early, and let what they do decide what gets built next. That means architecture which can be changed cheaply in the first year, a genuinely different set of decisions from the ones you would make for a platform whose shape is already known.

It also means building the unglamorous half properly from the start, because retrofitting it is painful: accounts and organisations, roles and permissions, plans and billing, a way to onboard a customer without a phone call, and enough visibility to know why something is slow before a customer tells you. Those are the parts that decide whether your tenth customer is easier than your first, or harder.

What you actually get

Built to be trusted

The parts of a product that are invisible in a demo and decisive in year two.

Accounts, teams and roles

Multi-user organisations, invitations, roles and per-seat permissions, with proper isolation between one customer's data and another's. Bolting this on later is one of the most expensive rewrites in software, so it goes in at the start.

Plans, billing and the upgrade path

Trials, tiers, usage limits, upgrades and downgrades, tax handling, and automatic recovery when a card fails. That last one alone is routinely worth several per cent of recurring revenue, so we build it as a feature rather than an afterthought.

Onboarding that does not need you on a call

Sign-up, first-run setup, sample data and the guidance that gets someone to the moment your product becomes useful. Products that require a demo call before anyone can start have a ceiling, and it is lower than most founders expect.

An API and real integrations

One documented way for your customers, your mobile app and your partners to reach your data. For business software this is frequently the difference between being adopted and being trialled and forgotten.

Knowing what is actually happening

Product analytics showing which features are used and where people abandon, plus errors and slowdowns alerting a person immediately with enough detail attached to fix the issue in minutes rather than reproduce it over days.

Built to be changed

One well-organised system, split into more moving parts only when growth genuinely demands it, with the reasoning written down. Over-engineering the first version is among the most common ways a product runs out of runway.

Where it earns its keep

Same pattern, different desks

Three routes into the same discipline.

01 · Founders & early-stage products

The version that finds out whether anyone wants it

The problem: A clear idea, a limited budget, and a powerful temptation to build the full imagined product. Every month spent building before anybody pays is a month in which nothing is learned and the runway gets shorter.
What we build: A deliberately narrow first release (one workflow, real accounts, real billing), built on foundations that will not need replacing, and shipped to real users in weeks rather than quarters.
What changes: Evidence instead of opinion. What gets built next is decided by what customers actually do, and the budget that would have gone into guessing goes into the parts that worked.

02 · Established businesses productising a service

Selling the thing you already do by hand

The problem: A service business has a process, a dataset or a piece of expertise customers would pay to use directly, but it exists as consultants, spreadsheets and email, and it cannot scale beyond the team's available hours.
What we build: The process encoded as a product with self-service accounts, subscription billing and a support model, run alongside the existing service so the revenue does not have to be swapped over in one move.
What changes: A second revenue line that does not consume more hours as it grows, and a far clearer picture of which parts of the service customers actually value.

03 · Marketplaces & multi-sided platforms

Two sides, and the one you have to solve first

The problem: Supply and demand each wait for the other to show up. Meanwhile the platform needs identity, payments split between parties, disputes, ratings and moderation. All before either side is large enough to justify building them.
What we build: A platform built around the harder side first, with payments, payouts and dispute handling done properly from the start because retrofitting money movement is genuinely difficult, and with the low-volume steps kept deliberately manual until volume justifies automating them.
What changes: A platform that can be run largely by hand at low volume without misleading anybody, and that automates those same processes as it grows rather than replacing them.

The technology

The tools behind it, named

Product work rewards boring, well-understood choices in the foundations, and lets you be interesting only where the product genuinely differs.

6 layers · 35 technologies

The product interface

A fast, typed front end with the data-fetching and caching that keeps a heavy application feeling instant rather than reloading the world on every click.

Next.js
React
TypeScript
Tailwind CSS
TanStack Query
Vite

APIs & services

Typed end to end wherever we can, so the front end cannot ask for a field the back end no longer sends, and your partners get an interface worth documenting.

Node.js
Hono
tRPC
GraphQL
FastAPI
Python

Data & scale

A relational core that will hold up, caching where it earns its keep, and separate storage for analytical questions so a heavy report never slows the product itself.

PostgreSQL
Prisma
Redis
Neon
ClickHouse

Accounts & billing

Sign-in your customers' IT departments will accept, and the billing machinery that turns usage into revenue without anyone raising an invoice by hand.

Stripe
Paddle
Lemon Squeezy
Clerk
Auth0
Okta

Shipping without breaking things

Every change reviewed, tested in real browsers, and previewed on its own link before it reaches a customer. That is what makes releasing on a Friday unremarkable.

GitHub
GitHub Actions
Vitest
Cypress
Storybook
Playwright

Running it, and knowing when it hurts

Deployed close to your users, with errors, performance and product usage all visible to a person who can do something about them.

Cloudflare
Vercel
Docker
Sentry
PostHog
OpenTelemetry

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

A first release ready for paying customers is typically twelve to twenty weeks, followed by a release rhythm measured in days.

Sharpen the problem

Who exactly, doing what exactly, instead of what today. Most arguments about product scope are actually disagreements about this, and they are enormously cheaper to have now than in month seven.

Prototype before production

A clickable prototype of the core workflow, put in front of people who match your target customer. It is the cheapest possible way to discover that the obvious idea is confusing to everyone except its author.

Foundations that will not need replacing

Accounts, permissions, billing and deployment, built once and built properly. Everything above this line is expected to change; this line is expected not to.

The first sellable slice

One complete workflow a customer could pay for, released to a small group. Narrow and finished, rather than broad and nearly.

Learn, then choose

Analytics, support conversations and usage data reviewed together, and the roadmap re-cut against them. This is the step that most often changes the plan, which is precisely why it exists as a step.

A steady release rhythm

Small changes, frequently, behind feature flags where the risk warrants it, with performance and error budgets watched as the customer count climbs. Boring releases are the goal, not a sign of low ambition.

Before you commit

The questions worth asking

How much does a SaaS product cost to build?

It depends far more on scope than on technology, so the useful answer comes from a scoping conversation rather than a price list. What we can tell you is where the money goes: accounts, billing and permissions are a fixed foundation cost regardless of your idea; integrations with other people's systems are the most common source of overrun; and the feature list you arrive with is usually two to three times larger than the version that should launch first.

Do we need to raise money first?

Not necessarily, and it is worth building the smallest version before you try. A narrow release with real users and, ideally, real revenue changes the conversation with an investor entirely. It also occasionally reveals that the product should be something else, which is a great deal cheaper to discover before a funding round than after one.

Who owns the code?

You do: code, infrastructure, accounts, domain, everything, from the first commit. The repository is yours and we work inside it. The stack is deliberately conventional so another team could take over. We would rather earn the next phase than rely on you being stuck with us.

What if it takes off faster than expected?

That is a nice problem and a real one. We design so the first bottleneck is predictable and can be addressed without a rewrite, and we load-test to find where it actually is rather than guessing. What we will not do is build for a million users on day one. That costs money you do not yet have, and the architecture you would need at that scale is usually not the architecture that gets you there.

How do you handle changes to the plan mid-project?

We expect them, and we work in a way that keeps them cheap: short cycles, working software you can react to, and scope re-cut at agreed points rather than treated as fixed. What we will not pretend is that changes are free. A change of direction has a cost, and we will show it to you as a trade against something else rather than absorbing it silently and letting the date slip without explanation.

Can you take over a product another team started?

Yes, and it is common. We begin with a paid technical review: what is there, what is safe, what is going to hurt, and what it would cost to stabilise versus rebuild. Sometimes the honest answer is that the existing codebase is fine and needs maintaining rather than replacing, not what everyone expects a development agency to say, but it is frequently true.

Tell us about the product in your head

Bring the idea, the half-built version, or the spreadsheet your customers keep asking to buy. We will tell you what the first sellable release should contain and what it would take to get there.

Start the conversation →

Explore more

The rest of Websites & Web Platforms

Company websites Online stores Customer portals Internal tools Redesigns & rescues ← All of Web