iPhone, not Apple Maps

Pulse is behind schedule. Not catastrophically — but enough that the date we told people is no longer the date, and we’ve decided to hold rather than cut.

We have design partners waiting. We have a waitlist that is genuinely real — not scraped, not incentivised, people who found us and asked. We could ship next week. Every instinct that startup culture has spent fifteen years installing says we should.

Holding feels wrong. It feels un-startup-like in a way that’s uncomfortable to write down publicly. So let me argue the other side properly first, because it deserves better than a strawman.

The case against us

Reid Hoffman’s line is the canonical version: if you are not embarrassed by the first version of your product, you’ve launched too late. The reasoning behind it is sound and it has been right far more often than it’s been wrong.

You do not know what your users need. You think you do. You are wrong in ways you cannot enumerate from inside the building, and the only reliable instrument for finding out is contact with reality. Every week you spend perfecting something is a week spent perfecting an assumption. Waitlists decay. Momentum is a real asset and it has a half-life. Competitors ship. And the founder who says we’re not ready yet is, statistically, more often afraid than right.

All of that is true. We contemplate it more than we’d like to admit, usually around 11pm. Are we paralysed by perfectionism? It’s the honest question and it deserves a real answer rather than a defensive one.

Here’s ours.

The iPhone was an incomplete product

It’s worth remembering how thin the first iPhone actually was. June 2007: no App Store. No third-party apps at all — Jobs told developers to write web pages. No copy and paste. No MMS. No video recording. EDGE, not 3G, in a market where competitors had shipped 3G years earlier. One carrier. Line up its spec sheet against a Nokia N95 — five-megapixel camera, video, GPS, 3G, removable battery, expandable storage, an app ecosystem — and the iPhone loses on almost every row. Line it up against a BlackBerry and it gives away the keyboard, the push email, the battery life, and the enterprise story that the entire professional market was buying on.

It was not a complete product. It was a narrow product where every single thing inside the narrow part was exact. Scrolling had inertia. The keyboard corrected you. Pinch-to-zoom worked the first time, every time, for everyone. You could hand it to someone who had never seen one and they would not get stuck.

Five years later, Apple shipped Maps.

Maps had the bigger feature list. It had turn-by-turn navigation, which Google Maps on iOS did not. On paper it was the upgrade. And it put towns in the wrong place, melted bridges in 3D, and routed people into the desert. Tim Cook published an open letter apologising and — extraordinarily — recommended that customers use competitors’ products in the meantime. The executive who owned it was gone within weeks.

Apple Maps didn’t fail the spec sheet. It failed the one job. You can be late on features. You cannot be wrong about where things are.

That’s the distinction we keep coming back to, and it’s the one the “ship embarrassed” advice tends to flatten. There are two entirely different ways to be incomplete:

• Feature-incomplete. The thing does less than you eventually want. Users notice, some of them wait, most of them forgive, and every gap is a roadmap item that makes them feel heard when you close it.
• Trust-incomplete. The thing does what it claims, unreliably. Users notice once, and the noticing is permanent.

The first is a launch strategy. The second is an obituary. Being embarrassed by your v1’s scope is healthy. Being embarrassed by its reliability is a different category of mistake wearing the same sentence.

Why this category punishes the second one harder

Two things about immigration practice make trust-incomplete unusually expensive, and both are go-to-market facts, not engineering ones.

The failure isn’t a bad user experience — it’s someone’s visa. If Pulse surfaces a deadline late, an application lapses. If a document doesn’t come back where it was filed, a submission goes in short. If an audit trail has a gap, a practitioner is exposed to their regulator with our logo on the screen. These aren’t degraded experiences that a patch on Thursday makes whole. Some of them are unrecoverable for a real family, and all of them are unrecoverable for the practitioner’s confidence in us. A consumer app that fails costs a session. This costs a case.

The market is small enough that reputation is the distribution channel. There are a few thousand registered agents in Australia and they are not strangers to each other. They share conference rooms, referral networks, and opinions — especially opinions about software, because most of them have already been burned by a CRM bolt-on that didn’t understand retention or the real shape of casework. In a market like this, a botched launch doesn’t cost you a cohort. It costs you the category, because the first ten principals who try you and get hurt will tell the next hundred, once, in a sentence, and that sentence will outlive whatever we fix.

There’s also no second at-bat on a sensible timeframe. Buying cycles here are annual. Switching costs are high — seven-year retention obligations mean migrating case data is a project, not a click. A principal who trials Pulse, gets burned, and reverts is not re-evaluating us next quarter. They’re re-evaluating us in two years, if at all, and the referral graph around them has already updated.

So the usual arithmetic inverts. In most markets, shipping early buys learning at the cost of a little polish. Here, shipping early buys the same learning at the cost of the exact asset the whole go-to-market runs on.

The counterargument we take most seriously

Not the momentum one. The learning one: you cannot know what’s wrong without contact with reality.

We agree completely. That’s precisely why we’re comfortable.

The reason “ship it and find out” is normally correct is that a pre-launch team has no other instrument for contact with reality. That’s the actual premise underneath the advice, and it’s the premise that doesn’t hold for us. My co-founder Naina runs the work-visa department at Visa Alliance — she is inside an operating agency every week, not adjacent to one. Three agencies are shaping the build. Our testing isn’t a theoretical simulation of what practitioners might do; it’s real users at a real client, doing real casework, on the actual product.

That’s how we know the sub-par version would make people pull their hair out. Not because we modelled it — because we watched it happen, in a room, to people whose Tuesday afternoon we’d just made worse. That’s the fast-feedback loop the orthodoxy is trying to get us. We already run it. We just run it without the blast radius of a public first impression, which means we get the learning and keep the asset. Given the choice, take both.

A two-month delay with reliable quality beats a fast knock-off. That’s not a philosophical preference. It’s what the last round of user testing told us, out loud.

So — perfectionism, or engineering?

Here’s the test we hold ourselves to, because “we have high standards” is what paralysis says about itself.

Perfectionism is a bar that moves. Engineering is a bar that’s written down. Ours is written down. The launch scope is narrow and fixed — we cut features to hold the date before we cut quality to hold it, and we’ve already done that cutting. The delay is bounded and dated, not open-ended. And the release criteria were defined before we were late, which is the part that matters: a bar set in advance can be met, whereas a bar set in the moment can always be raised one more time by a nervous founder at 11pm.

If we find ourselves adding a criterion after the fact, that’s the tell, and we’ve agreed to call it out loud when it happens.

The other half of the test: we’re delaying for defects users hit, not for things we merely want. Polish debt ships. Trust debt doesn’t. Every item on the list holding this release is in the second bucket, and when one turns out to be in the first we move it and go.

What launch day should feel like

Boring. Slightly disappointing on the spec sheet. A narrower product than the one in our heads, doing a smaller number of things, and doing every one of them exactly — so that a principal can hand it to a case manager who’s never seen it and they don’t get stuck.

That’s the iPhone shape. Ship less. Miss nothing.

Two months from now nobody will remember that we were late. If we ship the other thing, they’ll remember that for years — and in a profession this small, so will everyone they talk to.

We’ll be back here with a date. When it lands, it’ll be the boring one.