When Building Is Cheap, Judgement Is the Product

A year ago, the hard part of shipping a product was building it. Now I can stand up a grounded AI agent, with evaluations and full observability, over a weekend. I know, because I did. The agent answering questions on this site is the proof. I built it, instrumented it, broke it, traced it, and gated it before anyone saw it.

When the cost of building falls toward zero, the value does not disappear. It moves upstream, into the decisions. What is worth building at all. What is the one load-bearing piece the value hangs on. How the whole system lines up behind it. How I will know it worked. When to stop. Building is cheap now. Judgement is not. That gap is where I work.

I run it as five moves. None of them are new. They just matter more now that anyone can build anything, and together they are how I take an idea from a market read all the way to a number.

1. Choose what is worth building

With infinite cheap options, the first job is deciding what earns a place at all. This is the 30,000-foot work, and it is the half most "AI-native" talk skips.

I read the market outside-in and the company inside-out, then run a dynamic SWOT that asks the uncomfortable questions: can our strengths become traps, can a competitor's strength become the opening we exploit. I size the field with custom RICE buckets, from moonshots down to a bucket I label honestly as questionable, so a loud request with a bad payoff gets named and parked rather than shipped by default. The trigger question is always the same: why does this world not exist yet. That question is what drove the Strategic Pivot → up-market, and it is how I scope a new platform bet → from a blank page.

2. Cut to the load-bearing slice

Every product has one decision the whole thing hangs on. Find it, ship it, defer the rest to v2 and v3.

On the AI-native service desk → the load-bearing decision was not the model. It was the trust boundary: the AI drafts a plan, the technician approves before anything runs. I shipped that first and pushed automation to a later stage. On this site's agent the same instinct said no to a vector database, because the content fits whole and a database would only add a way to fail. And before any prompt gets written, I strip the screen to bare-bones English and ask what I would do without an LLM at all, because everything that can be plain code should be. The skill is not building more. It is knowing the one thing to build.

3. Wire the system behind it

A product that ships without the system around it does not move a number. This is the systems-thinking half, and it is where product meets go-to-market, pricing, and the org.

I care about strategic synergy: getting every function to run the same bet, from the value proposition down to the metrics, which is what the product operating model → exists to do. I price the value in, not on, so the monetisation is structural rather than bolted on →. I run adoption like a change program, so the product story and the sales story are the same story. I have carried that story to the board as the investor-facing product lead → across every round, and when buying and building both failed I wired a partnership that felt built-in →. The differentiation I bring is not a feature. It is the system.

4. Instrument before you build

I decide the metric and wire the measurement before I write the feature, so a release ships on evidence and not on a date.

That same service desk → had its observability layer from the first drop, judged on plan acceptance and recovered billable time. Monica → had its data foundation and adoption analytics from day one, which is what let us tune retrieval against real use. This site's agent has an eval suite, including adversarial leak tests, as a hard gate: it does not go to anyone until it scores perfectly, every run. The rule underneath all of it is that consumption is the only quality metric. An output a human will not read is a failure, however technically correct.

5. Kill or scale on the evidence

When something underperforms, the cheap move is to guess and patch. I diagnose in order, then decide deliberately to re-sequence, rethink, or kill.

Smart Tracker → was a genuine innovation that stalled, and the data showed the fix was the sequencing, so I re-ordered rather than quitting. The agent had a smaller version of the same lesson: my first hypothesis about the failure was wrong, and one look at the traces corrected me. And the discipline cuts the other way too. I killed a heavily-requested inventory feature because the numbers put it in the questionable bucket, and defended that call with the framework. Reading the evidence beats defending the idea, every time.

The through-line

Put together, these are one loop. The shortest version of it is a question I ask a lot in a room: what do we kill. Not what could we build, because the answer to that is now everything. The useful question is what earns its place, what we wire behind it, and what we cut to protect it.

Building is commoditising. Judgement, taste, and systems thinking are not. Which is why this site is the argument itself. I didn't build the most I could; I chose the right thing, cut to it, wired the system, measured it, and left the receipts.