The "Building of Basecamp" Workshop

What will we talk about?

  • We'll take you behind the scenes of the development of Basecamp, our popular web-based project management tool. We'll explain our process, our mistakes, our home runs, and the lessons we've learned. Then we'll discuss how you can transfer that knowledge to your own projects.

What will you learn?

  • It usually takes months (or years) of development trial and error to learn what we'll show you in one day. You'll leave armed with plenty of great ideas for making your own web app succeed.

Who's it for?

  • If you're considering building a web app, already have one, or just want to know what it really takes to make it happen, this workshop is for you.

Some of the issues we'll be covering:


  • What are "Mantras" and how do we use them to guide development?
  • What is the "LESS SOFTWARE" approach all about?
  • How does "SAYING NO BY DEFAULT" lead to a more focused product?
  • How placing constraints on your team, time, and budget can be the best thing you'll ever do.
  • How do I decide what features to launch with and which to introduce later?
  • How do I measure myself vs. competitors (how do I know if I even have competition)?
  • What are the advantages to being web-based?
  • What obstacles will surprise me?
  • What's the biggest pain about developing a web app?
  • What's the best part of developing a web app?
  • How do I plan the app, write the requirements, and execute the plan?


  • What qualities are important in a designer?
  • Do we design in-house or hire an outside firm?
  • Do we go CSS or tables or a combination of both?
  • How does the interface differ from that of a normal web site?
  • Do I need to worry about accessibility?
  • Do I need to worry about people using my app on a handheld or palm?
  • What specific interface design techniques apply?
  • Where do I find best practices that I can follow?
  • Do I paper prototype, photoshop prototype, or HTML prototype?
  • What design problems will I face?
  • What contingencies, error and otherwise, will I need to design for?


  • What qualities are important in a programmer?
  • How do I keep developers happy and empathetic to my business needs?
  • Which development methodologies are relevant for small-scale development?
  • What's a technical estimate and why don't they ever stick?
  • How, when, and from where do I staff the development team?
  • How can I prevent or, at worst, handle a technical crisis?
  • What programminng language (PHP, Perl, Ruby, .NET, etc.) should I develop in?
  • What's involved in planning for and scaling from 100 to 10,000 users?


  • How should I promote the app before/after launch?
  • What's important on a promotional site?
  • How do I get press coverage?
  • How do I get blog coverage?
  • How do I get testimonials?
  • What should I do with testimonials?
  • How should I organize a tour of the app?
  • What makes for a good domain name?
  • How do I build an audience?
  • How do I build goodwill and get others to promote for me?


  • How can I test before launch?
  • Who should my testers be?
  • How do I get feedback from users (before and after launch)?
  • How do you gather information from users?
  • What do you learn from testing and how do you transform findings into software requirements?
  • How do you decide what is important and what isn't?
  • How do I deal with "known bugs"?
  • How do I track bugs and feature requests?


  • How much should I sell it for?
  • How should pricing work (flat fee, subscription model, donationware)?
  • Should I process orders on my own or through PayPal??
  • How much should I give away free?
  • Should I give refunds and/or free trials?
  • Should I offer different pricing plans/tiers?
  • How should I handle bad accounts or invalid credit cards?
  • How should I charge? Per-person? Some other measurement of usage?


  • How long after launch should I update the app?
  • How do I learn about bugs from users?
  • Should I release big updates like traditional software, or release small, incremental and regular updates?
  • How do I decide whether something should be a v1 or v2 item?


  • Why "feeling the pain" is a good thing
  • How should I set up help?
  • Should help be inside the app or external (another site, printed manual, etc)?
  • What are the hidden costs of help and customer support?
  • How do I keep help up to date?
  • Should I charge for support and/or training?
  • Should I offer training?

Die Original-Seite befindet sich hier:


  • Der limitierende Faktor in Projekten.
  • Ueber Kommunikation und Angst. Und Wahrheit...
  • Wieviel neue Technologie?
  • Technologie(-layer), Beherrschbarkeit
  • Macht kommt von machen...
  • Raeumlichkeiten
  • Zweifler, Noergler und Besserwisser


  • Death March: The Complete Software Developer’s Guide to Mission Impossible Projects (Prentice Hall, 2003), by Ed Yourdon
  • Behind Closed Doors: Secrets of Great Management (Pragmatic Bookshelf, 2005), by Esther Derby and Johanna Rothman
Last modified 11 years ago Last modified on Aug 24, 2009, 10:21:06 AM