Deciding what to build next
Somebody has to decide what goes into the next release and what waits, then defend it when the list is longer than the time. We do that in the open, with the reasoning written down.
Services
End-to-end Product Development
Discovery to launch as one engagement, with the same team across every phase, including the gaps between the phases where most products quietly come apart.
You have a product to get to market and no complete team to build it. Or you have the team in pieces: a design agency, a development supplier, a QA vendor, and a growing suspicion that what falls between them is your product. This is the other arrangement. Discovery through launch as one engagement, with one group of people answering for the result rather than for their slice of it.
The whole lifecycle
One team, from first question to live traffic
The lifecycle does not change much from product to product. What changes is who is accountable at each boundary, and whether anybody is looking at the whole of it.
- 01Phase 1
Discovery
We work out what the product has to do and for whom, which parts of it are uncertain, and what the first releasable slice is. You get architecture decisions written down, including the options we rejected and why.
- 02Phase 2
Design and prototype
Interface design runs against the same constraints the engineers are working to, so the screens you approve are screens that can be built as drawn. Prototypes go in front of people early; the ones that confuse them change before anybody writes production code.
- 03Phase 3
Build
From the first commit, engineering happens in your repositories and your cloud accounts. Work lands in releasable slices rather than accumulating towards one date, so the state of the product is something you can open and look at rather than something you are told.
- 04Phase 4
Hardening
Nobody hands a finished build to a separate vendor and waits for a report. Automated checks grow with the code, and the harder work is hunting the cases the specification never mentioned: the duplicate submission, the abandoned payment, the user with no permissions.
- 05Phase 5
Launch and after
Launch is the middle of the work. The release goes out instrumented, so the first weeks of real traffic tell you something you can act on, and what users do with the product goes back into what gets built next.
Products break in the gaps, not the disciplines
Products rarely go wrong inside a discipline. The design was fine; it could not be built the way it was drawn, so it got quietly simplified in a sprint nobody told the designer about. The architecture was sound until a requirement turned up after the schema had shipped and there was no clean place to put it.
One team spanning the phases closes those gaps because the same people carry the consequences. Designers sit with the engineers who have to build the thing. Whoever chose the data model is still around when it meets its first awkward edge case. Nobody gets to hand over a document and consider the problem transferred. That is most of what owning the outcome buys you.
Scope of work
What the engagement contains
Writing code is a fraction of it. Most of the risk in a new product sits in the decisions taken around the code, and in the fortnight after it goes live.
Interfaces and prototypes
Design happens next to engineering here, which is why approval means an engineer has already agreed the thing is possible. You see flows, screens and a clickable version early, while changing them is still cheap.
The build itself
Services, data, the front end, and the integrations with systems you already run. It happens in your repositories and your cloud accounts, so there is no moment at which the code has to be handed back.
Launch, and the weeks after
Getting it live is a phase with its own work in it: the release, the instrumentation that tells you what people do, and the first weeks of running the product. Handover is built in here, not negotiated afterwards.
What you own at the end
Ownership accrues from the first commit, because the work happens in your accounts.
The code and the accounts
Your repositories, your cloud tenancy, your pipelines, from the first commit rather than at handover. There is no migration at the end because nothing ever lived anywhere else.
The reasoning, not just the result
We write architecture decisions down with the alternatives we considered and rejected. When somebody asks later why it works this way, the answer is in the repository rather than in anyone's memory.
A system you can run
Handover is a deliverable we build towards, not a week of meetings once the invoices stop. Runbooks, dashboards and on-call procedures ship with the software itself.
The people who know it
The engineers who designed the product are the ones who built and operated it, so what you are handed comes from the people who made the decisions.
Before you commit
Scope of accountability. A development supplier answers for the code it was asked to write; here we answer for whether the product works, which takes in the decisions upstream of the code and the operational reality after launch. If that sounds like more risk sitting with us, it is. It is also the only version where there is nobody else to blame.
Not sure which one you need?
Describe the problem in a paragraph and we will tell you which service applies.