Small is better

I don’t recall how many projects I was involved in stalled because the team tried to put too many things in there – while thinking back, a simpler approach could have lead to a more positive outcome.

Since it’s not possible to predict whether a software we build will be accepted and used by many users, we need to ship as soon as we can our products so we can see if it sticks.

The only way to have a fast release cycle for new products therefore is keeping a very tight scope. Support just one account instead of allowing as many as the user wants. Support a simple search box instead of advanced search functionality. Postpone everything that’s not essential to the app. There’s time for that later, when you have users that demand those functionalities.

Remember that it’s always easier to add stuff later, than to remove things once they’re backed in.

The consequences of an app launch

What happens after an app launch?

Unless you’re a big player, or you’re super lucky and you strike an immediate hit on the market, most always what happens is almost nothing.

Overnight success is obviously overrated, and I know almost no one in the software business that has achieved it. Overnight success takes years to build.

To gain attention and users to your app you need to drive traffic and interested people to yourself, and waiting until your product is out there is always late. The perfect day to start marketing is yesterday, and even if marketing for developers is always hard, it’s something that needs to be done if you want to dream of a little success for your apps over the years to come.

Over time you’ll get to know the real app potential.

If users stick, have good opinions of the app and continue to find it useful, you might have a steady revenue potential, because there’s a chance other people will find it useful.

If users are enthusiasts of your app, over time it might gain a good percentage of the niche you’re targeting, and maybe even become the de-facto standard app to solve a specific problem.

If users are unhappy about the app, you need to realize what are the problems, think and identify where your analysis of the problem failed, and try to correct by releasing newer versions of the app.

If you have too few users, despite all your marketing efforts, your app might become abandonware unless you have specific interests in keeping it alive (that’s why “scratch your own itch” apps are my favourite ones, less prone to be abandoned by the creator). If users are nowhere to be found, you might have picked a niche that’s too narrow for it to thrive, or you’re doing the wrong marketing in the wrong channels to the wrong people. It’s time to decide if it’s worth continue the effort, or learn the lesson for the next apps.

All in all, there’s a lot to learn with an app launch, from both successes and failures.

Stupid ideas

Sometimes good ideas come out of what we think are stupid ideas. Sometimes a new venture starts with a push of imagination, and history teaches us that many companies were born out of nowhere, just because one, two or more folks started doing something that may have appeared stupid to all the other people.

When developing software for the customers, it’s not easy to get in the mind of the user. As developers, we tend to build software for ourselves, and while something might sound to us like a stupid idea, maybe it’s not.

So, sometimes maybe it’s worth exploring things even if we think it’s not worth it, and see what comes out of our ideas and imagination.

One week to build an app

You’re joking, right? One week? It will take months!


I’m not talking about a super-duper vector editing app, obviously, or a GarageBand clone. I’m talking about a small, useful utility application.

I think one week is a great timing: you don’t lose much time, you build on momentum, you are full of energy on your great idea.

One week from start to finish is possible if you already know the tools of the trade, you have a solid base of technology you can build upon, and you have a clear idea in mind.

Let’s write my process for doing things.

Day one? Prototype. Open Balsamiq Mockups and start drawing the user interface of what you’re thinking about. Don’t end until you are 100% satisfied with the design.

If the thing does not convince you, jump ship and try doing some other app idea you have written somewhere in Evernote.

Let’s just not waste weeks for the design. If the app will never see the light of the day, or is not successful as you think, you’re just wasting time.

Once the idea is there, start working on the code. Maxiumum 3-4 days of coding and the app should be 80% there.

Allow for time to think and improve the details, and get ready for shipment.




Yes, the sooner your app sees real users, real customers and real world usage, the sooner you’ll have honest feedback. Forget beta testers and friends, you’ll never know the harsh reality about your apps from them, because they’re afraid to hurt you. Some good one-star review will let you know if your idea works or not.

Then the real work starts.

What happens after the App Launch

Once your MVP is shipped, published and people start downloading it, it’s really curious to see what people think about it.

After all it’s the reason we made it: to be used.

If no one buys the app, it’s like a song that no one will listen: a piece of art, but not really useful. Another idea that sounded great on paper but in practice it’s not much appreciated.

If instead the song gets popular, the app gets downloaded, it’s then that the project takes life on its own.

In your hands you now have a real thing that real people use. It’s time to dedicate more time to is, as bug reports come in, little things needs to be fixed, users demand features. You now have the power to decide its destiny.

Your App launch is the MVP

The best ideas are those that happen in the shower. Why is that? There’s serious science that explains it.

What’s important to note is that those ideas sometimes are just crazy and so brilliant that we must note them somewhere right away, or they’re lost.

The real work is getting those ideas down on paper once you get back to the drawing room, and try to imagine all the details that matter. Got an idea for a great App? Draw all the screens!

Many times those ideas are way better than the ones resulting from months of planning, meetings, feature documents etc etc etc. Let the gut work, and follow it.

Inspiration is the magic that must happen all across the process: idea, mockup, actual development and detail fine tuning.

Once the app takes a presentable form, ship it!

That’s the MVP, your original idea that took form and is ready to be used by people across the globe.

Less. Drop everything that’s not essential

Less is the key to most successful software projects (and not just those).

Less screens. Less things the user has to do to get the job done.

Less features. Drop anything that’s not fundamental to the app functionality. Than take away something more, until the app is so slim that anyone can use it without a user manual (do they still build those?)

Less starts at the front, the interface, and continues behind the scenes. Less code, less libraries, less dependencies, less complicated things to understand and document.

Less time to build it and get it to market, less time to work on it again and make it better in an update.

Drop anything that’s not essential.

Not enough quality products

We’re at the end of 2014, yet the world is full of low quality products. Specifically thinking about the Mac market, there are a lot of high quality apps, but also a lot of awful things. It’s clear if you take a look at the Mac App Store.

Someone needs to fix that.

I’m going to start small, and every day improve this very small portion of the world a little bit.


By building quality products.

Create a serie of little, useful Mac Applications, and sell them for a sum that allows me to continue working on little, useful Mac Applications.

If the Apps I build will be quality products, surely someone, somewhere, will find it useful, and will use it.

My goal will take years to build upon, but one needs to start somewhere, right?