Don't Toss the Dough

Or: The most important part of your product is the part your customers can't describe.

Years ago I found myself working at an industry gathering for family-owned pizza shops. Yes, that exists... there's a convention for nearly every business demographic you can imagine, and then some. This event had everything you'd expect to find anywhere near a pizza: from in-shop hydroponic ingredient farming to a walk-through Sysco refrigerated 18-wheeler parked on the show floor, ovens of every size, shape and material plus at least thirty distinct devices for delivering a pizza into those ovens and, most curiously, a keynote address about why mom-and-pop shops should cultivate artificial personas. Think "Uncle Tony's Pizzeria" with the stereotypical Italian goombah tossing pizza dough in the corner as pure performative brand strategy.

But despite all this colorful and delicious spectacle, the single most talked-about experience of the entire event was this one guy... World Pizza Cup Champion Tony Gemignani, the godfather of pizza dough. He was a real flesh-and-blood Italian Tony and his seminars ran literally for hours about how to do the most basic thing in all of pizza-dom... make and manage dough.

It wasn't an unusual sauce, nor extravagant topping... not some one-of-a-kind oven, flashy kitchen tool, or award-winning creative brand strategy... it was one person who knows pizza showing folks how to make their crust the best it can be.

That simplicity stuck with me, and it's taken me years to fully understand why. The dough, perhaps obviously when you stop to think about it, is the most fundamental thing about pizza and simultaneously the hardest part to get right. It takes real time and stubborn attention... from a person who knows what needs to be done and cares enough to do it. It's also the part that most wants to be automated out of human hands (from the economic perspective) and the part which most persistently resists that automation. It's the first thing about the pizza the customer touches... and often the last thing left on the plate... and yet most customers experience it only as pass or fail, in a way they couldn't articulate if you asked them. You yourself may be a pizza dough aficionado, but very few people are going to leave a review that says "the gluten development was rushed." What they're likely going to say is the pizza was "not great" or, worse, "the crust was like cardboard". More likely, though, they're going to say nothing and then never come back.

Why are we talking about pizza dough?

I'm glad you asked. I just finished a full documentation audit of a software milestone; seventy-two cards of delivered work on a multi-tenant SaaS product... a real Michael Bay kind of ending to an eight-month project... and somewhere in the middle of defending my own engineering choices to myself against a self-leveled charge of overbuilding, I realized the dough seminar had, to me, really been about software all along.

Think about it this way: every software product has two kinds of basic properties: the first of which are variable... you can add them, remove them and combine them how you like and the thing remains itself. A pizza with no cheese, or even no sauce, for example, may be a weird pizza, but it's still a pizza if it's got at least something riding on the crust. Call these the toppings.

Properties of the other type are constitutive: they're required as a base. Remove them and you don't have a minimal version of the thing... you have a different thing entirely that's just riding home in a box meant for pizza. 15 toppings mixed together in a cardboard box might make a delicious salad, but it is not a pizza. Likewise a "pizza" whose crust actually IS cardboard isn't a minimal pizza; it's a representation of a pizza... that could someday be made, perhaps... but isn't truly a pizza by anyone's standards. We can call this kind of property the crust.

MVP for a pizza

In software, the toppings are the features, the dashboards, the exports, the reporting and the settings panels. The crust is the stuff underneath: data integrity, tenant isolation, proper failure handling, the security architecture, and so forth. And here's where the eternal argument between "just ship an MVP" and "engineering self-indulgence" goes wrong on both sides: it treats the question as one of quantity... "how much should we build?"... likely expressed as a function of "how much time and money do we have left?"... when it's actually a question of category.

To make a pizza you've got to have a crust and a least one topping. To make software you also need one or more topping... some kind of deliverable features... but those features require a crust too, ideally transparent to the user, which is made up of all the code and infrastructure that makes it possible to deliver the features. The problem is that the "minimum" in minimum viable product was always supposed to refer to the toppings... which features must you include and which other ones can be deferred to later or cut entirely to get your product to market... but in practice it gets applied to the crust as well because the crust is where the hours and dollars get spent, and the crust is almost always invisible in a demo.

The customer feedback loop

The strongest argument for MVP-first has always been the process of discovery: you don't know what customers want until they start using (and hopefully paying for) the product... so ship something minimal, listen, and iterate. Be agile and let the market judge. It's a genuinely good argument and I won't straw man it, but let me show you where it breaks.

The entire concept rests on the feedback loop... customers accepting or rejecting features, designs, user experience, etc... but feedback is only generated by what users can see and talk about. The unfortunate fact is that the vast majority of users can only really articulate failures of the "toppings" category. "The interface is confusing." "I wish the reporting tools showed conversions." "The sauce is too sweet." Great signals, all specific and actionable. The problem is that failures of the "crust" type don't produce these specific types of complaints. They tend to produce vague unease and silent exit. Very few real users are going to file a bug report saying "your tenant isolation feels thin" or "your CORS policy isn't strict enough." They're going to say "it felt sketchy" or worse "I saw some data that wasn't mine"... or they're just going to say nothing and quietly not come back. And because there's no fail signal you can read and respond to, your analysis will likely chalk the lost customer up to poor design or the pricing model or "bad market fit."

