MVPs for Solo Founders

When a Narrow Product Meets Real Work

A founder wants to help small architecture studios turn project-meeting notes into client-ready weekly summaries. The imagined product already has a portal, approvals, tasks, branded templates, an archive, calendar sync, and a dashboard.

None of those features answers the first question: will a project lead trust a generated summary enough to send it to a real client, then return after the next meeting?

A landing page cannot answer that question. A clickable prototype cannot put a client’s name beneath generated claims. A manual writing service can show that the outcome is useful, but it may show only that the founder is a good editor. The next test needs product-shaped use: real notes go in, a reviewable summary comes out, and the project lead decides whether it is safe to send.

That is the useful meaning of an MVP. It is the smallest product experiment that lets a particular user perform one valuable behavior in real conditions while the founder can still support, measure, and change it.

The familiar bad MVP begins with the eventual product and removes features until something can ship. What remains is often broad but weak: too unfinished to earn trust, too complicated to interpret, and too fragile for one person to operate. Minimum becomes an excuse for roughness rather than a discipline of inquiry.

Begin with the decision instead. If project leads use the summary twice in real client work, the founder has reason to improve this workflow. If they approve drafts but refuse to send them, trust or output quality is the live problem. If they send one and never return, frequency, friction, or segment may be wrong. Each result points somewhere. A release with no consequence is merely a small product.

Cross the Product Threshold Deliberately

The preceding evidence work may have used conversations, sketches, a landing page, spreadsheets, scripts, or a manual service. An MVP is warranted when the missing evidence depends on a user doing real work through a repeatable product path.

The names matter because each artifact supports a different claim. A prototype asks whether an idea or interaction makes sense while the user may still be imagining use. A manual service asks whether the delivered outcome matters, although the founder may be the mechanism. An MVP asks whether a user can reach and repeat one value moment through something product-shaped. A beta comes later, when the product shape is largely chosen and the question has shifted toward quality, onboarding, defects, edge cases, and support.

If you are still learning whether anyone cares, calling a prototype an MVP will not strengthen the evidence. If people are already relying on the workflow, calling it an MVP will not excuse missing recovery or careless data handling.

The product threshold also depends on context. A developer-tool MVP may be little more than one API operation, but installation, authentication, documentation, examples, and errors are part of its interface. A marketplace may manually supply one side while testing whether a narrow exchange repeats. An AI product needs an accepted input, a bounded output, a review point, an error tolerance, and a recovery path before an impressive generation becomes a usable result. A paid B2B pilot must distinguish the buyer’s approval from the operator’s repeated use.

These are not separate recipes. They are reminders to put realism where the behavior requires it. The architecture-studio experiment is simultaneously paid, AI-assisted, founder-reviewed, and restricted to one workflow. Its integrity comes from named boundaries, not from choosing the purest label.

Write the Behavior Before the Features

The architecture-studio MVP can be stated in one sentence:

For five-to-twenty-person architecture studios that already send weekly client summaries, test whether a project lead can upload meeting notes, approve a client-ready summary, and send it after two consecutive weekly meetings, with no more than thirty minutes of founder review per summary by the second cycle.

That sentence does more product work than a feature list.

The segment is specific enough that behavior can be compared. The value moment is not account creation or generation; it is sending a summary the project lead is willing to stand behind. Uploading notes begins the value path. A second weekly cycle supplies the first retention signal at the natural rhythm of the job. The review limit makes founder labor part of the result.

Use the same form for another product:

For [specific segment], test whether [user] can reach [value moment] by doing [activation event], then repeat it after [natural interval], with no more than [bounded manual burden] from me.

The blanks should resist easy answers. “Small businesses” is not an interpretable segment. “Engagement” is not a value moment. “Returned later” is not a retention interval. “Some help with onboarding” is not a support boundary.

The value moment should be an outcome the user would notice losing: resolving an invoice exception, producing a correct compliance packet, shipping an integration, or sending a client communication. Activation is the first observable action that starts that path. Retention belongs to the problem’s cadence—a second build, the next weekly review, another billing cycle—not to an arbitrary analytics window.

Build Only the Path That Can Answer

Once the behavior is clear, scope becomes an argument rather than an appetite.

The architecture-studio MVP needs one notes-upload path, one summary form, one founder-reviewed draft, one approval-and-edit screen, and one way to export the result into email. It needs to record upload, generation, approval, export, return, corrections, support, and founder review time. Founder-led onboarding is acceptable because the experiment names it.

It does not yet need a client portal, task management, calendar sync, custom branding, template libraries, billing automation, project dashboards, or archive search. Those features may someday matter. In this experiment they would create more explanations for success and failure.

Cutting scope does not mean cutting whatever is inconvenient. Users must be able to behave as if the promise were real. Because project notes and client communication can be sensitive, the test needs a clear data-use statement, a review step before anything leaves the product, an honest failure state, and a recovery path. Without them, reluctance to send may measure distrust of the experiment rather than value of the workflow.

