The advice arrives stripped of its conditions. Ship ugly. Ship fast. If you are not embarrassed by version one, you waited too long. It gets repeated at demo days and in Slack channels and on founder podcasts until it sounds like permission. Permission to skip the design pass, to push the broken thing, to call the mess a strategy. That is not what any of the people who actually said it meant, and the gap between the slogan and the practice is where a lot of early products quietly die.
The slogan most often cited is Reid Hoffman’s. He has spent years correcting how people read it.
The quote, with its conditions restored
Hoffman’s line is “If you’re not embarrassed by the first version of your product, you’ve launched too late.” In a 2017 essay published on LinkedIn under the title If There Aren’t Any Typos In This Essay, We Launched Too Late, he explained where the idea came from: a shift from a world ruled by scarcity, where software shipped in boxes with thick manuals and “the value of getting it right the first time” was high, to one where reaching users is cheap and “the value of getting it right the first time has plummeted.” The embarrassment he describes is the embarrassment of incompleteness, not of failure.
A March 2026 piece in Mint revisiting the quote put the correction plainly: Hoffman “has repeatedly clarified that his statement is not a licence for recklessness.” The embarrassment “is not about launching something broken or irresponsible, but about accepting that a product, at its earliest stage, will inevitably be incomplete.” Incomplete and broken are different conditions. The slogan collapses them. The practice keeps them apart.
Eric Ries supplied the corollary that should travel with the quote and rarely does: “No matter how long you wait to release your first version, you will be embarrassed by it.” If embarrassment is inevitable, it cannot be the variable you optimize. The thing you control is what kind of incomplete you ship.
Half, not half-assed
The clearest statement of the actual discipline is not Hoffman’s. It is a single chapter in 37signals’ book Getting Real, titled Half, Not Half-Assed. The instruction is exact: “Build half a product, not a half-ass product.” Beware the everything-but-the-kitchen-sink approach, the chapter argues, because throwing in every decent idea leaves you with “a half-assed version of your product.” The alternative is to “build half a product that kicks ass.”
This is the distinction the ship-ugly crowd loses. Half a product is small. A half-assed product is broken. They feel similar from the outside, a thing with fewer features than the eventual version, but they are opposites in how they are built. Half a product is the result of cutting hard and finishing what remains. A half-assed product is the result of attempting everything and finishing none of it.
37signals lived this with Basecamp. On the company’s REWORK podcast, Jason Fried recalled the first version, launched in February 2004: it “didn’t have a way to share files,” to-dos “were a latecomer,” and it had no calendar, no automatic check-ins, no folders, no color coding. What it had was the messages section, which Fried describes as the heart of the app, built well. The strategy was not to ship a worse Basecamp. It was to ship a smaller one that did the central thing properly and let real usage decide the rest. As the Half, Not Half-Assed chapter puts it, that let them “base future decisions on real world usage instead of hunches.”
What Linear actually scoped
Linear is the company most often held up as proof that you can ship rough and win on craft later. The founders’ own account complicates that. In Building at the early stage, a January 2021 essay, co-founder Karri Saarinen describes the early model: scope projects so they “can be completed in 1–3 weeks with a team of 1–3 people,” ship the early version to yourself and private beta users in the first week, and collect feedback immediately. The first versions of Cycles and Projects, now two of Linear’s core features, each took “about two weeks to design and build.”
The operative verb is design. Saarinen does not describe shipping something that repelled the people who saw it. He describes shipping something narrow on a short clock and then improving it in public. The constraint that made it work was scope, not sloppiness. “Successful startups often start with something small, figure it out, and then scale,” he writes, and the small thing in Linear’s case was a deliberately bounded feature that already felt like Linear. The polish people credit Linear for was not added later to an ugly base. It was present in miniature from the start, on a surface small enough to keep clean.
That is the direction the good examples share. Basecamp shipped the messages section finished and left files out. Linear shipped Cycles finished and left the rest of the roadmap for later months. Both cut surface area. Neither cut quality on the surface they kept.
What too ugly actually looks like
If half a product is the target, the failure mode in the other direction deserves a name too, because founders rarely fail by being too polished. They fail by shipping a surface so confusing or untrustworthy that users cannot tell whether the underlying thing works.
The line is not aesthetic taste. It is whether the roughness costs the user the ability to evaluate the product. A spreadsheet-grade interface on a tool that does one thing is fine. A signup flow that errors silently is not. A plain, unstyled settings page is fine. A pricing page that contradicts the in-app behavior is not. Hoffman’s own framing supports the distinction: the embarrassment he endorses is typos in an essay, not an essay that argues the opposite of what you meant. Cosmetic incompleteness reads as early. Functional incompleteness reads as untrustworthy, and a user who does not trust the surface will not stay long enough to discover the substance.
The Linear and Basecamp accounts both rely on a step that a genuinely broken product cannot perform: putting the early version in front of real users and learning from how they use it. Saarinen’s whole model assumes the beta users can actually use the thing. Fried’s whole point about basing decisions on “real world usage instead of hunches” assumes there is usage to observe. A product too ugly to use produces no signal. It just produces churn that looks like rejection of the idea when it was rejection of the execution.
Half a product is small. A half-assed product is broken. They feel similar from the outside and are opposites in how they are built.
A heuristic that fits in one sentence
Here is the test that the three sources converge on. Before you ship, ask whether the roughness is in the surface or in the function. If the surface is plain but the one thing the product promises works completely, ship it. If the function is incomplete, that the one thing it promises does not yet work, cutting more features will not save you, and a design pass will not either. You have not built half a product. You have built a half-assed one, and shipping it teaches you nothing because users cannot get far enough to react.
The discipline in ship ugly was never about ugliness. It was about choosing what to finish. Basecamp finished messages and shipped without a calendar. Linear finished Cycles and shipped without a roadmap. Hoffman endorsed typos and warned against recklessness in the same breath. The founders who say they shipped ugly almost always mean they shipped narrow, with the narrow part done. The ones who shipped genuinely ugly mostly are not around to write the retrospective.