Most products launch with a “v1” — a simplified version that’s “good enough for now.” The plan is always to iterate toward the real thing. The problem is, the real thing never ships. The v1 becomes the product, and the product becomes a compromise.
At Jobsly, we don’t ship v1s. We ship the end state. It takes longer to get to launch, but what we launch is what we believe the product should be.
This philosophy is controversial. The startup world worships speed. Ship fast, learn fast, iterate fast. And for many problems, that’s exactly right. But for some problems — the ones where the user experience depends on getting the core model right — speed kills. Here’s how we think about it.
Why v1s are dangerous
A v1 creates a mental model in your users' heads. Once they learn the simplified version, every change feels like a disruption. You end up designing around the constraints of your own compromises.
Worse, v1s create technical debt that makes the end state harder to reach. You build abstractions around the wrong model. You optimize for the wrong workflows. And you accumulate users who depend on the simplified version.
We’ve seen this pattern at every company we’ve worked with. The migration from v1 to v2 is always harder than building v2 from scratch would have been. But by the time you realize that, you have users on v1 who can’t be disrupted, investors who want growth not rewrites, and a team that’s emotionally attached to the code they’ve already written.
The v1 becomes an anchor. Every decision is constrained by “but that would break v1.” You end up with a Frankenstein product: the v1 model with v2 features bolted on top. It works, technically. But it never feels right. The seams show.
What “end state” means
We don’t mean “finished.” Software is never finished. We mean the right model. The right interaction pattern. The right core architecture. The things that are expensive to change later.
For Jobsly, the end state was conversational hiring. Not a dashboard with a chatbot added on. Not a traditional ATS with AI features. A fundamentally conversational product where the primary interface is talking to Rob. That was the end state, and we shipped it from day one.
Could we have launched faster with a dashboard and added the conversational layer later? Absolutely. But then we’d have users who learned the dashboard model. Migrating them to a conversational model would have been a product transformation, not an iteration. That’s the kind of change that kills startups.
How we ship the end state
We spend more time in design and prototyping. We argue about the right model before we write code. And when we disagree, we prototype both versions and test them with real users.
This means our launch timeline is longer than most startups. But our post-launch timeline is shorter. We don’t spend months migrating users from v1 to v2. We ship the thing we believe in and iterate from a strong foundation.
Our design process for a new feature typically looks like this: one week of problem definition, one week of exploration (3–5 different approaches), one week of prototyping the top two approaches, one week of testing with users, and then we build. The building is the shortest phase because by the time we start writing code, we know exactly what we’re building.
This isn’t waterfall. We’re not writing specs and throwing them over the wall. The whole team is involved in every phase. Engineers are in the design sessions. Designers are in the user testing. Everyone has context. Everyone has opinions. The result is a shared understanding of the end state that makes execution fast and precise.
When this approach doesn’t work
We’re not dogmatic. There are cases where shipping fast and iterating is the right call. If you’re testing whether a market exists, ship the simplest thing possible and see if people pay for it. If you’re building a feature that’s additive and doesn’t change the core model, move fast.
The end-state approach matters most when you’re defining the core interaction model. How do users fundamentally interact with your product? What is the primary workflow? What’s the mental model you’re asking them to adopt? These decisions are the ones worth getting right before you ship, because they’re the ones that are hardest to change later.
For features that sit on top of the core model, we iterate like everyone else. We ship, we measure, we improve. The end-state discipline is reserved for the foundation, not the furniture.
The results
Since launching with the end-state model, we’ve had zero major product pivots. Our core architecture has remained stable through 18 months of growth and feature development. We’ve added capabilities without changing the fundamental interaction model.
Our NPS is 78, which we attribute partly to product stability. Users don’t experience the lurching, disruptive changes that characterize products in perpetual beta. The product they signed up for is the product they use every day.
We’ve also found that the end-state approach attracts a certain kind of team member: people who care about craft, who want to get things right, who find satisfaction in building something that will last. That’s the team we want. And the philosophy is part of how we find them.