Everything from

Basecamp / 37signals

5 resources from Basecamp / 37signals we point founders to, and the questions each answers.

📖 Book
✓ Link checked Free Intermediate

Why we picked it Basecamp's battle-tested, opinionated system for shipping meaningful work in fixed cycles without endless backlogs, a primary source, free in full. The antidote to over-planning your roadmap.

Shape Up: Stop Running in Circles and Ship Work that Matters

From Basecamp / 37signals by Ryan Singer free online book

  • Work in short cycles with a cool-down between them.
  • Fix time, vary scope, use 'appetites,' not estimates.
  • Make bets, not plans; no runaway backlog.
Open basecamp.com
Answers How do I decide which features to cut from v1? How do I decide what to build next? How often should an early-stage startup ship? How do I build a roadmap without over-planning? How do product teams keep a consistent shipping rhythm as they grow? When is my product 'ready' to launch? How often should I be launching, is once a quarter too much? How do I know when to stop researching an idea and just start building? I keep polishing the design and refactoring instead of shipping. How do I know I'm gold-plating my MVP versus doing necessary work? How much should I spend building an MVP as a bootstrapped founder in India, and where does the money actually leak? I built my MVP on no-code but my technical co-founder wants to rewrite it in real code. When is that migration actually worth it? How do I write a spec for a developer when I'm not technical? What's a fair way to structure a milestone-based contract with a dev agency? How much should an MVP realistically cost to build in India? How do I keep an offshore or remote dev team accountable across time zones? What are the warning signs a developer is building the wrong thing? When my technical hire and I disagree on the tech stack, whose call is it? How do I run a weekly ship cadence when I am non-technical and depend on a dev agency or freelancers? Every user interview gives me a different feature request. How do I turn messy feedback into a real prioritisation decision? What is a sane way to prioritise between fixing bugs, paying customer promises, and building the exciting new thing? How do I stop myself from adding features nobody asked for just because I enjoy building? Should I share a public roadmap with my early users, or does that just create pressure and expectations I cannot meet? How do I keep shipping weekly when I am building solo and constantly interrupted by support, sales, and admin? What does a 'soft launch' actually look like, and is it just a cop-out for being scared to ship? I keep tweaking the landing page instead of launching. How do I tell polishing from procrastinating? My first launch went okay but the second felt embarrassing, like 'why are they back again already?' Is relaunch fatigue real? My co-founder wants a big coordinated launch, I want to just ship quietly and iterate. Who's right?
📖 Book
✓ Link checked Free Intermediate

Why we picked it This chapter is the clearest argument for our claim that a long timeline means your scope is wrong. Basecamp starts with a fixed time budget (the appetite) and cuts the design to fit, instead of estimating a fixed scope and watching time balloon. If your MVP keeps slipping, this gives you the mental model to fix it.

Shape Up: Set Boundaries (Appetite)

From Basecamp / 37signals by Ryan Singer 15 min read

  • Fix the time and vary the scope, not the other way around
  • An appetite starts with a number and ends with a design
  • A deadline that cannot move forces the hard cuts for you
Open basecamp.com
📖 Book
✓ Link checked Free Beginner

Why we picked it Free to read online, with chapters like "Build Less" and "Half, Not Half-Assed" that name your exact trap. It argues that cutting scope is a feature, and that the version with fewer things done well beats the bloated one. A fast, opinionated read you can skim straight to the chapters that sting.

Getting Real (free to read online)

From Basecamp / 37signals by Jason Fried, David Heinemeier Hansson (37signals) Free online, ~4 hr

  • Build half a product, not a half-built product.
  • Every feature you add is one more thing to maintain and explain.
  • Deliberately underdo the competition on scope.
Open basecamp.com
Answers Should I hire an agency or a freelancer to build my MVP? How do I know if my product is confusing to users? Why does good design actually matter for an early-stage startup? When is my product 'ready' to launch? My launch flopped and nobody cared, did I mess it up? I keep polishing the design and refactoring instead of shipping. How do I know I'm gold-plating my MVP versus doing necessary work? Should my MVP be a mobile app or a web app? My users are mostly on phones in smaller Indian cities. How much should I spend building an MVP as a bootstrapped founder in India, and where does the money actually leak? I'm a domain expert with no coding background. Should I spend a month learning a no-code tool myself or hire a no-code freelancer? How much should an MVP realistically cost to build in India? Is it a mistake to hire one developer to build my whole product alone? How do I run a weekly ship cadence when I am non-technical and depend on a dev agency or freelancers? Should we ship an ugly, half-working version now or wait until it feels good enough to be proud of? How do I stop myself from adding features nobody asked for just because I enjoy building? What does a 'soft launch' actually look like, and is it just a cop-out for being scared to ship? I keep tweaking the landing page instead of launching. How do I tell polishing from procrastinating? My first launch went okay but the second felt embarrassing, like 'why are they back again already?' Is relaunch fatigue real? Should I gate my launch behind a waitlist, or does a waitlist just kill the momentum I worked to build? How do I write the actual launch post so it doesn't read like a press release nobody asked for? My co-founder wants a big coordinated launch, I want to just ship quietly and iterate. Who's right?
📄 Article
✓ Link checked Free Beginner

Why we picked it If you read one chapter, this is the core argument: doing less is a feature, not a compromise. It helps you strip your MVP down to the one thing worth testing, which is usually deliverable on the mobile web today. Concrete and quick.

Getting Real: Build Less

From Basecamp (37signals) by Jason Fried, David Heinemeier Hansson

  • Fewer features means faster learning
  • Cut anything not core to the first test
  • Less software is easier to change later
Open basecamp.com
✍️ Essay
✓ Link checked Free Beginner

Why we picked it A runaway roadmap is usually a list of every decent idea, and this piece is the antidote. Build half a product that is great rather than a full product that is mediocre, then cut the feature list in half again. For an early founder tempted to plan quarters of features, it reframes cutting as the point, not the compromise.

Getting Real: Half, Not Half-Assed

From Basecamp (37signals) by Jason Fried, David Heinemeier Hansson ~3 min read

  • Ship half a product, not a half done product
  • Cut your feature list, then cut it again
  • Real usage, not a plan, tells you what to build next
Open basecamp.com
eChai Partner Brands