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 5 of 5
“when I feel like it's not fun anymore it's like becoming like a burden it feels like an obligation that's where you have to like stop that that that self-awareness it should be part of your DNA”
When fun becomes obligation, that's the kill signal
Sharath's shutdown framework is emotional, not metric-driven. Building Bluey was fun until it wasn't — the moment it started feeling like a burden, that was the signal to wind it down. Run a quarterly check: is this still fun, or has it become obligation? If yes, schedule the sunset within 30 days rather than letting the project rot.
“let me tell you the first MVP was garbage I mean when I tell you garbage it was the worst MVP you could ever imagine it would like crash every couple of hours but being in sales I was like I could still I could sell the hell out of this like I'm just gonna you need this in your life”
Ship the garbage MVP and sell the hell out of it
Spencer hired one developer, shipped an MVP that crashed every few hours, and pitched it anyway. Non-technical founders with a broken product who can sell out-ship polished engineers who treat marketing as someone else's job. The build-in-public crowd over-indexes on craft and under-indexes on selling.
“we have always remained very lean with the team and I think that's that's a part of what makes us go very fast um and have this this ability when we have an ID to just jump on the ID and and make it live instead of going through three levels of validation you know”
Lean team = skip the three-level validation gauntlet
Staying lean lets a solo operator skip 'three levels of validation' and ship an idea the moment it appears. Most experiments fade, but a few hit hard — Tweet Hunter's yearly LinkedIn/Twitter growth challenge tripled ARR from under $2M to nearly $7M in 18 months by shipping more features and free mini-tools instead of pre-vetting each one.
“there are a lot of housekeeping things you could sum them up under the term due diligence ready due diligence Readiness it starts with HR I don't know do the Freelancers have IP assignments do have people proper employment and freelancer contracts interestingly all of those things are stuff which you should do anyway on your path to growth”
Due-diligence readiness is just growth hygiene — start day one
Due diligence readiness isn't a step before selling; it's the same hygiene that supports growth. Separate accounts on day one, IP assignments on every freelancer contract, clean documentation. The list a buyer hands over is the same list a healthy operation already maintains — bootstrap with the assumption you'll sell.
“get used to upload in every video to a transcription tool like that and not releasing content before you have subtitles and transcripts in place I know this might sound overwhelming but it's the right thing to do because it will make you stand out compared to other creators”
Gate releases on subtitles and transcripts done
Make 'transcript and subtitles done' a non-negotiable line on your shipping checklist — nothing goes live without them. Free tools like AssemblyAI mean there's no excuse on cost or time. Creators who never miss this beat the ones who treat it as polish-later work, and the SEO/discoverability lift is a free bonus.
“instead of going straight into filming after a script I go through my entire script and annotate it with exactly what is going to happen on screen during each of those times whether that be b-roll or a visual or an or an animation or talking head footage”
Pre-edit the script with visual annotations
Insert a visual-annotation pass between script and camera: mark every line with the b-roll, animation, or graphic that will accompany it. Filming captures exactly the footage editing needs, you avoid "I wish I had b-roll of X" regrets, and the final cut is more dynamic. Front-loads the mental editing cost; turns the editing day into pure execution.
“choose a collection of things a collections of ideas that you can and want to live up to when you're presenting yourself online and consistently show up as that person you'll find that authenticity here is a consequence and not just a prerequisite”
Earn authenticity through consistency, not declaration
You don't start authentic and then post — you post consistently and authenticity gets retroactively assigned to you. Define the 3-5 ideas you'll show up for, then ship against them daily for a year before judging whether it's working. The label "authentic" is the byproduct of repetition, not the input you need before pressing publish.
“I'm very used to like iterative building and kind of this idea that you never actually finish anything... this whole idea of like it's a bit like I guess like making a movie where once it's done it's done”
Match shipping cadence to the medium
Book publishing is the inverse of SaaS — no A/B tests, no iteration, no immediate feedback loop. Budget for a multi-year process you can't tweak post-launch, and accept that the audience will be unpredictably broad. If you need the dopamine of weekly shipping, books will frustrate you. Pick the right cadence per medium instead of fighting it.
“long-term optimism for difficult projects is made out of short-term pessimism... if you internalize that right up front and you're like everything's going to go wrong and then you operate accordingly you often are going to frontload whatever work you have um and and if you do that enough at the small scale you're going to have compounding wins”
Front-load short-term pessimism for long-term optimism
Wake up assuming the day will go sideways and the hard task will get harder. That mild pessimism forces you to eat the frog before noon, so when the inevitable wrench arrives you're already two hours ahead. Plan in nested scales (day → week → month → quarter), and at every layer ask "what does this look like when everything goes wrong?" Compounded daily, this is how multi-year shipping survives reality.
“we asked ourselves like can we put this damn podcast completely on autopilot effort wise and we're like no the answer is no and and and and so we didn't stop it in like an official it's officially dead kind of a way we're just like it doesn't make sense now it doesn't feel good to pour resources into it when we don't think it's just from a business perspective”
Kill projects the business no longer needs
Productivity creep is the silent killer of focus: things you launched once keep eating energy long after they earn it. Apply a brutal test: can this run on autopilot? If no, and the business doesn't need it, stop shipping it — Indie Hackers killed their flagship podcast (a full day per week) even after landing Seth Godin. Loyalty to old launches is how founders run themselves instead of running the business.
“I'm going to give this one more shot but instead of writing on a Blog I'm going to write a daily Twitter thread every single day for 30 days and instead of publishing like on a Blog I'm going to put it out in Social where other people might be able to find it”
Force shipping with a 30-day public thread challenge
Stop writing into the void of a blog nobody reads. Commit publicly to 30 consecutive days of shipping on a social platform where the algorithm can find readers for you. The volume forces you past your bad early work, and one of those 30 shots is statistically likely to break through — the way Dickie's day-29 thread did after 27 days of crickets.
“I've been using Apple notes to write for a long time now because it's the only thing that intentionally doesn't have anything shiny that is going to go pull my attention away from doing the writing itself”
Draft in Apple Notes to remove shiny-tool friction
Stop pre-optimizing your Notion dashboard, Obsidian graph, or fancy writing app — that's procrastination wearing a productive mask. Use the plainest possible tool (Apple Notes works) so shipping the words is the only thing on screen. Tool-tweaking is the #1 excuse for not publishing.
“Apple rejected it like a million times because they don't really want you to give it medical advice and a lot of the features came off as that So once we worked around it and found out how other kind of similar apps were doing it we found you know the good spot where Apple was happy and they approved it”
Reframe medical-adjacent features to copy approved competitor language
If your app is in any health-adjacent space (peptides, supplements, dosing, fitness recovery), expect serial Apple rejections for "medical advice." Don't guess at fixes — load approved competitor apps in the App Store, copy their exact disclaimer language, feature naming ("tracking" / "research library" instead of "advice" / "recommendation"), and re-submit using that vocabulary. The line Apple draws is mostly about phrasing, not function.
“I found out that you can expedite Apple reviews if there's something major So we actually got one approved kind of quickly and then there was a bunch of issues So then I found out about this expedite review which then they would review it in like two hours instead of two days which kind of sped up our process”
Use Apple's expedited review to drop approval cycles from 2 days to 2 hours
When you're iterating through rejection loops, submit an Expedited App Review request at developer.apple.com — it collapses the standard 24-48 hour cycle to ~2 hours. That means 3-5 fix iterations per day instead of 1, turning a week-long approval slog into same-day launch. Reserve the expedite request for genuine blocker fixes so Apple keeps honoring them.
“you need to develop experimental confidence so just just post but with intention so I have a big problem with when people are like just start like just get started... if you post with intention then post whatever you want but pay attention to how does it feel how do I feel after I posted that is anybody responding what questions am I getting like have people asked me something that is making me realize I need to clarify something more”
Develop "experimental confidence" — post with intention, then refine
"Just ship" with no intention produces noise. "Don't ship until perfect" produces nothing. The middle is experimental confidence: every post has an explicit hypothesis (audience, angle, expected response), and after publishing you observe — what landed, what didn't, what follow-up questions surfaced. Post → observe → refine, on the same artifact. That feedback loop replaces perfectionism with iteration.
“The first version took around a week or two it was a web app that kind of just had the core features... it broke many times during the event but we were able to validate the core idea... after we validated with the web app we threw out the first version and that's because I honestly believe that consumer app is basically a craft”
Ship a throwaway web validation harness, then rebuild native from scratch
Even if you're building a mobile app, write a scrappy web version in 1-2 weeks and tie it to one real upcoming event (a friend's Halloween party for Once). Let it break in production — the point is to prove the experience works with real strangers, not to ship the actual product. After that one event validates the mechanic, delete the entire web codebase and rebuild on the right platform from a clean slate. Don't let validation code contaminate v1.
“you set a time frame 30 days 60 days and you set the scope like um maybe not the full course but maybe just the module one or module two... so then you build in public intensively in order to build up the momentum and not just like sh keep sharing your updates that's kind of boring... people love seeing someone start to finish like they they they just want to see is he going to pass the finish line”
Run a 30-60 day building-in-public Sprint with start and end dates
Vague "I'm building in public" with no time bound produces vague results. Pick a scoped deliverable (one module of the course, one feature of the SaaS, a 30-day mini-product) and announce explicit start and end dates publicly. The finish line is your accountability mechanism and the audience's narrative hook — they want to see whether you cross it. Failed sprints still teach you (and your students) what to do next; ambient long-running posting teaches no one anything.
“it's not about PHP jig it's more about the point that it doesn't matter that you have these developers who work in Enterprise in agencies and there's this agency MLM I feel like where um you have a you have a company that doesn't know anything about tech they come to a web agency... these web agency need to sell like the best stuff so they say we use the newest technology”
Ignore the tech-stack cult — ship with what you already know
Pieter runs $40K+/mo businesses on PHP and jQuery. The pressure to adopt the newest framework comes from agency sales narratives and VC-funded framework companies needing evangelist growth — not from your customer. Ship with the stack you already know fast and validate. If your business doesn't survive long enough to need rewriting, the framework choice never mattered. If it does, rewrites are a great problem to have.
“I repeat myself all the time and then if I repeat myself 10 times like you know don't repeat yourself as the Mantra then I write a function but I don't people like people try immediately write a function for something you repeat twice it's like man just tweet repeat it TW you know like this kind of stuff”
Don't extract functions on the second repeat — let it repeat 10 times first
Standard DRY advice tells you to extract a function the second time you repeat code. For a solo indie hacker pre-PMF, that's premature optimization. Pieter's rule: let it repeat 10 times before you build the abstraction. By repetition 10, you know what the shape of the abstraction actually needs to be. Earlier than that, your function design will be wrong and you'll refactor it twice anyway. Validate the pattern first, abstract once.