Services · 04
Software Development & Feature Engineering. Most of it is somebody else’s code.
Features added to software that already runs, applications built from nothing where there is nothing to add to, and the checks around both that let somebody else carry it afterwards.
What I build here
The hard part is not the feature. It is what the feature sits on.
Writing a feature on a blank page is the easy version of this work. Writing one inside a system that already has users, already has data in it, and already has behaviour somebody depends on is a different job, and most of it happens before the first line changes.
I read the system before I change it, and I tell you what I found. That is not caution, it is where the money is: the expensive mistake in inherited software is almost never the code that got written, it is the assumption nobody checked.
Sometimes what I find is that the change you asked for is cheap and the thing underneath it is not. You get told that in the same week rather than in the third month.
- 01 A feature added to software that is already in production SCOPE
- 02 Taking over a system whose author has moved on SCOPE
- 03 An integration between something you run and something you bought SCOPE
- 04 A custom application where no product fits the shape of the problem SCOPE
- 05 A rule that matters turned into a check that fails the build SCOPE
- 06 The documentation and the accounts that make it yours rather than mine SCOPE
The operating principle
“Read it before you change it.”
A system that has been running for two years has already answered questions nobody wrote down. Some of those answers are load-bearing and some are accidents, and the only way to tell is to look at what calls what before deciding which is which.
Open the diagram description
A five stage sequence, read from left to right, showing how a feature gets added to software that somebody else already runs. Stage one, Read the system, is drawn as the largest panel because the reading is the work. It lists what calls what, what fails quietly today, what has no owner, and what nobody would notice for a month. Stage two, Name the assumption, asks which of the answers a running system has already given are load-bearing and which are not. Stage three, Make the change, notes that alerting and a way back come first, in that order. Stage four, Turn a rule into a check, says the check fails the build so that the rule survives the person who remembers it. Stage five, Hand it over in your name, covers the documentation and the accounts that make it yours. Below stage two a branch arrow drops to a dimmed panel which reads: sometimes the answer is that rebuilding is cheaper than inheriting, and you get told in week one. Below stage four a highlighted panel is joined by two short arrows, one going down into it and one coming back up, and it reads: and a fixture that proves the check can still go red. A closing line across the bottom reads, the expensive mistake in inherited software is the assumption nobody checked.
Drawn from this page’s own copy. It is the shape the work takes, not a picture of any one client’s system.
Taking one over
The first week is reading, not writing.
When a system arrives without the person who built it, the first piece of work is finding out what it does rather than changing it. What runs, what calls what, where it fails quietly today, what has no owner, and what would nobody notice for a month.
Alerting and a way back come before the first rewrite, in that order, because a change to a system you cannot observe is a change you cannot undo with any confidence.
If the honest answer is that rebuilding is cheaper than inheriting, I say so with the reasoning rather than quietly billing the difference.
What makes it safe to hand back
A rule that matters becomes a check.
Every system has rules that are held up by somebody remembering. A wellness app cannot make medical claims. A document cannot be filed without its classification. A price cannot go out unrounded. Those survive exactly as long as the person who knows them.
So the rule becomes a check that fails the build, and the check gets a fixture that proves it can still fail. A check nobody has watched go red is not a check. The full version of that argument, with the linter that does it.
The same discipline applies to code I did not type. I use AI coding tools every day, and nothing they produce reaches a real account without being read line by line, tested against safe fake data, and dry-run first.
The proof
Three builds, and only one of them started empty.
A search layer inside a tenant that already existed
A custom guided-search experience built into a live Microsoft 365 environment, with the native library left as the source of truth and reachable if the custom layer is not.
SPFx · React · TypeScript · Feature development on existing systemsVoiceInbox
A desktop application, because the constraint was that the audio could not leave the machine and no product does that. The model runs locally and the one API key lives in the system keychain.
Tauri · Rust · Desktop applicationsA wording policy that runs in CI
A rule that used to be a review step, written as a linter that reads every string the app can display in both languages and stops the build on a forbidden phrase.
CI · Policy as code · Automated checks in CICommon questions
What people ask before handing over a repository.
Will you work inside our stack rather than yours?
Yes. The stack line on this page is what I reach for when the choice is mine, and on this kind of work it usually is not. What matters more is whether the system can be read, run and tested by somebody other than its author, and that is a property I will try to leave behind rather than one I need to arrive to.
Can you work alongside our existing engineering team?
Yes, and it is a normal shape rather than an exception. I have led hands-on engineering teams and handed systems over to teams on three continents. What matters is that ownership is explicit from the start: who runs it, who is alerted, and what they have been given to run it with.
What if the code is bad?
Most inherited code is fine and misunderstood, some of it is genuinely bad, and telling the two apart is the first week rather than an opinion formed on the first read. When it is bad I will say which part, what it costs you now, and what it would cost to leave alone, and then it is your call rather than mine.
What next
Scope, then a fixed number.
Most first projects fall between a two-week scoped build and a two-month one. The number is fixed against a written scope after a discovery call, so you approve it before anything is built. What moves it inside that range, in full.
Somebody else’s code
What is the change nobody wants to make?
Tell me what the system is, who built it, and what it has to do next. I will tell you whether the honest answer is a feature, a repair, or a rebuild, and what I would read first.
Ask Dan on WhatsApp (opens in a new tab)or email dan@burdetsky.xyz