Software
Software development, built for the second year.
Web applications, internal platforms and APIs. Getting the first version out is rarely the hard part. The hard part is the system still being safe to change once the people who built it have moved on.
- Custom software
- Enterprise systems
- SaaS platforms
- Web applications
- APIs and integration
- Modernisation
Why systems decay
Nothing fails on the day it ships.
Systems fail slowly. A year of reasonable-looking compromises, each one defensible on its own, until the team is wary of the codebase and a small change takes a fortnight. These are the ones that do most of the damage, and what we do about each.
Nobody wrote down why
The reasoning lives in a chat thread and the person who had it has left. We keep decision records: the option taken, the ones rejected, what each would have cost, and the dissenting view if there was one.
The tests only cover the easy paths
A coverage percentage tells you almost nothing. What matters is whether the seams and the failure paths are tested, because those are what a change breaks and those are what nobody checks by hand.
Types stop at the boundary
Validated at the edge and typed all the way through. An unchecked payload from a third party is how a small bug becomes a data problem you find out about six weeks later.
The environment is a person
If one engineer is the only one who can deploy it, that is not a deployment process. Setup scripted, environments reproducible, access granted through something auditable rather than remembered.
Nobody owns it
A system with no named operator drifts. Dependencies age out of support, certificates expire on a Sunday, and alerts get muted because nobody knows which ones matter.
Scope
What the work covers.
Most engagements are one of these with part of another. We will tell you which parts your problem does not need.
Custom software
Applications shaped around how the work is actually done rather than around whatever a template made convenient. Usually replacing a process held together by spreadsheets and one very patient person.
Enterprise systems
Governance, auditability, access control and change management treated as design inputs. Retrofitting them after a security review is the expensive way to arrive at the same place.
SaaS platforms
Multi-tenancy, billing, onboarding and the operational metrics a product needs before it has customers it can lose. Tenancy in particular is close to impossible to add later.
Web applications
Systems with users who log in and data that changes. This is the side of the line where correctness matters more than composition, and where state is the thing that actually has to be designed.
APIs and integration
Contracts, versioning and documentation built so the next team can work against them without reading your source, and so a change on one side does not quietly break the other.
Modernisation
Taking apart a system nobody wants to touch, in pieces, while it keeps running. More on that below.
Handover
What you get besides the software.
The code is the part everyone expects. These are the parts that decide whether the next team can do anything with it, and they are written as the work happens rather than assembled in the last week.
Decision records
Every architectural decision with its alternatives, costs, risks and the dissenting view. So the choice can be re-examined later on its own terms instead of reverse-engineered from the code.
A runbook
How to deploy it, how to roll it back, what the alerts mean, who to call, and what to do at three in the morning when the thing nobody planned for happens.
A test suite that means something
Tests at the boundaries and the failure paths, runnable by anyone on your side, fast enough that people actually run them.
Reproducible environments
A scripted setup that gets a new engineer running the same way every time, rather than a wiki page that was accurate once.
An access map
What exists, who can reach it, and through what. Useful on the first day and essential on the day somebody leaves.
Source and rights, yours
You own the code and the infrastructure definitions from the first commit. There is nothing to buy back at the end and nothing you need our permission to change.
Modernisation
Taking over a system somebody else built.
A rewrite that lands in two years and misses the behaviour that actually mattered is the most expensive way to solve this problem. We take the system apart in pieces while it keeps running.
Read it before touching it
Including the parts that look wrong. Odd-looking code is often the only record of a rule somebody needed once, and deleting it is how a quiet three-year-old requirement resurfaces as an incident.
Characterise the behaviour
Tests written against what the system does today, not what the documentation claims. That becomes the contract the replacement has to honour, and the only honest way to tell whether the new thing is equivalent.
Strangle rather than replace
New functionality goes in beside the old system behind a boundary, and traffic moves across a piece at a time. Every step is reversible and every step ships.
Leave the riskiest part until last
By the time you reach it you understand the system properly and the surrounding pieces are already proven. Starting with the scariest component is how projects stall in month three.
Run both until one is boring
The old path stays available until the new one has been unremarkable for long enough to trust. Switching off is a decision made on evidence, not a date in a plan.
Delivery
How a project runs.
The same shape every time, with the detail set by what we find in the first phase.
Discovery
What the work actually is, who does it today, where it breaks, and what would have to be true for this to be worth building.
Architecture
Boundaries, data model, integration points and the decisions written down with their costs and risks before anyone writes code against them.
Build
Vertical slices that reach production, not layers that get integrated at the end. You see working software early and the surprises arrive while they are still cheap.
Hardening
Load, failure, access control and the paths nobody tests by hand. Plus the runbook, written by the people who will be on the end of it.
Operate
Monitoring, dependency upgrades, incident response and the unglamorous maintenance that keeps a system changeable. We stay on it.
Questions
The ones worth asking first.
Can you work with our existing team?
Usually that works better than working around them. Your engineers know things about the business that are not written anywhere, and a system built without that knowledge tends to be correct and useless. In practice it means shared review, shared standards and a deliberate transfer of context in both directions rather than a delivery at the end.
What if our codebase is a mess?
Most are, and it is rarely anyone in particular’s fault. The first question is not how to clean it but which part is actually costing you something, because a lot of ugly code is stable, cheap to leave alone and not worth the risk of touching. We characterise before changing.
Do you use our stack or yours?
Yours, unless there is a reason that survives being written down. A system your team cannot maintain is a liability however good the technology is. Where we do recommend a change, it comes with the cost, the risk and what you would give up, and you make the call.
Who owns the code?
You do, from the first commit. Source, infrastructure definitions and documentation sit in your repositories under your accounts. There is nothing to buy back at the end and no component you need our permission to change.
What happens if we part ways?
You keep a system somebody else can pick up, which is the point of the decision records, the runbook and the reproducible setup. We would rather be kept because the work is good than because leaving is difficult.
Fixed price or time and materials?
Both exist and both fail in predictable ways: a fixed price on a vague scope buys you a change-request process instead of software, and open-ended time on an unclear goal buys you a habit. We scope a first phase tightly enough to price it honestly, and the estimate for what follows is worth something only because that phase happened.
Tell us what you are trying to build.
Or what you are trying to get off. Describe the system and the constraint it has to work within, and you will get an engineer on the call.
info@eorbitt.com · We reply within one business day.