Have you ever tried an application that looked great at first, but once you started using it, it just didn’t feel right? The UI was slick and the feature list looked perfect, but the workflow just wasn’t there?
I see this all the time, and quite often it’s due to developers not using their own applications. They built something they thought would sell instead of something they needed, so they don’t see their software the way an end user would. They don’t notice the hundreds of little things that would make their applications easier to use, nor do they notice all the minor bugs that customers consider too small to report.
Not only does this result in less effective applications, but it also results in a boring job. Before becoming an independent developer, I spent a few years building corporate applications that I never used – and I hated it. My only reward for building these applications was a paycheck, which is nice and all, but it didn’t make working on them exciting.
Take it from me: building something you need is a lot more fun, and it also increases the chances that you’ll build something that people love.
14 thoughts on “Indie Tip #1: Build something you need”
Nick: I totally agree about “scratching your own itch” … but I’m kinda stuck … what happens when you get to the point where you really don’t need anything any more? How do you get “back into the game” so to speak?
Dossy, I believe that’s when you retire ;)
Seriously, if you’re at the point where you don’t think you need anything, then just wait a little while. I can’t imagine it would be too long before you discover something you really need.
Nick: I think you’re right, but I don’t have the funds to retire, yet. :-)
What I really want is to find local geeks who like to get together to either talk, code, debate, whatever. I participate on many different social networking sites and haven’t been able to find “the right kind of people.”
Of course, I’m in northern New Jersey–I suspect it might be easier to find people if I were in, say, the SF Bay Area, but … given the population density of northern New Jersey, I have to believe there are folks here, they’re just harder to find.
The question I keep asking (and failing to answer) is “what kind of technology would solve my problem?” Oh, failure …
> Have you ever tried an application that looked great at first, but once
> you started using it, it just didn’t feel right?
Yeah, it’s called Microsoft Office.
Great post Nick, looking forward to the rest of the series. I agree scratching your own itch is a whole lot more fun, but more importantly, it encourages you to actually _solve_ a real problem. If you can’t get that bit right then it’s a steep hill you’ve got to climb to success.
For what it’s worth, I wrote my own thoughts about the same topic a few days back:
Dave, that blog post of yours is excellent – and it touches on some of the things I’m planning to talk about here (including the desire to build “cool” software).
Nick: Couldn’t agree with you more.
So, does that mean the developer you hired to work on TopStyle Pro 4 uses CSS on a day-to-day basis then? ;-)
Seriously, I’ve lost count of the time I’ve wasted including “cool” features for users that I wouldn’t use myself. Oh well, you live and learn!
“Necessity is the mother of all invention”
I agree that it’s the most fun to write an application you actually need yourself. But if you’re stuck like Dossy, it can be almost as fun to write an application a family member or friend needs.
I completely agree – that’s why I wrote WebnoteHappy. There just wasn’t anything out there for the Mac that handles my bookmarks the way I wanted them. I wrote it up at http://www.happyapps.com/blog/2005/12/if-youre-looking-for-a-bookmarking-tool-for-mac-os-x/
One follow-on lesson though is that once other people start using your application, you should be prepared to integrate the good, popular suggestions to make it better. But without compromising your overall vision of where you want it to go.
Alternatively, you could also partner with a designer. We are good at figuring out what people need even if they don’t know it themselves. :-)
37signals have a good essay about this in their Getting Real book:
Actually whether you write an application that you need or that other people need, you should always get 4-8 end users who need it to evaluate your application on.
I am tempted to add a caution to this: While it is important that you use the application yourself, it is equally important that other people use it as well. I wrote a rather specialised application a few years back (to automate splitting up our phone bill) with the main intention to serve my needs and learn a bit of programming. That worked out all right, but because of its very limited audience, it only ever got a few users. And as long as I am pretty much its only user it’s much harder to justify spending/wasting time on improving it further. While when there has been feedback of other users suggesting to improve the application in some way (be it UI wise or by adding support for more phone bill file formats), that always managed to give development another nudge.
Nice article but couldn’t you have condensed it a bit? Otherwise people will think you’re just another waste of space blogger. Thx.
Comments are closed.