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 2 of 5
“I don't even build a product — I actually deliver the solution manually at this stage. I don't care about the margins yet, I just care about the solution being delivered to the customers.”
Deliver the Solution Manually Before Writing Any Code
Once pre-sales are confirmed, John fulfills the promise by hand rather than rushing to automate it. Iterating on a manual service is far cheaper than rebuilding code repeatedly, so he locks in what customers actually want before a co-maker writes a line. The product only gets built after the manual version achieves satisfaction.
“Doing daily videos kind of forces you to lower your standards and kind of just ship out a product. You'll learn way more in 30 daily bad videos than you know two perfect ones.”
Ship 30 Imperfect Videos to Learn More Than Two Perfect Ones
Jackie committed to daily YouTube uploads for 2.5 years, starting with a first video that got only 30 views in 24 hours. The discipline of shipping consistently — even poorly — compressed his learning curve and built the audience that eventually became his highest-converting distribution channel. Perfectionism at the cost of publishing volume is the single biggest mistake new creators make.
“if I can build a product from zero to making the first sale in 2 weeks but it takes you 6 months it's going to be very hard for you to compete with me”
Ship MVP in Two Weeks or Lose the Speed Advantage Over Competitors
Ure frames shipping speed as a direct multiplier on success odds — twice the iteration rate equals twice the chance of finding a winner. He turned a rough real-time transcription proof of concept into a sellable product in roughly two weeks, including the landing page. The 'viable' in MVP is defined solely as: can it make the first sale.
“I actually found a really great uh online course and I just started learning as much as I could as fast as I could within 8 weeks I had a full MVP built on a combination of Bubble and a handful of code that I understood how to build myself”
Build Your MVP in Eight Weeks Using No-Code Before Spending Anything
Dustin was broke with no technical background and no budget to hire developers. Instead of waiting until he could afford help, he found a single online course and time-boxed his build to eight weeks using Bubble. The constraint forced him to ship rather than perfect — and made $3K in his first month.
“When I first shipped my product I hosted it on a site called Heroku and the first person I gave it to they got an application error but they still managed to use some of the core features and were able to still use the app. Yes there were bugs. Yes there were issues but the main idea of the app was working. So as long as what you're trying to solve works I think you can ship anything.”
Ship a Broken MVP Immediately If the Core Feature Actually Works
Sam built his first MVP in a week by copy-pasting AI-generated code into VS Code with zero prior technical knowledge. Despite the product throwing an application error on the very first user interaction, that user still extracted value from it. This formed his core shipping philosophy: polish is secondary to solving the pain point.
“launch as soon as possible skip the boring parts of building a SAS like the password reset pages setting pages just launch the minimal basic products and run ads to test demand right away”
Skip the Boring Pages and Launch the Minimal Product Immediately
Samuel explicitly names the pages most founders spend weeks on — password reset, account settings — as launch killers. His philosophy is to get users into the core value loop first, then backfill infrastructure. This keeps early cohorts small, feedback tight, and time-to-market short.
“idea to live in the app store It took about a month and a half”
Ship from Idea to App Store in Six Weeks Using AI Coding Tools
Evan's team spent two weeks in Figma designing from scratch, then transferred everything to Xcode using YouTube tutorials, prior knowledge, and Claude Code. The entire cycle — from blank canvas to a live, monetized app — compressed into roughly six weeks, proving AI coding tools have fundamentally lowered the build time floor.
“your MVP doesn't have to be perfect try to nail design and usability make sure that your core feature works well in the case of Yodafone that was plainly making an outbound call from the app”
Ship a Working Core Feature First and Ignore Everything Else
Dennis built his entire MVP over a single weekend, guided by one constraint: the core feature had to work. He used Cursor and Next.js and accepted that everything else could be imperfect at launch. The result was a product people paid for the same day he posted it.
“Always optimize for a stack that would get your product out there as soon as possible and is highly scalable”
Always Optimize Your Tech Stack to Get Something Shipped Fast
When asked about his tech choices, Kishi explained his entire stack in under a minute: React Native, NestJS, Firebase, and Mixpanel. His guiding principle is not to pick the coolest tools but to pick what ships fastest. Overcomplicated stacks slow you down before you have a single paying customer.
“The whole product looked terrible I think this actually resonated with the crowd on Hacker News who are kind of you know a bit nerdy and it didn't look like a commercial product at all”
Ship Ugly Early — Raw Products Resonate With Technical Early Adopters
Nico launched on Hacker News just one week after going live, despite the product looking rough. That rawness turned out to be an asset with a technically sophisticated audience who valued authenticity over polish. The post hit the top six on a Sunday, sending 350 concurrent visitors and generating his first internet revenue.
“I have a clear image of how my app could look like so that I could fairly say that it's objectively better than my competitors”
Build Only What You Can Claim Is Objectively Better Than Competitors on UX
Ericas starts every new app by auditing competitors, noting what he likes and dislikes about their experience. His goal before writing a line of code is to arrive at a clear design vision he can objectively claim is better. This focused benchmark — not feature parity — defines the minimum he ships.
“mvp doesn't mean shitty product and it can't mean that if it does mean that for you your product is going to flop pretty hard you should shoot for minimum quantity not minimum quality”
Build Minimum Quantity Not Minimum Quality in Your MVP
Lane pushes back on the common misreading of 'MVP.' He argues that shipping fewer features at a high bar beats shipping a broad but mediocre product. The framing of minimum quantity — not minimum quality — keeps the scope tight while protecting the standard that earns early trust.
“make the app a single player...make your app single player something that someone could do on their own without having to invite anyone else in to get that initial value Yes you can do it afterwards as an added extra later on but it just makes things too complicated”
Build Single-Player Apps So Users Reach Value Without Inviting Anyone
Lots refuses to ship apps that need a second user to deliver value. Multi-player mechanics force you to acquire two cohorts before anyone activates, doubling marketing complexity and stalling first-use value. Social layers come later as a bonus, never as the gate to the first 'aha' moment.
“you need to build one key feature You need to send the product link to the first batch of users who left the emails on the landing page you built You can ask the feedback and based on that you can improve the product and relaunch it So it's going to be you know a sort of loop of build feedback edit and rebuild feedback endit”
Ship One Key Feature To Your Validation Email List Then Loop Feedback And Edit
Dom's MVP scope is deliberately one feature, not a roadmap. He ships that single feature to the exact emails he collected during validation, harvests feedback, edits, and relaunches in a tight loop. Reusing the validation list as the first beta cohort means day-one users are already qualified leads, not strangers.
“Don't waste your time on polishing it up thinking about adding one more killer feature that would definitely get you a ton of users. No, don't do it. Get it ready, bugs free, just one single feature — ship it and let users tell you what they think about it while you're building another app.”
Ship One Bug-Free Feature And Let Users — Not Your Roadmap — Pick The Next One
Max's one-line MVP rule: scope to a single feature, fix the bugs, then move on. He explicitly rejects the urge to add 'one more killer feature' pre-launch — the next app is the better use of that time, and real users will tell you what to build next. The portfolio approach only works if each app reaches users fast.
“you can try to validate before launching but if it takes you like one or two weeks to make an MVP it's not that much of a risk anyway so you might as well just build it”
Skip Pre-Launch Validation If Your MVP Only Takes One Or Two Weeks To Build
Angus argues that for tiny one-thing apps, the cost of building is so low that pre-launch validation rituals (surveys, landing pages, interviews) aren't worth the time. Ship the MVP first and let real usage be the test — the build itself is shorter than the validation theater.
“Prior to the 12 hours I went to Pinterest, I got inspiration, I figured out what I wanted the app to look like... design today differentiates a product and it takes way longer than you expect so figure out exactly what you want the thing to look like.”
Lock The Figma Design Before The Build Clock Starts So The 12 Hours Are Pure Execution
Lewis treated design as pre-work, not part of the build window. He pulled Pinterest references and locked the Figma before noon, so the 12-hour timer was pure execution on Bubble. His advice if starting over: never let AI just generate UI — design intentionally, because that's the real differentiator.
“I'd sit right there every single morning and put in two hours of deep work before I started my job... it wasn't impressive at all but it was consistent I kept coming back every single day refreshing Stripe watching it go from zero to a couple hundred bucks”
Run Two Hours Of Deep Work Before Your Day Job And Watch Stripe Tick From Zero
Pat couldn't execute on Starter Story after work — he'd come home and stall. The unlock was moving the work to before his day job: two hours every morning at a Starbucks, writing, coding, interviewing founders. The signal that made him go all-in wasn't a viral moment, it was sustained daily shipping plus a small but real revenue curve.
“My first step was to download Twitter to take some screenshot of each screen What I wanted to see is basically like how we go from screen one to screen two to screen three So I was continuing cursor Please make the same screen with the same visual elements with the same color with the same image In two weeks and a half I did one full copy”
Screenshot Every Screen And Walk Cursor Through The Flow To Vibecode A 1-to-1 Clone
David screenshotted every screen of the target app, walked Cursor through the flow one screen at a time, and instructed it to match visuals, colors and assets exactly. Full clone in 2.5 weeks plus a week for Apple review. Today he'd use mobbin.com to bulk-download screenshots and the Figma MCP to cut build time roughly in half.
“I'll go and download a whole bunch of apps, maybe 20 apps that are in the niche... screenshot every single page in every single onboarding... I'll put them all on one big line in a Figma file... You can really just drop the screenshots into Claude or Cursor and it'll actually be able to write the code for the full screen for you.”
Screenshot 20 Competitor Onboardings Into Figma Then Feed The Mashup Straight Into Claude Code
Connor's 2-week build process starts by ripping 20 competitor onboardings into a single Figma board, remixing the best screens in his own aesthetic, then dropping the redesigned screenshots directly into Claude Code to generate the screens. He also pre-writes a JSON data-structure doc so the AI doesn't have to guess at shape.
“My process is actually pure chaos. I basically jump into my code editor, I bring up ChatGPT or something similar and I just start asking how I should go about building the thing. And in terms of landing page I have just used like a boilerplate and I have made very small improvements. I'd go back and edit one section at a time usually and just make it a little bit better week over week.”
Start From A Boilerplate And Refine One Landing-Page Section Per Week
Jack doesn't design — he starts from a boilerplate (ShipFast) and ships immediately, then improves one landing-page section per week. Build velocity comes from accepting 'pure chaos' early and refining incrementally instead of polishing before launch. The site gets better one block at a time while real users are already arriving.
“I've formed a habit of waking up really early in the morning, prioritizing development tasks and stuff that just required more focus and attention in the morning. So I would do that between like 5:30 and 8:00, 8:30. And then if I worked on anything in the evening it might be more like marketing related because I could do those kinds of tasks without having to be hyperfocused and alert.”
Block Mornings For Deep Work And Save Marketing For The Tired Evening Hours
Ben treats a side-project day as two distinct shifts gated by cognition. Deep-focus building gets the pre-job hours when his brain is fresh; marketing — writing, posting, replying — gets the depleted evening hours after the day job, because it tolerates lower focus. Match the task to the brain state, not the other way around.
“In a matter of minutes he spun up Figma and started to design while I started initial project with Next.js and I created a hard-coded JSON file with some rules that I found online and in matter of like an half an hour we had something up in Vercel ready to to click around on.”
Hard-Code A JSON File And Push To Vercel Within Thirty Minutes Of Calling Your Co-Founder
Instead of building a CMS or database first, Pontus shipped a hard-coded JSON file with rules scraped from online. Within 30 minutes the site was live on Vercel and clickable; total build to launch was 3 hours flat on Next.js with a reused design system. The data layer can always upgrade — the bar to validate is just 'is it live?'.
“I use Supabase for database Next.js and Vercel for front end and hosting Sentry for debugging Trigger Dev for big compute cursor and claude code to actually develop the solution Nanobana to actually generate images with AI and then Gemini and OpenAI for the copywriting.”
Ship MVPs With Supabase Plus Next.js On Vercel And Cursor Plus Claude Code
Loick's exact MVP stack for repeatable SaaS launches: Supabase plus Next.js on Vercel, with Sentry for debugging and Trigger.dev for heavy compute. He pairs Cursor and Claude Code for development, routes AI image generation through Nanobana, and uses Gemini and OpenAI for copy. The same stack every time, so build velocity stays fixed across launches.
“It took me around a month to build the MVP and I gave it to my wrestling club to beta test... the first version was basically an app where the coach was supposed to give the wake up plans to the athletes however I realized that there was a lot of friction... so during July and August I changed the whole concept of the app to make it so that the app would give the weight cut plans to the athletes instead of the coach.”
Ship The MVP In A Month, Then Flip The Whole User Model When Beta Testers Won’t Adopt
Ethan built v1 in a month using Cursor and ChatGPT, handed it to his wrestling club, and watched them not use it. Instead of iterating on the wrong concept, he flipped the entire flow (coach-driven to athlete-driven) over two months and tested the new plans on his own body before relaunching. Pivot the user model, not just the features.
“I didn't actually write a single line of code in this entire codebase, but we use Cursor. We finished the MVP February 2025 and launched. We use React Native Expo as our framework, Superbase for database and backend, Claude Code and Codex as our coding agents, Mixpanel for analytics, RevenueCat, and for our marketing site we use Vercel and Next.js.”
Ship A Non-Technical-Founder MVP In Weeks Using Cursor And Coding Agents
Jack is non-technical but shipped the MVP within weeks by leaning entirely on Cursor and coding agents like Claude Code and Codex. The stack stays lean and standard: React Native Expo, Supabase, RevenueCat, Mixpanel, Vercel and Next.js — short build time, focus on content.
“we decided okay let's go two weeks we make a product start promoting it and it's it worked out... we started filming ourselves we started posting videos every day just from the first video we got the first sale but after that things started to snowball so first months $41K second months $32K and third months $27K”
Cap The Build At Two Weeks, Then Switch To Daily Posting Mode
They capped the build at two weeks and went straight into daily posting. The first TikTok produced a sale, and from there momentum compounded into $41K, $32K, and $27K across the first three months.
“You want to post pretty frequently just every single day you should be posting at least one video in my opinion just farming hooks finding what works learning each time having a spreadsheet just having a bunch of different ideas for content and then cutting off branches okay these ones I've tested this thoroughly this is not working cut off these.”
Post Daily, Kill Losing Branches, And Pull Harder On What Shows Signal
David treats content as a tree of hypotheses, posting at least one video a day and tracking each hook in a spreadsheet. Branches that fail get pruned, while branches that show signal get pulled on harder until something breaks through.
“your goal here is volume your goal here is knowing generally what direction your content should be going you're just looking for that first viral video the way to get there is by posting volume volume negates luck right so you need to be posting as much as possible and when you get a video that pops off recreate that concept”
Volume Negates Luck — Post Daily And Recreate Every Winner On Repeat
Steven pushes founders to stop perfecting and start shipping daily volume on short-form video. Once a single post breaks through, he immediately recreates that concept again and again because the platforms then trust the account and lift the floor on future views.
“the best way and the only way I know how to learn something new is simply just to throw myself into and just start building so I set myself a challenge to create one app every single month”
Commit To Shipping One App Every Single Month — Velocity Is The Learning Loop
After his first lawn-mowing app flopped, Adam stopped theorizing and set a constraint: ship one new app every single month. Building was his only way to learn what actually worked, and the cadence eventually produced over 50 apps.