Advisory

Ongoing technical advisory for founders and boards: architecture direction, vendor and hiring decisions, roadmap sanity, and a senior engineer in the room when it matters. A few hours a week, a capped client roster — judgment, not headcount.

What gap does advisory actually fill?

There’s a stage where you don’t need a CTO’s salary but you keep paying for the absence of one. It shows up as a tax on every technical decision:

• The agency quotes what it wants to quote, and nobody on your side can price-check the architecture inside the number.
• The senior hire interviews you, because nobody in the room can interview them.
• The board asks “is the tech scalable?” and everyone looks at the founder, who looks at the roadmap, which was written by the agency. See the problem.
• Every incident produces a convincing explanation from the people whose work produced the incident.

None of these people are acting in bad faith — they’re answering from where they stand. What’s missing is someone whose only incentive is being right, because they’re not selling you the build, the licence or the headcount. That’s the product here. Bharosa with a paper trail. And because the roster is capped, the attention is real: I read your board packs, your incident reports and your vendor contracts the week they land — not in a quarterly catch-up where the decisions have already been made and the advisor’s job is nodding at them.

What does advisory include?

• Standing working sessions — weekly or fortnightly, agenda driven by what’s actually live: the architecture fork, the vendor shortlist, the incident from Tuesday.
• Written reasoning on the decisions that matter — vendor selection, build-versus-buy, architecture direction — in memos you can forward to a board or a co-founder, with the trade-offs named rather than smoothed.
• Hiring help — the JD that attracts engineers instead of keyword-collectors, screening, and final-round interviews where I ask the questions you don’t know exist. One bad senior hire costs more than years of advisory; this line item alone usually pays for the rest.
• Board and investor translation — turning “we re-platformed the ingestion layer” into a sentence a board can act on, and turning a board’s “is it scalable?” into the three questions they actually mean.
• Escalation access — when production is down or a deal needs a technical answer tonight, you get the second brain before the expensive call, not a slot next Thursday.
• The decision log — every significant call recorded with reasoning and alternatives. It’s your institutional memory, your diligence artefact, and my accountability, in one document you own.

How does an engagement start and run?

The first month is a baseline review — where the technology, the team and the roadmap actually stand, versus what everyone currently believes. The gap between those two is where the first quarter’s agenda comes from, and it’s never empty. Then the standing cadence begins, and the log starts filling.

The deliberate limits. I stay part-time by design — the moment you need a full-time CTO, my job is to help you hire one, hand over the log, and leave cleanly; succession is the exit criteria, not a threat to the arrangement. And I don’t quietly become the build vendor: when advisory uncovers work I could do — a ledger, a migration, an audit — you get the same recommendation logic as for any vendor, in writing, and the freedom to take it elsewhere. The services on this site — /services/fintech, /services/delivery, /services/architecture — are options in the log, never conclusions smuggled into it.

What it costs to ignore this stage. The companies that skip the advisory layer don’t save the fee — they pay it to the wrong people: the agency’s change requests, the mis-hire’s notice period, the re-platform that a two-page memo would have prevented. The pre-Series-A review and scale-stage triage pages describe the two moments where that bill usually arrives.

Which decisions is this actually for?

The honest answer: a handful a year — but they’re the expensive ones, and each has a default failure mode that neutrality prevents. Build versus buy — default failure: building, because engineers propose what’s interesting and vendors demo what’s polished; the memo prices both against the third option nobody proposed. The re-platform — default failure: approving it, because the team that wants it wrote the analysis; half my written recommendations here are “no, and here’s the smaller fix”. The senior hire — default failure: hiring confidence, because nobody in the room could test competence; one real technical interview changes the shortlist. The vendor renewal — default failure: renewing, because switching feels risky and nobody read the usage data; the log entry takes an hour and has paid for entire engagements. The “quick” integration with a partner — default failure: agreeing in a meeting to an API contract that engineering sees afterwards. Five patterns, one common thread: the room decides differently when someone in it has no stake in the outcome. That’s the seat being rented.

What’s the proof?

The same as everywhere on this site: the thinking is public. Fourteen architecture teardowns show exactly how I reason about other people’s systems — the same reasoning that lands in your decision log. The case studies — the ledger rebuild, the migration — show what happens when the reasoning becomes construction. Advisory is the subscription version of that judgment; read the free samples first. If the reasoning in those teardowns is the kind you want in your corner monthly, the engagement will feel familiar from day one.

Related reading

Event-driven pitfalls · Why your ledger drifts · Zero-downtime migration · /services/fractional-cto for the accountability version

The test for whether you need this

If your last three technical decisions were made by whoever was most confident in the room — /contact, and bring one of those decisions to the first call as the test case. Chalo, let’s add some hisaab to the confidence.