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 4 of 5
“We were pre-seed investors in Supabase which I think the company's done an incredible job of really leaning into what's happening in AI... the speed at which they ship features, they ship a new feature every single day and so they I think they set the bar for what product velocity should look like.”
Supabase Ships A Feature Every Day — That Velocity Is The Bar For Product Teams Now
Jeff's biggest portfolio win highlight is Supabase — not just for the category dominance, but for the velocity standard they've set. A new feature every single day. He frames this as the new bar every product team should measure itself against, calling out that founders who overthink before shipping are losing ground as markets move faster than ever.
“the first thing you're going to do is turn that into a Twitter thread and we're going to think about what is the main headline what's the interesting hook... if you're working on a feature and it doesn't make for a good Twitter thread you better have like a really good reason to be building it”
Write the Twitter thread before writing the code
ElevenLabs requires every new feature to be distilled into a Twitter thread before a line of code is written. If you cannot write a compelling hook and three sub-tweets about what you are building, you do not yet understand why it matters and users will not either. This acts as a pre-build virality test that filters out features too incremental to earn attention and forces clarity on the core value proposition.
“speed is becoming the moat right and I think that we kind of live by that... when small teams with driven product-minded engineers and founders fit together with this go fast and ship move then that's where you really start to get harmony and you can deliver bigger results”
Speed is the moat: small teams plus founder-mindset engineers compound their edge
ElevenLabs' competitive edge is not just the voice model but the organizational structure that lets them ship improvements faster than any competitor can respond. Small teams, founder-mindset engineers, and a culture where speed is the explicit guiding principle combine into a compounding advantage: the company that learns fastest wins, and learning speed is a direct function of ship cadence. In AI, a quarter of stagnation can cost market leadership.
“we actually ripped out all the localization infrastructure we built our own GitHub action and there's like a thin library which just extracts the strings or wraps all the strings and then each time we make a PR to our repo it just sends it with like a prompt per language about the localization guide and that means we're able to localize like way cheaper and much faster”
Replace expensive localization SaaS with a GitHub Action and LLM prompts
ElevenLabs was paying an agency and an expensive SaaS for localization until engineers noticed that ChatGPT consistently produced better translations. They replaced everything with a GitHub Action: on every PR, a thin wrapper extracts strings and sends them through a per-language LLM prompt. The result is faster, cheaper, and more natural-sounding copy — making full localization of ads and app store listings practical for any team.
“We don't have like a tightly coupled spec where we want to release everything at the same time for all platforms... if you really tie them together you don't make like big steps. We try to have some flexibility to make sure we move fast because that's the key to success for a startup.”
Don't Tie Both Legs Together — Platforms Need Different Release Cadences To Let Startups Move Fast
Photoroom runs iOS, Android, and web as loosely-coupled tracks rather than releasing all three in lockstep. Synchronizing everything adds planning overhead and slows down each individual platform. The analogy Matt uses: if you tie two legs together, you can't take big strides. Allowing platforms to release on their own cadence — with some experiments running earlier on whichever platform makes them easier to measure — preserves startup velocity.
“Do we have this algorithm... for these five countries? Let's just launch it. For the rest we can build over time. We could be wrong — in which case we iterate and get it right.”
Ship Features in Small Country-Scoped Batches via Feature Flags Before Global Rollout
When Super Unlimited rebuilt its server-selection algorithm, they resisted the urge to launch globally at once. Instead they used feature flags to ship to five countries first, accepted the risk of being wrong, and iterated before expanding. Tanuj calls this 'doing it in smaller chunks rather than building a big massive Taj Mahal and launching it' — a philosophy that applies to any complex feature where a bad rollout would affect tens of millions of users simultaneously.
“Once you've tested that in a few different ways you can also use emails for this if you've got a good size email base you can test with push notifications you can test this in different ways once I start to get confident of like hey we're consistently seeing this win that's when I start to test integrating it step by step.”
Confirm Messaging Signal Across Multiple Channels Before Hardcoding It Into the App
A messaging winner in one channel might be an artifact of that channel's audience or format. Daphne's rule: confirm the signal in at least two channels (e.g. Meta ads + email or push) before integrating the message into onboarding, paywalls, or app store copy. Consistent wins across independent channels give the confidence needed to invest in full product integration.
“I honestly think the MVP not just in our category but I'd say most categories the whole concept of it is rarely applicable... the viable part might actually take a little more time these days than it ever has in the past.”
The Viable Bar in MVP Has Never Been Higher — Plan More Time, Not Less
When smartphone apps were new, curiosity drove downloads and a rough MVP could find an audience. Now people install fewer than 10 new apps a year and are set in their habits — so competing in any mature category means the product must be genuinely complete before expecting anyone to switch. Val spent years building Monarch's data-cleansing intelligence layer before launching publicly because in personal finance that infrastructure was table stakes, not a v2 feature.
“the big launch philosophy has been one of like the great mistakes of my career... for me it's definitely fear right is like oh I don't want to... I'm not going to show this to the world because I need this one little extra thing otherwise people are going to ignore me.”
Holding Features for a Big Launch Is Fear Dressed Up as Strategy
David spent four years bundling Weather Up 3.0 features — Apple Watch app, widgets, interactive widgets — waiting until it felt big enough to launch. What felt like strategic packaging was really delay rationalized as planning. During that time downloads dropped to 15 a day, the app fell out of Apple feature rotations, and he was funding it personally. The subscription model removed every incentive to hold features back; he just never updated his mental model to match.
“things really dropped off the map like apple stopped featuring the app because it hadn't been updated in a while we stopped getting any kind of bumps from these new updates... downloads were at low double digits a day like 15 downloads a day.”
Not Shipping Is Compounding Harm — Stale Apps Fall Out of Features and Lose Organic Momentum
Between 2019 and Weather Up 3.0, David withheld updates for four years while working toward the big launch. The compounding cost was invisible until it was not: Apple editorial stopped featuring the app, organic discovery dried up, revenue fell below costs, and he was personally funding the deficit. Each month of non-shipping is not neutral — it is actively losing ground in editorial algorithms, press relationships, and user momentum.
“I can do something faster than anyone else not necessarily because there's something magic about me but it's just there's no… sprint planning meeting, no breaking up the features — I just open up Xcode and start working.”
Solo Dev Speed Advantage: No Coordination Overhead
The single most underrated advantage of a solo developer is elimination of coordination costs. David can go from idea to shipped code in days; a five-person team needs meetings, specs, and handoffs that can take weeks for the same output. That speed matters most at the moment a new platform API is released — where being first captures outsized attention.
“From the very first week on the App Store until today we've released one app version every single week on Monday. By Thursday you're like let's get something in because I want to see the number change next week.”
Weekly Shipping Cadence Creates the Iteration Rhythm That Makes 121 Tests Possible
Opal shipped a new app version every Monday without exception, from launch through $5M ARR and beyond. This cadence created a natural experiment loop: change something Monday, measure the effect by the following Tuesday when day-8 cohort data lands. Without this discipline, 121 A/B tests in the same period would have been impossible.
“if you can get people excited about a crappy app it's not going to be scalable right because it's crappy... but if you can get people actually using it despite all and that's the hidden secret of launching an MVP.”
A Crappy App That Gets Used Proves Market Pull — A Pretty App Might Just Attract Looks
Adam shipped an embarrassingly bare-bones iOS wrapper — just the map, nothing else. But people kept opening it. That signal matters more than polish: if users tolerate bugs to access your core value, you have product-market pull worth investing in. Build a beautiful app and you risk attracting curiosity rather than genuine demand. The MVP's job is to expose that one rare insight, not to impress.
“projects in progress don't do anything for your business they only start to do something for your business when they go out the door so if you have big projects kind of like chunking them up into milestones so you ship things incrementally and start to slowly test assumptions goes a long way”
Projects In Progress Don't Move The Needle — Only Shipped Features Do
Dan's core product management insight after years scaling Codeacademy: the feeling of being busy — full project tracker, multiple things in parallel — is completely decoupled from business results. A backlog of in-progress work produces zero revenue until it ships. The remedy is aggressive milestone chunking so that something goes out the door continuously, test assumptions accumulate, and the team gets signal instead of just staying busy.
“the biggest wins we found were always like the third or fourth swing at something because you ship something you realize it doesn't work and if you move on immediately then unless you were completely off base it doesn't work”
Your Biggest Product Wins Come On The Third Or Fourth Attempt At The Same Problem
Dan's repeated experience at Codeacademy: the first and second attempt at any meaningful product problem rarely land. Engineers need time to learn the codebase area; designers need to internalize the nuances; the team needs to build intuition. The teams that win are the ones that stay focused on a problem long enough to take three or four shots — and look for 'signs of life' in test variants rather than declaring failure and moving on.
“I think I fell into every like developer trope where there was like feature creep there was working on like too many features instead of bugs... by some luck stroke of luck it came together and released.”
Every developer falls into feature creep — ship the buggy version, fix after
Apollo took a year and a half longer than it should have because Christian kept adding features instead of shipping. The same trap captures most solo developers. The fix is external pressure: a beta community demanding release, a public ship date, or just the discipline to declare the current build good enough and go.
“Within our premium subscriptions we run over a thousand AB tests a year we essentially test anything that we would launch into market uh whether it's a new feature a new layout a new way to talk about kind of the value that we provide it would all go through an AB test process.”
Run 1,000+ A/B tests per year — maximize learning speed by minimizing internal debate
LinkedIn Premium runs 3+ tests per working day across features, layouts, paywall copy, and value messaging. Levit's philosophy: time spent debating internally is worse than time spent getting signal from actual members. The bottoms-up structure means each PM owns their domain and drives tests independently — no central committee approving experiments. Speed of iteration beats quality of internal debate.
“We moved the paywall before onboarding and added a video of the actual app experience. Trial conversion went up 80%. Install-to-paywall rate went from 40% to 85%. Nothing about the actual product changed.”
Paywall before onboarding + app video lifted trial conversion 80% with zero product change
Moore's team ran this experiment on Fitness AI, a workout app. Moving the paywall to before the onboarding flow (standard industry practice had been to onboard first) and swapping a static screenshot paywall for one with an in-app video produced an 80% lift in trial conversion. The insight: users who haven't yet experienced the product need to be shown the product — video does that better than screenshots or feature bullets.
“When you go into App Store Connect you can have one set of iPhone screenshots per language and then one set of iPad screenshots per language — just massively reduced complexity. I can't tell you how many times I tried to submit and it's like you didn't do this and I'm like did what.”
Screenshot requirements cut to one set per language — a long-overdue relief that frees significant release time
Previously, submitting an App Store update required separate screenshot sets for multiple iPhone screen sizes across every supported language — a multi-hour workflow for localized apps. Collapsing to one set per device class per language removes one of the most tedious production taxes on shipping. Developers who managed screenshots manually will see significant release velocity gains.
“In certain categories like weather there are tons of people who actively check two or three different weather apps. Part of my decision making in leaving those out was that people are still going to probably check other weather apps — but if I can create one thing that's so delightful that they're willing to pay for my app, they're still going to come back.”
Must-haves vs delighters: sometimes shipping the delighter first builds enough trust to fill the musts later
Paloni and host David Barnard discuss the strategic choice to ship delighters before fulfilling all category must-haves. Barnard's weather app launched without features users expected but with an extraordinarily delightful interactive widget that no other weather app had. The delight generated enough paying subscribers and word of mouth to fund filling in the musts. Paloni's framework: must-haves keep users from leaving, but delighters bring them in and create advocates. In crowded categories with multi-app behavior, one outrageous delight can justify the subscription even alongside competitor apps.
“what's the impact of this decision how does the entire repo and the community of developers at large benefit from this change it can't be well I like doing it this way or it can't be well it compiles faster okay what is faster about three milliseconds like I don't care”
Filter every PR with: 'how does the whole community benefit?'
Josh's filter for contributor PRs is a single question: 'tangible benefit to everyone?' Preference-based arguments and bikeshed wins (3ms faster compile) get killed fast. As a solo founder shipping in public, the same filter applies to internal debate: stop optimizing the codebase for an imaginary future team and just make the call. The market doesn't reward elegant abstractions on an unlaunched product.
“I placed probably 10 different small bets in 2022 and I made money I wasn't eating Ramen I was eating steak a couple of courses a cohort course a couple of recorded courses a book all these things I did in 2022 I started a newsletter I started a podcast”
Trade one big bet for ten small ones a year
Louie had been eating ramen on VC money trying to build one SaaS. The mindset shift: stop betting everything on one idea. In 2022 he shipped roughly 10 small bets — cohort course, recorded courses, a book, a newsletter, a podcast — and made enough to stop eating ramen. Diversification across cheap shots beats betting it all on one swing.
“try to time box it uh if you're spending six months a year I don't tend to like those small bets even though you know people call them small bets every one of those things if I can't layer it into a small bet where I could do it in a week or two then then I'm not going to do it”
If it doesn't ship in two weeks, it isn't a small bet — it's a risk
The rule that keeps a portfolio actually small: if a bet can't ship in roughly one to two weeks, kill it before starting. Six-month 'small bets' aren't small — they're risk. The recent free-preview feature on smallbets.com took two weeks and converted 4% of traffic to email. Two-week ceilings force the scope cuts that make the whole portfolio work.
“do you have a time limit for this like if a product that doesn't like how long do you work on a product before you think okay maybe it's time to Pivot to something else so there are different stages um in the last year it would be maximum one month I'll never spend more than a month on it”
One-month ship ceiling — never grind past 30 days on a fresh idea
Hard cap: one month from idea to live. Anything longer means burning runway on something the market hasn't asked for. The exception only kicks in once a product has pre-validation — visible questions, feedback, inbound emails — proving demand already exists before deeper investment.
“I spent probably a week Gathering the code making a little documentation and I push it live before going on holiday to Hong Kong and then I just woke up to the lunch and at the time I was making maybe 3 to 4,000 a month and I would wake up to the launch with something like 3K already made within 2 hours”
Extract the boilerplate from your own 15-product pile
After 15 products of repeating the same setup — landing page, domain, payments, support — Marc spent one week packaging it as a boilerplate and shipped it before flying to Hong Kong. Woke up to $3k in two hours, nearly his previous monthly total. Solving his own repeated pain was the entire validation.
“you need to get more scientific with something that's going to be in production and that could be as simple as you know just running that prompt like 30 times um and then pasting it into Google doc right um and and then just reviewing like okay like how often does it do bad things”
Run the prompt 100 times in async, then review the failures
Running a prompt once and shipping it is the prompt-engineering equivalent of medieval bloodletting — a lucky hit mistaken for a working system. Before any prompt goes into production, run it 30-100 times asynchronously, dump outputs into a doc, and cluster the failures. Bulk review surfaces real failure modes instead of the one good output that tricked you.
“it is almost impossible to build a real business without that so you really need to understand your customers because what you I see I have some friends who who are building a product and they want to launch it in the building feature after feature after feature before launch they don't even know who's going to use the product”
Launch barely-working software early, then let users move the product
Klemke pushes back on founders stockpiling features pre-launch. The play: ship as early as possible with barely-enough functionality, then talk to as many users as possible and let those conversations move the product. Real customer understanding beats guessing in private — and the only way to get it is to have users.
“we launched Breeze do which is a docy sign alternative and it's already on track to be a seven figure business in 12 months but that's the within our Originals team I think that's our 10th product we've launched in 10 years and only the third third or fourth one that's actually worked significantly”
Ship ten products to get three or four hits
Even Noah's internal product team — with AppSumo's distribution behind it — ships 10 products to get 3-4 hits. Stop expecting product #1 to land; plan a portfolio. The compounding only kicks in if the next launch happens, no matter how the last one went. The product that hits is usually the one you almost didn't make.
“you can't really be super Indie hacker about it you can't just make the first version really crappy and put it out into the world it's got millions of followers worth of brand tied to it so it has to be good so if you usually can launch at like a five out of 10 quality you kind of need to be hitting a seven or an eight before you can even be out the door”
Creator-backed launches can't ship at indie-hacker quality
When a launch is tied to a creator's brand of millions of followers, the usual scrappy 5/10 MVP doesn't fly — the quality bar moves to a 7 or 8 before going public. Design investment up front becomes non-negotiable. The trade: less iteration speed in exchange for borrowed brand trust.
“you have to be perfect to learn that Perfection is a not the right way I used to be like very very very minic about like let's do this in the right way and spend a lot of time tinkering not shipping so I learned the hard way by failing and taking the shot hitting the rock bottom”
Pursue perfection once so you can permanently abandon it
Counterintuitive: try being a perfectionist long enough to hit rock bottom from it. Sharath spent years tinkering instead of shipping, and only after failing that way did he internalize that putting incomplete work out — typos, grammar mistakes, amateur tweets — is the actual path. The rules come first; the jazz comes after step 10.