Consultancy & retainer
Your developers optimise for shipping this week. We check whether this week's shortcut still holds next year. Architecture reviews, technical due diligence, and a second opinion on the decision you are about to commit to, billed by the hour or as a monthly retainer.
| 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 questions nobody on your team is paid to ask
A good developer optimises for shipping this week, which is what you hired them for. Nobody in that arrangement is paid to ask whether this week's shortcut still works next year.
The gap is cheap until it is not. It shows up as a launch that slips, 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 stalled on a security questionnaire nobody prepared for.
More developers do not close it, and neither do more tools. Someone senior asking the compounding questions does, and that takes a few hours a month rather than a full-time salary.
Five decisions that are cheap now and expensive later
These are the ones worth paying for an outside opinion on.
- Product analytics, instrumented early. In a year you will want to know whether the product is moving the right way. That needs history, and history cannot be added later. Instrumenting late costs you a year of data, not the code.
- Security and privacy groundwork, before it is urgent. Your first serious enterprise buyer will send a security questionnaire. Doing the work in advance costs a fraction of doing it with a deal held open.
- One coherent stack, with routine deploys. If shipping is a scheduled, nerve-racking event, the team ships less often, and that compounds for years.
- 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. Deciding what to wrap and what to depend on directly is a five-minute conversation now and a rewrite later.
Advice from someone who paid for these decisions
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 leave 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 in production before the off-the-shelf tooling existed.
What you are buying is having been there when decisions turned out badly, and having had to fix them.
It starts with one question
Is this architecture going to hold? Rewrite or refactor? Is the team structured right? Is this vendor telling us the truth? We agree what you want answered, read the code and the infrastructure as well as the diagrams, and give you a written answer with the reasoning attached.
Some clients then keep a retainer: a few hours a month to bring decisions to before committing to them.
When to buy delivery instead
If what you need is delivery, a build engagement costs less per unit of progress than advice. If you need someone to own the platform rather than review it, that is platform and infrastructure.
Our developer says they can handle the architecture. Isn't that enough?
Often it is. A good developer makes sound decisions inside the frame they have been given. The question is who sets that frame. If your developer is doing both jobs well, you do not need this.
Do we need a CTO?
Usually not a full-time one yet, and hiring early is expensive in salary and equity. What most teams need is someone senior on the compounding questions for a few hours a month. Outgrowing that is a good sign.
How is this billed, and why not fixed price?
Hourly, or as a monthly retainer for a set number of hours. There is no fixed deliverable to scope, so a fixed price 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 costs less than any of the ways it can go wrong.
What do we get, other than an opinion?
A written assessment of strengths, real risks, bottlenecks and a prioritised list of what to do about them, plus a session to walk through it and challenge 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 fits better and costs less.
Will you go around our engineers?
No. We work alongside your team to make them better at the decision, not to bypass them. Nothing lands as a recommendation your engineers first hear about in a slide.
What if the review says the plan is wrong?
Then the written assessment says so, with the reasoning. Agreement by default is the one outcome with no value.
Does a retainer mean you are on call?
No. It buys attention and availability, not an SLA. On-call for a running system is platform and infrastructure work.
Bring the decision you are about to commit to.
Describe it in a few lines. Within one business day we reply with whether a few hours will settle it and what those hours cost.