This is the boundary between a narrow MVP and a broken one. The MVP is too small when the value remains imaginary, the central output is fake, or missing safeguards stop honest use. It is too large when the founder cannot name which behavior caused the result, customer requests automatically become scope, or changing direction would require migrations across features that have proved nothing.

When in doubt, cut questions before cutting features. Decide which uncertainty deserves a real answer. Keep only what creates, measures, supports, or interprets the behavior needed for that answer.

Put Founder Labor in the Evidence

Manual work is often the fastest way to learn a workflow before freezing it into software. It becomes dangerous when it quietly manufactures success.

In the summary MVP, the founder may review every draft. That can reveal recurring corrections, unsafe claims, missing note structure, and the language project leads expect. The review is useful because it is visible, timed, and tied to a learning purpose.

Now imagine the founder also repairs every upload, rewrites every summary, reminds every lead to return, and adapts the format separately for each studio. The users may appear to activate and retain, but the product has not produced the result. A private service has.

Ask a severe question after every value moment:

If my hidden labor disappeared, which part of the promised value would disappear with it?

The answer need not be “none.” Concierge and Wizard-of-Oz experiments deliberately depend on human work. But the dependency must be legible. Record founder minutes, interventions, judgments, corrections, reminders, and exceptions. Decide which work is teaching stable rules and which work is compensating for a weak promise or workflow.

Support deserves the same treatment. Define how users enter the experiment, where they ask for help, what recovery the founder will provide, how support is logged, and which custom requests are out of bounds. The point is not to deny early users care. It is to prevent care from becoming unmeasured product functionality.

Instrument the Journey, Not the Screens

Early instrumentation can be modest: an event table, server logs, a few product events, support tags, and dated founder notes. It must still follow the whole value path.

For the summary experiment, record where each lead came from and which promise they accepted; whether upload began and completed; whether a summary was produced, edited, approved, and exported; whether it was actually sent; whether the lead returned after the next meeting; what failed; what required rescue; and how long founder review took. Annotate trust events such as sharing sensitive notes or approving externally visible text.

These observations answer three questions:

1. Where did the user stop before value?
2. Did the valuable behavior happen again at its natural interval?
3. What founder effort was necessary to make it happen?

Counts alone are not enough. An export after a founder reminder is different from an unprompted return. An approved summary that was never sent is different from one used in client communication. A failed upload caused by unclear data handling is different from weak demand. Keep qualitative notes close enough to the events that the differences survive.

Do not instrument every available click. A dashboard full of activity can hide the absence of the one action that justifies the product.

Decide While the Result Can Still Disappoint You

Write the success, change, and rebuild rules before recruiting users. After code and customer attention accumulate, ambiguity becomes much easier to defend.

For the architecture-studio MVP, a useful success rule might be: three studios complete two weekly cycles; each sends at least one summary to a real client; the second cycle begins without a founder reminder; and founder review falls below thirty minutes per summary by then.

The result should branch into decisions:

• If leads approve summaries but do not send them, investigate trust and output quality before adding product scope.
• If they send once but do not return, test the workflow frequency, segment, and activation friction.
• If every summary needs bespoke rewriting, narrow the segment or template and remain manual longer.
• If fewer than two of eight recruited leads send a summary after onboarding, stop building summary automation and return to discovery around client communication.
• If repeated use is strong and review corrections converge, decide whether the next investment is more durable automation.

A kill rule need not kill the company. It may kill a segment, promise, workflow, or implementation. Its purpose is to name evidence you will not explain away.

Rebuilding is a different decision. The MVP code may have been optimized for learning and may deserve replacement after the learning succeeds. Rebuild when repeated use has earned continued investment and the current implementation now slows learning, creates unacceptable support or trust risk, or encodes rules that have finally become stable enough to automate. Do not rebuild because early code is embarrassing. Rebuild because the engineering job has changed.

The MVP should end. Success turns it into a narrower product, a more durable system, or a test of the next risk. Failure sends the founder toward a different segment, promise, artifact, or idea. Keeping an experiment alive indefinitely protects the implementation from delivering its most valuable output: a decision.

Complete the Experiment Card

Before opening the product to real users, write one page:

1. Name the target segment and the current alternative.
2. State the value moment, activation event, and natural return interval.
3. Draw the shortest product path that can produce that behavior honestly.
4. List every manual component and the lesson it is meant to produce.
5. Set the support boundary and the trust or recovery baseline.
6. Choose the events, notes, and burden measures that will preserve the evidence.
7. Write the success rule, the result that forces change, and the trigger for rebuilding.

Then remove every feature that contributes to none of those lines. Add back only what users need to reach value safely enough for their behavior to mean something.

Finally, answer both questions in verbs: if this succeeds, what will you build, automate, sell, or measure next? If it fails, what will you narrow, revisit, or stop?

The architecture-studio founder does not need a miniature version of the imagined platform. The founder needs one honest weekly cycle, followed by another. Once real users enter that path, the interface itself becomes part of the evidence: it must explain the promise, guide the next action, expose failure, and earn enough trust that the founder is no longer standing beside every click.