By Alyssa Miller
A finished spec document is the most confident artifact an early-stage founder will ever produce. Thirty pages. Every screen accounted for, every edge case resolved, every feature ranked and justified. It reads like a plan.
Vitalii Sydorenko thinks it is usually a list of untested assumptions in a professional font.
“Founders bring me a document and what they want is for me to tell them it’s correct,” he says. “I can’t. Nobody can. The only people who can are the customers, and they haven’t seen it.”
Vitalii is co-founder of beyond the wow, an AI-native MVP studio for early-stage founders, and CEO and Partner at Gearheart, the product development studio behind it. He also scouts late-seed and Series A B2B startups for Network VC, which means he sees the same failure from two directions: as the person building the product, and as the person deciding whether to fund the company that built the wrong one. His position is that insisting on a complete spec before development begins is not discipline. It is a way of converting uncertainty into paperwork, and it defers the moment of being wrong to the point where being wrong costs the most.
Two versions of the same lesson
Vitalii’s first company, LOOQME, went through 37 product versions before it worked. It became the leading media monitoring platform in Ukraine, with roughly 40% market share, more than 300 clients including McDonald’s, Lenovo, Samsung and Deloitte, and operations across four countries. He exited it.
“Thirty-seven versions is not evidence that we planned badly,” he says. “That’s what the plan looked like after customers were allowed to touch it.”
The second lesson cost more, because on paper everything went right. Jiffsy, his mobile-first e-commerce venture, raised $290,000, was accepted into Startup Wise Guys, won a Google grant, and onboarded more than 30 clients. It shut down without finding product-market fit.
“Investors approved the plan. An accelerator approved the plan. A grant committee approved the plan,” Vitalii says. “Every group that reviewed it said yes. The one group that mattered never did.”
What the document actually locks in
The purpose of a spec is to remove ambiguity, and it does that by selecting an answer for every open question. That is the mechanism Vitalii objects to. Each answer selected without a customer in the room is a guess with a delivery date attached.
The cost of a wrong guess scales with how much sits on top of it. In week two, changing the data model is a conversation. In month five, it is a rewrite, and it arrives precisely when runway is thinnest, and investors are asking about traction. The cheapest moment in the entire lifecycle to be wrong is the first week. A comprehensive spec is built specifically to prevent a founder from being wrong in the first week.
“It doesn’t remove the error,” Vitalii says. “It reschedules it for the worst possible date.”
This is also, in his account, where the phrase “it’s 95% done” comes from.
“Ninety-five percent done against what? Against the spec. Nobody is measuring against the customer, because the customer got replaced by a document five months ago.”
The objection worth taking seriously
The obvious counterargument is that this reasoning produces the mess currently spreading across the early-stage market: half-built applications generated by founders prompting AI tools with no engineering standard underneath, breaking the moment real users arrive. Vitalii sees that caseload directly, and beyond the wow runs a diagnostic service specifically for founders whose vibe-coded products have started failing.
So he draws the distinction narrowly. Locking scope is not the same as locking answers.
Scope discipline means one core use case, one customer type, one thing the first version does, and nothing else ships until that works. Vitalii argues this constraint should be enforced without flexibility, and that it is the thing most founders actually lack.
Answer certainty means claiming to know how onboarding works, which integrations matter, and what the pricing tiers are. “You don’t know those things yet,” he says. “You have opinions about them. Opinions cost nothing to change in week one and they cost you the company in month five.”
Engineering standards are not the flexible part either. Real authentication, a real database, real error handling, deployed on real infrastructure. An enterprise buyer will not sign off on a prototype the founder is nervous to demo. Vitalii’s argument is that a team can hold a high production bar and still refuse to decide, in advance, the things only a customer can answer.
Three sentences instead of thirty pages
What Vitalii asks founders to write instead is short enough to be defended out loud.
Name the specific person who has this problem, by role and company type. “Operations managers at construction firms with 20 to 200 employees” is a person. “SMBs” is not.
Name what that person does today instead of using the product. If the honest answer is a spreadsheet and a group chat, that is useful information. If the honest answer is nothing, the problem may not be worth solving.
Name the one thing that must be true for them to switch, and write it so it can be proven false in under a month.
Then build only enough to test the third sentence, put it in front of the three users who can already be named, and set an explicit go or no-go. beyond the wow’s stated criteria for the founders it works with include being able to name three people who will use the product on day one.
“If you can’t name three, you’re not ready to build,” Vitalii says. “You’re ready to have a conversation.”
The part that gets misfiled as execution risk
Every founder Vitalii has watched get this wrong shared one belief: that the risk in software development is execution. He argues execution risk is real but manageable, and that competent firms handle it routinely.
The risk that kills companies is direction. Everything gets built correctly and the thing itself is wrong.
“A spec doesn’t reduce that risk,” he says. “It hides it, professionally, for about five months.”
The founders who ship, in his account, are not the ones who walked in with the best answers. They are the ones who built a short enough loop to find out which of their answers were wrong while it was still cheap to be wrong.
