Manage your Bills on OSX

We recently published a bill management application for Mac OS, called “My Bills”.

icon 4256pt

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.

Slice 1

Slice 4

Slice 3

Slice 2

Slice 5



It’s better to have competitors

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.

One day closer

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.

Lists lists lists

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.

Small is agile. Agile is survival.

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.

Software you use

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.

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.