Originally posted at https://tailapps.com/build-apps-that-you-use/
One of the things I especially enjoy doing is building apps that I’m going to use in the years to come.
I think it’s the absolute best way to ensure:
- the app will perfectly do the job you want it to do
- you’re going to maintain it even if it’s not a success in terms of usage
- it will be built with passion
Software for ourselves
Many times we developers are hired to build things we’re never going to use, and while we’re professionals and we always do our best job and look forward to provide top-quality software, we all know it’s way easier to do a great job on something you know every detail of what you need, because you’re the first user of it.
Build something with you as the most important user, and you can be pretty much sure that if the problem you solve is compelling and strong, someone else in the world will have the same issue to solve.
I hear from time to time stories and postmortem of failures or pivots caused by missing passion in a particular topic the app or service or startup was acting in. If you expect something you build to succeed, you’re going to put in so many hours to make it work and run, that it’s nearly impossible to be motivated if you’re not passionate in the field you’re in.
This is why I don’t believe when people suggest for example to find a problem someone has and solve it. Not when you’re an indie developer, and you know nothing about that field and you’d need to invest too much time to just test your idea.
Something entirely new or our own version of X?
Many times the question is, should I write this software I need which maybe 50 people in the world need too (which I’ll never have a chance to market to, probably) or build my own TODO list app, or my own photo editing software?
The answer is not easy. They’re both good approaches at building good software. What I usually do is: do both things, differentiate.
When I built my own app to track my dogs weight over time, for example, I never thought “this is going to be huge”. It was a small app for my own use. I plan to use it for the rest of my life. I put it on the Mac App Store, and a few people are actually finding it useful too. There’s no similar app around AFAIK.
My app to measure what I spend on bills over time is something I envisioned to be more popular, and of course it’s a niche which has competitors and other nice apps. I just wanted something laser-perfect for my needs and during the process I made it general enough to be useful to other people too.
You know what’s wrong
When you’re the user of your app it’s really easy to know what’s wrong. What could be improved. What is great. What is the main value proposition of the app.
You’re the expert of the domain. It’s not something to be undervalued, it’s a rare opportunity to do great things.
I’m pretty sure I will not abandon my apps as long as I’m the main user, or use case if you prefer. And, as long as the app is useful to me.
I see too many apps that are being built and then abandoned, or have never been updated in the last 2 years or so.
Most of the times the developers moved on to something different, and left the app in the dust because they probably were not passionate enough about the problem it solved, or never used it themselves so they didn’t feel the urge to improve it.
Marketing products we believe are useful
If the product we build is something we use, and you believe it’s useful to other people too, it’s easier to market. We developers sometimes are terrible marketers. I know I am a terrible marketer when it comes to promoting my products and I’m trying to improve over time.
One of the things I cannot fake is the enthusiasm around my products. Either I’m proud of them, or I’m not.
Also, you have that inner voice that says “the software is great, it’s a pity that no one else uses it!”
Building stuff that I think is great is the best way to stimulate myself to market a product, which is the other 50% of the equation to have a successful product, the other 50% being have a great product in the first place.
Putting things on the wall and see what sticks
One of the approaches I have to software is making many utilities, even very simple things in their initial iterations, and seeing how they are perceived by the users. If something is never downloaded at all, maybe what I built is not compelling enough or there’s not a great market for it.
One of the key motivators is waking up every day and say, today I’ll build this thing I’m going to use instead of “software X” which never satisfied me 100%. Or, today I’ll build this thing that no one else has ever done as an app, but required use of Y and Z.
Over time the outcome of this process is a serie of products which will provide real value to users. Even in the worst case, you have something to show that explains your dedication to building quality products.
You never know what will stick. Building an app is mostly guessing. I think this could do well, but in reality it’s not. That other app, which I build in 5 hours, is selling nicely. Maybe you’re lucky and the first things you build is a success. Maybe you need to build 60 apps before one is actually used by customers.
When a software sticks and hits the right cord, it will become popular given enough quality and marketing. Then it’s up to you deciding to include feature requests, changes required by vocal users, therefore changing the initial scope of the product. It might completely change its face and move from “a product that satisfies me” to “a product that meets the needs of every user”.
This is more a business reasoning and of course to keep doing our job as indie developers we must sometimes adapt to what the market, the paying users, need.
The “little utility made just for me” can still of course continue to be used just by you on your Mac while you take the general availability product to the next levels, or you can keep on using the product you ship, thus keeping on with the mantra “Build apps that you use”.