You're in the room when the invoice lands.
This page exists so you can forward it. It explains one thing your client can use whether or not we ever speak — and exactly what happens to them if they do call.
You've got a client paying for software they can't evaluate. You'll have seen the invoice. I can tell them what it bought.
I read the code, the plan and the invoices, and give them a written verdict in five days: keep, fix or stop, with the cost of each.
Around 66% of software projects overrun on cost or schedule, and only 29% land on time and on budget. Large projects average 45% over budget. Your client is not unlucky — they are in the majority, and nobody else around that table is independent enough to say so.
Enterprise software cost overruns (Forecast) · IT project statistics, McKinsey/Oxford (Runn)
Five questions you can ask without me
You don't need to understand software to ask these. You only need to recognise a bad answer, and a bad answer to any of them is legible to anyone.
- 01
What can a customer do this month that they couldn't do last month?
A bad answer lists activity — refactors, migrations, tickets closed. Activity is not progress.
- 02
If the person who wrote this left on Friday, what stops working?
A bad answer is a name. A good answer is a document, and they can show it to you.
- 03
Show me the last three things that broke in production, and what changed afterwards.
A bad answer is “nothing has broken”. Either it isn't really in production, or nobody is watching it.
- 04
What are we paying for that we own, and what stops working the day we stop paying?
A bad answer needs a week to research. They should already know which accounts are in your client's name.
- 05
What did we decide not to build this quarter, and why?
A bad answer is “everything's on the roadmap”. A plan has things it rejected. A queue doesn't.
If those five get good answers, your client doesn't need me. Send it anyway — the questions are the useful part.
What I do, and what I will never do
I'm a hands-on fractional CTO. I read builds, I run builds, and I take companies through security certification. That is the whole list.
- I don't do finance, tax, legal or recruitment.
- I don't sell developers, licences, or anyone's software.
- I will never quote your client for anything you already provide. If they ask me about something in your lane, the answer is “ask them”.
What happens if you forward this
- The first call is thirty minutes and there is no charge for it.
- If your client isn't a fit, I say so on that call. Roughly as often as not.
- Nothing that follows starts without a fixed scope and a fixed fee, agreed in writing first.
- Your client's details do not go on a mailing list. No sequence, no drip, no follow-up chain.
- With your client's permission I'll tell you what I told them, so you're never the last to know in your own board meeting.
I don't pay them, and I'm not asking you to sell anything. If it's useful to your client, forward it. If it isn't, don't. What I'd rather have is the introduction back, when one of my clients needs what you do.
Who this page is for
- Fractional CFOs and finance directors
- Startup lawyers
- Accountants and R&D tax advisors
- VC platform and talent partners
- Anyone who sees the software invoice before the software works
What I've actually done
Recent programmes are written up as the clients allow — the mechanism rather than the logo, since two of them are under NDA. The mechanism is the part worth reading, because it is the part that repeats.
The ask
Forward it, or don't. If you'd rather vet me before you put your name anywhere near it — which is the right instinct — take the twenty minutes first.
“Someone worth twenty minutes if the build's worrying you — Mayur Kale. He reads software you're paying for and gives you a written verdict in five days. He isn't selling you developers. mayurkale.com/for-advisors”
That's a pointer, not a recommendation. It commits you to nothing.