Build, Maintain, Evolve: how we structure every engagement

We describe every engagement with three words: build, maintain, evolve. They are not marketing language — they describe real phases with real responsibilities attached to each.

Build

The build phase starts after architecture is agreed and ends at launch. It is bounded: a defined scope, a fixed fee, a target date. Everything in the build was specified before the first line was written.

The fee covers everything required to go live: configuration, branding, integrations, domain, training, and launch support. It does not change unless the scope changes — and changes to scope require a written amendment, not an informal conversation.

Maintain

Maintenance begins at launch and does not end. It is not a separate engagement — it is continuous. Dependencies are updated. Infrastructure is kept current. Errors are monitored. Incidents are responded to.

The monthly fee covers this work. It is not discretionary. A system that is not maintained is a system that is gradually becoming a liability.

Evolve

Evolution is distinct from maintenance. Maintenance preserves the system as designed. Evolution changes what the system does — new capabilities, new integrations, new user flows.

Evolution work is planned and scoped before it begins. It is assessed against the original architecture, not implemented in isolation. The system grows coherently because each change is made with the full design in view.

Why the distinction matters

Most software relationships collapse this structure. Work happens continuously, fees accumulate unpredictably, and neither party is clear about what falls under the engagement and what is extra.

Separating build, maintain, and evolve makes everything explicit. Clients know what they agreed to. We know what we are accountable for. There is no ambiguity about whether a given piece of work is included — because both parties agreed to the scope before it started.