Chapter 2

Shipping Is the Starting Line

Projects Have Finish Lines

For weeks or months, the launch date can organize almost everything.

Before launch, there is a backlog with an unusually clear purpose. Fix the login problem. Finish billing. Test the import. Write the documentation. Resolve the security issue that appeared shortly after someone confidently declared security finished. Get the application deployed somewhere other than the developer’s machine. Every task points toward the same event: the product becomes available.

Software projects are good at creating this kind of directional certainty. We define milestones, acceptance criteria, release candidates, severity levels, sprint goals, and some version of “done.” Even teams that claim not to care much about project management eventually invent a project-management system, although sometimes it consists primarily of GitHub issues and increasingly concerned Slack messages.

The point is that software work gives us finish lines because it has to.

Without them, a product can remain under construction forever. There is always another defect to fix, another capability to add, another architectural improvement worth making, another browser behaving strangely, another model to evaluate, another integration that would be nice to have. Eventually someone has to decide that this version is sufficient to release.

That decision changes the emotional structure of the work.

I have experienced this on enough projects to recognize the feeling. Before release, the unfinished product occupies a particular place in your head. There is always something between where you are and where you are trying to get. The application is not deployed yet. The customer cannot access it yet. The workflow is not complete yet. You can describe the distance.

Then the deployment succeeds. The URL works. The production environment stays up. The payment system is connected, the major defects are resolved, and somebody who did not help build the thing can finally use it. For a few minutes, possibly longer if you are disciplined enough not to open the issue tracker, there is a satisfying sense that you have arrived somewhere.

You have.

Just not where you thought.

This is one of the reasons shipping is so easy to misunderstand commercially. In the development system, shipping really is a major finish line. A large collection of technical questions has been answered well enough to put the product in front of other people. The application has crossed from proposed software into operating software.

That is not symbolic. It is a legitimate accomplishment.

The mistake is carrying the same definition of completion into the business.

A development project can have a release date because the team controls enough of the system to define one. We can say version 1.0 includes these workflows, meets these requirements, passes these tests, and will be deployed on Friday. Friday may become Saturday morning for reasons familiar to anyone who has ever deployed software, but the concept remains intact.

Commercially, nothing equivalent happened merely because the deployment completed. No buyer was required to care on Friday.

No budget automatically appeared because the release notes were finished. Nobody became dissatisfied with their current workaround at the moment your DNS record propagated. The person with purchasing authority did not receive a mysterious internal notification informing them that your sprint was complete and that they should adjust their priorities accordingly.

The launch date belongs to you. The buying decision belongs to them.

I think builders sometimes blur those events because everything leading up to launch encourages us to imagine a transition from before to after. Before launch, we are building. After launch, we are selling. Before launch, the product is incomplete. After launch, it exists. Before launch, we are preparing for the market. After launch, presumably, the market begins doing market things.

There is some truth in that. But the symmetry is misleading.

Shipping completes a body of technical work. It does not complete the commercial thesis that justified the work.

You may still not know whether the person you targeted is the person who cares most. You may not know whether the problem is important enough to fund. You may not know whether buyers understand the offer, accept the price, trust you, or have enough urgency to change what they already do. You may not know whether the people who appear immediately after launch resemble the people who could eventually support the business.

Those are not loose ends from the development project. They are the beginning of another kind of work.

This distinction becomes especially important for technical founders because we are accustomed to treating unresolved questions as things that should have been handled before release. That instinct is often healthy in engineering. You do not want to discover after deployment that you never considered authentication, backups, access control, or what happens when an external service stops responding.

Commercial uncertainty is different. Some of it cannot be eliminated before launch because the evidence does not exist yet.

You can interview people. You can study alternatives. You can test positioning. You can show prototypes, discuss pricing, ask about current workflows, and seek commitments before building. You should do much more of that than many builders do.

But eventually the product has to encounter reality.

At that point, uncertainty is not evidence that the launch failed. It is evidence that the commercial experiment has finally become capable of producing better answers.

