Loading
Products
Six product lines, each described by its anatomy rather than by a sales pitch: the parts the built thing is made of, the platforms it runs on, and what you are handed at the end. None of them is a licence you buy — they are the shapes of software we build to order.
Before you read the list
A service page answers how an engagement would be run. A solution names what changes about a working day. This page answers a narrower and more concrete question: what is the thing that exists at the end, and what is it made of. That is a different question, and it is the one a technical buyer usually asks second.
So each entry below leads with anatomy — the navigation shell, the offline store and its conflict rule, the permission matrix, the subscription state machine, the audit trail — then names the platforms it runs on and the artefacts you are handed. Where you want the engagement rather than the artefact, every band links across to the service page that covers it. Nothing is said twice.
One honesty note, stated once and true of the whole page. We have no licensed catalogue, so none of these six is a named product you can buy, and no figure, rating, client or launch date appears anywhere on it. The visuals are original generated art — device-frame abstractions in our own palette, captioned as reference layouts — because publishing a client’s interface as our own would be dishonest and stock photography is not the look this rebuild is trying to reach.
01Mobile product
A mobile product is not a website in a frame. It is a signed binary that has to pass two store reviews, survive a train tunnel, keep a session alive across a cold start, and ask for permissions in a way a stranger will grant. What we build is one Flutter codebase where the app is screens and data, or native Swift and Kotlin where it depends on platform depth — and we will say which of the two your idea actually needs before either of us commits to it.
Runs on
02Website
A website and a web application are two different builds, and most quotes conflate them. This is the first one: pages that have to be found, read and understood by someone who arrived from a search result and will leave in four seconds if the first screen is slow. The artefact is a content model, a component set, a rendered page under a byte budget, and a person on your side who can change the copy without filing a ticket.
Runs on
03Web platform
Where a website publishes, a web application computes. People sign in, records change hands, permissions decide who may do what, and somebody eventually has to answer the question "who changed this, and when". That last question is the one that separates a real platform from a form with a database behind it, and it is designed in at the start rather than added when an auditor asks.
Runs on
Anatomy
04SaaS product
The demo is the easy part. What turns a demo into a product is the half nobody puts in the pitch deck: how tenants are isolated, what happens when a card fails, who can invite whom, how a trial converts, and whether your own team can answer a support ticket without opening a database client. That half is what we build, and it is why this line exists separately from web applications.
Runs on
05Internal system
Custom software exists for the part of your operation that a package gets wrong. Not the whole operation — the part. The artefact is an internal system that encodes a real process including its exceptions, records who did what, and replaces the spreadsheet that three people maintain differently. If a package covers ninety per cent and the remaining ten per cent is not what makes you money, we will tell you to buy the package.
What is in the build
Runs on
06Supporting systems
Not every useful thing we build is an app, a site or a platform. A great deal of it is the connective work between systems you already run: the integration that stops two teams retyping the same order, the portal that answers the question people telephone about, the automation that reads two thousand documents a week. These are smaller, they ship faster, and they are frequently the highest-return work available.
Six shapes this work takes
A defined exchange between two systems that currently exchange nothing, or exchange it by somebody retyping. With a stated schedule, a failure path, and a report naming what did not transfer rather than a silent gap.
A signed-in surface where the people who currently telephone can see order status, documents, balances or tickets themselves. Read-mostly, scoped tightly, and usually the fastest reduction in inbound calls available.
Agreed metric definitions first, pipelines in version control second, screens third. Built to be opened at shift start rather than at the quarterly steering meeting.
The recurring task that arrives as a PDF attachment or a scanned form, read and routed automatically, with a confidence threshold that sends the uncertain cases to a person instead of guessing.
A stable, documented contract in front of systems whose shape changes, so a supplier's upgrade breaks one adapter rather than every consumer at once.
Moving off a platform that is ending, or stabilising a system somebody else left behind. Starts with a written read of what exists and a risk list ordered by what would hurt most.
Runs on
In practice
Four questions, in the order we ask them. Most briefs contain two of these six lines, and which one goes first is usually the most valuable decision in the project.
Nobody means a website. Your own staff means custom software. People outside the building means a web application. People outside the building who pay for access means a SaaS product. This one question removes three of the six.
If the answer is "nothing, they will retry", the browser is enough. If work has to continue and reconcile later, you are describing an installed app with a queue, an identifier strategy and a stated conflict rule — and that is an architecture, not a feature.
If a package covers ninety per cent and the remaining ten is not what makes you money, buy the package. If that ten per cent is the actual business, it should be built properly rather than squeezed into somebody else's model. We will say which we think applies.
A documented API, a supported database view, a scheduled file exchange, or nothing usable. That answer sets both the cost and the fragility of everything that has to connect, so we check it against the real endpoints before quoting rather than after.
No, and we will not describe them as though they were. Each of the six is a product line — a category of artefact we build to order, described honestly by what it contains and what it runs on. There is no licence fee, no plan, no trial and no download, because there is nothing pre-built sitting on a shelf. If that changes and we ship a named product of our own, it will appear here with facts you can check rather than adjectives.
Subject, not vocabulary. A service page answers "how would you run this engagement" — discovery, phases, team shape, what we need from you. This page answers "what is the thing at the end" — the navigation shell, the offline store, the permission matrix, the admin console, the release pipeline. Both are useful and they are deliberately not the same page, so each band here links across to the service that delivers it rather than repeating it.
Because we do not have permission to publish our clients' interfaces, and showing a client's app as though it were our product would be dishonest. Rather than use stock imagery, every visual on this page is original art generated by this repository: device-frame abstractions in our own palette, with no text, no figures and no labels anywhere in them. Each is captioned as a reference layout, and the typed image slot behind them is built so a real screenshot can replace one the day we are allowed to show it.
Usually two, and the split matters. If people outside your organisation will sign in and change records, that is a web application or a SaaS product depending on whether you are selling access. If the work is internal and shaped by a process no package models correctly, that is custom software. If it needs the camera, offline use or a home-screen presence, add a mobile product. If it mostly needs to be found and read, it is a website. Describe the problem and we will say which, including when the answer is smaller than you expected.
Frequently, because a mobile product usually needs an API and a web platform usually needs a marketing site. What we avoid is starting three at once. Each of these lines has its own release rhythm and its own risks, and running them in parallel from a standing start mostly produces three unfinished things. We sequence them and say which one goes first, and why.
You do, from the first commit rather than at the end of the project. The repository, the cloud accounts, the app store developer accounts, the signing material and the content system are all yours throughout, and the handover documentation is written while the work happens rather than summarised from memory in the final week. We would rather be re-engaged on merit than retained by making the code hard to leave.
Not which technology, and not which of the six you think it is. Describe what somebody should be able to do at the end of it, and we will tell you which shape that is, which parts are the expensive ones, and where a smaller build would get you most of the way.
What happens next
