The business first, the technology second
The architecture follows how the company operates. We do not start from a favourite stack.
Delivery and governance
How we build.
A board is entitled to know how the system it is funding will be designed, secured, governed, released, adopted and looked after. This is the route every engagement follows, from business need to live system, and the controls that sit around it.
- 6steps
- from business need to live system
- 3ways to engage
- discovery, build or operate
- 4foundations
- built into every release
- 0verbal scopes
- every engagement starts in writing
The delivery route
- Business need
- Step 01: Understand
- Step 02: Design
- Step 03: Build
- Step 04: Integrate
- Step 05: Launch
- Step 06: Operate
- Live system
Operating framework
The decisions we will not leave open.
One place for the truth
Every system we build reads from and writes to a single authoritative record. Duplicated data causes most operational failure.
Connect before replacing
Where a system works, we integrate it. Replacement needs a business case, not a preference.
Built to be run
Monitoring, audit trails, backups and access control are part of the build, not a phase that gets cut.
People stay in the loop
Anything financial, contractual or customer-facing keeps a human checkpoint and a record of what the system decided.
You own it
Your data, your integrations, your deployment. Exit terms are discussed before they ever become relevant.
The six steps
From business need to live system.
Each step ends at a review point with a named output. Nothing moves to the next one until that output has been seen and agreed, which is how scope, cost and risk stay visible rather than surfacing at the end.
Understand
We spend time in the operation before designing anything: how the work flows, where it stalls, what data exists and which constraints are real.
Key activities
- Interviews and time alongside the team
- Process mapping, including the exceptions
- An audit of systems, data and constraints
Outputs
- Process map
- Systems inventory
- Problem statement
Where the work actually stalls Design
We agree what the system should do, how it fits with what you already run, and in what order it should be built.
Key activities
- Requirements written as real scenarios
- Architecture and integration design
- Build order set by business value
Outputs
- System design
- Integration plan
- Phased plan and cost
Every layer reads from one record Build
Working software in short cycles, reviewed against the real process rather than a specification document.
Key activities
- Each cycle planned around a usable outcome
- Working software shown at the end of every cycle
- Automated tests from the first release
Outputs
- Working increments
- Automated tests
- Staging environment
- Monitoring and alerts
A larger working system every cycle Integrate
Payments, messaging, accounting, hardware and the systems that cannot be replaced yet are connected and reconciled.
Key activities
- Adapters for the systems that stay in place
- Data migration rehearsed on real records
- Reconciliation between every source
Outputs
- Live integrations
- Reconciliation checks
- Migration scripts
Connected through adapters, not replaced Launch
Migration, training and a controlled go-live, with a rehearsed way back if anything goes wrong.
Key activities
- Acceptance testing with your own team
- The cutover rehearsed before the real one
- Close support through the first days live
Outputs
- Acceptance sign-off
- Launch runbook
- Rollback plan
- Training material
A controlled cutover, with a way back Operate & Improve
Monitoring, support and a continuing backlog of improvements, because a business system is never finished.
Key activities
- Alerts on what a customer would notice
- Security updates and integration upkeep
- Regular reviews that reorder the backlog
Outputs
- Support and incident process
- Improvement backlog
- Service reviews
Seen before a customer sees it
Delivery artifacts
Every step leaves something you can audit.
Each step produces something you can hold, review and keep. If we stop after any one of them, you still own something useful.
| Artifact | 01Understand | 02Design | 03Build | 04Integrate | 05Launch | 06Operate |
|---|---|---|---|---|---|---|
| Process map | Created | Kept current | Not used | Not used | Not used | Not used |
| System design | Not used | Created | Kept current | Kept current | Not used | Not used |
| Phased plan and cost | Not used | Created | Kept current | Kept current | Kept current | Not used |
| Working software | Not used | Not used | Created | Kept current | Kept current | Kept current |
| Automated tests | Not used | Not used | Created | Kept current | Kept current | Kept current |
| Monitoring and alerts | Not used | Not used | Created | Kept current | Kept current | Kept current |
| Integrations and reconciliation | Not used | Not used | Not used | Created | Kept current | Kept current |
| Launch runbook and rollback plan | Not used | Not used | Not used | Not used | Created | Not used |
| Improvement backlog | Not used | Not used | Not used | Not used | Not used | Created |
Controls and foundations
The controls nobody demonstrates.
Security, reliability and monitoring are scoped into the build from the first release. They are not a phase that gets cut when a date moves.
Identity and access
Who can do what, enforced where it cannot be bypassed.
- Sign-in and recovery designed, not assembled
- Roles and row-level rules enforced on the server
- Single sign-on with your identity provider
- Administrative actions logged and reviewable
Data and privacy
Only what the process needs, protected, with a way out.
- Encryption in transit and at rest
- Collect what the process needs, and no more
- A retention period for each category of data
- Export and deletion paths built in advance
Reliability
Releases that can be undone and backups that restore.
- Releases without downtime, with a way back
- Backups that have actually been restored
- Sensible behaviour when a third party is down
- Jobs that run safely more than once
Observability
Problems found by us, not reported by customers.
- Logs, metrics and traces from the first release
- Alerts on symptoms a customer would notice
- Audit trails on consequential decisions
- Performance budgets agreed with the business
Technology
Chosen for the workload, not the trend.
We work across the major cloud platforms and the mainstream application and mobile ecosystems. The recommendation depends on your workload, your budget and who will maintain it afterwards. Sometimes the right answer is the cheapest one.
And sometimes it is a product you can buy rather than something we build. We will say so.
Cloud
Cloudflare · AWS · Azure · Google Cloud
Data
PostgreSQL · Redis · Managed data warehouses
Application
TypeScript · Node.js · React · Astro
Mobile
iOS · Android · React Native · Progressive web apps
Business platforms
WhatsApp Business Platform · Payment gateways · Accounting systems
Want this applied to your operation?
An engagement can start with one contained problem, or with discovery as a defined piece of work whose output you keep. Either can stand on its own, and goes further only where there is a business case.