Consultancy & retainer
A good developer optimises for shipping this week. This is for the questions above that: whether this week's shortcut still works next year, and what it costs when it does not. Architecture review, technical due diligence, and standing access to a second opinion, billed by the hour.
| Engagement | Hourly, or a monthly retainer |
|---|---|
| Built for | Teams with engineers but nobody above them |
| Price | Quoted on scope |
An outside read on your system
Where the bottlenecks are, which risks matter, and which of the things worrying you are fine. Written down, so it survives the meeting.
Decisions with their reasoning
The recommendation, the alternatives considered, and why they were rejected, so the decision outlives whoever made it.
Time with your engineers
Working sessions, so the people who will live with the decision get to argue with it first.
A prioritised plan
What to do now, what can wait, and what to leave alone, ordered by consequence.
The gap above the developer
A good developer optimises for shipping this week. That is what you hired them for, and holding it against them would be unfair. The question nobody in that arrangement is being paid to ask is whether this week's shortcut still works next year.
The gap is cheap to leave open right up until it is not. It shows up as a launch that slips because the work was never really being committed, a codebase only one person can pick up, a rewrite that a decision eighteen months earlier would have made a refactor, or an enterprise deal that stalls on a security questionnaire nobody prepared for.
Hiring more developers does not close it. Neither does buying more tools. It closes when someone senior is asking the compounding questions, and the useful part is that this takes a few hours a month rather than a full-time salary.
Decisions that compound
Some choices are cheap now and expensive later, and they are the ones worth paying for an outside opinion on.
- Product analytics, instrumented early. A year from now you will want to know whether the product is moving in the right direction. That answer needs history, and history cannot be added retroactively. The cost of instrumenting late is not the code, it is the year of data you do not have.
- Security and privacy groundwork, before it is urgent. Your first serious enterprise buyer will send a security questionnaire. Doing this work in advance costs a fraction of doing it with a deal held open and a procurement team waiting.
- One coherent stack, with deploys that are routine. If shipping is a scheduled, nerve-racking event, the team ships less often, and the cost of that compounds quietly for years. Delivery tooling is worth getting boring early.
- Automation in the right places. Automating the wrong step adds friction and a maintenance burden nobody owns. Knowing where not to automate is worth as much as knowing where to.
- What you build directly against. Platforms deprecate whole API surfaces with little notice, and anything built tightly against them gets torn up and rebuilt. Deciding what to wrap and what to depend on directly is a five-minute conversation now and a rewrite later.
Where the judgement comes from
Six years as CTO of an interactive live-streaming platform, from the first commit to a company of around fifty across multiple regions. Long enough to live with the early architecture decisions rather than move on before the bill arrived.
Before that, technical manager and product owner over twelve engineers on an enterprise document platform that displaced Microsoft, SAP and Oracle at customer sites. Since then, AI agent platforms running in production before the off-the-shelf tooling existed.
What makes that useful is having been there when decisions turned out badly and having had to fix them.
How it usually runs
Most engagements start with a specific question: is this architecture going to hold, should we rewrite or refactor, is this team structured right, is this vendor telling us the truth. We agree what you want answered, we read the code and the infrastructure as well as the diagrams, and you get a written answer with the reasoning attached.
Some clients then keep a retainer for standing access, a few hours a month to bring decisions to before committing to them.
When to buy something else instead
If what you need is delivery, buy delivery: a build engagement costs less per unit of progress than advice does. If you need someone to own the platform rather than review it, that is platform and infrastructure. We will point you at the right one instead of selling you hours.
Our developer says they can handle the architecture. Isn't that enough?
Often it is, and if so we will tell you rather than sell you hours. A good developer makes sound decisions inside the frame they have been given. The open question is who sets that frame, and whether anyone is asking if this week's shortcut still works next year. If your developer is doing both jobs well, you do not need this.
Do we need a CTO?
Most companies asking that question do not need a full-time one yet, and hiring early is expensive in both salary and equity. What they need is someone senior asking the compounding questions a few hours a month. If you reach the point where the honest answer is a full-time CTO, that is a good sign and we will say so.
How is this billed?
Hourly, or as a monthly retainer for a set number of hours if you want standing access. There is no fixed deliverable to scope, so pricing it as a fixed project would be a fiction.
Can I just ask one question?
Yes, and it is often the best use of this. A few hours on a decision you are about to commit to is cheaper than any of the ways that decision can go wrong.
What does a review produce?
A written assessment covering strengths, real risks, bottlenecks, and a prioritised list of what to do about them, plus a session to walk through it and be challenged on it.
Will you write any code?
Some, where a prototype settles an argument faster than a document. If you mainly want delivery, a build engagement is the honest fit and costs you less.
Do you work with our existing team?
That is the usual shape. We are there to make your engineers better at the decision, not to go around them. Nothing lands as a recommendation your team first hears about in a slide.
What if the review says the plan is wrong?
Then it says so. Paying for an outside opinion and getting agreement by default is the one outcome with no value.
Is a retainer a support contract?
No. It buys attention and availability, not an SLA. If you need someone on call for a running system, that is platform and infrastructure work.
Tell us the one thing it has to do.
If it's sharp enough to prove in a week, we'll say so and give you a date. If it isn't, we'll tell you that too, along with what we'd build first instead.