Discovery and design
A defined piece of work producing a process map, a system design, a phased plan and an indicative cost. It stands on its own, and you can take it elsewhere.
When the problem is clear but the solution is not.
You are entitled to know how the system you are paying for is designed, secured, released and looked after. This page explains it, in the order the work actually happens.
These decisions determine whether a system still serves the business in five years, so they are settled before a project starts rather than during it.
The architecture follows how the company operates. We do not start from a favourite stack.
Every system we build reads from and writes to a single authoritative record. Duplicated data causes most operational failure.
Where a system works, we integrate it. Replacement needs a business case, not a preference.
Monitoring, audit trails, backups and access control are part of the build, not a phase that gets cut.
Anything financial, contractual or customer-facing keeps a human checkpoint and a record of what the system decided.
Your data, your integrations, your deployment. Exit terms are discussed before they ever become relevant.
Each step produces something you can hold, review and keep. If we stop after any one of them, you still own something useful.
We spend time in the operation before designing anything: how the work flows, where it stalls, what data exists and which constraints are real.
We agree what the system should do, how it fits with what you already run, and in what order it should be built.
Working software in short cycles, reviewed against the real process rather than a specification document.
Payments, messaging, accounting, hardware and the systems that cannot be replaced yet are connected and reconciled.
Migration, training and a controlled go-live, with a rehearsed way back if anything goes wrong.
Monitoring, support and a continuing backlog of improvements, because a business system is never finished.
Security, reliability and monitoring are scoped into the build. They are not a phase that gets cut when a date moves.
We work across the major cloud platforms and the mainstream application and mobile ecosystems. Which one we recommend depends on your workload, your budget and who will maintain it afterwards. Sometimes the right answer is the cheapest one.
We will also tell you when the sensible option is a product you can buy rather than something we build.
Cloudflare · AWS · Azure · Google Cloud
PostgreSQL · Redis · Managed data warehouses
TypeScript · Node.js · React · Astro
iOS · Android · React Native · Progressive web apps
WhatsApp Business Platform · Payment gateways · Accounting systems
Terms are agreed in a written proposal or statement of work. No project begins on a verbal scope.
A defined piece of work producing a process map, a system design, a phased plan and an indicative cost. It stands on its own, and you can take it elsewhere.
When the problem is clear but the solution is not.
A scoped delivery with named outcomes, working software in short cycles and a production system at the end. Environments, deployment and monitoring are included.
When there is a system to build or replace.
Ongoing responsibility for a live platform: monitoring, support, integration maintenance, security updates and a continuing improvement backlog.
When the system matters enough to need an owner.
Discovery is a defined piece of work with an output you keep. It is the cheapest way to find out whether the rest is worth doing.