How we work, from first call to full handover

Four steps, the same on every project. You see working software every week, approve the cost of each phase before it starts, and end up owning the code, servers and accounts.

Step 1Discover
Understand the problem before discussing solutions.
Step 2Architect
Design deliberately before a single line of production code.
Step 3Build
Production-grade engineering in reviewable increments.
Step 4Inherit
Transfer ownership completely. It is in our name.

Why most software projects leave you stuck

The usual agency model is built to keep you coming back. We built ours the other way round.

Retainer-first incentives
Many vendors are structured to stay involved. Success is measured by ongoing dependency, not by making the client self-sufficient.
Opaque delivery
Software arrives as a black box. The business can use it, but cannot inspect, extend or operate the system with confidence.
Knowledge walks out the door
When the engagement ends, architectural decisions and operational context leave with the agency. What remains is fragile dependence.
Lock-in by design
Proprietary platforms, managed hosting traps and undocumented integrations make leaving expensive, even when the relationship no longer fits.

The four steps, in detail

Step 1

Discover

Understand the problem before discussing solutions.

Every engagement begins with clarity, not assumptions. We embed with your team to map the real problem, the constraints that shape it and the metrics that define success.

Discovery is not a sales exercise. It is a technical and operational audit that produces a shared picture of what needs to exist, what already exists and what should not be rebuilt.

What happens

Stakeholder and workflow interviews
Technical audit of existing systems
Integration and data landscape review
Success metrics and scope definition
Discovery summary and recommended path

What you get

A written problem statement both teams agree on
Documented constraints, risks and success metrics
A scoped roadmap with clear decision points

Step 2

Architect

Design deliberately before a single line of production code.

Architecture is where long-term cost is won or lost. We design the system end to end: data models, infrastructure, integrations and the decisions that determine how far it scales.

You approve the blueprint before we build. Nothing moves forward on faith. Every significant trade-off is documented, explained and agreed.

What happens

System and data architecture diagrams
Infrastructure and deployment model
Integration design and API contracts
Security and access model
Architecture decision record (ADR) set

What you get

An architecture your team can explain and defend
Stack and infrastructure choices tied to business requirements
Integration boundaries defined before build begins

Step 3

Build

Production-grade engineering in reviewable increments.

Build is not a phase where we disappear. You see working software every week, with tests, CI and reviewable commits from the first merge.

We engineer for longevity: readable code, observable systems and patterns your team can maintain without us in the room.

What happens

Weekly increments with demo and review
Automated test suite and CI/CD pipeline
Code review and engineering standards
Staging and production deployment paths
Performance and quality gates

What you get

Working software shipped in tight, predictable increments
Automated tests and CI from early in the engagement
Code and infrastructure your team can operate

Step 4

Inherit

Transfer ownership completely. It is in our name.

At handover, the entire system becomes yours: source code, infrastructure, accounts and documentation. No proprietary platforms, no licensing traps, no dependency on us to keep it running.

Inherit is not a final meeting. It is the designed outcome of every prior phase, structured so your team can operate, extend and own the system for years.

What happens

Source code repository handover
Cloud account and credential transfer
Architecture and API documentation
Deployment and operations runbooks
Knowledge transfer sessions with your team

What you get

Full repository and infrastructure access transferred
Documented architecture and operational runbooks
A team equipped to maintain the system independently

What handover actually looks like

Not a zip file and a goodbye. Handover runs in five steps, and it ends when your team can run the system without us.

1
Repository Transfer
Full source code ownership, branch history and access credentials moved to your organization.
2
Documentation Delivery
Architecture diagrams, ADRs, API references and environment guides delivered as living artifacts.
3
Infrastructure Ownership
Cloud accounts, deployment pipelines, monitoring and credentials transferred under your control.
4
Knowledge Transfer Sessions
Structured engineering and operations walkthroughs until your team can explain the system independently.
5
Independent Operation
Your team deploys, extends and operates the system without us in the room. Client becomes independent.

Handover note

At go-live

1.Source codein your GitHub account
2.Servers and cloud accountsin your name
3.Domain and app store listingsin your name
4.Admin accessto every part of the system
5.Documentationfor your team or any developer

Received by

You

Monthly licence fee
None to us

Documentation is written as we build

Not assembled in the last week. These are kept up to date from the design step onwards.

Architecture documentation
System diagrams, data models, integration maps and decision records that explain why the system is shaped the way it is.
Operational runbooks
Deployment steps, environment configuration, monitoring expectations and incident response paths written for your team, not for us.
API and integration references
Contracts, authentication models and boundary definitions so internal teams and future partners can integrate without guesswork.
Knowledge transfer sessions
Structured walkthroughs with your engineers and operators. We leave when your team can explain the system without us in the room.

Questions about ownership

More on what we build is on the services page.

Do we own the source code?

