Photo: Google Gemini · AI-generated
“Full lifecycle” is on every provider’s website, including ours. It sounds complete. It means almost nothing until someone spells it out.
Here is what it means when we say it, using two systems we run today.
The promise is about the gaps
A software project has five moments where responsibility usually changes hands. The specification goes to the developers. The code goes to the testers. The tested build goes to whoever runs the servers. The launched system goes to support. And years later, the running system goes to whoever builds the next version.
Each handover is a gap. Something is lost in every one: a decision nobody wrote down, a configuration that lives in one person’s head, a bug that each side believes belongs to the other. When four vendors share a project, the gaps belong to the client. That is where the delays, the blame and the surprise invoices live.
Full lifecycle means the gaps are ours. Not because one contract covers everything, but because the same team sits on both sides of every handover. The people who wrote the data model build the pipeline. The people who built the pipeline answer the phone when it breaks.
What it looked like for a purchasing portal
A machinery manufacturer in Germany, 100 to 150 employees, ran a vendor network across several countries by email, spreadsheets and manual entries into Sage 100. We built a purchasing portal as an add-on to that ERP. Vendors confirm orders and log shipments themselves. The sourcing team sees every open order live. The data flows back into Sage 100 without anyone retyping it.
Look at what “full” covered. We modelled the data. We built the portal. We set up the release path, with development, QA, test and live as separate environments, so every change walks the same gated route into production. We host it on the company’s own infrastructure, because that is their setup, not ours. And the audit trail of every order and change is there because finance and compliance would ask for it, not because someone bolted it on later.
No part of that was handed to another company. When something in that chain fails, there is one number to call.
What it looks like after ten years
A medical device company needed an online catalogue of more than 10,000 products. Plugin-based shop platforms struggle at that size, so we built a custom framework with its own content and product information management.
That was nearly a decade ago. The platform has been in production since, with over 99 percent uptime, and it has needed only rare updates. This is the part of “full lifecycle” that nobody puts on a slide: the hosting, the server maintenance, the language and library upgrades, the certificate renewals, the server that eventually has to be replaced. All of it has stayed with us. The client has never opened a ticket with a hosting company and been told the fault is in the application, or the reverse.
What it does not mean
It does not mean lock-in. Documentation, environment access and the source code are the client’s, and a clean handover is always possible.
It does not mean cheapest. One accountable partner costs more than the lowest bid for each separate piece. It is worth it only if the gaps would otherwise be yours to manage.
And it is not always the right model. A company with its own engineering team is usually better served by a dedicated team or time and materials, and we say so.
Three questions that reveal whether a provider means it
Who is on call when the server fails at two in the morning, and is that the same company that wrote the code?
Who pays for the framework upgrade that nobody asked for but everybody needs?
Can you see the pipeline that carries a change from a developer’s laptop to production, and does the provider own it?
If the answers point to three different companies, the gaps are yours. Read how our full lifecycle engagements run, or talk to us about which model fits your situation.