As programmers, we are often told some golden rules about how to do our job. Generally, these rules are technical in nature, or managerial, but they hardly consider the business part of having a software product, or if they do, it’s generally not explicit. We are coders, we deal with code. Money is not our problem, as long as a salary is paid in our accounts every month.

The point of software is to solve a problem someone has. This someone can be you, the community, your employer, a colleague, or a customer. If your software does not solve a problem, it’s pretty much useless. Even a trivial exercise solves the problem of teaching you a new technique.

All this seems trivial, but what most programmers (including myself) often don’t evaluate is if there’s a match between what they believe their audience is, and what is the actual, real world one.

Make it work

This is of course the first step. Very few people are able to sell something that does not work, and that’s generally considered a scam. While some readers may think that Microsoft did it for 30 years, they fail to realize that their products actually solved problems, and that was enough.

If you want your product to have a chance of being successful, it must solve a problem. It can be an extremely trivial problem, but it must do it, and it must do it better than similar products. “Better” is the important and undefined keyword here. Sometimes “better” means cheaper. Sometimes it means “more integrated with an established environment”. Sometimes it means “in a more cool, stylish and edgy way”, and sometimes it means “faster”. the better point must actually matter to your audience.

Make it earn

Here is the second important point, and the one where programmers are mostly incapable off. Making a great product is something a programmer can do. it’s their call. Making it nice is something that UI and graphic designers can do, collaborating with programmers. Both might be talented individuals, but you need someone able to sell the product if you want these programmers and designers to get a salary. Remember that companies do go bankrupt, and every employee costs around 50-80k eur per year. Have 5 people in your staff? that’s at least 250k eur that your product has to earn, per year, to keep the whole thing going. If you sell your product at, say, 15$ per copy, that’s at least 17000 copies to sell per year just to cover the salaries.

Companies don’t go bankrupt for lack of money. They go bankrupt for lack of liquidity. You might strike a deal for next year to earn that money, but it won’t matter if you don’t have the liquidity to pay salaries to get to the end of the year. The company will be bankrupted by then, or will have slashed the workforce so much that it’s no longer able to support the product or the customers, or add new features. Despite what the myth of Agile methods want to teach us, shared code knowledge is impossible to achieve once the codebase grows. Developers are not interchangeable, and every effort to make them so is going to fail on the long run. As a company grows, people will specialize, and will have unique knowledge of the dark corners of your codebase that other developers will not have.

Which leads me to the reason behind this point. Make your product earn money as soon as possible. Everything changes as soon as you start getting earnings. You can observe the trend of demand and respond with more marketing, adjust your product to specific needs (which rings back at the previous point), and have a smaller startup investment. It allows you to fail fast, or to grow accordingly.

This point is hidden in the famous mantra “release it early, release it often”, but as I said, it’s hidden. The hot point is “make it earn money as soon as possible, by solving a problem nobody is solving as well as your product does”.

Make it clean

Once you establish a stable and reliable cash flow, you have to deal with the code you have. This is an often ignored point, and it’s the one that sooner or later will grind your production to a halt, if you don’t take care of it. The salary clock keeps ticking, competition may catch up or take your customers, or people will refuse to upgrade, making your older self a competitor of your newer self. If ignored, it will kill your company.

If you refuse to refactor, and keep piling up code without proper refactoring, the amount of knowledge of the hacks, or the complexity of the logic and the interconnected dependencies will make your coders’ productivity lower and lower. Fixing bugs will take longer. Adding features will take longer. Horrible events such as non-working patches or unstable additions will happen, ruining the reputation you put so much effort into building up, and remember that reputation in business is a huge component. Use well established patterns and best practices, and have developers that care and take pride in quality work.

If you dont’ get trapped in the code quality hole, you will be able to move faster back to square one: make your product work for new customers, or old customers with new demands.