Keep It Right-But-Light

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.

Can You, Did You, and Taste

Three stages separate ideas from products, and products from things people love.

The first stage is capability.

Can it be done? Can the software be written? Can the company be started? Can the product be built? Can the problem be solved?

These questions matter because capability is the foundation upon which everything else rests. Nothing can be executed, adopted, or admired until it is first plausible.

This is where most people rest comfortably.

The surprising thing about capability is that proving something can be done often provides many of the same emotional rewards as actually doing it. Once someone becomes convinced they could build the company, write the book, get in shape, learn the skill, or launch the product, the pressure largely disappears. Potential becomes a source of comfort.

The entrepreneur enjoys imagining the startup. The author enjoys discussing the book. The engineer enjoys architecting the system. The athlete enjoys knowing they could get serious whenever they decide the time is right. People tend to love their own brains and marvel at what it can achieve. Potential is attractive because it is free from accountability. It cannot fail because it does not yet exist.

Did you actually do it?

The second stage is execution. It only lives in the past tense. This is where the conversation changes. Ideas become products. Plans become companies. Discussions become outcomes. Concepts become features available for use and critique to the public domain. The world stops evaluating intentions and starts evaluating evidence.

A customer cannot buy potential. A user cannot interact with ambition. An investor cannot generate returns from possibility alone (though they push this rule as much as possible). The market, unlike our friends and colleagues, is remarkably indifferent to what could have happened. It only responds to what did happen.

People who reach this stage deserve significant credit. The distance between an idea and reality is far larger than most people appreciate. Building something that survives contact with the real world is difficult. Something complete, end-to-end. It accomplishes its intend (big or small) and no hand holding or excuses are needed for it to be used properly. Launching is difficult. Selling is difficult. Maintaining momentum is difficult.

Most people never get there. And I am being generous with “most”.

Yet many who do arrive at execution mistakenly believe they have reached the finish line. They assume that because something works, people will care. They assume that because a solution is objectively better, adoption will naturally follow. They assume that utility alone is enough. They believe a logical use case exists and therefore usage will follow. A good plan and execution is all that is needed.

History suggests otherwise.

The graveyard of technology is filled with products that worked. Many were faster than their competitors. Many were technically superior. Some were years ahead of their time. Their failure was not one of engineering. Their failure was assuming that human beings make decisions primarily through logic.

Taste.

Taste is one of the most misunderstood concepts in business because it is often reduced to aesthetics. People hear the word and think about typography, color palettes, industrial design, architecture, or fashion. Those things matter, but they are only symptoms of something deeper.

Taste is the ability to understand how another human being will experience what you have created.

It is the recognition that people do not merely consume functionality. They consume stories, emotions, identity, aspiration, status, trust, culture, and delight. A chair is not simply somewhere to sit. A restaurant is not merely a place to eat. A home is not simply shelter. A product is not just a collection of features. Even a purposefully poort taste for those that are tasteless is, in fact, a taste. The trickle down story line of decisions and focused intent lead to those that have the same test to become interested. Taste is not being fashionable, it is knowing people need clothes and certain groups of people like cheap clothes, some like expensive clothes, and some like expensive clothes that are on sale – but they know which group of tasters they want to have.

Every meaningful creation eventually becomes an experience.

This is why two products with nearly identical functionality can produce radically different outcomes. One becomes beloved while the other is forgotten. One creates a movement while the other creates a user base. One becomes part of a person’s identity while the other remains a tool.

The difference is often explained by taste.

The creators who understand taste recognize that presentation is part of the product. Storytelling is part of the product. Culture is part of the product. The emotional experience surrounding something is not separate from what is being built. It is one of the things being built.

Most people spend their lives asking whether something can be done. A much smaller group proves that it can. The rarest creators understand that neither capability nor execution guarantees significance.

The first stage asks whether something is possible.

The second proves that it is.

The third determines whether anyone cares.

Mountain West road trip 2026

Jackie and I have wanted to see Wyoming and Montana for a long time. As the saying goes, people often travel across the world while overlooking what is right in their own backyard. For us, this was finally the trip to change that.

