How Do You Judge Work You Cannot Read?
You can tell whether a salesperson is any good, or an accountant, or a designer. Software is the one supplier most founders have no instrument for assessing — and every decision about it is expensive. That gap is what this engagement exists to close.
Everything You Are Told Sounds Equally Plausible
A developer says a change will take six weeks. You have no way of knowing whether that is careful or padded. Three agencies quote for the same brief and the highest is eight times the lowest, all of them with confident decks. Somebody says the platform needs rewriting before it can grow, and they may be right, or they may simply prefer writing new code to reading old code.
None of this is resolved by reading about technology. It is resolved by having somebody on your side of the table who has built these things, has no interest in the outcome beyond yours, and will tell you which of the three quotes is the dangerous one. For a few hours a month, rather than an equity stake and a salary.
What Sits Inside the Engagement, and What Does Not
The honest version, including the parts that would be easy to quietly leave off a services page.
Architecture and Technology
What to build it in, what to buy rather than build, where the data lives, how it will cope at ten times the load, and which of the constraints you operate under — UK GDPR, an FCA-regulated client, WCAG 2.2 AA for public sector buyers, an insurer requiring an audit trail — genuinely change the design rather than just the paperwork. You make the call; we make sure you are making it with the trade-offs in front of you.
Oversight of Whoever Is Building It
Reviewing the output of an agency, a freelancer or your own first developer. Reading a statement of work before you sign it and telling you which clause will cost you. Sitting in on a supplier sprint review and asking the questions you cannot. Checking that what was delivered matches what was described. This is often the whole value of the engagement, and it usually pays for itself on the first quote we stop you signing.
Set-Piece Work
Technical due diligence before a funding round, and being in the room when an investor technical adviser runs theirs. Writing the technical section of a board pack or a data room. Defining and screening for your first engineering hire. Answering the technical half of a customer security questionnaire. A technology cost review when the cloud bill has quietly doubled. These come in bursts rather than monthly, which is why the hours are agreed rather than fixed.
What You Are Not Buying
Engineering capacity — we are not writing your features here, and if that is what you need it is a team or a fixed-price project. A signature to reassure an investor about a decision already taken. Legal, regulatory or tax advice. A seat on your board. And not a full-time CTO, which is a different job with different economics, described further down this page.
Four Choices That Are Free Today and Expensive in Year Two
These are the conversations that make up most of a first quarter. None of them takes long. All of them are painful to revisit later.
| The decision | What we actually ask | What getting it wrong costs later |
|---|---|---|
| Build it or buy it | Is this the thing your customers pay you for, or plumbing that a subscription already solves? | Months spent building a rota engine or a billing system that could have been rented for a few hundred pounds a month. |
| How the data is shaped | Will you ever have more than one branch, one brand, one country, or one currency? | The single most expensive retrofit in software. A multi-site retailer bolting locations onto a single-shop data model is a rebuild in all but name. |
| Where personal data sits | What do you genuinely need to hold, for how long, and how will a deletion request be serviced? | Retrofitting UK GDPR obligations across a live system, usually under time pressure from a customer contract or an ICO enquiry. |
| Who holds the accounts | Are the repository, the cloud account and the store listings in your company name from day one? | A recovery exercise instead of a handover, at exactly the moment you are trying to change supplier. See project rescue. |
Checking the Work Without Poisoning the Relationship
Most founders who want a supplier reviewed also want to keep that supplier. Both are usually achievable.
What we actually look at
Whether the work matches what was quoted. Whether tests exist around the parts that would hurt. Whether anybody but the author could pick it up. Whether security basics are in place. Whether the estimates given to you have any relationship to how long things took. Not coding style, and not the choice of framework, which is rarely worth an argument.
How it is raised
Engineer to engineer, privately, before anything is said to you as a verdict. Most findings are fixable and most developers fix them willingly when the conversation is technical rather than accusatory. You hear the version that matters: what it means commercially and what we advise.
When it is genuinely bad
Occasionally the answer is that the supplier should be changed, and we will say so plainly with the evidence attached. We will also tell you what that costs, because switching supplier mid-build is expensive and sometimes the cheaper answer is to finish the current phase and part company politely afterwards.
Run Your Own Diligence Before Somebody Else Runs Theirs
UK seed and Series A processes increasingly include a technical review. The cost of a surprise in that review is measured in valuation, not in engineering days.
Establish what is actually there
An inventory of the code, the infrastructure, the third-party services, the dependencies and their licences, and where personal data sits. Founders are regularly surprised by this list, particularly where several contractors have passed through.
Trace the chain of title
Written assignments from every contractor and agency who touched the code, and employment contracts that cover intellectual property for staff. This is the single most common thing to derail a UK funding round, and it is far cheaper to fix while everyone is still on speaking terms.
Fix what is cheap, disclose what is not
Some findings take a fortnight and are worth clearing. Others are structural and should be disclosed with a plan and a costing attached. Disclosed risks are negotiable. Discovered ones are leverage.
Write it down and be in the room
A clear technical narrative for the data room, and somebody technical on your side of the table when the investor adviser asks about scaling, security or the bus factor. Founders should not have to improvise those answers.
Your First Engineer Sets the Ceiling for Everyone After
The first technical hire writes the standards, interviews the second, and is very hard to replace once the product depends on them.
Work out what the role actually is
Most first job adverts we are shown describe three different people. We help you decide which one you need now, what a realistic salary band looks like for that skill in the city you are hiring in, and whether a permanent hire is even the right instrument yet.
Sit in on the technical interview
A short, paid, realistic exercise rather than puzzles at a whiteboard, and a technical conversation where somebody can tell the difference between a confident answer and a correct one. You still choose. You just choose with better information.
Give them somewhere to land
A new engineer arriving to an undocumented system and no technical peer is a resignation in slow motion. We stay on for a few months afterwards as someone for them to argue with, then step back once they have the context.
Deciding Which Debt to Pay and Which to Keep
Technical debt is not a moral failing, it is a loan. The only question is whether the interest is affordable.
Debt worth carrying
- Shortcuts in a feature that may be withdrawn in six months anyway.
- Manual processes that work fine at your current volume and cost a person twenty minutes a week.
- Untidy code in an area nobody has needed to change in a year.
- Infrastructure that is oversized for the traffic but cheap enough not to argue about.
- A dated interface on an internal screen five people use and none of them mind.
Debt that compounds
- Anything that makes every future change slower, which is where most projects quietly die.
- Missing tests around payments, pricing or anything that touches money.
- A data model that already cannot express what the business does.
- Framework or platform versions approaching the end of support.
- Knowledge held entirely by one person, whether that person is an employee or a supplier.
The practical output is a running list with the interest rate attached to each item, so that when a quarter has room for one piece of remedial work, the choice takes ten minutes rather than a fortnight of debate.
How Much Time This Usually Takes
Billed monthly in sterling excluding VAT against an agreed number of hours, reviewed quarterly. Most engagements move between these shapes as circumstances change.
A few hours a month
One scheduled call, plus reading whatever you send over and answering it properly. Suits a founder with a supplier who is performing, where the need is a second opinion before decisions rather than continuous involvement. The most common starting point.
Around two days a month
Weekly contact, reviewing work as it is delivered, involvement in planning, and the set-piece work when it arrives. Suits a company with a supplier or a first developer and a product that is actively changing.
About a day a week
Effectively part of the team: in planning, in hiring, in front of investors, and carrying the technical relationships. Usually a temporary shape around a raise, a migration or a period of rapid growth rather than a permanent arrangement.
The Point at Which You Should Hire a Real One
A fractional arrangement has a natural end, and we would rather name it than quietly extend past it.
Fractional still fits while
- The engineering is done by suppliers or by one or two people.
- The hard technical decisions come up monthly rather than daily.
- Nobody needs to be in a room at short notice to make a call.
- The product is one thing rather than a portfolio of connected systems.
- Technology supports the business rather than being the business.
You have outgrown it when
- You employ more than about six engineers, who need managing, developing and reviewing.
- Technical decisions arise several times a week and waiting a fortnight blocks people.
- Engineering culture, career paths and retention have become real problems.
- Your product is the technology, and the roadmap is a technology roadmap.
- Customers or regulators expect a named accountable technical officer inside the company.
When that point arrives we will say so, help write the role, help assess the candidates, and hand over to whoever you appoint. Staying too long would be comfortable for us and bad for you.
Questions Founders Ask Before Engaging Us
Are you going to tell us to rebuild everything with your own team?
It is the obvious conflict of interest and you are right to raise it early. Two things keep it honest. The first is that we say in writing, at the start, whether we think the existing arrangement should continue, and that document does not change later. The second is that you can engage us for advice only, with a written agreement that we will not quote for the build work that comes out of it. That arrangement is available on request and costs nothing extra. In practice the advice is more often to keep the developer you have and change how the work is specified than to replace anybody.
Can you sit on our board or be appointed as a director?
No. We advise; we do not take office. A director of a UK company carries statutory duties and personal responsibilities that do not sit sensibly with a part-time external supplier, and being registered at Companies House as an officer of your company is not something we will do. What we will do is attend a board meeting as an adviser, write the technical section of a board pack, answer questions from investors or non-executive directors, and sit in the room when a technical decision is being taken. You keep the authority and the accountability, which is the correct arrangement.
Our investors want a technical section in the data room. Can you write it?
Yes, and it is one of the more common reasons founders call us. It usually covers the architecture and why it was chosen, the state of the codebase, the security position, how personal data is handled under UK GDPR, what the intellectual property chain of title looks like including assignments from any contractors, open-source licences in use, key technical risks and what it would take to scale by an order of magnitude. Written plainly, with the weaknesses disclosed rather than buried, because an investor technical adviser will find them and finding them undisclosed costs you far more than the weakness itself.
We already have a developer we rate. Will this undermine them?
Not if it is handled properly, and how it is introduced matters more than what we do afterwards. We meet them early, we explain that the engagement is about supporting decisions rather than auditing their work, and we give them any critical feedback directly and privately rather than through you. A good developer usually welcomes it, because it means someone else is carrying the architectural arguments and they get a technical peer to think out loud with. A developer who reacts badly to any external review is itself information worth having.
A client has sent us a security questionnaire. Is that something you handle?
Yes, the technical parts of it. Large customers, NHS trusts, universities and financial services firms all send these, and they are written for organisations far larger than yours. We answer the sections about encryption, access control, patching, backups, hosting locations, logging and incident response, and we tell you plainly where the honest answer is not yet and what it would cost to change that. The organisational sections about staff training, policies and insurance stay with you. The same applies to preparing for a Cyber Essentials assessment or an NHS Data Security and Protection Toolkit submission.
Is any of this legal or regulatory advice?
No, and we are careful about the boundary. We can tell you how UK GDPR shapes an architecture, what the FCA expecting audit trails means for how a system records changes, or why an accessibility requirement affects a design decision. What we cannot do is tell you whether you are compliant, whether you need authorisation, or what a contract means. Those belong to a solicitor, a compliance consultant or your accountant. What the engagement does do is make those conversations much cheaper, because you arrive with a clear technical description instead of paying professional rates for somebody to work out what you have built.
Bring Us the Decision You Are Stuck On
A quote you cannot assess, an architecture argument you cannot referee, or a diligence process approaching. First conversation costs nothing and often settles it.