Consultancy
A second opinion from people who've had to live with it
Some technical decisions are difficult to make when you're the business who must live with them, especially if you don’t have the technical expertise in house to really judge them. Is the system architecture going to scale how we expect? The technical debt we’re accumulated, does it need fixing now or is it just a bit annoying to deal with? The most common questions we get are “Is the quote you've been given reasonable?” and “And if you're not technical yourself, who do you trust to give you a straight answer?”
We review architecture, assess codebases, and give you an independent view on decisions like build versus buy. We've built systems handling millions of payments a year, rebuilt fifteen-year-old desktop applications into a modern web apps, and inherited plenty of other people's decisions along the way. We've seen the shortcuts that turned out fine, and the ones that quietly became the reason nothing shipped on time three years later.
You get a fixed scope, a clear deliverable, and our honest assessment in writing. We're not bidding for the work, selling you a platform, or trying to turn a review into a six-month engagement. We're there to help you make the decision. What you do with it afterwards is up to you.
What we cover
Architecture review
We 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, not just a list of everything we'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. We have no stake in the answer, which is the only reason the answer is worth anything. Most recently the recommendation is to buy, and occasionally it's to leave it alone for another year although with the rise of AI, building is becoming a bit cheaper than it used to be.
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. We'll read the proposal, understand the project specification 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. We'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 when something's wrong, but less often right about the order to tackle it in. We'll help you sequence it against what the business actually needs at this point in time.
How it works
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
We 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, we're 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.
What's included
- A defined question, agreed upfront
- A written assessment you can act on or forward
- Findings ranked by urgency, with the reasoning
- A call to talk it through properly
- A fixed price - no retainer, no follow-on pitch
- An honest "don't build this" when that's the answer
Proof
Consultancy is the one thing we 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 we've built for, we still work with today, which is the closest thing to a reference we can offer.
Frequently asked questions
What do I actually get at the end?+
A written assessment, not a slide deck of generalities. It sets out what we found, what we'd recommend, and the order we'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 we can offer at this time. Of course, we're always happy to have a chat about ongoing issues you have, or if you'd just like a general chat about anything we're happy to help, but consistent CTO work isn't something we can offer.
Will you tell me not to build something?+
We tell clients not to build things all the time! 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. We're not quoting for the build, so 'don't do this, do this instead' costs us nothing to say. If a review always ended in 'you should commission a project', you'd be right to be skepical and 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. We'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. We'll tell you which, and we 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 we 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 we'll let you know whether it's realistic or not.
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. This is simply because it's really difficult for us to know the number of hours it'll take, and we don't want to be racking up the meter for you. What moves it is the size of the system, the type of consultancy, how much of it is in scope, and how deep you want us to go. You'll get a fixed price once we've agreed the question and type of review, and if the scope is too broad to price sensibly we'll suggest narrowing it rather than padding the estimate.
Will you work directly with our engineering team?+
Yes we can! Your engineers usually already know where the problems are; what they often lack is someone external saying it out loud, or being able to communicate those issues with relevant urgency. We come at it as fellow engineers trying to understand the decisions, not as auditors looking for faults. If the brief is really about assessing individuals rather than the system, we're the wrong fit as we're not here to judge your engineers or your team!
What do you need from us to get started?+
It depends on the type of consultancy work. If it's code review, we'll need read access to the code, whatever documentation exists if you have any, 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, we can work with less, though we'll be explicit in the report about what we couldn't see rather than filling the gaps with assumptions, but we'll outline these risks during the initial quotation.
Is this worth it if we're a small business rather than a startup?+
Yes, often more so. Small businesses tend to make one or two big software decisions in a decade or so, and getting one wrong is genuinely painful and can really limit growth because there's no room to absorb it. You may only have a handful of staff, and them being stuck dealing with poor software and design choices is not a good position to be in. 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.