The Shipping Bible

First Draft — Living Document

Our Philosophy

We ship. We build in public. We learn by doing.

At Crafter Station, we don’t wait for perfect. We believe that a shipped project teaches more than a hundred planned ones. Every line of code we share, every demo we record, every build session we stream is a statement:

LatAm tech talent is here, and we’re building the future.

This playbook exists to help us ship consistently, grow our community, and keep the momentum going.

The Shipping Cycle

Shipping isn’t a one-time event. It’s a rhythm.

Most people think shipping is linear: build something, launch it, done. But the builders who maintain momentum know the truth — shipping is a continuous cycle.

Every rotation through the cycle is valid, whether it takes 5 minutes or 5 weeks:

• Think: Capture an idea, a question, a problem worth solving
• Share: Tweet it, post it, tell someone — this creates accountability
• Build: Code, design, write — any form of creative work
• Ship: Put it out there — a thought, a WIP, a demo, a full launch
• Learn: Gather feedback, reflect, and let it feed your next idea

The 6 phases detailed below? That’s one full rotation — a complete project from spark to follow-up.

But you can run smaller cycles every day:

The key insight: Every output maintains momentum. A thought shared is a ship. A demo posted is a ship. Don’t wait for “big” launches to feel like you’re shipping — the cycle rewards consistency over size.

The Shipping Lifecycle

Phase 1: The Spark

From idea to commitment

• Capture the idea (Notion, voice note, whatever works)
• Answer: Why this? Why now?
  • Is it fun?
  • Does it showcase something we learned?
  • Will it resonate with our community?
  • Does it solve a real problem (even a small one)?
• Define the scope: What’s the smallest shippable version?
• Set a time constraint (2 hours? A weekend? One week max?)
• Decide the format: Solo build, Pair/team session, or Live build challenge
• Commit publicly (tweet it, post it, tell someone)

Phase 2: The Build

Heads down, cameras optional

• Set up the project (repo, basic structure)
• If recording: start the screen capture
• Build the core feature first—skip the nice-to-haves
• Document interesting moments/decisions as you go
• Hit blockers? That’s content. Note them.
• Time-box ruthlessly. Done > perfect.
• Commit often. Push to GitHub.

For Team Builds:

• Assign clear ownership (who builds what)
• Keep communication async-friendly (quick Slack/Discord updates)
• Sync at the halfway point: are we on track?

Phase 3: The Polish

Make it presentable, not perfect

• Write a clear README with:
  • What it does (one sentence)
  • Why we built it
  • How to use it
  • Tech stack
  • Link to demo/live version
• Deploy it (Vercel, Railway, wherever)
• Test the happy path—make sure the demo works
• Take screenshots/screen recordings of key features
• Create a simple landing page if relevant

Phase 3.5: The Pre-Launch

Build anticipation before you drop

The launch doesn’t start when you post—it starts days (or even hours) before. Pre-launch is about warming up your audience, creating curiosity, and setting the stage for maximum impact.

Teaser Content

• Post a teaser 24-48 hours before launch
  • Blurred screenshot
  • Cryptic one-liner (“Working on something for [problem]…”)
  • Short clip of the UI without full context
• Share work-in-progress shots during the build
• Drop hints in comments/replies on other posts

Build in Public Updates

• Post “Day 1 of building X” updates
• Share blockers and breakthroughs in real-time
• Tweet/post from the build session (even rough clips)
• Use Stories (LinkedIn/Instagram) for raw, unpolished updates

Early Access & Feedback

• Create a simple waitlist (Tally, Notion form, or landing page)
• Invite 5-10 trusted people to try it before launch
• Gather quick testimonials or reactions
• Fix critical issues based on early feedback
• Screenshot positive DMs/reactions (with permission) for launch day

Community Warm-Up

• Engage heavily in relevant communities 2-3 days before launch
• Comment on related posts (add value, don’t just promote)
• DM key people who might be interested (personalized, not spammy)
• Coordinate with team members to be online at launch time

Strategic Setup

