The Starting Line

Build less
- underdo your competition: less features; less options; less people/structure; fewer meetings; fewer promise

Build software that solves your problem
- your passion comes through in the solution

"Scratch your own itch"

Fund yourself
- do more with less to drive innovation
- forces you to get idea into the wild sooner: a month or two will know if your idea is a lemon or otherwise you have cash flow 
- focus on building a quality tool that you and your customers can live a long time with

Fix time and budget, flex scope 
- keep time and budget fixed, just scale back scope
- helps with prioritisation

Pick a fight
- sometimes best to know what app shouldn't be rather than what it is
- tell a completely different story
- ask what is the key problem we are trying to solve and how do we solve it

Stay Lean

Less mass
- leaner you are the easier to change
- you can actually change your mind

Lower cost of change
- stay flexible to change

Use a team of three for version 1.0
- a developer, a designer and a sweeper roaming between both

Embrace constraints
- let constraints guide you
- creative solutions

Be yourself
- differentiate from bigger companies by being personal and friendly
- being small can be huge advantage regarding communication


Explicitly define the one-point vision for your app
- what does it stand for?
- what is its purpose, it's vision?
- why. Why exist ?

Ignore details early on
- can perfect later

It's a problem when it's a problem
- don't waste time on problems you don't have yet
- just wing it and be honest / communicate with customers

Hire the right customers
- if you try to please everyone you'll please no one
- relates to marketing and sales synergy

Scale later
- wait for scaling problem when it comes
- biggest problem is getting to a point where you have to scale

Make opinionated software
- your app should take sides: best product has a vision. People are looking for an approach

Feature selection

Build half a product, not a half assed product
- take what you think the product should be and halve it
- start with lean smart app and let it gain traction

Figure out what matters to the product and leave the rest (even if requested)
- essentials only

Start with no to features: each time you say yes to a feature you're adopting a child

Hidden cost to every feature update

Build and offer services you can manage / sustain

Build software for general concepts and encourage people to create their own solutions
- do the best job you can with the root of the problem then step aside

Read and throw away feature requests: if it's worth remembering they'll remind you till you can't forget

Ask people what they don't want


Get something real up and running quickly

Work on iterations
- let app morph and evolve

Brainstorm > sketches > HTML > coding
- ideas
- paper sketches
- mock up in HTML and CSS
- program
- cycle through multiple times ok

Avoid preferences
- be opinionated about design

Done means you're building momentum
- make quick simple decisions: execute

Test your app via real usage

Break time schedule down to realistic amounts
- problems too

The organisation

Don't split into silos: integrate for communication

Leave people alone to get things done: get in the zone

Don't have meetings. If absolutely must:
- 30 mins times
- Invite as few as possible
- always have clear agenda

Celebrate small victories, maximise motivation


- Hire less, later
- Start with trials
- Judge by open source contributions
- Get well rounded generalists
- Go for enthusiasm
- Hire good writers


Design interface before starting to program
- interface is what you'll use to sell

Start at epicentre and work out
- most important content first

3 screens to design for:
- regular state
- blank with no content
- error

Regular state

Screen people see when everything is working and app is flush with data.


Set expectations with a thoughtful first-run experience.  Blank slate is the first impression: unfortunately the customer decides if the app is worthy based on no content impression from blank slate:
- insert tutorials and help blurbs
- give sample screenshot with data
- explain how to get started
- answer key questions for first time users
- set expectations and help reduce frustration, intimidation and confusion.

Design for context over consistency

Good writing is good design: the copywriting of labels and buttons etc matters, and is part of the design.

Incorporate admin functions into the public interface.


Write less software / code: restate any hard problems that require a lot of software into a simple problem that requires much less.  Solving 80% of the original problem for 20% of the effort is a major win.

Optimise for happiness: choose tools that keep the team excited and motivated.  This extends to programming languages, the right one makes the process enjoyable and invigorating.  Happy programmers are productive programmers.

Code speaks: is there a simple way that will take less than an hour, rather than a complicated one that will take ten?

Manage code and design debt: hack together something bad that’s functional and you’re building up debt.  That’s okay sometime, but you need to recognise its debt and pay it off at some point by cleaning up the hairy code or redesigning that page.

Get your data out into the world via RSS, APIs etc: don’t try to lock-in customers, let them get their information when and how they want it.  Give up the idea of sealing in data, you’ve got to let it into the wild.  Offer APIs that let third-party developers build on to your tool.  When they do, they make life more convenient for customers and expand then possibilities of what your app can do.


Don’t write functional specification documents:
- they’re fantasy
- about appeasement (making everyone happy)
- lead to an illusion of agreement
- force you to make most important decisions when you have least information
- lead to feature overload
- don’t let you evolve, change and reassess

Go with a briefer alternative that moves you towards something real.  Write a one page story about what the app needs to do.  Shouldn’t be more than a page and take more than a day.  Use plain language.  Then begin building the interface (sketches > HTML > coding).

