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.

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:

Humans do the work.
Humans delegate work.
Humans direct work.

Multi-prompting quietly introduces a fourth:

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.

Socratic AI: The debate-based Writing Method to create better content

When asking AI to write articles, I think most people prompt apps to “Write about this…”. They provide some details about what to write, more or less, and then use AI to help with the editing. It’s a kin to having an editor or ghost writer.

I started in the same way, but always felt like I was battling the AI instead of working with it. I’ve come to use it very differently. Not do I love this new method but I learn a lot from the experience each time.

Instead of asking AI to write for me, I use it to think through concepts with me. To have it debate or question my thoughts. To specifically “not write an article” for quite some time until I think we are on the same page. This can sometimes take weeks strewn with small chats with long breaks in between until a new thought spark up again.

This whole approach started by accident when I discovered more personality with GPT 4. One day I got riled up from reading some shallow post. It sparked a mental argument with myself to try and see how “the other side” could come to such a different conclusion. On a whim I gave ChatGPT a chance to give me the other side and it surprised me. It not only delicately agreed with my POV, but it gave another potential position followed by “if you could change the circumstance how would you do it?”

It didn’t just echo my points. It pushed back. It made counterarguments. It sharpened the conversation. I ended up having a long conversation with the AI. By the end of it, I understood my own idea better. I felt like I had a smart, patient thought partner who genuinely got what I was trying to work through. It was mind blowing.

That’s when it hit me. If GPT can do this with abstract ideas, why not use the same kind of back-and-forth to help me write?

That’s how this process was born. I’m not starting with a goal to create a draft. I’m starting with a goal to think through a conversation and see where it leads.

What I’ve found feels like a modern revival of the Socratic dialectic. It gives me a space where I can toss out half-formed thoughts, question assumptions, test ideas, and refine them through dialogue. Some go nowhere, but all end with a better grasp of my original thought or counter thoughts.

I keep all my writing in a single project so GPT has context from everything I’ve written or said before. When I want to explore something new, I open a fresh thread and say:

“I don’t want anything created yet. I want to jot thoughts down and then I’ll let you know if I’m ready to create something or if I want to dig deeper.”

Then I just post whatever comes to mind. No outline. No goal. Just the original vapor of a concept. Sometimes I ramble. Sometimes I loop back or take side paths. Sometimes I ask:

“What do you think?” or “Is there a counterpoint I’m missing?”

And it responds. Not with a final draft, but with friction. With momentum. With more angles to explore.

I think best in conversation. I rarely find clarity in a vacuum. Often I will argue a point with someone and walk away with a whole new version or perspective on my belief. Often, I push on ideas, debate myself, and churn.

So when GPT became more conversational, it clicked. It felt like I finally had a thinking partner who didn’t judge, remembered everything, and has no distinct side. The result isn’t just better writing. It’s better thinking.

Once the idea has been explored enough, I ask GPT to turn the thread into an article. Since it has been there for the full conversation and already knows my tone from past articles, the first draft usually comes back pretty close to what I want.

It is never final, but far more inline and final than anything I have ever tried to create with AI before.

Once I am done I end the thread with my final post in my project:

“Here’s the one I actually used. Save this to memory. No more feedback or follow up needed.”

Over time, it learns me. My tone. My rhythm. The kinds of lines I keep, the ones I cut, and the ones I repeat for emphasis. It becomes both a mirror and a co-writer.

So no, I don’t start by asking GPT to write something. I start by asking it to listen. To push back. To help me think through things better. This isn’t AI-assisted writing, it is AI-assisted dialectic.

Building with AI Is Easy. Choosing What to Build Is Not.

AI Rewards the Bold: Pick Something and Go.

In this new technological era, the decisive and action-oriented will shed the chaff.

Company-building, product creation, even personal capability. None of it is constrained like it used to be. AI has shattered the old limitations. You can build more, faster, and cheaper than ever before. But that’s not the hard part. It never really was.

The real challenge, now more than ever, is deciding what to build.

Decision-making (and actually acting on it) has always been the backbone of entrepreneurship. But compared to what’s coming, the past was a cakewalk. As access to capabilities explodes, the cost of distraction skyrockets. Shiny object syndrome isn’t a cute founder flaw anymore, it’s a startup killer.

The paradox of progress is this: the easier it becomes to build anything, the harder it becomes to choose one thing.

This is where AI breaks the old rules. In the corporate world, bureaucracy thrives on optionality, doing many things slowly, debating endlessly over direction. Startups win because they choose something, even if it’s wrong, and go all in. Most successful companies didn’t choose perfectly; they chose decisively and refined through motion.