Our goal was to see Jackson Hole, Big Sky, and Bozeman, with hopes of making it all the way to Glacier National Park. Unfortunately, Glacier did not make the cut because of time constraints.

We traveled during what they call the shoulder season. The upside was that everything felt quiet, calm, and untouched by the usual crowds of tourists. The tradeoff was that some roads, activities, and park areas were still closed for the season. It was not a major issue, but it was another reason Glacier eventually fell off the itinerary since parts of it were still inaccessible.

Thankfully, it ended up being a lighter snow season than expected. We had been warned about muddy roads, difficult trails, and constant wet conditions, but along our route, those issues were mostly nonexistent.

We decided to take the Rivian even though it meant more charging stops along the way. Honestly, it ended up being far less of a hassle than we expected. Fast chargers were usually spaced every 1.5 to 3 hours, and most charging stops only lasted around 15 minutes.

To be fair, about 80% of the time we were already stopping anyway to walk Rosie, use the restroom, or grab something to eat. In the end, charging rarely felt like an interruption.

Oddly enough, the EV changed the pace of the trip in a good way. Instead of falling into the classic “drive six hours straight and push as far as possible” mindset, we naturally slowed down a bit. Because of that, we actually enjoyed the scenery more and felt less exhausted overall. For a nature-focused road trip, it ended up feeling surprisingly relaxing, which was completely counterintuitive.

We also kept in mind that this was Rosie’s trip too. Everywhere we went, we made a point to find a local dog park, and honestly, it ended up adding just as much to our experience as the destinations themselves. Dog parks turned out to be an unexpectedly great way to meet locals. People are naturally more open and friendly when dogs are involved, so we ended up getting all kinds of recommendations and local tips we probably never would have found otherwise. The variety of parks was incredible too. One park in Montana felt like absolute dog heaven: 35 acres of fenced-in trails surrounded by stunning scenery with almost no visual obstruction anywhere around you. Rosie could run as far as she wanted while we wandered the trails ourselves without constantly worrying about where she was. It felt less like a dog park and more like a giant shared nature preserve for both people and dogs.

This was my first truly long road trip as an adult, and there was something incredibly freeing about it. Having Rosie with us made it even better. The whole trip developed this laid back rhythm of simply driving to wherever was next. We had a list of places we definitely wanted to see, but beyond that, everything stayed wonderfully flexible. Some towns pulled us in longer than expected, while others ended up being quick stops before moving on to the next stretch of road.

What surprised me most was how differently time works on a road trip like this. A “small detour” is rarely small. Once you factor in the drive out, the drive back, possible overnight stays, and the reality that you will probably discover more things nearby once you arrive, a side trip can quickly grow from a couple of hours into two full days. That was probably the hardest part of planning: estimating when we would actually return home. At some point, the trip stops feeling like a strict itinerary and starts feeling more like momentum. And honestly, that was part of what made it great.

Folks still wonder “why MCP?”. Here is a step-by-step comparison

Not much feels different. And that’s exactly why it confuses people. They expect magic.

I want a list of users. Here’s my pseudo-code way of sorting it out ways of doing it.

Traditional-coder scenario

Human: “I want user data from your system.”

Human goes to the docs
Finds the right endpoint
Sets up auth
Writes code: GET /users
Parses the response and uses it

The human is doing discovery, auth, integration, and parsing.

AI without MCP

Human Prompts: “List users from System X, using this doc [url]”
AI tries to reverse engineer endpoints and payloads
Maybe works, Maybe hallucinates
Human does not get coffee, they have to watch the AI progress and steer it.

The AI is the one reading the docs, but the developer is still doing work.

MCP scenario

Human: “List all users from in a Modal”

That’s it. Human goes to get coffee.

AI checks connected MCP servers
AI asks: “Do I have a tool for this?”
Finds a structured tool like list_users exposed by that service’s MCP server

That tool defines:

  • What it does
  • What inputs it needs
  • How auth works (handled server-side)

AI calls the tool through the MCP client
MCP server executes the call safely
Structured user data comes back
AI keeps going with real data

AI: “Modal with Users is ready for your review”

Human Browsing Web

