Today Apple approved our first to-do app on the Mac App Store.
Just do This is a peculiar to-do app that focuses on helping you achieve your goals for the day.
The most clean and simple to-do app available, lets you focus on your tasks rather than on the to-do app itself.
Add what you want to accomplish today, then just work towards your goals.
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
Many the 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.
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.
Of course that had more success in terms of users, but I see both apps in the same way when I’m looking to improve or add more features.
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.
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.
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”.
We all have those little code snippets scattered around. Maybe you’ve used some app to manage them, maybe not.
Today we welcome our latest app, dedicated to managing code snippets in the right way: it’s called Code Snippet.
Available on the Mac App Store, Code Snippet features a powerful code editor built-in, which can recognize 120 different languages and syntaxes. Here’s the full list:
abap, actionscript, ada, apache_conf, applescript, asciidoc, assembly_x86, autohotkey, batchfile, c_cpp, c9search, cirru, clojure, cobol, coffee, coldfusion, csharp, css, curly, d, dart, diff, django, dockerfile, dot, eiffel, ejs, elixir, elm, erlang, forth, ftl, gcode, gherkin, gitignore, glsl, golang, groovy, haml, handlebars, haskell, haxe, html_ruby, html, ini, io, jack, jade, java, javascript, json, jsoniq, jsp, jsx, julia, latex, less, liquid, lisp, livescript, logiql, lsl, lua, luapage, lucene, makefile, markdown, mask, matlab, mel, mushcode, mysql, nix, objectivec, ocaml, pascal, perl, pgsql, php, plain_text, powershell, praat, prolog, properties, protobuf, python, r, rdoc, rhtml, ruby, rust, sass, scad, scala, scheme, scss, sh, sjs, smarty, snippets, soy_template, space, sql, stylus, svg, tcl, tex, text, textile, toml, twig, typescript, vala, vbscript, velocity, verilog, vhdl, xml, xquery, yaml
For each of these languages the editor shows you autocompletion and code suggestions, so you might also detect those missing semicolons in your snippets.
Additionally, we have included 32 different themes so you can show your snippets in your favorite color scheme.
We all have half a dozen devices in our house. Desktop computers, laptops, tablets, smartphones, and maybe in the future smart watches. Too much to track, and there are many useful things to store about each device, in an organized place, that will come useful for example when you decide to sell them, or if you have to call the assistance or bring them to the shop and you don’t remember if you are still under a warranty.
Devices, our new app, is made for this.
Available on the Mac App Store, Devices is amazingly simple. Check out these three screenshots:
You can see, it’s a very simple and intuitive interface. You can add your own devices, add a picture, enter the dates when you bought, and when the warranty will end, and the place where you bought it.
All essential information when you need it.
And of course there’s an open text section where you can add your detailed notes or upgrade information.
We recently published a bill management application for Mac OS, called “My Bills”.
Available on the Mac App Store, My Bills is a simple application that allows you to keep track of all your bills.
You can view the bill entries together, or each bill separately. It’s a great way to overview your expenses related to house or office bills, and it’s super simple to use, the way we like it!
Here are some screenshots that demonstrate the app functionality.
Most of the time the products we make have competitors. If we enter a market with no competitors, maybe there’s no market after all (I’ll let you try). A good market has strong competitors, and most of the times those competitors have pretty strong products that do lots of things.
To find your way on the market it’s a good strategy to remove the fuss, focus on the essential. Maybe the users of the competitors products find them difficult to use, cumbersome and full of unused stuff.
Maybe they just need a simpler way to do their job, and it’s your product that can help them.
Your competitors might think they’ve saturated the market by providing all the user can need within the app, who needs an alternative?
Apps like Clear, the to-do app by Clearmac, really put these things in perspective. There are TONS of todo apps. Yet the succeed with a super-simple, minimal app, yet a big success.
Let’s make Clear-level apps our goal.
We hear from time to time the stories of the outliers: the ones that got a lot of press on launch day, the ones that make viral posts every time they say something.. one in a million perhaps.
Then there are the real people stories, the ones with full-time jobs they need to deal with, the ones that make an app in the evenings, and sometimes they do it, and they strike it big. Outliers too, maybe.
Making a product is really a complicated business, especially if your goal is top quality. Top quality demands top dedication, and often the constrains posed on us make it very difficult to achieve it.
But, we need to stay focused, drop the useless, drop the slightly useful and keep on doing our job, the day when the product will see the light of the day is one day closer.
I used to keep a list of everything.
Just in case.
Even old projects still deserved a little spot in the TODO app of the moment, just to in case I’d revamp them after some time.
I happen to forget everything after a couple of weeks, like if my own memory was a FIFO queue and after some time all the things memorized in the past get thrown away because there’s no space for newer things.
That’s why I keep lists, after all.
Now from time to time I review all the projects in limbo state and decide what to do with them. If it’s not worth it, kill it forever. Don’t keep any reference to it. Not even “just in case”.
There are so many ideas that seem great for one day or two, then disappear into oblivion when there’s a new shiny idea. Talking about little side projects, of course.
Until one side projects grows so big and gets people to use it, we’re always in time for something that looks better.
Don’t get me wrong, I don’t want to get into the ‘agile movement’ argument, nor share my opinion about that.
The title means this: if you’re small, you’re fast and agile. Your cost of change is near-zero, and you can easily jump where the real opportunities arise.
Suppose you’re at the end of a 1-year long project, but no one cares about it no matter what you try to do. You lost a whole year on that thing and now you need to wake up with bad news.
Consider instead if you worked that year on 26 2-weeks-long smaller projects, or 13 4-weeks-long projects. At the end of the year you threw a lot of things at the wall, and now you can see what sticks.
Nothing sticks? I don’t believe it. It’s your problem identifying why is that.
Pick what sticked and expand, drop the dead ends and go on.
That’s nature, only the best trees survive, only the best projects get to grow and prosper.
Building software is not easy if you don’t know the key flows that lead to providing real value to the users.
There are many ways to master those flows, and the most enlightening one only happens when you are a user of your own software.
Building software you’re going to use is key to providing a great value.
The only catch is that sometimes “scratch your own itch” apps are so focused to a super-tiny niche that no one uses them except the creator. Key is having a bigger vision for the app, and keep it more general that you’d want, so it will be useful to others too.
Using yourself the apps you build is one of the best ways I know of ensuring them a long life of nice updates and usefulness for the years to come.