Now, with AI supercharging optionality, even sharp founders are getting stuck in the freeze. When I talk to peers, more and more of them say: “I’m still figuring it out.” But it’s not hesitation out of fear, it’s hesitation out of abundance. The question has shifted from What am I capable of? to What should I focus on? It’s sort of like dating apps. With infinite choice, settling down feels harder. Possibility becomes paralysis to commit.

In the AI era, execution still matters, but conviction matters more. The ability to choose early, clearly, and with intent will be the new differentiator.

You don’t need to do everything. You need to do something deeply, consistently, and unapologetically. You don’t have to predict the future. You just have to take the first few steps toward it—with your whole weight behind the decision.

The Studio Era of Startups Has Begun

For decades, the startup game has been a one-shot endeavor. You rally a team, raise money, pick a problem, and commit. If you’re lucky, you pivot when you have to, maybe once or twice. But fundamentally, you’re placing a single bet. Pouring your time, capital, and reputation into one idea.

That world is changing quickly.

The world is focusing on their ability to now code more with fewer people, or allow folks with less coding skill to vibe code to success. The fact is, the amount of code was never what made a startup successful, or the number of coders. If that were they case no startup could disrupt a large, well funded, company. More significantly, a new paradigm of startup is emerging, one that leverages the startup creativity and ingenuity. One that helps founders evolve from creating a company with a product, but for just as much cost and time a studio of bets. One that moves with the agility of a hacker and the creative churn of a film studio. And AI is the accelerant.

Imagine if all the studios and accelerators you know were now able to be run by a few founders, with as little funding and workforce as the typical garage startup.

Every Startup Can Now Be a Studio

What’s different today isn’t the concepts, it’s the economics.

The execution bottleneck has collapsed:

Build v1 of an app in days, not months
Ship a prototype in the time it used to take to write a product spec
Generate research, copy, and flows on command
Test real experiences with minimal investment
Multitasking and directing employees has merged into one skill.

A solo founder can now run what used to require a venture studio’s entire apparatus. A three-person team can operate multiple product lines simultaneously in a pre-seed stage or earlier stage.

This isn’t just “faster iteration” it’s a change in who gets to play and at what breadth an entrepreneur can address a market.

The old studio model was top-down: institutions funding experiments. The new model is bottom-up: individuals becoming their own institutions.

When indie hackers ship 12 products in a year and 2 of them hit, that’s not hustling. That’s systematic creative output.

The Rise of the Experiment Engine

The shift isn’t just technical it’s philosophical.

Traditional startups were binary: succeed or fail. Traditional studios were capital-intensive: big bets, long cycles.

But now you can run a creative system where:

Failure is cheap
Iteration is constant
Signal emerges from volume
Products are hypotheses, not commitments

This is what studios do, but now it has been democratized. Again, it isn’t the amount of code and workforce people should be focusing on as they predict the future, it is the breadth of creative experimentation and lack of wide nets of attempts to fund a winning idea be limited to heavily venture funded organizations.

Pixar doesn’t bet the farm on a script — they storyboard, test scenes, rework characters. Record labels don’t drop millions on a demo — they release singles, test styles, build momentum.

Now individual founders can operate with the same creative methodology at a scale never before possible.

Remember “ghetto testing”? Half-baked landing pages, fake feature toggles, manually faked automation? All just to see if anyone cared.

Today, you don’t need to fake it. AI and automation let you spin up real features, fast with polish, interactivity, and branding.

This isn’t just efficiency. It’s a mindset shift. Testing doesn’t feel like cutting corners anymore. It feels like genuine creative exploration.

From Founders to Creative Directors

In this new world, successful founders aren’t just CEOs. They’re creative directors.

They guide taste. They shape vibe. They ask: “what world do we want to live in, and what prototypes can get us there?”

The core skill isn’t managing or scaling, it’s imagining boldly and moving quickly enough to find signal before the market shifts.

The Individual Studio Playbook

The next generation of great startups will operate more like personal creative studios:

Default to prototyping — Ideas aren’t precious until they prove value
Build multiple product lines — Portfolio thinking, not single bets
Use AI as infrastructure — Not just to code, but to design, write, and explore
Kill fast — Speed means nothing without the ability to stop wasted motion
Treat products as experiments — Hypotheses to test, not commitments to defend

The Democratization of Venture Capital

When the cost of experimentation drops to near-zero, everyone becomes their own venture capitalist.

You don’t need Rocket Internet’s playbook. You don’t need Betaworks’ capital. You don’t need Y Combinator’s batch.