Yes. At handover you receive full repository access and ownership. There is no proprietary layer, no escrow arrangement and no licensing fee to keep using what we built.

What happens to infrastructure and cloud accounts?

Infrastructure runs in accounts you control. We set up environments in your cloud organization, document everything and transfer admin access as part of handover.

Can we continue without you after the engagement?

That is the designed outcome. Documentation, knowledge transfer and clean architecture are built in from discovery so your team can operate and extend the system independently.

How is this different from a typical agency retainer?

We are structured around delivery and transfer, not ongoing dependence. The engagement has a clear arc toward ownership, with transparency at every phase.

Is documentation really included, or added at the end?

Documentation is produced throughout the engagement, not assembled in the final week. Architecture decisions, runbooks and references are living artifacts from architect through build.

What if we want ongoing support after handover?

Optional support can be arranged, but it is never required to keep the system running. You inherit a product you fully control, support is a choice, not a condition.

Tell us what you want to build.

A short call is enough to scope it. If you don't need custom work, we'll say so.

Start a conversation

How we work, from first call to full handover

Four steps, the same on every project. You see working software every week, approve the cost of each phase before it starts, and end up owning the code, servers and accounts.

Step 1Discover

Understand the problem before discussing solutions.

Step 2Architect

Design deliberately before a single line of production code.

Step 3Build

Production-grade engineering in reviewable increments.

Step 4Inherit

Transfer ownership completely. It is in our name.

The four steps, in detail

Step 1

Discover

Understand the problem before discussing solutions.

Every engagement begins with clarity, not assumptions. We embed with your team to map the real problem, the constraints that shape it and the metrics that define success.

Discovery is not a sales exercise. It is a technical and operational audit that produces a shared picture of what needs to exist, what already exists and what should not be rebuilt.

What happens

Stakeholder and workflow interviews
Technical audit of existing systems
Integration and data landscape review
Success metrics and scope definition
Discovery summary and recommended path

What you get

A written problem statement both teams agree on
Documented constraints, risks and success metrics
A scoped roadmap with clear decision points

Step 2

Architect

Design deliberately before a single line of production code.

Architecture is where long-term cost is won or lost. We design the system end to end: data models, infrastructure, integrations and the decisions that determine how far it scales.

You approve the blueprint before we build. Nothing moves forward on faith. Every significant trade-off is documented, explained and agreed.

What happens

System and data architecture diagrams
Infrastructure and deployment model
Integration design and API contracts
Security and access model
Architecture decision record (ADR) set

What you get

An architecture your team can explain and defend
Stack and infrastructure choices tied to business requirements
Integration boundaries defined before build begins

Step 3

Build

Production-grade engineering in reviewable increments.

Build is not a phase where we disappear. You see working software every week, with tests, CI and reviewable commits from the first merge.

We engineer for longevity: readable code, observable systems and patterns your team can maintain without us in the room.

What happens

Weekly increments with demo and review
Automated test suite and CI/CD pipeline
Code review and engineering standards
Staging and production deployment paths
Performance and quality gates

What you get

Working software shipped in tight, predictable increments
Automated tests and CI from early in the engagement
Code and infrastructure your team can operate

Step 4

Inherit

Transfer ownership completely. It is in our name.

At handover, the entire system becomes yours: source code, infrastructure, accounts and documentation. No proprietary platforms, no licensing traps, no dependency on us to keep it running.

Inherit is not a final meeting. It is the designed outcome of every prior phase, structured so your team can operate, extend and own the system for years.

What happens

Source code repository handover
Cloud account and credential transfer
Architecture and API documentation
Deployment and operations runbooks
Knowledge transfer sessions with your team

What you get

Full repository and infrastructure access transferred
Documented architecture and operational runbooks
A team equipped to maintain the system independently

What handover actually looks like

Not a zip file and a goodbye. Handover runs in five steps, and it ends when your team can run the system without us.

Repository Transfer

Full source code ownership, branch history and access credentials moved to your organization.

Documentation Delivery

Architecture diagrams, ADRs, API references and environment guides delivered as living artifacts.

Infrastructure Ownership

Cloud accounts, deployment pipelines, monitoring and credentials transferred under your control.

Knowledge Transfer Sessions

Structured engineering and operations walkthroughs until your team can explain the system independently.

Independent Operation

Your team deploys, extends and operates the system without us in the room. Client becomes independent.

Documentation is written as we build

Not assembled in the last week. These are kept up to date from the design step onwards.

Architecture documentation

System diagrams, data models, integration maps and decision records that explain why the system is shaped the way it is.

Operational runbooks

Deployment steps, environment configuration, monitoring expectations and incident response paths written for your team, not for us.

API and integration references

Contracts, authentication models and boundary definitions so internal teams and future partners can integrate without guesswork.

Knowledge transfer sessions

Structured walkthroughs with your engineers and operators. We leave when your team can explain the system without us in the room.