Do you take over software somebody else built?

Yes, and it is a large share of enterprise work. It starts with a review of what the system currently does, what it is supposed to do, and where those diverge. The output of that review is a written assessment you own outright, including the case for leaving it alone if that is the honest answer.

Who owns the code and the infrastructure?

You do, entirely. Code lives in your repositories and infrastructure runs in your accounts wherever that is practical from the first day rather than being migrated across at the end. Handover includes credentials, architecture documentation and runbooks, and the test of a real handover is whether your team can deploy without us.

What happens after launch?

Support arrangements are agreed before launch rather than improvised after it, and they are optional. A system that can only be operated by the people who wrote it has not been finished, so the alternative is always a genuine handover rather than a dependency.

Service

Enterprise Software Development

Most enterprise software fails after it ships, not before. It works on the day it is demonstrated and then degrades, because nobody could see what it was doing, nobody could explain why it made a decision, and the people who built it are the only people who can run it. We build for the years after the demonstration.

What counts as enterprise here

Not size. A system is enterprise when someone's job depends on it being right and someone else has to answer for it when it is not. That is true of a fifty-user internal tool that prices contracts and untrue of a thousand-user product where the worst outcome is a refund.

The distinction matters because it decides what gets built first. When a system carries that weight, the audit trail, the permission model and the failure behaviour are the product. They are not hardening applied to a working prototype at the end, because by then the data model has already made several of them impossible.

How we approach it

We start with the operations, not the screens. Who has to be able to answer what question, under what deadline, with what authority to overrule the system. Those answers constrain the schema, and the schema is the decision that is genuinely expensive to reverse later.

Every state change is recorded as an event with an actor and a timestamp before any interface exists. This is what makes the difference between a system that can tell you what happened and one that can only tell you what is currently true. The second kind cannot be audited and cannot be debugged in production.

We work in production-shaped environments from early on. Software that has only ever run on a developer machine has not been tested, it has been demonstrated, and the gap between those two is where most delivery risk actually sits.

Integration and existing systems

Enterprise work is rarely greenfield. There is usually a system of record that cannot be replaced, an export that arrives as a file on a schedule, and at least one process that runs on a spreadsheet nobody will admit to.

We treat those as fixed constraints rather than things to be migrated away in phase two, because phase two frequently does not arrive. The integration boundary gets an explicit contract, its own tests, and defined behaviour for the case where the upstream system is unavailable or wrong. Systems that assume their inputs are correct fail in ways that are very hard to trace.

What an engagement includes

Domain and data model, with the audit trail designed in rather than added
Role and permission model derived from who answers for what
Application, API and administrative interfaces
Integration contracts for existing systems of record, including failure behaviour
Observability: structured logging, metrics and alerting on the conditions that matter
Backup and restore, tested by performing a restore rather than by configuring one
Runbooks, architecture notes and a handover that includes every credential and access path

Common questions

Do you take over software somebody else built?: Yes, and it is a large share of enterprise work. It starts with a review of what the system currently does, what it is supposed to do, and where those diverge. The output of that review is a written assessment you own outright, including the case for leaving it alone if that is the honest answer.
Who owns the code and the infrastructure?: You do, entirely. Code lives in your repositories and infrastructure runs in your accounts wherever that is practical from the first day rather than being migrated across at the end. Handover includes credentials, architecture documentation and runbooks, and the test of a real handover is whether your team can deploy without us.
What happens after launch?: Support arrangements are agreed before launch rather than improvised after it, and they are optional. A system that can only be operated by the people who wrote it has not been finished, so the alternative is always a genuine handover rather than a dependency.

Related practices

Let's Build Something Extraordinary.

Whether you're looking to collaborate, partner with us or simply follow our journey, we'd love to hear from you.

info@starblyn.com