• Identify 3-5 people who will engage immediately when you post
• Prep them with the launch time and ask for early comments
• Schedule posts if launching across multiple platforms
• Have replies and additional context ready to drop in comments

For Bigger Launches

• Consider a countdown (3 days, 2 days, 1 day, launch)
• Create a launch thread/document with all assets ready
• Coordinate with collaborators on cross-posting
• Reach out to newsletters or community accounts that might share
• Prep a Product Hunt or Hacker News launch if relevant

Pre-Launch Intensity Levels

The “Warm Launch” Technique

Instead of going from zero to launch, build momentum:

• Day -3: Teaser post (hint at what’s coming)
• Day -2: WIP update (show progress, share a struggle)
• Day -1: Sneak peek (demo clip, screenshot, early reaction)
• Day 0: LAUNCH (full post + video + links)
• Day +1: Follow-up (results, learnings, thank the community)

Phase 4: The Content

This is where the magic happens

Video (the multiplier)

• Record a demo (60-90 seconds max for social)
• For build sessions: create a timelapse (speed up the 2h to 2min)
• Show the thing working, not just talking about it
• Add captions (most people watch on mute)
• Keep energy high—you just built something cool

The Post

Write the story, not just the features:

• What we built
• How long it took
• What we learned
• The “why” behind it

Include a clear CTA (try it, star the repo, follow for more)

Tag relevant people/tools/communities

Add the video/demo directly in the post (native uploads perform better)

Platform-Specific Notes

• LinkedIn: Longer story format works. First line is the hook.
• Twitter/X: Thread or single punchy post. Video auto-plays.
• YouTube: Longer demos, tutorials, behind-the-scenes

Phase 5: The Launch

Ship it to the world

• Choose your primary platform (where your audience is)
• Post during peak hours (test and learn what works)
• Cross-post to secondary platforms
• Share in relevant communities:
  • Discord servers
  • Slack groups
  • Reddit
  • WhatsApp/Telegram groups
• Ask the team to engage early (comments, shares)
• Respond to every comment in the first 2 hours

Phase 6: The Follow-Up

Keep the momentum

• Share wins (likes, comments, traffic) with the team
• Capture feedback from the community
• Write a quick internal retro:
  • What worked?
  • What would we do differently?
  • What did we learn?
• Update the project if there’s quick wins from feedback
• Archive learnings for future playbook updates

Quick Reference: Launch Checklist

• Idea captured and scoped
• Time constraint set
• Commitment made public
• Core feature built
• Deployed and working
• README written
• Pre-launch teaser posted
• Early feedback gathered
• Demo video recorded
• Post written with story + CTA
• Launched on primary platform
• Cross-posted and shared in communities
• Engaged with comments
• Retro completed

The Crafter Station Principles

1. Ship > Perfect. A working demo beats a polished pitch deck.
2. Build in public. The process is content. Share the journey.
3. Time-box everything. Constraints breed creativity.
4. Story > Features. People connect with why, not just what.
5. Community first. We grow by lifting each other up.
6. LatAm represents. We’re here to show the world what we can do.

Appendix: Content Templates

LinkedIn Post Template

I just built [THING] in [TIME].

Here's what it does:
-> [Feature 1]
-> [Feature 2]
-> [Feature 3]

Why I built it:
[1-2 sentences on the motivation]

What I learned:
[Key insight or challenge]

Try it: [LINK]
Star it: [GITHUB]

#buildinpublic #[relevant hashtags]

Twitter/X Thread Starter

Just shipped: [THING]

Built it in [TIME] with [@teammate if applicable]

Here's a quick demo:
[VIDEO]

Pre-Launch Content Ideas

• “Building something new this weekend…” + hint
• Screenshot of code/terminal with context blurred
• “What if you could [solve problem] in [time]?”
• Raw 15-second clip from the build session
• “Hit a wall with [tech]. Anyone solved this before?”
• Poll: “Would you use a tool that does X?”
• “48 hours until we ship [NAME]. Here’s a sneak peek”

Version 0.1 — Living document. Update as we learn.

Crafter Station