Shipping Playbooks
Tactics for getting to a working product fast — scoping the first version, cutting features, and shipping before it feels ready. Drawn from founders who talk candidly about how they actually build and ship.
139 tactics · page 3 of 5
“Our first MVP was just two weeks of work. I closed basically the first 100 customers doing live demos and outbound. I did only this. On top of it, the first customers I was onboarding I would tell them you know what, buy the software subscription and I will myself write the campaigns for you, and in exchange I would also ask them if they want to be part of the content I create as success stories.”
Two-Week MVP, Then Close Your First 100 Customers Via Live Demos And Outbound
Guillaume shipped lemlist's first version in two weeks and personally closed the first 100 customers through live demos and outbound. He even wrote their campaigns by hand in exchange for the right to turn them into public success stories.
“this Manifesto this little piece of paper right here it did one thing it forced me to get started and getting started even in the tiniest way taught me something that would change everything failure is success when I finally gave myself permission to fail it unlocked the answer”
Permission To Fail Is What Finally Unlocks Shipping The Tiniest Thing
Pat's obsession with control and fear of failure kept him from ever starting. Writing a one-card manifesto forced him into the smallest possible action, and giving himself permission to fail was what finally unlocked execution.
“when we first launched we were working at Hulu and Sony Music respectively for Kent for like a year and a half the first 4,000 lb of gum was sitting in Kent's apartment we didn't have a warehouse like Kent's apartment in downtown La was the warehouse and we'd ship 4,000 lb of gum going to USPS every day”
Run Fulfillment From Your Apartment Until You Outgrow It
For the first year and a half, Ryan and Kent kept their day jobs and ran shipping out of Kent's downtown LA apartment. Four thousand pounds of gum lived in the apartment-turned-warehouse and went out to USPS every day.
“I basically started taking what I thought would be helpful and I started drawing it out in a notebook and I was thinking about the way I wanted the information to be presented... I taught myself how to basically create them as wireframes in Photoshop and Illustrator and then I went to an agency and I could not afford to work with the agency... then at one point a student developer said that he would love to work with me and so that's how I was able to finally launch that first MVP.”
Notebook Sketches → Photoshop Wireframes → A Student Developer = MVP
With no technical background, Anya sketched flows in a notebook, taught herself Photoshop and Illustrator to turn them into wireframes, and after being priced out by an agency, partnered with a student developer to ship Rooted. Doing the design and content prep upfront meant the build itself only took a few months.
“my first MVP it had like basically just one feature which was click on a button here and a timer starts counting over there I'm use all the technologies I already know I use JavaScript I use Vue.js I use NodeJS... if I would have used new unknown technologies I would have had to learn them understand them find out they have limitations I didn't know before and it was good because I could I could ship my MVP in 3 days”
Ship The MVP In 3 Days By Using Only Tech You Already Know
Lucas built the first version of Stage Timer in three days by deliberately sticking to JavaScript, Vue.js, and Node.js — tools he already knew. He skipped trendy new tech because learning unknowns would have cost weeks of side-project evenings.
“Nowadays everyone would just vibe coded on a weekend but for me it took 6 years. So for me it was, I guess, a marathon and not just a vibe coding weekend.”
A Side Project Is A Six-Year Marathon, Not A Vibe-Coding Weekend
Chris started building Wishlist in 2019, shipped the first version in 2020, relaunched as 2.0 in 2023, and only quit his job in 2025. He frames realistic side-project timelines as a multi-year marathon rather than a weekend sprint.
“Late is a social media API. What we do is wrap around the official APIs Facebook Instagram Twitter LinkedIn. We go through all the platform permissions, we uh basically pay for the highest plans so that you have access to the uh all the features available and uh we hand it to you in a single API.”
Ship A Single Developer-Friendly API That Wraps Every Platform Underneath
Mickey shipped Late as a single unified wrapper around the official Facebook, Instagram, Twitter, and LinkedIn APIs. He paid for the highest-tier plans and handled the platform permissions himself so developers could access every feature through one API.
“We really wanted to scope it down and launch something quickly and basic and I would say we achieved that and it like sort of worked when we launched — there was plenty of audio recordings getting lost and things like that.”
Ship the MVP with bugs — basic and broken beats polished and late
The April 2024 launch shipped with known reliability bugs — audio recordings actually getting lost — but Brett prioritized launching basic over launching polished. Much of what's in the product today looks like that scrappy v1; the alternative was missing the AI note-taking window entirely.
“We had a free trial from day one but we were in effect charging from day one. There's nothing quite like the dopamine high of realizing you're creating something valuable to the world and people are returning. You captured some of it right — it's hard to debate something is being done.”
Charge from day one — paid conversions are the only unambiguous signal
Zack insisted on real revenue from launch instead of free-tier vanity metrics. Mixpanel events can be gamed or noisy, but paid conversions are unambiguous proof of value — and the dopamine loop kept both founders building hard.
“At Elevate before we even launched we had an Android app — it was great because we could release a new version every week and do a beta list. We curated a list, we measured each cohort. We weren't A/B testing — we just watched and iterated on the app until we felt like that number was pretty good, and then we launched.”
Iterate weekly on Android beta cohorts before you ever launch (Elevate)
Pre-launch, Elevate shipped a weekly Android beta to a curated TestFlight list and watched raw cohort numbers like signups and activations. No A/B testing, no heavy tracking — just iterating until the funnel looked healthy before going public. Big swings, obvious results.
“We specifically for our app wanted to solve the retention piece first. We chose the behavior in the app that would be associated with retention. Our whole app is like a water reminder app right now — we built that specific functionality before anything else.”
Ship the one retention-driving behavior first — water reminders
Instead of broad feature scope, Greg shipped one core retention behavior first — push-notification water reminders — because that was the behavior most likely to bring users back over six months. The team needed six months of retention data to fundraise, so they front-loaded the single feature that would generate that signal.
“There's a typical model where a consumer gets unlimited access to a limited amount of features. There's another model — the New York Times model — where you get limited access to features. After your third time using these features you're no longer allowed. There are pros and cons to both. Ultimately I'm a bigger fan of not limiting engagement.”
Two freemium MVP architectures — unlimited of some vs metered of many
Paul breaks freemium into two canonical scoping choices: gate by feature (unlimited use of a small free set) or gate by usage (metered access to a wider set). He prefers the feature-gate because high free engagement creates more in-product touchpoints to message and convert later.
“Product people, marketing people are scoping things out on Lovable and getting a spec or a new idea approved in like a day, where previously they would have to loop in a bunch of engineers and it would take weeks.”
Product/marketing people now scope a spec on Lovable in a day, not weeks
Non-engineers now scope and validate ideas in Lovable or Cursor in a day instead of looping engineers for weeks. The bottleneck has moved off the eng team, and PMs/marketers can prove an idea end-to-end before anyone writes production code.
“Before I integrate it into all the messaging of the app itself I'll test it first. If you're running ads meta ads are great for this... I've literally tested very similar visuals with different messaging overlay on them... tested those against each other first on the job to be done level with a more general image that isn't skewing people too much.”
Pressure-test JTBD framings in Meta ads before touching in-app copy
Don't rewrite onboarding, paywall, or App Store copy on a hunch. Run cheap Meta ads with near-identical visuals but different JTBD messaging — click-through and cost-per-trial deltas tell you which framing wins before you spend cycles changing in-app surfaces. The visuals stay neutral so they don't bias the read.
“I've also right away used a usability hub to run 5-second tests with two messaging and ask people what their preference is and why and what stood out. That's also really really good in refining it because sometimes you use a word that just triggers people the wrong way or people don't understand what you mean.”
When CTR is too noisy, run UsabilityHub 5-second tests on the copy
Click-through rate doesn't always correlate with monetization, and small ad budgets produce noisy results. Run 5-second qualitative tests on UsabilityHub alongside CTR tests — they catch words that trigger people the wrong way or messaging that's trying to be too smart, which raw CTR can't explain.
“We had a button on the scan document that you would tap and shows an OCR text and after this refactoring we had moved this button in a drawer and was not directly visible and the effect on the paywall displays was like maybe like 10 20%... that's something I noticed after months.”
A buried OCR button silently cut paywall views ~15% for months
A UX cleanup hid the OCR entry point in a drawer, killing one of the main paywall trigger paths. Revenue dropped for months before they traced it back. Treat paywall-trigger surfaces as load-bearing UI — never tuck them behind a refactor without measuring impressions per trigger.
“The server went down — one of the reasons that we track taps on the banner and the integer on the database overflow... the fallback banner that was display most of the time so it was like an accidental AB test... the fallback banner was converting twice as much as the existing.”
Server crash → fallback banner accidentally doubled paywall conversion
A remote-server integer overflow forced the in-app fallback banner to render — and it doubled paywall conversions versus the live version. The text and icon were only slightly different. The lesson: hardcoded fallbacks are worth treating as real variants, and tiny copy/icon changes on a high-traffic surface can move revenue more than anyone's intuition predicts.
“They had their sort of thing they'll say is like one man three platforms four months was how they built their first version because they weren't even planning to build an app... Paul on their team didn't even have React experience and he just learned on the fly.”
Bluesky shipped one engineer, three platforms, four months
Bluesky had no iOS or Android developers and a tight timeline when they realized they needed a flagship app for their federated protocol. One engineer, Paul, learned React on the fly and shipped across web, iOS, and Android in four months. They still only have about three people working on the app today — a benchmark for what a focused crew can ship.
“If you can't, you have to really know what you want when you're [building]. If it's to make it worth it, even if there is some relative difficulty of working with the tools, like it can easily be wiped out by a small increase in iteration speed.”
Iteration speed beats native polish — you can't validate what you can't ship
Charlie's designer-engineer friend abandoned a polished Swift app because slow iteration made it impossible to discover whether features actually worked. Unless you already know exactly what you're building, faster feedback loops dominate any quality advantage from native tooling. Discovery requires speed, not perfection.
“A comparison of basic versus Pro Plan, this can be done for long scrollable screen or multiscreen paywall, and this is from Catarina who was at Mimo and she was mentioning that at Mimo the multiscreen option led to 60% increase in the trial opt-in rate.”
Multiscreen paywalls beat long-scroll: Mimo saw a 60% trial uplift
Long paywalls only get scrolled by explorers, and plans often fall below the fold. Breaking the same content into three or four sequenced screens lets each message land and keeps pricing visible. Especially effective for free-trial flows where each screen can explain day 2, day 5, etc. This is an easy A/B test against any existing long paywall.
“The conversion behavior of users during onboarding and post onboarding is different, so you probably want a different build for the two. When you AB test your paywall, separate the analysis between the onboarding paywall and the post onboarding paywalls.”
A/B test onboarding paywalls separately from post-onboarding paywalls
A free-vs-paid comparison chart can hurt the first paywall but help a later one shown after a user hits a gated feature — they already know free. Treating both contexts as one test averages out opposite effects, hiding the real signal. Caveat: ~80% of conversions happen on the day-one paywall, so this segmentation only pays off past roughly $100K/month.
“The first version of MySwimPro was simply to give someone a workout, as simple as that. You couldn't log it, there's no profile, there's no analytics, none of this stuff... we just iterated on it over and over and over.”
Ship the dumbest possible v1 — single feature, no profile, free for a year
V1 was a single feature: deliver a workout. No logging, no profile, no analytics, no Apple Watch. They charged nothing for the first year, just listened to the small group using it, and only added a $10/month tier in 2016. The MVP was small enough to ship, the free year was long enough to learn.
“We would get the same questions via email every single day... one day I was like you know what, I'm just going to make a video that explains this because I've had to copy and paste the macro basically, I'm telling the same people over and over the same thing. So I got up a whiteboard and I just explained swimming terminology.”
Whiteboard Wednesday started as support-email leverage, not a YouTube strategy
Whiteboard Wednesday started as pure leverage: instead of copy-pasting the same answer to seven users, film once and link it. The whole loop — concept, film, edit, blog, email — was a single-day Wednesday project for years before they ever hired help. Even at 7 views, the time math beat writing 7 emails. Compounded into millions of views.
“We originally used Greenlight like five years ago and it just wasn't there yet... and then recently I'm sitting at the pool with said fellow dad... I went and signed back up — like five years later I've been reacquired. It takes that long, it takes that long to build really great software. Five years to make a really great app.”
Five-year iteration: churned users come back when the app finally clicks
Greenlight bounced Crowley as a user on v1, then re-acquired him five years later via a peer recommendation. Don't expect a hit on launch, and don't read early churn as a death sentence. Churned users are not gone forever; if you keep iterating, your TAM includes a returning cohort that gets reacquired via word-of-mouth years later.
“Maybe you build a painted door app where you prove out that people are willing to pay for this and then you go build it.”
Painted-door MVPs: sell the promise before the tech exists
Cal AI shipped a product that didn't actually do what it promised, but distribution carried it until the team built the real tech. The lesson: in select categories a believable promise plus elite marketing can validate willingness-to-pay before the engineering exists. Run the painted-door, prove the conversion, then go build what you sold.
“they switched MMPs they didn't implement any events on the new MMP and the old MMP was still connected to meta they still had campaigns optimizing on meta”
MMP migration without re-implementing events silently breaks all ad optimization
A real case: a company migrated their MMP, forgot to implement conversion events on the new one, and left Meta campaigns running against stale signals from the old one — undetected for almost a month. The failure was silent because the attribution and media teams were siloed. This is a must-audit checklist item before any MMP switch.
“we couldn't just like start it from all the pay walls right because we have a lot of different paywall and then the same times that's very expensive to and it takes a lot of time and then effort to train the model to test the model so we start with something small so we test with couple features”
Roll out ML paywalls on a small feature subset first — full rollout is expensive and slow
Tinder scoped the initial ML paywall rollout to a handful of features rather than the full product catalog, reducing training cost and risk. The incremental approach let the team validate the model quality before expanding. The eventual multi-million-dollar lift came after proving the concept at small scale first.
“you click it and it breaks or you have made some graceful failure You should be able to do that on 100 people or 10 people and well then we're not going to get enough uh predictive power But I'm kind of okay and I paint a door that you get like 70% certainty”
Paint the door before you build the room
Before writing real code for a feature, show 100 users a button or screen for it, let them click through to a graceful failure, then survey them. A fake door to 100 people gives ~70% confidence on intent signal — enough to justify the real build or kill it. Hulls explicitly calls this the alternative to statistically-burdened percent rollouts: get the learning cheap, then commit.
“I actually think killing someone's battery is it's a one-way door not a two-way door... they will forever feel like you're killing the battery And we still have that from a few handfuls of battery bugs”
Battery drain is a one-way door — never fix it twice
At Life360, battery drain and location accuracy are treated as guilt-until-proven-innocent bugs worth chasing even when 80–90% of alerts turn out to be ghosts. The reasoning: a single real battery drain bug is irreversible — users never forgive it even after you fix it, and they churn permanently. Hulls identifies 'one-way door' bugs as a separate class from ordinary quality issues, warranting asymmetric paranoia and resource allocation.
“I already knew that I shouldn't develop this app for 12 months and then release it and then see that nobody really cares about it I just was disciplined enough to buckle down and then develop it in the first two months of my free year and then launch it”
Ship the first version in two months, not twelve
Sebastian built and shipped both Lift Bear and HabitKit in roughly two months each. His rule: don't develop in isolation for a year and then launch to nobody. Two months gives you a real signal — people show up or they don't — before you've sunk twelve months into an untested concept. Setting a hard two-month ship deadline also prevents scope creep and perfectionism from delaying the learning.