That requires a different psychological posture.

Instead of looking at launch as the moment when uncertainty should collapse, I now prefer to think of it as the moment when the quality of the uncertainty can improve. Before shipping, much of what you believe about the business is prediction. After shipping, people can encounter the actual product, actual offer, actual price, actual friction, and actual consequences of adopting it.

Now their behavior can disagree with your model. That may be less emotionally satisfying than checking off a launch milestone, but it is considerably more valuable. The product project needed a finish line because otherwise you might never ship. The business cannot use the same finish line because shipping is what finally gives the market something real to respond to. And unlike a project plan, the market does not consider your release date a deadline.

Markets Do Not

A release can be frozen.

You can tag the commit, archive the build, publish the version number, and say with some confidence that this is what the product looked like on September 2. The code may change tomorrow, but version 1.0 has a boundary.

Markets are not so considerate.

The buyer you spoke with last month may have a different budget this month. A competitor can change its price. A new tool can make the workaround cheaper. A manager can leave. Procurement can introduce a requirement nobody mentioned during the demo. A problem that felt urgent in January can disappear behind a larger problem in February, then become urgent again when somebody misses a deadline in March.

Nothing about your product needs to change for its commercial position to change.

This is uncomfortable for builders because a market is not merely a larger technical system waiting to be understood. It contains people making decisions under changing constraints, and those decisions affect one another.

Suppose you launch an application that automates a reporting process. At launch, your strongest alternative may be manual work in spreadsheets. The product saves several hours, the workflow is easier, and the comparison looks favorable.

Six months later, the software the buyer already uses adds a similar capability. Your application did not become slower. It did not become less accurate. No feature disappeared. But the purchase decision changed because the alternative changed.

Or imagine the opposite. Your product has been available for months and gets polite interest but little urgency. Then a regulation, customer requirement, staffing reduction, or internal deadline makes the underlying problem much more expensive to ignore. The same application can suddenly become easier to sell without receiving a single new line of code.

The product did not improve. The context did.

This is one reason I am wary of treating a launch as a final judgment on an app. A disappointing launch can be useful evidence, but it is not a court ruling issued by something called The Market and permanently entered into the record.

Sometimes the wrong people saw it. Sometimes too few people saw it. Sometimes the right people saw it and did not care enough. Sometimes they cared but the timing was bad. Sometimes the offer made the product difficult to understand.

Sometimes the buyer wanted the result and distrusted the seller. Sometimes the market really is telling you that the current proposition is weak.

The important part is not to protect yourself from that possibility. It is to avoid pretending that one launch event tells you which explanation is true.

There is a strange mythology around launches, especially in software. We see the announcement, the ranking, the traffic graph, the burst of signups, the screenshots of dashboards heading reassuringly upward. Public launches create visible moments, and visible moments are easy to narrate.

Businesses are usually built in the much less photogenic period afterward. That is when you discover who came back. Who asked serious questions. Who disappeared. Who paid.

Who needed approval. Who wanted something different from what you thought you were selling. Who had the problem badly enough to change what they were already doing. Most of that does not happen on launch day.

A launch spike can even make the commercial picture harder to read if you treat all of the activity as one thing. A few hundred visitors may include curious founders, friends, competitors, people collecting ideas, people who like new software, people who accidentally clicked something, and a handful of plausible buyers. The aggregate number is real. The commercial meaning is not self-explanatory.

I have learned to separate the event from the evidence. The event is: we launched. The evidence begins with what happened because we launched. Those are not the same sentence.

This distinction also changes how I think about timing. Builders sometimes postpone commercial learning because the product is not finished enough, then after launch behave as if the commercial questions should already have been answered. That leaves a remarkably small window in which uncertainty is considered acceptable.

Before launch: “We can’t know until people use it.” After launch: “Why isn’t this working yet?” There needs to be more room between those two thoughts.

