Custom Software

Web, mobile and the platform underneath, built as one system

Most of what goes wrong between three suppliers goes wrong in the space between them. One team, one set of contracts, agreed before anyone writes a feature — so the surfaces are built in parallel rather than in a queue.

Four surfaces onto one contract. Each is a client of the same agreement rather than a project that has to be kept in step with the other three.

Who it is for

You are probably here for one of these

You are building the first version of something

And the thing that decides whether it survives is not the feature list. It is whether the data model can carry version two without a migration nobody has time for.

You have a product and no platform

Surfaces that grew separately, each with its own idea of what a user is, kept in step by hand. Every new feature has to be built two or three times and they drift between releases.

You are coordinating three suppliers

Web, mobile and backend, and every hard problem is agreed to belong to one of the other two. The integration is where the schedule goes, and it belongs to nobody.

What we do

Named things, not capabilities

Every line below is something that exists when the work is finished — a service, an index, a check that runs in your pipeline.

The surfaces: Next.js and React for the web, server-rendered where it matters
Flutter for iOS and Android from one codebase
The admin console — the surface that is always cut and always needed
A design system rather than a page of components
The platform underneath: NestJS services, PostgreSQL, Redis
API contracts agreed and reviewed before implementation starts
Background jobs, scheduled work and queues that survive a restart
Notifications as a service, not a code path in three places
The parts that are usually late: Search that works on real data volumes
File handling, uploads and the storage behind them
Payments, and reconciling them against what was ordered
Roles and permissions, applied identically on every surface

One system

Four surfaces, one contract

This is the whole argument for taking the work as one system rather than three. Nothing below waits for anything else below it.

Surface	Built with	What it is for
Web	Next.js, React	The product itself, and everything a search engine has to be able to read.
Mobile	Flutter — iOS and Android from one codebase	The part people use standing up. One codebase, because two teams produce two products.
Admin console	Next.js, against the same API	How your team operates the product without calling us. Always cut first, always needed by month two.
Service layer	NestJS, PostgreSQL, Redis	The system of record, the jobs, the notifications, the permissions everything else asks about.

All four are built against one contract, agreed and reviewed in week two. Your own client teams can start against it that week rather than waiting on our backend — which is the difference between building the surfaces in parallel and building them in a queue.

What you get

The things that are yours at the end

Objects rather than activities. Each of these is something you hold, in your own repository, whether or not we are still working together.

Reviewed API contracts, first

The data model, the endpoints and the failure paths, agreed in week two. Your own client teams can start against them the same week rather than waiting on our backend.

Working software, in increments you can open

A build every week that you can click through on the surface it belongs to. Not a screenshot, not a percentage — the thing itself, running.

The admin console

In scope from the start. It is the surface that decides whether your team can operate the product without calling us, which is what makes it the one that must not be cut.

A repository you own from the first commit

Your accounts, your infrastructure, your CI. Including the parts we reuse from our own templates — nothing is licensed back to you and nothing is held as leverage.

Stack

What this line is built with

Chosen per system rather than per company. Where two things sit together below, we treat them as interchangeable and pick on the day.

Web: Next.jsReactTailwind CSSRadix UITanStack QueryReduxZustandViteTurborepo
Mobile: FlutterFirebaseSwiftKotliniOSAndroid
Services: Node.jsExpressNestJSFastifyGraphQLRESTOpenAPIPostman
Data: PostgreSQLMySQLMongoDBRedisPrismaDrizzleElasticsearchClickHouse
Work in the background: KafkaRabbitMQBullMQTemporal

Engagement

How it runs, and how it is bought

Fixed scope suits a first version, where discovery can say what "done" means. Products that keep moving after launch usually move to continuous delivery at the first release rather than at the end of a contract.

Fixed scope

A defined deliverable, priced once — after discovery has said what it is, never before. What is in, what is deliberately out, and what we are assuming about your data and your deadlines is written down first.

Suits A first version, a migration with a known end, or a pilot with a decision at the end of it.

Continuous delivery

A team on your work month to month. A written update every week and a working build you can open — not a status percentage, the thing itself, running.

Suits A product still finding its shape, or a system that needs to keep moving after it launches.

Team extension

Engineers inside your team: your repository, your conventions, your release process, your stand-up. A good deal of our work is delivered this way, so it is a shape we have real practice at rather than one we are trying on.

Suits A team that knows what to build and is short of the people to build it.

01
Discovery
2 weeks
A written scope with every assumption named — about your data, your users and your deadlines. The ones nobody states are the ones that cost a month.
02
Contracts
1–2 weeks
Data model and API contracts, reviewed and agreed. From here every surface is built in parallel rather than in sequence.
03
First usable build
6–8 weeks
A running system you can click through end to end. Incomplete, and real — not a prototype that has to be thrown away.
04
First production release
10–14 weeks
Depends mostly on how many surfaces you need at once. Two surfaces and an admin console is the common shape.

Indicative, and stated as ranges on purpose. What moves them is how many surfaces you need at once, how much of the existing system has to keep running, and how quickly decisions can be made on your side — never how many people we add.

Related work

Where this line has been used

All work

April 2024

SODVELONCON 2024

The 18th National Conference of the Society of Dermatologists, Venereologists and Leprologists of Nepal — Hotel Barahi, Pokhara.

A two-day national conference where registration, payment and attendance all had to work at once, in front of the delegates. Registration alone spanned nine delegate categories across three pricing tiers in two currencies, and once the doors opened the organisers needed to know who was in which hall, live, without a queue forming at any of them.

Web platform
Mobile app
Backend
UI/UX and graphics
On-site IT

2023 – 2025

A three-surface operations platform

Field operations

A web platform, a mobile application and a dedicated notification service, built as one system and kept running through fifteen months of continuous delivery. Three surfaces, one set of contracts, and a release cadence that never stopped to let the others catch up.

Web platform
Mobile app
Notification service

Questions

Asked before, answered here

Do you do design, or do we need someone else?

We do. UI/UX is part of the same engagement rather than a hand-off — for SODVELONCON it included the graphics as well. Working to a design your own team produces is equally fine; what does not work is a design that never met the data model.

Can you work inside our existing codebase?

We have shipped inside other teams’ repositories, to their conventions, under their release process and their review culture. Joining an existing team without disrupting it is not something we would be attempting for the first time on your project.

Web and mobile at once, or one and then the other?

One contract, then both against it. Building the surfaces in sequence is what produces two products that disagree — the second one discovers what the first assumed, six months later, and one of them has to change.

What happens to the code if we stop working with you?

Nothing. It is already in your repository, on your accounts, and the handover document is written as we go rather than assembled the week before it is needed. Leaving is not a project.

How often will we see it?

A written update every week, and a build you can open. If a week goes by where the honest update is that we are still on the same problem, you get that instead of a rearranged percentage.

Start here

Tell us what you are building

Or what is breaking, or what has to go faster. You will get a straight answer from an engineer who would do the work.

Start a project