Your first version is not a smaller version of the company you hope to become. It is a test of one hard belief: that a specific customer has a painful enough problem to change what they do today. Knowing what not to build in v1 is how you protect that test from your own good ideas.
The trap is understandable. You see the full product clearly. The workflow, the automation, the reporting, the admin controls, the integrations. Each item feels like part of the promise. But a v1 loaded with future-state work does not give customers more value. It gives you more ways to delay the verdict.
A founder does not need a bare product for its own sake. They need the smallest credible product that can create a real customer outcome, produce a clear signal and survive being used by someone who did not help design it.
What Not to Build in V1: The Future Company
Do not build for the buyer you expect to have after a successful seed round. Build for the person who will take a meeting now, tolerate a few rough edges and tell you whether the problem is real.
That distinction changes the roadmap. A multi-team permissions model may matter when large accounts arrive. Sophisticated usage analytics may matter when you have hundreds of active customers. A marketplace, partner portal, or developer API may be central to the long-term business. None of that earns a place in v1 just because it appears on the three-year vision.
The question is not whether a feature will matter eventually. Almost every reasonable feature will matter eventually. The question is whether its absence prevents your first customer from getting the promised result.
If the answer is no, write it down, explain why it matters later and leave it out. That is not abandoning the vision. It is sequencing it.
Build the painful moment, not the whole workflow
Say you are building software for independent clinics. Your insight is that front-desk staff lose new patients when insurance intake takes too long. Your v1 should make insurance intake materially faster or more accurate for a defined kind of clinic.
It does not need a complete practice management suite. It does not need scheduling, messaging, billing, a patient app, custom reports and connections to every major system before anyone can use it. Those are separate products hiding inside a single roadmap.
You may need one integration if it is required to reach the painful moment. You may need a basic export if the customer cannot act on the result otherwise. The line is practical: build enough of the workflow to deliver the outcome, then stop.
Do Not Build Features That Replace Learning
Founders often add features to answer questions they could answer in a conversation. That is expensive learning.
A self-serve onboarding flow sounds right until you have watched ten prospects try to explain their setup. Automated recommendations sound useful until you know what customers trust and what they ignore. A pricing page with four plans can wait while you learn which job customers will actually pay to get done.
At the start, high-touch work is not always a failure of product. Sometimes it is the shortest path to the truth. You can onboard early customers manually. You can prepare a report behind the scenes. You can handle exceptions yourself while you learn which exceptions repeat.
This is not permission to run a disguised service business forever. Manual work becomes a problem when it masks the fact that the product does not create repeatable value. But before you automate a workflow, you should know the workflow is real, common and worth automating.
A useful test is simple: if you removed the proposed feature, could you still learn whether the core promise is true? If yes, do not build it yet.
Avoid Configurability Before You Have a Pattern
Early customers will ask for exceptions. They will have different fields, policies, approval paths, branding needs and definitions of success. The instinct is to build settings so every customer can have the product their way.
That instinct can bury a young company.
Configurability adds surface area faster than founders expect. Every setting needs an interface, documentation, tests, support and a decision about what happens when it conflicts with another setting. Soon the team is maintaining an internal toolkit instead of a product with a clear point of view.
For v1, choose a narrow customer and make a few firm decisions for them. Use defaults. Offer a manual workaround where the request is rare. If three or four customers need the same variation for the same reason, you have a pattern. Then build the setting or workflow that captures it.
The same rule applies to custom dashboards, templates and permissions. A request from a serious customer deserves respect. It is not automatically a roadmap commitment. Ask what decision they cannot make without it, how often that decision occurs and whether the need appears across your target market.
Do Not Build Enterprise Proof Before Enterprise Demand
Security, compliance, reliability and controls are not decorative. For some categories, they are part of the product from day one. If you handle protected health data, move money, serve government customers, or sit inside a regulated workflow, your baseline is different. Skipping the necessary safeguards can make a launch irresponsible.
But founders also overbuild enterprise proof for a customer segment that has not chosen them yet. They spend months on elaborate role structures, audit exports, procurement packages and integrations before they have confirmed that the buyer cares enough to run a pilot.
Start with the non-negotiables for your market: sensible access controls, secure data handling, backups, clear terms and an honest account of what the product does and does not support. Then let actual deals tell you what evidence must come next.
Do not promise certifications, uptime commitments, or technical capabilities you have not earned. The wrong number dies in the draft. So does the unsupported claim.
The Things That Feel Small but Change the Test
Some work looks unglamorous and still belongs in v1. A clear setup path matters if users cannot reach value without it. Error handling matters if one bad input destroys trust. Basic instrumentation matters if you cannot tell whether people completed the core action. A way to talk to users matters because silence can look like satisfaction when it is really confusion.
These are not features for a future roadmap. They protect the learning loop.
The same goes for a narrow definition of success. Before building, write down the customer action that would prove the product is useful. It might be a weekly task completed in half the time, a qualified lead recovered, a report trusted in a real meeting, or a process no longer handled in a spreadsheet.
If your v1 cannot produce that moment, it is not ready. If it can produce that moment without the next ten items on the roadmap, those items can wait.
Make the Cut With Evidence, Not Anxiety
A tight v1 can feel exposed. You worry a prospect will ask for the missing feature and decide you are not ready. That may happen. It is still better than building six months of work around an objection you have not heard.
When a request comes in, capture the exact language. Record who asked, what they were trying to do, what they use instead and what happens if the problem stays unsolved. Put the request next to your core assumption. Over time, you will see the difference between a one-off preference and a product gap.
This is where one shared company context helps. Your customer interviews, product decisions, market claim, financial plan and investor narrative should agree. Firmgrove keeps that operating picture connected, so a product choice does not quietly contradict the raise you are planning or the customer you say you serve.
A v1 is allowed to be narrow. It is allowed to require your attention. It is allowed to disappoint people who were never the right first customer. What it cannot be is vague about the problem it is here to solve.
Make the cut until the product has one job a real person will use it for. Then put it in their hands, stay close enough to hear the truth and let that truth earn the next build.