Eliminate unnecessary paperwork: build, don’t write.  If you need to explain something, mock it up and prototype it rather than writing. If you absolutely must write something, tell a story about it.  Don’t get into technical or design details.

Don’t use lorem ipsum text, write real copy.

Personify your product: think of it as a person.  What type of person: polite, stern, forgiving, strict, funny, serious etc.  Once you decide, keep those personality traits in mind as the product is built.  Your product has a voice and its talking to customers 24 hours a day.

Pricing and Signup

Give something away for free to stimulate demand.

Make it easy to signup and cancel.  All customers to take data on cancellation: crucial because giving people control over their information builds trust.  You’re allowing them to leave without penalty, which builds trust and goodwill.

Avoid long-term contracts, signup fees, early termination fees etc.

Soften the blow of bad news with advance notice and grandfather clauses for  a period of time.


Hollywood launch: go from 1) teaser to 2) preview to 3) launch.

1. Teaser
A few months ahead of time start dropping hints.  Let people know what you’re working on.  Post a logo.  Post to your blog about development.  Stay vague but plant a seed.  Get a site set up where you can collect emails from folks who are interested.

Start seducing mavens and insiders.  Folks on the cutting edge.  The tastemakers.  Appeal to vanity and status as ahead-of-the-curve.  Tell them you’re getting an exclusive sneak preview.

2. Preview
A few weeks ahead of launch, start previewing features.  Give people behind-the-scenes access.  Describe the theme of the product.  For Basecamp, they posted screenshots and highlighted features.

Tell people the ideas and principles behind the app.  Post a manifesto before launch.  Get people thinking and talking about the app.  Offer “golden tickets” to special few people so they can start using the app early.  Encourage people to sign up so you’ve a foundation of emails to blitz once you launch.

3. Launch
Now people can go and see your app.  Send emails out. Launch your full marketing site.  Spread the gospel: get blogs to link to you, post about your progress.  How many people have signed up? What updates have been made? Show momentum and keep at it.

Build a promotional site that introduces people to the product:
- overview: explain app and its benefits
- tour: guide people through the various features
- screen captures and videos: show people what the app looks like and how to use it
- manifesto: explain the philosophy and ideas behind it
- case studies: provide real life examples that show what’s possible
- buzz: testimonial quotes  from customers, reviews, press etc
- forum: offer place for members of the community to help each other
- pricing and signup
- blog: keep your site fresh with news, tips, etc

Ride the blog wave: cheaper and more effective than advertising:
- offer helpful advice, tips, tricks, links etc

Solicit early
- get advance buzz and signups ASAP: get some sort of site up and start collecting emails as soon as possible.  Pick a domain name and put up a logo and maybe a sentence or two that describes or at least hints as what your app will do.  Then let people give their email address.

Promote through education
- education is a soft way to get your name and product name in front of more people.
- post tips and tricks
- speak at conferences and stay afterwards to meet and greet attendees
- conduct workshops so curious fans can learn more
- give interviews to publications
- write articles and share helpful information, and write books.

Feature food: new or interesting features are a great way to generate buzz for the application.

Promote upgrade opportunities inside the app.

Give your app a name that’s easy to remember.


Don’t build walls internally between customer support teams and development design teams.

Use inline help and FAQs so your product doesn’t require a manual or training.

Quick turnaround on support queries is a top priority: answer candidly and directly.  This sets apart from larger enterprises.

Be willing to say no to customers when it comes to feature requests.

Use forums or chat to let customers help each other.

Publicise your mistakes: take responsibility.


Issue a major update 30 days after launch: it shows momentum.

Keep the blog posts coming to show your product is alive:
- FAQs
- How-tos
- Tips and Tricks
- New features, updates and fixes
- Buzz / press

Don’t use Beta as a scapegoat: private betas are fine, public betas are bullshit.  Take responsibility for what you’re releasing publicly.  Put it out and call it a release.

All bugs are not created equal
- prioritise your bugs, and even ignore some.

If you introduce new features, change a policy or remove something, wait until all the knee-jerk reactions have come in before taking any action.  Also negative reactions are almost always louder and more passionate than positive ones.

Beware bloat: just because something becomes mature doesn’t mean it needs to get more complicated.

Go with the flow: figure out where the big waves are breaking and adjust accordingly.  The beauty of a web app is its fluidity.  Flickr started out as an online game before creators realised the photo sharing aspect of the game was more plausible product.


To score big, you have to combine all elements.  That means doing a lot of things right: good writing, clean interface design, great code, great promotion.  The key is balance: if you tilt to far in one direction you’re heading for failure.  Constantly seek out your weak links and focus on them until they’re up to par.

You need people who are passionate about whey they do.  People who care about their craft.  People who take pride in their work regardless of the monetary reward.  People who want to build something great and won’t settle for less.  In the end the folks on your team will make or break your project and your company.