Engagement Models
Software Consulting Services
Independent technical advice from engineers who actually ship and operate software, not career consultants who have only ever drawn the diagrams. Architecture reviews, technology strategy, audits, due diligence and honest second opinions on the decisions that are expensive to get wrong. We have no build to sell you, so when the right answer is to do less, buy off the shelf, or not build at all, we will say so.
What Software Consulting means in practice
Who it’s for: Leaders and teams facing a technical decision that is expensive to get wrong: a major architecture or platform choice, a stalled or troubled project that needs a straight diagnosis, technical due diligence on a company being bought or invested in, a scaling problem, or simply the wish for an honest second opinion from someone with no product to sell.
There is a moment before every significant technical decision where the cost of being wrong is enormous and the information you have is thin. You are about to commit to an architecture, sign a seven-figure vendor contract, greenlight a rebuild, buy a company for its technology, or pour another year into a project that is already late. The people advising you internally are the same people who proposed the plan, and the outside firms circling the decision mostly want to sell you the thing the decision leads to. Software consulting, done properly, is the independent voice in that moment: a senior engineer with no stake in the outcome telling you what they actually think, including the parts you were hoping not to hear.
This is advice, not a build, and the distinction matters more than it sounds. Building software and advising on it are different jobs, and the industry is full of consultants who are excellent at the second because they have never had to do the first: their diagrams are clean, their frameworks are tidy, and none of it has ever been paged at three in the morning when the design they drew met real traffic. Our consulting comes from the other direction. We advise as engineers who build and operate systems for a living, so what we tell you is grounded in what actually survives production rather than in what reads well in a strategy deck. The recommendation and the reality are informed by the same people.
The single thing that makes consulting worth paying for is candour, and candour is precisely what most engagements quietly lack. A consultant whose next contract depends on pleasing you has every incentive to validate your plan, praise your architecture and endorse your vendor: to sell you permission rather than judgement. We keep our incentives clean so that the inconvenient conclusion is one we can afford to reach: that your architecture is wrong, that your project is doomed as currently scoped, that the platform you are about to standardise on is a mistake, or that the thing you want to build should not be built at all. You are not paying us to make you comfortable. You are paying us to tell you what we would tell a colleague.
What you get
- A direct, written assessment of the specific decision or system in front of you. The real findings, the risks ordered by how much they actually matter, and the reasoning laid out so you can challenge it rather than take it on faith
- An architecture and technology review that judges your design and stack against how it will behave in production, not against a checklist of current fashions
- A code and technical-health audit where relevant. The quality, the shortcuts, the risk concentrated in one person or one fragile module, and what it would genuinely cost to put right
- A security and risk read as part of the assessment: where the system is exposed, what an attacker would actually reach, and what belongs at the top of the fix list
- Clear build-versus-buy and do-versus-do-not guidance, with the trade-offs on cost, lock-in, timeline and maintenance stated plainly rather than hedged
- A prioritised, actionable set of recommendations, sequenced, costed at the level of effort, and written to be acted on rather than filed
- A working session with your leadership and your engineers to make sure the recommendations are understood, owned and turned into decisions before we leave
What Software Consulting does for you
The expensive mistake caught before you make it
The decisions we are brought in for (an architecture, a platform, an acquisition, a rebuild), are the ones where being wrong costs a year and a fortune, and where the cost of getting a second opinion is trivial by comparison. Finding out on paper that a plan does not hold, before the money is committed, is the cheapest good outcome available to you, and it is the one this work most often delivers.
Judgement with the incentives removed
The value of independent advice is that it can afford to be honest. Because we are not selling you the build, the platform or the vendor that the decision leads to, we have no reason to shade a recommendation toward what earns us more. That is what lets a "buy off the shelf", "do far less than you planned", or "do not do this at all" be a real conclusion rather than a courtesy, and it is what makes a "yes, proceed" worth trusting when we give one.
Advice that survives contact with production
Because we build and operate software ourselves, our recommendations are calibrated to what actually works under real load, real teams and real deadlines, not to the idealised version that looks correct until it ships. You get counsel that already accounts for the messy realities, so you are not left discovering them yourself six months later.
Why teams choose us for Software Consulting
- We are engineers who ship and operate software, so our advice is grounded in what survives production. A fundamentally different and more useful thing than strategy from people who have drawn many architectures and delivered none.
- We have no build, platform or vendor margin riding on the outcome, so when the honest answer is to do less, buy rather than build, or stop entirely, we can say it cleanly and without a conflict of interest.
- We will tell you the uncomfortable thing: that the architecture is wrong, the project is doomed as scoped, or the contract is a mistake, because candour is the entire product, and an assessment you cannot trust to include the bad news is worthless.
- Senior people do the assessing. The person reading your code and pressure-testing your plan is one who has had to make these decisions and live with them, not a junior running a template over your system.
What Software Consulting includes
The concrete pieces of work this covers, scoped to what your problem actually needs.
Architecture review and technical strategy
A hard look at your system design or your proposed one, where it will bend as you grow, where the coupling and the single points of failure are, and where it is over-engineered for problems you do not have. Delivered as a clear view of what to change, what to leave, and a technology strategy that fits where the business is actually going.
Technology selection and second opinions
Independent guidance on the platform, framework, database or vendor decisions that are painful to reverse. We weigh the options on their merits for your constraints (cost, lock-in, hiring market, operational burden), as people with no horse in the race, which is exactly what a second opinion is supposed to be.
Code and security audits
An assessment of the health of a codebase and its exposure: the quality and the shortcuts, the risk concentrated in one fragile area or one irreplaceable person, and the security weaknesses that actually chain into something. Prioritised by real impact, with an honest estimate of what remediation would cost.
Technical due diligence
For investors and acquirers, a clear-eyed read of a target’s technology: whether the product is what it is claimed to be, how much of the value is real engineering versus technical debt waiting to be paid, the key-person and security risks, and what it will genuinely cost to own and scale after the deal closes.
Scaling and performance review
When a system that worked at one scale is buckling at the next, we find out why. The bottleneck, the architectural assumption that no longer holds, the cost curve bending the wrong way, and set out what to fix, in what order, to get ahead of growth rather than perpetually behind it.
Troubled-project rescue and team assessment
When a project is late, over budget or quietly stuck, we diagnose why, scope, architecture, process, team, or a management structure that is hiding the problem, and give a straight verdict on whether it can be saved and how, including the cases where the honest recommendation is to stop.
Where it fits
Pressure-testing a big architecture decision
A team is about to commit to a major redesign (microservices, a new platform, a fresh data architecture), and the decision will shape the next several years. We stress-test the reasoning, name the risks the internal advocates have talked themselves past, and either endorse the plan with our own confidence behind it or set out plainly why it will not hold and what to do instead.
Diagnosing a project that has stalled
A build is months late, the estimates keep slipping, and leadership can no longer tell whether the problem is the team, the scope or the architecture. We come in from outside the reporting line, find the real cause rather than the reported one, and give a candid recommendation (fix it this way, restructure it, or stop before more is spent), with the reasoning that supports it.
Technical due diligence on an acquisition
An investor or acquirer is about to commit capital largely on the strength of a company’s technology and needs to know what they are really buying. We assess the codebase, the architecture, the security posture, the key-person risk and the true cost of ownership, and tell you where the story matches the substance and where it does not, before the money moves.
An honest second opinion before signing
A leader is being pushed toward a large vendor contract or a build their own people are enthusiastic about, and wants one independent expert to look at it cold. We assess whether it is the right call for the actual problem, where the hidden costs and lock-in sit, and whether a smaller, cheaper or off-the-shelf option would serve better, plainly enough to act on either way.
How we approach Software Consulting
We start by getting to the real question, which is rarely the one written in the brief. "Review our architecture" usually means "we are about to double our headcount and we are frightened this will not hold"; "is this project on track" usually means "we suspect it is not and we need someone outside the reporting line to say so". So the first thing we do is establish what decision actually hangs on the answer, because that determines where we dig deep and where a lighter look will do. An assessment that treats every part of a system as equally important produces a long report and no clarity; we go hard where the risk and the money are.
From there we look at the evidence rather than the story. We read the code, the architecture, the incident history, the cost data and the delivery record, and we talk to the engineers doing the work rather than only the people who commissioned the review, because the truth about a system almost always sits with the people maintaining it, and it is frequently different from the version presented upward. Because we build and operate software ourselves, we know what we are looking at: we can tell the difference between a pragmatic shortcut and a fault line, between complexity that is earning its keep and complexity that is quietly strangling the team. Then we tell you plainly what we found and what to do about it, in that order.
How we assess and hand you something you can act on
We begin by pinning down the decision the advice has to serve. A review with no decision behind it produces a tour of everything that could be improved and helps with nothing; a review anchored to a real choice (proceed or not, buy or build, save or stop), tells us exactly where depth is worth it and where it is not. So the opening conversation is about what actually hangs on the answer and by when, and we scope the work to that rather than to a generic audit of your entire estate.
Then we gather evidence from the ground rather than the summary. We read the code, the architecture and the infrastructure; we look at the incident history, the cost data and the delivery record; and we talk to the engineers doing the work, not only the people who commissioned the review. This matters because the honest state of a system almost always lives with the people maintaining it, and it is routinely at odds with the version that travels upward. Because we build and operate software ourselves, we can read what we find accurately: separating the shortcut that is fine from the one that is a fault line, the complexity that earns its place from the complexity that is quietly killing velocity.
From the evidence we form a judgement and we are willing to make it uncomfortable. We tell you plainly what we found, rank the issues by how much they actually matter rather than listing them flat, and give a clear recommendation on the decision that prompted the engagement, including, where it is warranted, that the plan is wrong, the project cannot be saved as scoped, or the thing should not be built. A recommendation you cannot trust to contain the bad news is not worth the paper, so we do not soften the parts you most need to hear.
Finally we make sure the advice lands, because a report that is admired and ignored has failed regardless of how good it was. We turn the findings into a prioritised, sequenced set of actions with the effort and trade-offs attached, and we sit down with your leadership and your engineers to walk through them until they are understood and owned. The measure of the engagement is not the quality of the document; it is whether, a month later, the right decisions have been made and the right work is underway.
Architecture review and technical strategy
A good architecture review is not a search for everything that could be better. Every system fails that test, and a list of a hundred improvements is indistinguishable from no guidance at all. It is a search for the small number of things that will actually hurt you, given where the business is going. So we anchor the review to your real trajectory: the growth you are planning for, the team you are hiring, the reliability the business now depends on, the change the product roadmap demands. Against that, most of a system’s imperfections do not matter, and a few of them matter enormously, and the job is to tell those apart with conviction.
We look hardest at the decisions that are expensive to reverse, because those are the ones where an outside opinion earns its cost. Where are the boundaries drawn, and will they still make sense at three times the load or the headcount? Where is the coupling that means a change here breaks something unrelated there? Where does the whole thing depend on one component, one service or one person who could take the system’s understanding with them? And, just as important, where has the design paid for flexibility it will never use: the premature microservices, the speculative abstraction, the platform chosen for a scale you are nowhere near, because over-engineering quietly taxes every future change and is as real a problem as under-engineering.
Technical strategy is where the review turns from diagnosis into direction. A stack and a design should fit the organisation that has to run them, not an idealised one: a small team is served by boring, well-understood technology it can operate and hire for, not by whatever is generating conference talks this year. So our strategy recommendations weigh the operational burden, the hiring market and the maintenance cost as heavily as raw capability, and they are explicit about what to change now, what to leave until it genuinely hurts, and what to deliberately never do. A strategy that only ever adds is not a strategy; the discipline is in what it tells you to leave alone.
Security and risk as part of the assessment
Security belongs in a technical assessment as a first-class concern, not a footnote, because the decisions we are usually advising on (an architecture, an acquisition, a platform choice), carry security consequences that are painful and expensive to unwind once committed. So where it is relevant to the question in front of you, we read the system for exposure: how access and trust are structured, where sensitive data lives and travels, what an attacker who got a foothold could actually reach, and which weaknesses chain together into something real rather than sitting as isolated theoretical findings. The point is to surface the risk that would actually be exploited, and to rank it by impact, not to hand you an undifferentiated scanner dump.
In technical due diligence the security read is often decisive, because it is where the gap between the story and the substance is widest. A target company will present its security as sound; the codebase, the dependency history and the access model frequently tell a different story, and the cost of closing that gap after a deal closes can materially change what the company is worth. We assess it honestly and price it into the picture: the concentration of risk, the compliance obligations that will attach on your watch, the remediation that will be needed, so you go into the decision knowing the real liability rather than discovering it as the new owner.
Because this is advisory work, the deliverable is a clear account of where you are exposed and what to do about it first, not a fix, though the same senior people can go on to do the remediation if you want them to. We are candid about severity in both directions: we will not inflate a low-risk finding to pad the report, and we will not soften a genuinely serious one because it is awkward. What you get is a risk picture you can act on and trust, prioritised by what an attacker would actually reach, so the effort goes where it reduces real exposure rather than where it merely looks diligent.
Signs it’s time
- You are about to make a big, hard-to-reverse technical decision (an architecture, a platform, a major vendor contract, a rebuild), and you want an independent expert to pressure-test it before you commit
- A project is stalled, late or over budget, and you need an honest diagnosis of why and whether it can be saved, from someone outside the team that is delivering it
- You are buying, investing in or merging with a company and need technical due diligence. A clear-eyed read of what you are actually acquiring, what it is worth and what it will cost to keep running
- The system is straining as you grow, or you simply want a candid second opinion on a decision your own people are too close to, or too invested in, to assess dispassionately
Candour is the method
Everything else about this service is in service of one discipline: the willingness to reach an inconvenient conclusion and state it plainly. It is easy to tell a client their architecture is sound, their project is nearly there and their vendor is a fine choice, and it makes for a pleasant engagement and a likely follow-on. It is harder, and worth far more, to tell them the design will not survive the scale they are planning for, the project cannot ship as scoped, or the contract they are about to sign is a mistake. We do the harder thing, because a consultant who only validates what you hoped to hear is selling permission, and permission is not what a serious decision needs.
We keep our incentives clean so that honesty is affordable. We are not reselling the platform, taking the vendor’s margin, or trying to maximise a build we have already decided you need, and crucially, we have no reason to recommend a large piece of work simply because we would profit from it. That independence is exactly what lets "do less than you planned", "buy this off the shelf", or "do not build this at all" be genuine recommendations rather than ones bent toward what earns us more. When we do tell you to build, you can weigh it knowing we were equally free to tell you not to.
And we are realistic rather than flattering about what we find. We would rather give you a sober read that leaves you clear-eyed than an encouraging one that sets you up to be blindsided, because the whole value of an outside expert is the perspective your own people are too close, or too invested, to hold. Calibrated honesty (about your system, your plan, your project and your options), is the entire product here. The reviews, the audits and the diligence are just the ways we earn the right to give it.
Technologies we build it with
Chosen per problem, not per fashion. This is the stack we most often reach for on this work.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Want a straight answer on Software Consulting?
A short call with a senior engineer, before you write a brief. If Software Consulting is the wrong answer for your situation, we will say so and tell you what we think is right.
What changes
A decision you can defend
Independent, evidence-based judgement on the choice in front of you, so you commit knowing why it is right, or walk away knowing why it was wrong, rather than hoping.
Risk you can see
The real problems in your system or plan surfaced and ranked by impact, including the ones nobody internal wanted to be the person to raise.
Recommendations that get acted on
A prioritised, practical set of next steps written to be delivered, not a handsome report that gathers dust while the situation it described gets worse.
Industries we serve
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
How pricing works
- Software consulting is priced on the scope and depth of the assessment rather than a headline rate, because a focused second opinion on a single decision and a full technical due diligence on an acquisition are very different pieces of work. The main drivers are how much of the system is in scope, how deep we need to go. A review of well-documented architecture is a lighter task than reverse-engineering a codebase nobody can fully explain, and how much is at stake in the decision the advice has to support.
- A focused engagement. An architecture review, a second opinion on a major decision, or a diagnosis of a troubled project, is typically a fixed-scope piece of work over one to a few weeks, priced to the depth required and delivered as a prioritised set of recommendations you can act on regardless of who does the resulting work.
- Technical due diligence is scoped to the transaction: the size and complexity of the target, the depth the investment or acquisition warrants, and the timeline you are working to. Because these often move on a deal clock, we are explicit up front about what we can assess in the time available and where a deeper look would need longer.
- Where an assessment leads into remediation or a build, we are transparent that the consulting fee bought you independent advice (including the freedom to conclude there is nothing worth doing), and never a commitment to proceed with us. The advice stands on its own, and it is yours to take anywhere.
Typical timeline
- 01
Framing the decision
A short opening phase establishing what actually hangs on the answer and by when, so the assessment is scoped to the real question rather than a generic audit, and so depth goes where the risk and the money are, not evenly across everything.
- 02
Evidence gathering
Reading the code, architecture, infrastructure, incident history and cost and delivery data, and talking to the engineers doing the work rather than only those who commissioned the review, because the honest state of a system lives with the people maintaining it.
- 03
Judgement and prioritisation
Forming a clear view, ranking the findings by how much they actually matter, and reaching a plain recommendation on the decision that prompted the engagement, including, where warranted, that the plan is wrong or the work should not be done.
- 04
Handover that gets acted on
A prioritised, sequenced set of recommendations with effort and trade-offs attached, worked through in person with your leadership and engineers until it is understood and owned, because a report that is admired and ignored has failed.
What working with us actually means
Engineers who build and operate, not career consultants
Our advice comes from people who ship and run software for a living, so it is calibrated to what actually survives production rather than to what looks correct in a diagram. That is a different and far more useful thing than counsel from advisers who have drawn many architectures and delivered none of them.
No build to sell, so no reason to oversell
We do not profit from recommending a large piece of work, so we have no incentive to tell you to build when you should buy, or to do more when you should do less. That is exactly what makes a "do not build this" a real recommendation, and a "yes, proceed" worth trusting when we give one.
We say the uncomfortable thing
If the architecture is wrong, the project is doomed as scoped, or the vendor is a mistake, we tell you plainly and early. Candour is the entire product, and an assessment you cannot rely on to include the bad news is worse than none, because it gives you false confidence to act on.
Advice that can continue into delivery, or not
If you want the same senior people to carry out the remediation or the build, they can, so nothing is lost in a handover. But the assessment stands on its own and is yours to take to your own team or anyone else. The consulting is a service you buy, not a funnel into work you did not need.
How to engage us
Three ways to work with us on this, chosen to fit the problem, not our margin.
- Dedicated team A standing team that works only on your product, in your rituals and your tooling. Best when the roadmap outlives the project. Ongoing product development
- Staff augmentation Named senior engineers embedded into your existing team, reporting into your leads. Best when you know what to build and need capacity. Filling a capability gap
- Software outsourcing A defined outcome delivered end-to-end by an accountable team. Best when you want the result owned, not just the hours filled. Outcome-owned delivery
Related services
Part of Dedicated Development Teams. Other work we do alongside this.
Weighing the options
The decisions people are usually making at the same time as this one.
Common questions
How is this different from hiring a big consultancy or a strategy firm?
The people giving you the advice are engineers who build and operate software, not career consultants who produce diagrams they never have to deliver. That changes what you get: our judgements are grounded in what actually survives production. The scaling failures, the operational cost, the way a design behaves under real load and a real team, rather than in a framework that looks tidy until someone has to ship it. And because we have no large build to sell you on the back of the advice, we have no incentive to inflate the scope of what you should do. You get a practical, candid read from someone who has lived the consequences of decisions like yours, not slideware.
Will you actually tell us if our project is failing, or just soften it?
We will tell you plainly, because that is the entire point of bringing in an outside voice. Troubled projects rarely fail for want of effort; they fail because scope, architecture, process or team problems have accumulated and nobody inside the reporting line can safely be the one to name them. We come in from outside that structure, find the real cause rather than the reported one, and give you a straight verdict, including, where it is the honest answer, that the project cannot be saved as scoped and the least expensive path is to stop. An assessment you cannot trust to include that conclusion is not worth commissioning.
We are acquiring a company for its technology. What does your due diligence actually cover?
We assess what you are really buying against what is being claimed: whether the product is the engineering it is presented as or a demo held together with technical debt, how the architecture will behave as you scale it, where the security and compliance exposure sits, how much of the system’s understanding is concentrated in a few key people who may leave, and what it will genuinely cost to own and run after the deal closes. The security and key-person reads are often where the story and the substance diverge most, and that gap can materially change what the company is worth. You get an honest picture before the capital is committed, not after.
Do you charge more if you recommend a bigger project?
No, and that is deliberate. The consulting is priced on the depth of the assessment, not on the size of whatever work it points to, so we gain nothing by telling you to build big when you should buy small or do nothing. This is the core reason independent advice is worth paying for: our recommendation to do less, to buy off the shelf, or not to build at all is a genuine conclusion rather than one bent toward our own revenue. If we do recommend a substantial build, you can weigh it knowing we were equally free (and equally paid), to recommend against one.
We just want a second opinion on one decision. Is that too small to bring you in for?
Not at all: a single high-stakes decision is one of the best reasons to bring us in, because it is precisely where an independent expert earns their cost many times over. A focused engagement on one architecture choice, one vendor contract or one build-versus-buy question is a tightly scoped piece of work, usually over a week or two, and the output is a plain recommendation with the reasoning behind it. The value is not in volume; it is in getting one expensive, hard-to-reverse decision right, assessed cold by someone with no stake in which way it goes.
Thinking about Software Consulting?
Tell us the problem in your own words, not in requirements. A senior engineer reads it and comes back with a straight view on whether Software Consulting is the right answer here, or what would be.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.