A clearer standard for building well

Most builders have inherited a bad vocabulary for early product work.

We tell people to build an MVP, but the phrase has become so overused that it often clarifies less than it confuses. Some people hear “minimum” and interpret it as permission to ship something brittle, awkward, or barely usable. Others hear “viable” and inflate the work into a miniature production system, complete with abstractions, infrastructure, tests, edge-case handling, and design polish that may never matter.

To balance that out we encourage people to “just hack it together,” which pushes the pendulum into a different problem. Hacky can be useful when it means fast, practical, and unconcerned with unnecessary ceremony. But hacky too often becomes an excuse for bad work. It works in the narrowest technical sense, but some see it as license to create terrible unpleasant use, error laden, difficult to understand, and fragile the moment reality touches it.

This is the gap “right-but-light” is meant to name.

Right-but-light means building something correctly enough that it earns trust, while keeping it light enough that it remains easy to change. It is not about doing less work. It is about refusing to carry more weight than the moment requires. It isn’t minimal or maximal. It is that harmonious balance so many folks have trouble finding. We don’t hack down the scope to get away with a bad implementation, we do it so the one thing we choose to do is done well – while still not evergreen or perfect.

The “right” part matters because users do not experience your product through your intentions. They experience it through the surface area you give them. A button that is twice as large as it should be may not break the system, but it may still signal that your offering is dangerously unkempt. A workflow that technically completes the task but makes the user think too hard won’t get used – at all. A prototype that loses data, hides errors, or makes the user feel unsure doesn’t give you the real signals you are looking for. These things may be excusable in a throwaway 24-hour hack-a-thon demo, but they are not balanced for an initial product seedling. They train the builder, the user, and the team to tolerate roughness where clarity was needed.

The “light” part matters because early certainty is usually fake. At the beginning of a product, most of the important learning still has to happen. The shape of the problem will change. The user may care about a different part of the workflow than expected. The thing you thought was a feature may turn out to be a demo path. The thing you thought was temporary may become the center of the product. In that environment, heavy architecture is often a liability disguised as discipline and thoughfulness.

A right-but-light implementation avoids both forms of waste. It does not ignore usability in the name of speed, and it does not overbuild permanence into something that has not yet earned permanence.

This distinction has become more important with agents. Human teams already struggled with the nuance between fast and sloppy, or thoughtful and overbuilt. Agents amplify that ambiguity. Ask an agent to “build an MVP” and it may produce a sprawling approximation of a real application. Ask it to “make it hacky” and it may skip the very details that make the product usable. The instruction was vague, so the output becomes a coin flip between underbuilt and overbuilt.

“Keep it right-but-light” is a better constraint because it tells both the human and the agent what kind of tradeoff is being made. The work should be correct in the parts that matter. The interface should be understandable. The happy path should feel intentional. The data should not vanish. The user should not have to forgive the product in order to use it.

But the implementation should remain light. Maybe the data lives in a JSON file before it earns a database. Maybe the workflow is hardcoded before it earns configurability. Maybe the UI uses an existing design pattern rather than inventing a new system. Maybe the feature does not need role-based permissions, event streams, audit trails, background jobs, and a full settings page on day one. Maybe the right version is simply the smallest version that behaves with taste.

Right-but-light also gives teams a cleaner stopping rule. The question is not “is this complete?” because early products are almost never complete. The better question is: “Is this right enough to learn from, and light enough to change after we learn?”

That question changes the conversation. It moves the team away from false binaries. You are no longer choosing between a disposable hack and a production-grade system. You are choosing the minimum level of correctness required for meaningful use, and the minimum level of structure required for responsible iteration. Yes, that is what MVP and lean startup. It is just that I have tried for YEARS to explain that to people and it either doesn’t land or get me in to trouble with “you said to do the minimum!”

For example, a right-but-light onboarding flow may not need analytics dashboards, branching personalization, enterprise configuration, and a polished admin panel. But it probably does need clear copy, coherent visual hierarchy, a reset path for testing, and enough state handling that the user does not get trapped. A right-but-light internal tool may not need a formal database schema or complex permissions. But it probably does need predictable inputs, readable outputs, and error states that do not require the builder to stand nearby and explain what went wrong.

There are many great product folks out there building things you love, and I am sure you have used a product you loved and realized there was no delete button and wonders “WTF? Why can’t I delete?!”. If you get a req for your unaware peers in different departments they would have died on the sword to put the obviousl “delete” in on v1, but no feature is truly “simple” and without a time cost. So, that product manager says “they need to love what they create before they need to delete.” One less unit of time for one side of the product, one extra unit of time for another. No one has infinite time or infinite money. No one. 

So how do you chose? The point is not to lower standards. It is to place the standard in the right part of the work and be okay with walking away from the other.

Long-lasting applications deserve robustness, scalability, observability, automated tests, security reviews, edge-case handling, and design precision. But not every early feature has earned that full burden yet.

Premature permanence slows learning. It turns every change into a negotiation with yesterday’s assumptions.

Speed without standards is not iteration. It is motion. Wheels spinning fast in the mud.

It asks for seriousness without heaviness. It asks for speed without sloppiness. It asks for taste without vanity. It asks the builder to cut everything that is not required, while doing the remaining things with care.

That is the deeper meaning of the phrase.

Right-but-light is not another way to say MVP. It is a correction to what MVP has become. It restores the part people forgot when “agile” and “MVP” became a household term.