Not endless room. I am not suggesting that founders spend three years calling zero revenue “early data.” Patience is not a business model either. But markets often require repeated exposure, conversations, offers, decisions, and revisions before the pattern becomes clear enough to act on confidently.

That is especially true when the thing being sold has meaningful switching costs or organizational consequences.

A consumer utility can sometimes reveal a great deal quickly. The visitor understands it, the price is visible, the purchase is simple, and the decision belongs to one person.

A B2B application may behave very differently. The person who discovers it may not be the buyer. The buyer may not be the budget owner. The budget owner may need security approval. Security may need documentation. Someone may want a pilot. The pilot may require implementation support. The person using the product may love it while the person signing the agreement is worried about whether your company will exist next year.

That is not one decision. It is a chain of decisions. A launch merely gives that chain a chance to begin.

This is why commercial progress often looks less like completing tasks and more like updating a model. You begin with a theory: this kind of person has this problem, our product improves it enough to matter, the offer makes sense, the price is acceptable, and we can reach them through this path.

Then reality starts editing. Maybe the buyer is different. Maybe the use case narrows. Maybe the strongest value appears somewhere you considered secondary. Maybe the price turns out not to be the objection you expected.

Maybe people understand the product but do not trust the implementation. Maybe the market tells you something more annoying: the existing alternative is good enough.

A mature engineering organization expects a system to change as it encounters production. We monitor it because the world around the code is messy. Traffic changes. Dependencies fail. Users behave differently from test scripts. Data arrives in forms that seemed improbable right up until somebody uploaded it.

Commercially, we sometimes become less sophisticated. We launch the business thesis once and expect it to be correct. I do not think it deserves that confidence.

The first theory about the market is architecture before production. It may be thoughtful. It may be based on interviews, experience, research, and a genuinely good understanding of the problem. That makes it better than guessing.

It is still a theory. The market is where it gets load tested.

The analogy has limits. I do not want to reduce buyers to packets moving through a funnel diagram. Human decisions are more complicated than that, and treating them as engineering objects can create its own kind of stupidity.

But one engineering instinct does transfer cleanly: when reality behaves differently from the model, reality wins. You do not argue with the production logs because the architecture diagram was excellent. You update your understanding of the system.

Markets deserve the same humility.

This is also why the commercial side never becomes “finished” in quite the same way as the product release. Even a healthy business keeps learning. Competitors move. Customers change. New segments appear. Channels weaken. Prices that once worked stop fitting. A trusted partner can create a new path to buyers. A once-important feature becomes expected table stakes. A small use case grows into the primary reason customers buy.

The business you eventually discover may not be the business you thought you launched. That is not necessarily evidence that the original idea was foolish. It is often evidence that the market contributed information you could not manufacture alone. Shipping matters because it changes the quality of that information. Before shipping, buyers can react to your description of the product. After shipping, they can react to the thing itself.

Launch Creates Access to Evidence

Before a product exists, people are mostly reacting to an idea.

You can describe the workflow. You can show a mockup. You can walk through a prototype. You can explain how much time the application should save, what it will automate, what the output will look like, and why you think the current way of doing the work is unnecessarily painful.

Those conversations are useful. I would much rather have them than spend six months building in total isolation.

But there is a limit to what someone can tell you about a purchase they have not actually had the opportunity to make.

A person looking at a prototype can imagine themselves using it. They can imagine the problem disappearing. They can imagine the budget being available, the implementation going smoothly, their coworkers cooperating, the integration working, the output being trustworthy, and the product fitting neatly into the rest of their work.

Imagination is unusually good at removing friction. The real product puts some of it back.

Once the application is live, the buyer has to encounter the actual experience. The signup process takes however long it really takes. The data has to connect. The output has to make sense. The pricing page contains an actual number. The security concern is no longer theoretical. The buyer has to decide whether setting this up is worth interrupting whatever they were doing before you appeared.

This is why shipping creates such an important change in the quality of commercial evidence. Before launch, you can ask, “Would you use this?” After launch, you can observe whether they do. Before launch, you can ask whether the price seems reasonable. After launch, you can see whether anyone accepts it.

