You Work With Me.
Every Project.
Who architects your system, who writes the code, what I will refuse to recommend, and what each engagement actually costs. Every .NET version since 1.1 in 2003. Still shipping on .NET 10.
The Person Who Sold It Is the Person Who Builds It
You work with me. Every project. I architect and review every engagement personally — that doesn't get delegated.
The engineers alongside me are people I have worked with for years and go on working with, project after project. Not a rotating cast, and not strangers matched to a requirement sheet — a settled group whose work I already know, building to my design and under my review.
You always know who is writing your code, and it is never a stranger from a bench.
The same people
The engineers alongside me are a settled group I have worked with for years and go on working with. Nobody is matched to your project from a requirement sheet.
From VB6 to .NET 10
Between us the coverage runs from VB6, MS Access, VBA and classic ASP right through to .NET 10 — so a system from any era meets somebody who has shipped in it.
One design, one reviewer
Everyone who touches your system builds to my architecture and under my review. That is what makes the accountability real rather than a promise.
I don't subcontract projects out and I don't sell staff augmentation. I'm not a middleman placing bodies.
Where others contribute, they're people I've worked with for years, on my design, under my review — and I remain accountable for every deliverable.
I Don't Recommend Large Rewrites
I don't recommend large rewrites. Most systems that “need replacing” need three or four targeted changes. We modernise incrementally — section by section, with the existing system running throughout.
A rewrite quote is really a quote for re-deriving your business rules. Those rules are in the running code and almost never anywhere else — every exception, every special case for one important customer, every rule someone added after an expensive mistake. A specification written now is a summary of what people currently remember, which is why the rebuild both overruns and arrives missing behaviour nobody could name until it was gone.
Reading the existing system first usually finds that the thing actually blocking you is narrower than the rewrite it triggered — infrastructure the code assumes, a dependency that is out of support, a deployment path nobody has touched in years. Those are addressable without touching the business logic at all.
How the assessment establishes which one you have →Put a router in front of the old system
A reverse proxy sits between your users and the existing application. Every request still reaches the old system, so nothing has changed yet — but we now have a seam, and a seam is the thing that makes everything after this reversible.
Extract a service layer behind it
One capability at a time, the business logic moves out from behind the UI into a service with its own tests and its own contract. The old screens keep calling it. If the extraction is wrong, we find out against a working system rather than against a launch date.
Replace the interface section by section
The router starts sending one section — one module, one workflow — to the new front end while everything else stays exactly where it was. Users learn one screen at a time instead of arriving one Monday to an unfamiliar system.
Cut over when the new path is boring
The old route stays live and reachable until the new one has been in production long enough to be dull. Rollback is a routing change, not a restore from backup. That is the entire reason for doing it this way.
Four Ways In, In Order of Commitment
Each step answers a different question, and each one states what it deliberately does not cover. You should be able to tell which one you need without talking to me first — if you can't, that is a fault in this page rather than in you.
Technical Diagnostic
For you if: You suspect the estate is a problem but nobody has established whether it actually is, or whether now is the moment to spend money on it.
- A 45-minute call — with me, not a salesperson — about what the system does and what is prompting the question.
- A short written summary afterwards: which .NET version you are on, whether it is still in support, and where that leaves you.
- The two or three biggest risks as they stand, named specifically rather than as general warnings.
- A straight answer on whether modernisation is worth doing yet. Sometimes it is not, and that is a useful thing to know for free.
What this is not: This diagnoses. It does not plan. A migration plan requires reading your code, which is the paid assessment below — anyone offering you a costed plan off the back of one call is guessing, and the guess will be wrong in your favour until the invoice arrives.
Book the free diagnosticModernisation Assessment
For you if: You have accepted something needs doing and now need a number you can take to a budget holder — one that will survive contact with the code.
- A system and dependency map: what the application is actually composed of, and which versions you are pinned to.
- A named risk register rather than general warnings, including anything already out of support.
- A per-module position on incremental migration versus rebuild, because the answer is rarely the same across a whole estate.
- A phased plan with effort sized per phase and the assumptions shown, so your engineers can challenge them.
- A costed first phase — or a written explanation of why the system should be left alone, which is a legitimate and reasonably common outcome.
What this is not: The fee is credited in full against the modernisation project if you proceed within 90 days.
Request the assessmentFixed-Scope Modernisation Project
For you if: The assessment is done, the phases are agreed, and you want the first one delivered against a scope and a price that were both worked out by reading your code rather than estimated from a description.
- A fixed price for the agreed phase, produced by the assessment rather than quoted off a conversation.
- The phases delivered section by section, with your existing system running throughout.
- Architecture and code review by me on every phase — that part does not get delegated.
- Tests written alongside the work rather than promised for later, and a build that fails on warnings.
- A working, deployed system at the end of each phase, not just at the end of the project.
What this is not: There is no published price band here on purpose. Anyone quoting you a range before reading your code is guessing, and the guess runs in their favour until the invoice arrives. The assessment produces the number; once it is agreed it is fixed, and work beyond the written scope is quoted separately rather than absorbed silently.
See how we workSupport & Maintenance Retainer
For you if: The system is business-critical, the people who built it have gone, and you need someone who knows why it works the way it does to still be there in two years.
- Bug fixes, security patching, framework and dependency upgrades, and performance work on a system I already know.
- A named person — me — rather than a ticket queue and a rotating cast.
- Continuity of context. The reason clients stay is that we are the ones who remember why a particular calculation works the way it does.
What this is not: Not a lock-in: the minimum term is a single month, and it runs rolling after that. The figure depends on what the system is and what keeping it healthy actually takes, so it is set after reviewing it rather than published as a band. And a retainer is not an unlimited change budget — new capability is scoped and quoted as project work, while the retainer keeps what exists running and current.
Talk about ongoing supportAI Readiness is the follow-on, not the front door. If your systems are already supportable and current, it is the right next engagement. If they are not, the modernisation assessment comes first — an AI integration plan for a system you cannot safely deploy to is a plan you cannot act on. The AI Readiness Assessment.
This Isn't a Fit If…
Four situations where you should hire someone else. Knowing this before a first call saves us both a month.
You want the lowest hourly rate
There are firms considerably cheaper than me, and if hourly rate is the deciding variable you should use one of them. What you are paying for here is that the person who designs the system is the person who reviews every change to it, and that arrangement does not come at the bottom of the market.
You need a large team at short notice
A team on your project is fine — that happens, greenfield especially. Six engineers starting next month is not: they are engaged for the work rather than sitting on a bench, so a team forms around a project rather than waiting for one. If your constraint is headcount at speed rather than judgement, a larger firm is genuinely the right answer.
You want engineers to direct yourself
A dedicated team on your project is something I do offer — greenfield especially. What I can't do is hand you engineers to line-manage on a design nobody here owns. I take responsibility for outcomes, which means I have to own how the thing is built; those two are the same sentence. If your leadership wants the architecture to be theirs, that is a legitimate model and you should buy it from someone who sells it.
You want a full rewrite from day one
If the decision to rebuild from scratch is already made and not open to evidence, we will spend the engagement disagreeing. I will always look for the three or four targeted changes first, and if you have already ruled that out, I am the wrong person to argue with for three months.
Still Not Sure Which Step You Need?
Tell me what the system does today and what is prompting the question. Forty-five minutes, no charge, and a written summary afterwards whether or not there is anything here for me.