So the MVP feedback loop isn't merely undervaluing the constitutive properties... the crust of your product. It is practically incapable of seeing them and, worse, it mis-reports problems that exist there, making them difficult to act on (and justify spending real resources fixing). You can iterate on toppings forever with excellent customer signals, while the crust receives no signal at all... right up until it fails completely. And at that point the signal isn't a ticket in your support queue. It's a departed customer and a negative story circulating through your target industry where everyone knows everyone.

Having said all of this, overbuilding is real; I've caught myself doing it, and a good audit will show you exactly where (more on that in a moment). But it is an argument for a specific division of labor: the market is a superb judge of toppings and a blind judge of crust... so you should delegate accordingly. Crust quality can never be outsourced to customer feedback... not because customers are stupid or don't know what they like, but because the information channel doesn't exist. They can't talk about what they can't see... and even if they could see it, they most likely don't have the words to talk about it, regardless. Judgment of the crust has to come from the builder's standard, applied before anyone else takes a bite.

A nicer word for defensiveness

When I make this argument out loud, the polite pushback is usually some version of "you're just being precious about your craft." And for a while I was willing to accept that. Defensive of my craft... you're darn right I am. They can etch it into my headstone when I'm done and gone.

But defensiveness, at least in this case, I think, is the wrong word. Defensiveness is protecting your work from valid judgment. What I'm describing is something closer to custody: me taking responsibility for being the only holder of a standard that the customer feedback loop cannot reliably enforce. Most customers can't articulate the crust, most business partners can't evaluate it, surely not from the time sheet or the invoice alone, and the market only reports on it post-mortem. The standard for crust quality lives with the builder... with Tony the pizza dough guy and everyone who took the time to attend his seminars and who stayed after to ask questions and who paid for one-on-one mentoring... or it dies quietly.

To be sure, custody cuts both ways. The same audit that vindicated most of my invisible work also found the cracks in that same work: a tenant-isolation gap that early-me had poured into the foundation and later-me had to jackhammer out (imagine deciding to move your brand-new tile shower to the other side of the bathroom a week after it's finished), and a verification habit that occasionally proves things to a standard of certainty the risk doesn't require (measuring for nanometers where inches would have been fine). Custody means owning those findings too... and being more mindful of them in the future. The difference between custody and pride is what you do when the audit comes in and the findings don't break in your favor; do you bury the results or embrace them and encode new and better rules into your process?

Make the record able to survive being questioned

Which brings me to why I was doing a documentation audit in the first place, and the last thing the dough seminar taught me.

After the milestone review, I went back through the entire project's delivery records... not to rewrite anything per se, but to make sure the record could survive being questioned. Duplicate task numbers, stale completion notes, one place where two cards touched the same delivery and needed to be merged together. Small stuff that's easy to fix before the invoices go out and the questions come back. The delta was minor, which is the point: a record that survives a hostile read in one place usually survives it everywhere, because it was produced by the same habits. And I'm happy to say that my habits are generally good, even if I do sometimes overdo it by measuring six times for one cut.

Rewriting history changes what the record claims. Cleaning it up so it's defensible does the opposite... it ensures the record doesn't claim more than it can prove. And that turns out to be the same principle all the way down. The documentation must not claim things that aren't true in the code. The demo must not claim to be the product. The cardboard picture of a pizza must not claim to be actual food. An MVP can have fewer toppings than the picture of the final product, but it can't be missing the crust and still claim to be ready for delivery.

The crust of your project is where this principle touches the oven. It's the part the customer handles first, even if they don't realize they're touching it, the part that resists automation, the part that takes hours of focused attention to get right... and the part your users will almost certainly only ever grade as pass or fail. The job of the software architect is to honestly hold this standard on the customer's behalf, not just toss it for show.

Post Script

There's another element to consider which I hadn't mentioned when writing this post originally so I'm adding it here after the fact. Because shipping apps has become so much easier as a result of the "AI coding revolution", the bar for what potential customers are willing to accept from your project on day one has risen considerably. It's not just about features any more, it's about the user's experience too. If your app is slow, clunky or visually unappealing, users will turn to other tools in the same space that "feels better" to use, even if that tool is lacking functionality you've already nailed.

More important than giving the user a good experience, though, is instilling in them a sense of trust. Capturing and holding interest with dopamine-producing animations or well-designed UI/UX may be enough to get your nose in the tent, but closing and retaining customers requires delivering the whole camel... features, experience, security, scalability, resilience and customer support... plus a pricing model that makes sense and a meaningful continuity plan to address the "bus factor" question. It's not enough any more to bring a functional demo to market... you've got to deliver enough features to make your app feel useful, enough polish to make it look professional and a strong enough crust so that it doesn't end up a hot, gooey mess in a decision-maker's lap.