Before launch, someone can tell you the product would save them hours. After launch, you can find out whether saving those hours matters enough for them to change a workflow, involve a manager, connect their data, schedule an evaluation, or spend money. The difference is not that people become more honest after launch.

The situation becomes more honest.

That distinction matters because I do not think most weak pre-launch signals come from people deliberately misleading founders. If I show someone an application concept that appears useful and ask whether they would use it, they may sincerely believe the answer is yes. At that moment, the decision costs them almost nothing.

Then the product becomes real, and so do the tradeoffs. Using it requires ten minutes of setup. Or access to data they do not control. Or a conversation with IT. Or $79 a month.

Or telling their team to change a process that, while annoying, has survived quite happily for four years. Suddenly the original answer has competition.

That is useful information.

It is also why I resist the idea that launching is mainly a distribution event. Distribution matters, obviously. A product nobody encounters cannot teach you very much about buyers. But the deeper value of launch is that it converts certain hypothetical questions into behavioral ones.

The product can finally be chosen. Ignored. Tried. Abandoned. Compared.

Rejected. Purchased. Those verbs contain more information than “liked.”

Suppose you have been developing an application for independent consultants. Before launch, fifteen consultants tell you the concept sounds useful. Several ask when it will be available. Two recommend features. One tells you they have been looking for something exactly like it.

That is encouraging. Ship it.

Now imagine that twelve of the fifteen create accounts. Eight complete onboarding. Six use the central feature. Three use it repeatedly. Nobody upgrades when asked to pay.

The launch did not erase the earlier evidence. Those conversations still told you something. The signups tell you something more. The repeated use tells you something else.

And the absence of payment tells you something else again. The mistake would be compressing the entire sequence into either “people want it” or “people don’t want it.” The market has given you a richer set of observations than that. Your job is to preserve the distinctions. I think of launch as opening new instrumentation.

Before the product is available, you may have interviews, surveys, prototypes, competitive research, perhaps letters of intent or other commitments if you have done particularly strong pre-launch work. After launch, another layer of behavior becomes observable.

Which promise gets someone to click? Which buyer actually starts? Where do people stop? Which capability gets used? Who comes back?

What questions appear before purchase? What objections appear after a real demonstration? What happens when the price becomes concrete? Who brings another person into the conversation? Who says, in effect, “This is useful, but not useful enough for what you are asking me to do”?

These observations do not all carry the same commercial weight. We will spend much more time separating them later because that distinction becomes critical.

For now, the important point is that shipping gives you access to evidence you could not obtain from the codebase and could only approximate through conversation. That makes the period immediately after launch enormously valuable. It also makes wasting that period surprisingly expensive.

If the application goes live and the founder’s only plan is “promote it,” a great deal of potentially useful buyer behavior can pass by without producing much learning. Traffic arrives. Some people sign up. Some disappear. A few send comments. The analytics dashboard accumulates numbers.

Then the founder asks the dashboard the question it was never designed to answer:

Why isn’t this a business yet? The useful post-launch questions have to be narrower. What did we expect this particular buyer to do? What did they actually do? Where did the behavior differ from our expectation?

What commercial belief should that result make us reconsider? You do not need enormous scale to begin asking those questions.

In fact, early on, small numbers can sometimes be easier to learn from because you can still investigate individual behavior. Ten prospective buyers can be ten actual conversations rather than a conversion percentage. You can ask why someone stopped, what they expected, what they compared you with, what made the setup feel worthwhile or not worthwhile, and what would have needed to be different for the decision to change.

Later, scale gives you different kinds of information. Early, proximity gives you detail. Use it. There will be plenty of time to build dashboards once you have enough customers to make the dashboards interesting. Shipping is the moment the product stops being only your argument about what should happen.

Other people can finally answer back. The commercial value of launch depends on whether you are prepared to listen closely enough to learn what their behavior is actually saying.

