Every post in this series so far has been a version of “here's what went wrong and what we learned.” This last one is the other side of that: given everything in the first four posts, what does the actual playbook look like when you're starting a new AI product for a client, before any of it has gone wrong yet?
There's real tension in the answer. Clients want to move fast, and that's usually the entire pitch for using AI in the first place. But “fast” and “reckless” get confused constantly, and the four posts before this one are basically a list of what happens when they do: a model confidently wrong about DJSI ratings or CSRD scope, a reconciliation nobody can reconstruct for an auditor, a cost spike from one customer's “select all” click, a pricing model that quietly bleeds money. None of that is an argument for moving slowly. It's an argument for knowing, before you start, which parts of the system are load-bearing and can't be improvised later.
What goes in from day one, non-negotiable
A handful of things are far cheaper to build in from the start than to retrofit later, because retrofitting them means doing it under pressure, after an incident, with a client already watching.
Logging that captures the process, not just the output. Not an afterthought bolted on after the first time a customer asks “how did it get this number.” Capture the input, what the model proposed, what a human confirmed or changed, and when, from the first release. This is the difference between an incident review that takes an hour and one that takes a week of archaeology.
A real fallback for “the model didn't give me something usable.” Decide what a degraded or partial answer looks like before launch, not after the first time it happens in front of a real customer.
Rate limits and guardrails against the worst-case click, not just the average one. A “select all and refresh” button will get pressed. Decide what happens when it is before someone does it, not after your cost spikes.
A decision, made explicitly rather than by default, about where the human checkpoint sits. Every product needs one somewhere. Very few need it everywhere. Figure out where the actual risk concentrates and put the checkpoint there, not reflexively at every step.
A starting eval set built from real domain edge cases, even a small one. It doesn't need to be comprehensive on day one. It needs to exist, and it needs to be treated as something that grows every time production surfaces a new case, not a box checked once before launch.
None of these are features a client will ask for by name. They're the reason the product is still trustworthy six months in instead of one incident away from losing the account.
What you deliberately leave out of v1
The other half of moving fast without being reckless is having the discipline to not build things, on purpose, and to say so out loud, rather than let scope quietly expand until launch slips.
The clearest example is generalization. Building for the handful of customers in front of you, in their specific industry, with their specific conventions, is the fast path to a working v1, and it's also exactly how Carbon Credit Management ended up overfit to oil and gas retirement conventions before we consciously separated “works for these customers” from “works generically.” That's not a mistake to avoid entirely on the first release. Narrow and correct beats broad and wrong. It's a decision to make consciously: ship narrow, know that you're narrow, and treat “make this genuinely generic” as its own deliberate phase of work rather than something you assumed you were already doing.
The same logic applies to cost optimization. Model tiering and caching, routing mechanical checks to a cheaper model, reusing confirmed judgment calls instead of re-deriving them, matter enormously at scale, and they're genuinely premature in week one, when you don't yet know which questions are actually mechanical versus ambiguous, or which decisions actually repeat often enough to be worth caching. Building that too early means optimizing against a usage pattern you're guessing at instead of one you've observed. Get the product correct and used first. Get it cheap once you know what's actually expensive.
Where to draw the scope line, with the client, not just internally
The projects that stayed on schedule were the ones where “what's in v1 and what's explicitly not” was a conversation with the client at kickoff, not a decision engineering made quietly and hoped nobody would notice. That conversation does double duty. It sets the scope, and it sets the same expectations we talked about earlier in this series: what the product will and won't claim to do, where a human still needs to be involved, and what “v1” honestly means for a product in a domain like carbon accounting or sustainability disclosure, where the client's own name ends up on what comes out of it.
Being explicit about what's deliberately deferred, generalization across industries, deeper cost optimization, broader regulatory coverage, is a very different conversation from a client discovering a gap on their own after launch. One is a roadmap. The other is a trust problem.
A rough sequencing that has lasted across all four products
Groundwork. Logging, fallback behavior, and the human checkpoint decision, before any real feature work starts. This is the foundation everything else sits on, and it's the same cost to build early regardless of which product it's for.
Narrow correctness. Get the product genuinely right for the specific customers in front of you, in their specific context. Accept that it's narrow. Say so.
Harden. Build out the eval set from real production cases, tighten the audit trail, pressure-test the failure paths. This is where most of the “boring” engineering work actually lives, and it's the phase that's easiest to skip under deadline pressure and most costly to skip in practice.
Generalize and optimize. Deliberately invest in making the product work generically across new customer segments, and in making it cheap to run at real volume: model tiering, caching, cost visibility. This is the phase that turns a working product into a platform, and it's genuinely hard to do well before you have real usage data to generalize from.
Skipping straight to the last step because it feels more ambitious is how you end up with a system that's fast, broad, and unreliable. Stopping at narrow correctness because it feels done is how you end up with a system that works great for three customers and nobody else.
The takeaway
Shipping fast and shipping recklessly look identical for the first few weeks, because the visible parts of the product, the demo, the first few happy customers, look the same either way. The difference shows up later, in whether the product can absorb a hard question from an auditor, a client's usage spike, or a customer outside the narrow group it was built for. Building the foundation first, being deliberate about what you're not building yet, and having the scope conversation with the client instead of around them, that's the actual difference between fast and reckless, and it's learnable, which is really the point of writing any of this down.
That's the fifth and final lesson from the front line, for now. If any of these resonated, or you've got your own version of one of these stories, I'd genuinely like to hear it.
