My default as an engineer is to start building. Not because I'm reckless, but because building is how I think. I understand a problem by implementing a solution. I see edge cases by writing the code that hits them. That instinct served me well for 10 years at Red Hat. It does not serve me as well when the question isn't how to build something but whether to build it at all.
The old loop
The loop used to go: have an idea, sketch the architecture, start writing code, discover the hard part three months in. The hard part was sometimes technical. More often it was something adjacent: a dependency that's hard to monetise, a distribution problem, a regulation I hadn't thought about. By the time I found it, I had momentum in a direction I'd already half-built.
This isn't a personal failing. It's how engineering training works. You are evaluated on working software. The incentive is always to get to something runnable as fast as possible. Strategic questions feel soft, slow, and unproductive compared to code that compiles. So you skip them, or defer them, or tell yourself you'll figure it out once the prototype is working.
What AI changed
AI made the discovery step cheap. Questions that would have taken a week of research, or a conversation with a lawyer or accountant I'd have to book two weeks in advance, can now be explored in an afternoon. Not perfectly, not instead of professionals, but well enough to know which direction the real risk is coming from before you've built anything.
That changes the loop. Now the first thing I do with a new idea isn't sketch the architecture. It's interrogate the assumptions. What does this model depend on being true? What's the regulatory environment? What do the unit economics look like at 100 customers versus 1000? What's the hardest part of the go-to-market, and what happens if that part is harder than expected?
I'm not asking AI to make these decisions. I'm asking it to surface the questions I should be asking, and to give me enough signal to know where the real research needs to happen. One targeted hour with an accountant who knows the specific question beats three weeks of general research, but only if you already know what to ask.
OtterSay: the lighter example
When I started building OtterSay, I assumed I'd use a Merchant of Record for global payments. Standard advice for digital products. MoRs handle VAT and sales tax across jurisdictions so you don't have to. I'd read enough founder blogs to know this was the answer.
A few hours with Claude exploring the actual mechanics told me the picture was more nuanced, specifically around Czech VAT obligations. When a Czech company starts receiving cross-border B2B services (Stripe fees, cloud hosting, API charges), it triggers identifikovaná osoba status under Czech tax law, which means filing EU VAT returns, before you've sold a single thing to a customer. That's not a reason to not build the product, but it changes when you need to set up the tax infrastructure, and it's the kind of thing that creates a nasty surprise post-launch if you don't know about it.
Finding this out at architecture time cost an afternoon. Finding it out after launch would have cost significantly more.
OtterSource: the harder lesson
OtterSource was a more expensive discovery. I designed the full model before stress-testing it: time-limited bounties on GitHub issues, funds held in escrow, 80/20 split between contributor and maintainer on merge, refunds in credits, 10% platform fee on withdrawal. It felt elegant. Then I ran the business model through a serious interrogation with AI.
The discoveries came in layers. Merchant of Record doesn't work for marketplaces: MoRs become the legal seller of record, which only makes sense when you're selling your own product, not mediating money between third parties. So I'd need a marketplace payments stack instead. Stripe Connect's published fee structure, when priced against a 10% fee on a $100 bounty, left almost no margin before disputes and refunds. The 'escrow' mechanic wasn't just a UX choice: holding funds for third parties is a regulated activity under PSD2 in the EU, requiring a Payment Institution license with significant capital requirements and 6 to 12 months of regulatory runway. The credits-as-refund model was technically e-money issuance. DAC7 meant mandatory EU income reporting for any platform facilitating payments to European contributors.
None of these were individually fatal. Together they described either a different product than I'd imagined, or a much larger business: the kind that needs serious capital and regulatory licensing before it can hold funds for anyone. The business model is being rethought.
I found all of this before building the payment infrastructure. That's the point.
The new loop
The pre-MVP loop, as I now think about it, is a phase before building where you try to break the idea. Not as a pessimist, but as someone who wants to spend the next three months going in the right direction. What's the hardest business assumption in this model? What regulatory environment does this touch? Does the fee math work at realistic volumes? What does the competitive landscape actually look like?
AI makes this loop fast enough to be worth doing before you have any code. The discovery that used to cost weeks now costs a day or two. That's not because AI is infallible: it makes mistakes, it sometimes confidently summarises things that are more complicated, and nothing it says replaces a professional who knows the specific jurisdiction or industry. But it narrows the space dramatically. By the time I'm talking to a lawyer or an accountant, I know what I'm asking about.
What this means in practice
I'm still an engineer. My instinct is still to build. But I now treat the pre-building phase as its own deliverable: a quick loop that answers the questions a business needs answered before it decides what to build. Sometimes the loop confirms the original idea. Sometimes it reshapes it. Occasionally it kills it before you've spent three months on something that was never going to work.
The shift isn't really about AI. It's about the order of operations. AI just made changing that order cheap enough to be the obvious choice. Build later. Think first. For someone with a decade of engineering instinct in the other direction, that took a concrete failure to learn.