Consultancy
A second opinion from someone who's had to live with it
The expensive technical decisions are the ones made in a room where nobody has had to maintain the consequences. I review architecture, assess codebases, and give you a straight answer on build versus buy. Fixed scope, clear deliverable, no retainer.
There's a particular kind of decision that's hard to get right from inside: whether the architecture you're committing to will still work at ten times the volume, whether the quote you've been given is reasonable, whether the technical debt you keep hearing about is genuinely urgent or just uncomfortable. Everyone with an opinion in the room usually has a stake in the answer.
I don't. I'm not bidding for the build, I'm not selling you a platform, and I'm not trying to convert a review into a six-month engagement. That's the whole point of buying an opinion from someone outside it. You get my honest read, in writing, and what you do with it is your business.
What I bring to it is having been on the receiving end. Over a decade I've built systems handling millions of payments a year, rebuilt a fifteen-year-old desktop application into a modern web app, and inherited plenty of other people's decisions. I know which shortcuts turn out to be fine and which ones quietly become the reason nothing ships on time three years later.
Architecture review
I go through your system as it stands and report back on what will hold up, what won't, and what will hurt first. You get a written assessment with the problems ranked by how urgent they actually are, rather than a list of everything I'd have done differently.
Technical due diligence
Buying a company, investing in one, or getting your own house in order before someone looks at it. An assessment of the codebase, the architecture, the key-person risk, and the things that would be expensive to discover after the money has moved. Delivered as a report you can hand to other people.
Build vs buy
A straight recommendation on whether to build something custom, buy something existing, or do neither yet. I have no stake in the answer, which is the only reason the answer is worth anything. Frequently the recommendation is to buy, and occasionally it's to leave it alone for another year.
A second opinion on a quote
You've been quoted for a piece of work and you can't tell whether the number and the timeline are reasonable. I'll read the proposal and tell you what looks sensible, what looks optimistic, and which questions to put back to whoever wrote it before you sign.
Reviewing another developer's work
Something has been built and you're not sure what you've got. I'll assess the state of it: whether it's maintainable, whether it's finished, whether it's secure enough for what it's doing, and what it would take for someone else to pick it up. Useful when a relationship is ending, or before you commit further.
Technical debt & roadmap input
Working out which of the problems your team keeps raising genuinely need fixing now, and which can wait. Engineering teams are usually right that something's wrong and less often right about the order to tackle it in. I'll help you sequence it against what the business actually needs.
Agree the question
We define precisely what you want answered and what you'll get back, before anything starts. A vague review produces a vague report that nobody acts on, so this bit matters more than it sounds.
Dig in
I read the code, the architecture, and the documentation, and talk to whoever knows how it really works, which is rarely the same as what the diagram says. If your engineers are involved, I'm there to understand their reasoning, not to mark their homework.
Report and talk it through
You get a written assessment with clear recommendations, ranked by urgency, and a conversation to go through it properly. Then it's yours. No retainer, no follow-on commitment, and no proposal attached to the back of it.
Consultancy is the one thing I do where the deliverable is an opinion, so there aren't neat numbers to put here. What's behind it is over a decade of building and maintaining software across healthcare, fintech, logistics, and consumer: 40-odd shipped products, systems processing millions of payments a year, and enough inherited codebases to know what ages badly. Every business I've built for, I still work with today, which is the closest thing to a reference I can offer.
What do I actually get at the end?+
A written assessment, not a slide deck of generalities. It sets out what I found, what I'd recommend, and the order I'd tackle things in, with the reasoning attached so your team can disagree with it on the merits. Then we talk it through properly. It's a document you can act on, forward to your board, or hand to whoever does the work.
Do you offer ongoing or fractional CTO time?+
Unfortunately, it's not something I can offer at this time. Of course, I'm always happy to have a chat about ongoing issues you have, or if you'd just like a general chat about anything i'm happy to help, but consistent CTO work isn't something I can offer.
Will you tell me not to build something?+
Regularly, yes. It's most of the value. The recommendation is often to buy something off the shelf, to fix a process rather than write software, or to wait until you know more. I'm not quoting for the build, so 'don't do this' costs me nothing to say. If a review always ended in 'you should commission a project', you'd be right to ignore it.
Can you review work another developer or agency has done?+
Yes, and it's one of the more common reasons people get in touch. I'll give you a fair assessment rather than the easy answer, which cuts both ways: sometimes the work is genuinely fine and the frustration is a communication problem, and sometimes it's worse than you feared. I'll tell you which, and I won't dress up a rebuild pitch as a review.
How long does a review take?+
Usually one to three weeks from getting access to delivering the report, depending on the size of the system and how quickly I can get hold of the people who understand it. It's very rarely months. If your timeline is tighter than that because of a deal or a board date, say so upfront and I'll tell you honestly whether it's doable.
What does a review cost?+
It's priced per piece of work rather than by the hour, so you know the number before you commit. What moves it is the size of the system, how much of it is in scope, and how deep you want me to go. You'll get a fixed price once we've agreed the question, and if the scope is too broad to price sensibly I'll suggest narrowing it rather than padding the estimate.
Will you work directly with our engineering team?+
Yes, and it goes much better that way. Your engineers usually already know where the problems are; what they often lack is someone external saying it out loud. I come at it as another engineer trying to understand the decisions, not as an auditor looking for faults. If the brief is really about assessing individuals rather than the system, I'm the wrong person.
What do you need from us to get started?+
Read access to the code, whatever documentation exists even if it's out of date, and an hour or so with the people who know how the system works in practice. If you're mid-acquisition and access is limited, I can work with less, though I'll be explicit in the report about what I couldn't see rather than quietly filling the gaps with assumptions.
Is this worth it if we're a small business rather than a startup?+
Often more so. Small businesses tend to make one or two big software decisions a decade, and getting one wrong is genuinely painful because there's no room to absorb it. A review before you commit to a large build is a fraction of the cost of the build itself, and considerably cheaper than eighteen months into the wrong one.