Your product was built fast, often with the help of an AI assistant. It works. But you have a threshold to cross — first real users, a raise, an enterprise client’s audit, a sharp rise in user numbers — and nobody can tell you what will hold.
Founder or technical director whose product is already running, and who has to answer to someone — an investor, an enterprise client, a board — for what happens next.
I first surface the rules your system is supposed to guarantee in all circumstances: yours, those of your trade, rather than a list of generic good practice. “A validated invoice can no longer be modified.” “A client never sees another client’s data.” “A displayed price never differs from the price charged.” You give me three or four in two minutes: these are your fears, and they are written down nowhere. I then examine the paths by which you would lose data or money, the separation between your different clients’ data, your dependence on components you do not control, and what you would know of an outage at the precise moment it happens.
I take the measure of the system and surface its implicit rules — what your business forbids, and that nobody has written down anywhere.
I look for what prevents those rules being breached. Nine times out of ten, nothing prevents it: they hold because nobody has tried yet.
I rank, I cost in days, and I write it all in a language a non-technical decision-maker can read without a translator.
The audit stops at the map and the plan: where to go, in what order, and what each postponement costs. Three days are enough to know, and that is what keeps it readable. The repair work is the next job, which you entrust to your team, to someone else, or to me.
The guardrails, if the audit concludes that the problem is not this or that line of code, but the absence of everything that should have refused it.
Because three days are enough to say where to go. The audit is deliberately short: it leaves you free on what follows. You entrust the repair work to your team, to someone else, or to me — and it is in my interest that this be a choice.
The report names rules, not people. What is written is that a rule can be breached with nothing to signal it: that is a failure of apparatus, not of discipline. The report is presented to your team during the hour of reporting back, and whatever they had already identified is noted there as such.
You. That is the writing criterion: what to keep, what to redo, what to throw away, and for each point what it costs if it is ignored. The technical detail is in an appendix, for your team.
We use cookies solely for the site to work properly. With your agreement, we also enable the Calendly scheduling module, which sets its own cookies. You can change your mind at any time from the footer. Learn more