Engineered ForThe ReleasesAfter The First.
A product is not a project that happened to ship. Customers depend on last quarter's behaviour while next quarter is being built, and most structural decisions either keep that affordable or quietly stop it.
Next Step / Technical Discovery
- What is product, and what is not
- Configured, never branched
- Proven on a cohort before everyone
- Broken on notice or not at all
Where a product stops being able to change
Not at launch. Somewhere past the point where enough accounts depend on enough behaviour that altering any of it requires a meeting.
- 01
The second large customer arrived with conditions
Nothing they asked for was unreasonable, and the quickest way to agree was a branch. Now each change is made twice, and the two copies have begun to disagree.
- 02
Nobody is willing to touch the schema
The tables were shaped for the first version. Every account opened since holds data in that shape, and the migration has no volunteer.
- 03
The interface is a promise nobody wrote down
Consumers depend on fields never meant to be public, ordering that was never guaranteed, and a behaviour that began as a defect. All of it is the contract now.
- 04
Every release reaches everyone at once
A change is live for every account or for none, so the safe move is to ship less. The roadmap settles to the pace of the most cautious customer.
What product engineering owns
The product, and the machinery that lets it keep being sold while it keeps being changed. The second half is what gets deferred, and what decides the ceiling.
- 01
Product architecture and boundary
Where the product ends: the behaviour every customer receives, and the requests deliberately answered somewhere other than the source tree.
- 02
Tenancy, entitlements and plans
Isolation between customers, and the entitlement model deciding which capabilities an account reaches without anyone shipping code to grant them.
- 03
Configuration and extension surfaces
The places difference is designed to land — settings, rules, templates, webhooks — so a requirement has somewhere to go that upgrades with the rest.
- 04
Versioning and compatibility
What the product has promised, how long the promise lasts, and how a change to it gets announced rather than discovered.
- 05
Release, rollout and telemetry
Flags, cohorts, staged exposure, and the measurements that establish whether a change is working while it is still small enough to withdraw.
- 06
Operations and support tooling
What a support team needs to answer for one account — state, history, impersonation, limits — without a database console and an engineer on call.
What holds still, and what is free to move
A product that changes everything is unusable; a product that changes nothing is finished. The engineering question is which surfaces are promises and which are implementation — decided in advance rather than discovered.
Data shape
Schemas change and old accounts keep working, because the migration carrying the previous shape forward is written before the change merges, not after somebody reports it.
Public interface
What consumers may rely on is written down, versioned, and withdrawn on a published timetable — never by a deployment nobody outside the team expected.
Internal structure
Anything not on the contract can be replaced without asking. The worth of a small promise is how much it leaves unpromised.
Customer variation
Difference lives in data rather than in code paths that exist for one account. A setting costs once; a branch costs on every release it survives.
New behaviour
A change is measured against real accounts while the previous path still stands, so withdrawing it is a decision rather than an incident.
The product boundary
Every product eventually meets a requirement it did not anticipate. Whether to accommodate it is not the question — accommodating customers is the business. Where the accommodation is permitted to live is, and the four answers are priced very differently.
Customisation is not the mistake; putting it in the wrong place is. Each step outward costs more to maintain than the one before, and only the last leaves two products under one name.
- 01
Behaviour every customer receives
The product's actual claim. Changing it changes it for everyone, which makes it the most expensive place to put one account's request.
- 02
Difference the product expects
Settings, rules, templates and limits, held as data. The variation is supported, tested and upgraded alongside everything else, because it never left the product.
- 03
Difference the customer owns
Webhooks, APIs and extension points where the customer's own system does the specific thing. It moves on their schedule and never enters the product's release.
- 04
A second product, acquired by accident
A branch held for one account. It works the same afternoon — the last inexpensive thing about it. Every change afterwards is made twice, and eventually made differently.
How a change reaches everyone
Not a project plan. This is what happens to one change between merge and the removal of what it replaced, repeated across accounts that never asked to be involved.
- 01
Merged, and not yet true
The change reaches production behind a switch that is off. Deploying and releasing become separate events, which is the decision everything below depends on.
- 02
True for chosen accounts
A selected subset gets the new behaviour while the rest stay where they are. The comparison is between live accounts rather than between environments.
- 03
True by default
Exposure grows while the measurements hold. The previous path stays in place, so reversing course is a configuration change instead of an emergency release.
- 04
The old behaviour is withdrawn
Announced, dated, and executed once telemetry shows the path is empty. Teams skip this step, and skipping it is how a product accumulates code nobody dares delete.
What the product team is left holding
- A request to work differently resolves to a setting, an extension point, or a considered no — never a second copy of the codebase.
- A consumer learns a field is going away from a deprecation notice with a date on it, not from their integration failing overnight.
- Accounts opened before the current data model keep working, because each shape change shipped with the migration that carries them across.
- New behaviour proves itself on a subset first, and withdrawing it is a switch rather than a hotfix at the end of a long day.
Related pages
Custom Software Development
The bespoke build: one defined problem, one defined group, and a system scoped to the smallest thing that solves it.
Cloud Infrastructure
The operating environment beneath critical software: deployment, isolation, observability and recovery, engineered so failure stays bounded and the service returns to a known state.
Bring a product carrying a branch you regret, an interface you can no longer change, or a release process that has turned the roadmap into a negotiation.