You just need curiosity, taste, and the willingness to ship quickly.

More strange tools. More niche apps. More absurd experiments that just might work. We’re not heading into a world with fewer opportunities — we’re heading into a world where more people get to be entrepreneurs.

The studio era isn’t coming. It’s here.

The question is: Are you ready to be your own venture studio?

The time has come. You must adapt to LLM/AI/Agentic based development.

2025 marks a turning point in software development. Incorporating AI or some variation of Large Language Models (LLMs) into development workflows is no longer optional—it’s a competitive necessity. This shift isn’t about following trends; it’s about pragmatic productivity and maintaining a competitive edge.

It isn’t the AI, it is you

Even if the technology stop progressing from this point in time it would still necessitate adoption. Modern AI-powered tools have evolved far beyond simple code suggestions. They now understand context, manage complex refactoring tasks, and can handle entire development workflows from your project’s code base, to its Dev Ops configs, to its integrated terminal CLI commands. You can see a screenshot below of Windsurf’s Agent deploy a Terraform instance (it created) while checking to see if its previous deploy of K8 pods were complete! Agentic IDEs, combining sophisticated code assistance with terminal access, have redefined what’s possible with software development.

I was surprised to hear a few close developer friends tell me how they aren’t comfortable with how the AI “gets in the way” of their development. That made sense a year ago, but we are far past that being a valid excuse. It is tantamount to saying I don’t like looking up issues or solutions on Github, Google, or Stack Overflow because I like to just work it out problems myself. Which is more like saying, “I like reinventing the wheel with painfully slow speed”.

At this point it is no longer a question of whether the quality of the AI workflow fits your patterns, but that you are falling behind on skills your craft requires of you to develop quality code and infrastructure efficiently.

As this panel in Windsurf’s VS Code demonstrates, not only have my files and code been improved but it suggested and executed subsequent deployment plans and ran checks to see if the steps it took were running. Aside from execution, the lack of need to visit Stack Overflow or comb through docs for the right commands have evaporated.

Your Hesitation Is Costing Time and Money

Not adopting LLMs in your development process carries significant costs:

Efficiency Gap: AI-assisted teams can identify and fix issues in minutes, while others might spend hours debugging.
Market Disadvantage: Companies embracing AI-assisted development ship features faster, with fewer bugs, and at lower costs.
Resource Misallocation: Every hour spent on routine tasks is time not invested in innovation.

The question isn’t whether to adopt AI development tools, but how quickly you can integrate them. Every day spent working “the old way” accumulates technical debt in development velocity. The future of software development is here, and it’s AI-assisted.

Todays Tech: Editorial

Being part of the industrial revolution must have been amazing. I use to wish I was around during a revolution of that size as I would have wanted to take risks and catch the business wave as early as I could. Like being around when Bill Gates started MicroSoft. How could people have thought it was a fad, or rejected such an practical, obvious, beneficial product? Computers and software changed the way life happens and a majority of the population were/are late adopters. These last few years have been the beginning of yet another great revolution in my eyes and I wasn’t going to pas it up. I cant believe how many thought/think the technologies of today are a fad, many of those nah sayers who argued in my and coworkers face and mocked the industries goals are forgotten (lucky for them) and from only 1 year ago! More and more are getting on the ride. Im glad I started giving it my all early on, no regrets.

We still have a long way to go. Those who said Facebook was a fad are now on FaceBook with the rest of their family and friends and use it fairly often. What’s more disturbing is how often I over hear people on FaceBook or in passing that scream how much Twitter is a useless fad……I guess we just need to give them a few years in which I suspect that they will be bashing yet another new technology, but will do it using Twitter.

Even the most basic and useful forums of social media get bashed to this day, often purely for cultural reasons in which technology in many peoples eyes equal sub par information and practicality. I don’t know how many times I’ve over heard intelligent people bashing any information found on Wikipedia. Although not perfect it’s easy to for get that Webster and Britannica were all originally missions of one man traveling the globe. One man one perspective asking strangers and alike what they knew to be knowledge of the earth and its inhabitants. Accuracy is subjective and in this case a multitude of subjective persons might be more powerful and “true” then a single man is the final say.

Let’s try harder to find use in things that catch on or connect us all, that increase our perspective across greater bounds whether it be 100% accurate or not. If we are brought together and information is shared more readily then we are only following a path set thousands of years before us first with smoke signals, then to written stone, bibles, printed news, telegraphs and phones, radio and TV, internet and social media. Let us allow ourselves to find the good, as we have so reluctant at each point of our past, in connecting with one another and decipher the positive gains in mediums that do just that.