Human says, “I want to get Users for the [service]”
Human opens Chrome and goes to https://%5Bservice%5D.com
Human click “Users” on the page.
They read list of Users on the page and spams them (or whatever else humans like to do these days.)

You don’t manually open a socket and craft packets. Your browser speaks a standard protocol and every website that follows it “just works.”

MCP is trying to be that layer, but for AI using software tools instead of humans using web pages. The key part is the contract. The AI is not inventing how to call your system. It is using a capability your system formally exposed over a shared protocol.

Multi-Prompting Makes Multitasking Real

For years we treated multitasking as a skill. A badge of honor. A sign that someone could juggle more than the rest of us. But anyone who has actually tried real multitasking knows the truth: it never works as well as the multitasker thinks. The human brain simply is not built for parallelism. It is built for rapid switching, and rapid switching has real cognitive taxes.

Yet a strange thing has emerged in the age of AI. A new pattern. A new form of workflow. Not delegation, not automation, not parallelization. Something in between.

I call it multi-prompting.

Multi-Prompting as an example

Multi-prompting is what happens when you have several active projects, each one running in near-real time, with the help of an AI system you guide through tight loops of prompting and review. You prompt one project, then the next, then the next. By the time you return to the first, the AI has completed executing the task (in detail). You immediately see the results, assess them while the objective is still fresh in your short-term memory, refine the prompt (or create a new task), and send it back into motion.

The entire loop across multiple projects might take only a few minutes.

The key is that nothing has left your mind. The objectives for all active projects remain in active memory, and the micro tasks are executed almost instantly. You are still steering. Still directing. Still deciding. The system is not replacing your cognition, it is amplifying it by absorbing the tedious layers of implementation. It is doing so without making tiny errors like typos; the fist things that begin to fail when a human multitasks entire objectives.

Why It Is Not Delegation

Delegation is a full transfer of work. You hand something to someone else, they go off and implement it, and you hear about it later. Your mind no longer holds the details. You wait for updates. There may even be days where it never crosses your mind. That bandwidth is completely freed up.

Multi-prompting is the opposite. The work never leaves your head. You retain the objective. The AI takes on the lower level implementation, the same way spell-checking takes on mechanical proofreading. You remain fully engaged. You never stop being the author of the work. You simply stop being the one doing the slowest parts.

The cognitive loop stays intact.

Why Multi-Prompting Works When Multitasking Fails

Human working memory can hold only a small number of active threads at once. Research usually puts the upper bound around four to seven items: https://www.sciencedirect.com/science/article/abs/pii/S0010027704000314

Traditional multitasking forces those threads to fight for attention. We lose details. We forget sequences. We get the order wrong because the interruptions break our mental stacks.

Multi-prompting shifts the burden. The AI holds the intermediate states, the logical steps, the incremental implementation. Your mind only holds the mission. The objective stays crisp because you are not spending your limited working memory rehearsing each substep.

You get to move to the next objective immediately. And when you return, nothing has decayed. The context is still there because the AI is preserving the continuity through rapid iteration.

A New Human Work Pattern

This is not a small shift. The human tech interface has gone through three major phases of labor:

  1. Humans do the work.
  2. Humans delegate work.
  3. Humans direct work.

Multi-prompting quietly introduces a fourth:

  1. Humans co execute work.

It is not automation because you still drive the objectives. It is not delegation because nothing is handed off. It is more like working with multiple cognitive extensions that each operate at computer speed while you maintain the higher level coherence.

Your mind becomes the conductor. The AI becomes the orchestra.

And suddenly you can work across many projects without losing the plot of any of them.

The Future of Daily Work

In ten years, people will look back at how we worked in 2023 and realize how primitive the workflows were. We had powerful machines but we used them in single threaded patterns carried over from the industrial age. Multi-prompting is one of the first glimpses of a different kind of knowledge work. One where human intention stays front and center, while machines handle the cognitive drudgery that used to slow us down.

We will not call this multitasking. We will not call it delegation. We will probably give it a better name than multiprompting.

But the shift is already here.

One minute of human direction. One minute of machine execution. A continuous loop. And a new concept of our internal thinking flow and what one person can accomplish.