A system goes down at two in the morning. The people who wrote it don't take the call — not because they don't care, but because the contract says production isn't theirs. Someone else, who has never seen the code, starts reading logs.
This is not a failure of anyone involved. It is how the industry is arranged, and the arrangement is easy to describe.
Four ways this gets arranged
| Model | Who writes the code | Who manages the developers | Who carries production |
|---|---|---|---|
| Staff augmentation | External developers | The client | The client |
| Project outsourcing | Vendor team | Vendor | Handed to the client at delivery |
| Managed services | Vendor | Vendor | Vendor, under an SLA |
| Core70 | Named developers | Working directly with you | The same developers |
Three of those four rows separate the people who build the software from the people who live with it. Only the fourth doesn't.
The line is deliberate
Vendors don't avoid production out of modesty. Carrying it means being liable when something breaks, staffing someone to answer at odd hours, and accepting that a bad night is now your bad night. Every one of those is a cost, and the standard contract removes all three with a single clause.
It is an efficient arrangement for the vendor. The question worth asking is what it does to the software.
Ownership changes how developers think
When a developer knows they might be the person reading the logs after release, production stops being somebody else's problem. Something shifts, and it shows up in the code long before it shows up in an incident.
Reliability becomes part of development, not a phase that happens after it. Operability becomes part of architecture — you design differently when you're the one who'll have to restart it. Documentation becomes part of engineering, because the runbook is the thing you'll be grateful for at 3am, and you're writing it for yourself.
None of that can be mandated by a process. It follows from who gets the call.
What the client actually gets
Not additional capacity. Capacity is what you buy when you know what needs doing and need more hands to do it. This is something else: someone who owns what they build.
That word has to mean something structural, or it's just a claim. At Core70, 70% of what a client pays goes to the engineers doing the work and 10% to the Account Owner responsible for that client — paid only after the client has paid, for as long as the relationship lasts. Nobody is reassigned by a resourcing manager. The person who wrote your system three years ago is the person who still answers for it, because that is where their work and their income both sit.
This is not managed services
The distinction matters, because the words sound similar. A managed services provider runs your infrastructure with a team of operations specialists and a monitoring desk. They are good at what they do. But they did not write your software, and the people who wrote it are somewhere else — which puts the split back exactly where it was, one step further down the stack.
We are not selling an operations desk. We are selling engineering ownership: the same named people, building and running the same system. Overnight standby exists where a client needs it, and it is priced as an addition — it is not what the product is.
What we still won't promise
We don't sell availability percentages with service credits attached. Not because we can't calculate one, but because of what it does to both sides: the vendor prices defensively, engineers optimise for the number rather than the system, and every conversation about a problem becomes a conversation about whether it counts.
What goes in the contract instead is concrete: the engineers who hold production access, by name. What they may change without asking, and what needs your approval first. How fast an incident is acknowledged, and what happens after one. If your procurement needs formal service levels, we'll set them with you against the systems we actually run — not publish a number designed to be safe.
It changes who we look for
An engineer who owns a production environment is doing something harder than writing good code. They have to understand why the business works the way it does, explain a technical trade-off to a founder in terms of money and risk, and stay long enough that the system's history lives in someone's head rather than only in a wiki.
Those people are rare, and they don't stay in organisations that treat them as resource. That is the whole reason our structure looks the way it does. The model isn't generosity; it's the price of keeping the kind of engineer this work requires.
When not to hand it to us
If you have a technical lead who wants to keep the keys — and many good companies do — you don't need any of this. You need engineers who work to your process and ship into your environments, and we'll tell you so. That's a dedicated developer, and it's where most of our engagements start.
But if the software is the business and there's nobody whose job it is to own it, the split the industry treats as normal is a cost you're paying without seeing it. Somebody has to be the one reading the logs tonight. It works out better when it's the person who wrote them.