Four groups of work, from a first release to a platform your team depends on. Each one says where it stops, on this page, rather than burying that on a page you have to click.
The software your business runs on, built from your requirements rather than bent out of a template: web, mobile, internal tools and the integrations between them.
We build software to a written scope. We do not do one-week template sites, and we will not start a build on requirements nobody has written down. That is what a discovery is for.
Getting a product from an idea to something real users can pay for, scoped down to what has to exist first, designed properly, and shipped while the market still cares.
We build a first version to learn from, not a five-year platform on day one. If you need the complete vision live before launch, the budget and the timeline both roughly triple, and we will say so before you commit.
Adding the capability your product does not have yet: AI where it genuinely helps, automation where people are retyping things, commerce where you are selling, and reporting you can trust.
We add AI where it removes real work. We will talk you out of a chatbot that answers questions your FAQ page already answers, and we do not sell AI strategy decks. We build features and show you what they cost to run.
Adding capacity and keeping things standing: engineers who work as part of your team, infrastructure that survives a bad day, and someone who answers when production breaks.
We support software during working hours, with an agreed response time. We do not staff a 24/7 production pager, and we will not pretend otherwise to win a contract we would then fail.
Build
The software your business runs on, built from your requirements rather than bent out of a template: web, mobile, internal tools and the integrations between them.
Most business software fails for the same reason: it was specified by people who would never use it, and built by people who never watched it being used. We start in the opposite order, with the work itself, the people doing it, and the spreadsheet or the paper register they currently trust more than the software they were given.
What comes out of that is a written scope: what is being built, what is explicitly not, and where we think the risks are. You own that document whether or not you build it with us.
Then we build in increments you can open in a browser. Every week, not at the end, because a demo at the end is a negotiation, and a demo every week is a correction while correcting is still cheap.
Customer portals, dashboards, booking and workflow systems, admin consoles. Anything where a browser is the tool people do their job in, rather than a brochure they read once.
Android and iOS, cross-platform or native depending on what the app has to do. Built for real conditions, a phone in the field on a patchy connection, not a simulator on a desk.
The system that replaces the spreadsheet everyone is afraid to touch. Inventory, operations, scheduling, approvals, modelled on how the work is actually done, not how a generic product assumes it is.
Marketing sites, content platforms and multi-user portals with an editing experience your team can use without calling us every time a page changes.
Making your systems talk, payments, accounting, logistics, CRM, messaging. Including the unglamorous part, which is what happens when the other end is down.
Where this stops
We build software to a written scope. We do not do one-week template sites, and we will not start a build on requirements nobody has written down. That is what a discovery is for.
Launch
Getting a product from an idea to something real users can pay for, scoped down to what has to exist first, designed properly, and shipped while the market still cares.
The expensive mistake in a new product is almost never the code. It is building eleven features before finding out which two people wanted, and discovering that at the end of a six-month build rather than in week three.
So the first thing we do is argue with the scope. Not to make the project smaller for our own convenience, a bigger build is a bigger invoice, but because the version that reaches real users soonest is the one that tells you what to build next.
Design comes before code, and it comes as something buildable: flows, states, components and tokens, not a flat picture that looks finished and answers none of the questions a developer will hit on day two.
The smallest version that a real customer can use and judge. We are ruthless about what goes in, because every extra feature in v1 is a month you spend before learning whether any of it was right.
Multi-customer products, with the things that are painful to retrofit built in from the start, accounts, roles, billing, onboarding, and keeping one customer data strictly separate from another.
Research, flows, wireframes and a design system your developers can actually build from. Delivered as components and tokens, not as a picture of a screen.
A paid, fixed-length engagement that ends in a scope, an architecture, a cost range and a risk list. Run it with us and take the output to another shop if you want a second price.
A clickable or working prototype to put in front of users, a board or an investor before anyone commits a build budget to it.
Where this stops
We build a first version to learn from, not a five-year platform on day one. If you need the complete vision live before launch, the budget and the timeline both roughly triple, and we will say so before you commit.
Grow
Adding the capability your product does not have yet: AI where it genuinely helps, automation where people are retyping things, commerce where you are selling, and reporting you can trust.
Growth work is different from a build. The system already exists, people already depend on it, and the cost of breaking it is real. That changes the method more than the technology does.
So we start by reading what is there. Not to rewrite it, to find the smallest change that gets you the capability, and to find out what else touches the code we are about to change.
On AI specifically: we are interested in the cases where it removes real work. Reading a stack of documents nobody has time to read. Answering from your own content rather than the open internet. Sorting a queue that a person currently sorts by hand. Where the rule is knowable, we will write the rule instead and charge you less.
Document extraction, summarisation, classification, search over your own content, and assistants scoped to a real task. Built with the failure cases handled, because a confident wrong answer is worse than no answer.
The reports someone rebuilds by hand every Monday, the data copied between two systems, the approval that lives in a WhatsApp thread. Automation pays back fastest here, and it is the least glamorous thing on this page.
Storefronts, catalogue and inventory, checkout and fulfilment, and the integrations into payments, shipping and accounting that decide whether the store is actually usable.
Dashboards and reporting built on numbers that reconcile. Most reporting projects fail on the data model rather than the charts, so that is where we start.
Opening your system up to partners, mobile clients or your own second product, versioned, documented, rate-limited and safe to expose.
Where this stops
We add AI where it removes real work. We will talk you out of a chatbot that answers questions your FAQ page already answers, and we do not sell AI strategy decks. We build features and show you what they cost to run.
Scale
Adding capacity and keeping things standing: engineers who work as part of your team, infrastructure that survives a bad day, and someone who answers when production breaks.
Most of the cost of software is not the build. It is the years afterwards, when the person who wrote it has moved on, the dependencies have aged, and nobody is confident enough to change anything.
Scale work is what stops that from happening. Sometimes that means engineers added to your team. Sometimes it means fixing a deployment process so a release takes fifteen minutes instead of an evening. Sometimes it means writing the tests that let anyone touch the system again.
It is the least exciting part of what we do and the part clients keep us for longest.
Engineers working as part of your team, in your stand-ups and your tools, reporting to you. Monthly, with a notice period, and no rotating cast of unfamiliar faces.
Deployment pipelines, environments, monitoring, backups you have actually restored from, and cost that does not quietly double. On the major clouds or on servers you manage.
Automated test suites, release checks and manual QA where it earns its place. The point is that a release stops being an event people dread.
Bug fixes, dependency and security updates, small changes and someone who knows the system when something breaks. Monthly hours, rolled over once and then expired.
Software that still works but nobody can safely change any more. We go in increments, keeping it live while it changes, rather than betting the business on a rewrite.
Where this stops
We support software during working hours, with an agreed response time. We do not staff a 24/7 production pager, and we will not pretend otherwise to win a contract we would then fail.
Technology
Our team works across these. Which one you get depends on what the system has to do, what your team can maintain, and what you already run, in that order.
A description of the problem is enough to start. You will get a reply from one of the people who would do the work.