Build software for yourself
A great way to build software is to start out by solving your own problems. You’ll be the target audience and you’ll know what’s important and what’s not. That gives you a great head start on delivering a breakout product.
The key here is understanding that you’re not alone. If you’re having this problem, it’s likely hundreds of thousands of others are in the same boat. There’s your market. Wasn’t that easy?
Basecamp originated in a problem: As a design firm we needed a simple way to communicate with our clients about projects. We started out doing this via client extranets which we would update manually. But changing the html by hand every time a project needed to be updated just wasn’t working. These project sites always seemed to go stale and eventually were abandoned. It was frustrating because it left us disorganized and left clients in the dark.
So we started looking at other options. Yet every tool we found either 1) didn’t do what we needed or 2) was bloated with features we didn’t need — like billing, strict access controls, charts, graphs, etc. We knew there had to be a better way so we decided to build our own.
When you solve your own problem, you create a tool that you’re passionate about. And passion is key. Passion means you’ll truly use it and care about it. And that’s the best way to get others to feel passionate about it too.
Scratching your own itch
The Open Source world embraced this mantra a long time ago — they call it “scratching your own itch.” For the open source developers, it means they get the tools they want, delivered the way they want them. But the benefit goes much deeper.
As the designer or developer of a new application, you’re faced with hundreds of micro-decisions each and every day: blue or green? One table or two? Static or dynamic? Abort or recover? How do we make these decisions? If it’s something we recognize as being important, we might ask. The rest, we guess. And all that guessing builds up a kind of debt in our applications — an interconnected web of assumptions.
As a developer, I hate this. The knowledge of all these small-scale timebombs in the applications I write adds to my stress. Open Source developers, scratching their own itches, don’t suffer this. Because they are their own users, they know the correct answers to 90% of the decisions they have to make. I think this is one of the reasons folks come home after a hard day of coding and then work on open source: It’s relaxing.
—Dave Thomas, The Pragmatic Programmers
Born out of necessity
Campaign Monitor really was born out of necessity. For years we’d been frustrated by the quality of the email marketing options out there. One tool would do x and y but never z, the next had y and z nailed but just couldn’t get x right. We couldn’t win.
We decided to clear our schedule and have a go at building our dream email marketing tool. We consciously decided not to look at what everyone else was doing and instead build something that would make ours and our customer’s lives a little easier.
As it turned out, we weren’t the only ones who were unhappy with the options out there. We made a few modifications to the software so any design firm could use it and started spreading the word. In less than six months, thousands of designers were using Campaign Monitor to send email newsletters for themselves and their clients.
—David Greiner, founder, Campaign Monitor
You need to care about it
When you write a book, you need to have more than an interesting story. You need to have a desire to tell the story. You need to be personally invested in some way. If you’re going to live with something for two years, three years, the rest of your life, you need to care about it.
—Malcolm Gladwell, author (from A Few Thin Slices of Malcolm Gladwell)