The New Milestone

For most builders, “launched” feels like a milestone because it is one. The trouble begins when we ask it to carry too much meaning.

A launch tells you the product is available. It tells you the technical work reached a point where people can encounter something real. It tells you the application crossed an important threshold from private construction to public consequence.

It does not tell you that the business works. So I think the milestone needs an upgrade.

Instead of asking, “Did we launch?” ask:

What did we learn after launch that changed a commercial decision?

That is a much higher standard. Maybe you learned that the buyer you targeted does not own the problem. Maybe you learned that the people who use the product most are not the people willing to pay. Maybe a price you assumed was too high created less resistance than expected. Maybe a feature you considered essential had almost no effect on the buying decision.

Maybe prospects repeatedly understood the value but would not proceed because the implementation felt risky. Maybe a small, unexpected segment behaved very differently from the larger audience you originally pursued. Those are milestones because they alter what you do next. The milestone is not the observation by itself. It is the combination of observation and changed decision.

That distinction matters because otherwise founders can accumulate enormous amounts of market information without allowing any of it to affect the business. They collect survey responses, analytics, comments, demo notes, support requests, campaign results, and user feedback while preserving the same buyer, same offer, same pricing assumptions, and same explanation for why sales have not appeared.

The market speaks. The founder takes notes. Nothing changes. That is not learning in the sense I care about. Commercial learning should have consequences.

If evidence changes your understanding of the buyer, targeting changes. If the problem appears weaker than expected, the problem hypothesis changes. If people value the product but refuse the offer, the offer gets examined. If they accept the offer but never reach the value, attention shifts into the product experience. If the wrong people keep arriving, distribution changes.

You should be able to point to the evidence and say, “Because we saw this, we stopped doing that and tried this instead.” That sentence is a better post-launch progress report than “traffic increased 37 percent” unless the traffic itself answered something important. This does not mean every week needs a revelation.

Some periods are simply execution. You may need to build what the evidence already justified, run the next batch of conversations, wait for enough behavior to accumulate, or continue a test long enough to learn anything from it.

Commercial learning is not a slot machine where every pull produces an insight. But over time, the business should become less dependent on assumptions. That is the direction I would watch. At launch, you may believe the buyer is a certain kind of company. Later, you know which companies actually engage seriously.

At launch, you may believe the main problem is time savings. Later, you discover buyers care more about missed deadlines, errors, labor cost, compliance risk, or something you barely emphasized. At launch, the price may be an educated guess. Later, real prospects have accepted, rejected, negotiated, ignored, or compared it. At launch, distribution may mean “we will post about it.”

Later, you understand which paths reliably create conversations with people who can actually buy. The business becomes more specific. That specificity is progress. I would rather hear a founder say, “We learned that our original buyer was wrong,” than, “We got 20,000 impressions.” The first sentence may sound like bad news.

It may save six months. This is where launch changes from a finish line into a starting line. The point of shipping is not merely to expose the product to more people. It is to expose your commercial assumptions to reality. That is a more demanding definition of progress because it means some of your best post-launch results will arrive disguised as disappointment.

The campaign that failed to generate sales may reveal that your intended buyer does not recognize the problem. The prospect who refuses the price may finally force a serious conversation about what the offer is worth. The user who keeps coming back without paying may expose the uncomfortable difference between utility and commercial value. The feature everyone requested may ship and change absolutely nothing. None of those feels as good as watching revenue go up.

Revenue is preferable. But before you know how to produce it reliably, the next best thing is evidence that makes the business less imaginary. That is the milestone I care about.

Not:

We launched.

But:

We learned something the business could not afford to keep guessing about.

And once the product is live, the easiest thing to do is start counting whatever the software makes easy to count. Visitors. Accounts. Downloads. Sessions.

Active users. Feature requests. Time in the app. Those numbers can be useful. They can also create the next mistake almost immediately.

Because the moment people begin using the product, builders start calling them customers. They are not necessarily the same thing.