Learning from your own experiences is priceless. We’ve all made our share of blunders, myself included. While sharing tales of our missteps might provide some comic relief, the real value lies in the lessons learned. You don’t forget a mistake when you’ve had to deal with its consequences.

Speaking from firsthand observation, it’s not uncommon for developers to roll out code live, often hastily, to meet pressing business deadlines. The urgency tends to outweigh any considerations for the potential havoc it could wreak on a production environment. These situations occur more often than you might think.

As a project manager, I’ve seen the freemium model become increasingly popular in the software development community. The idea is simple: offer a basic version of your product for free, and then charge for premium features or additional functionality. This model has worked well for some companies, but I believe it’s a risky proposition for most startups.

Here are a few reasons why:

It’s difficult to attract enough users to generate a reliable revenue stream. In the crowded app and webapp space, it’s getting harder and harder to stand out from the crowd. Even if you do manage to attract a large number of users, it’s no guarantee that they’ll be willing to pay for your premium features. It’s difficult to get users to upgrade to a premium plan. Once users have gotten used to getting your product for free, they may be reluctant to pay for it, even if they’re getting a lot of value from it. It’s difficult to provide good customer support. When you have a large number of free users, it can be difficult to provide them with the level of customer support they need. This can lead to negative reviews and a poor user experience. I believe that startups are better off focusing on building a fantastic product and charging for it. This may seem counterintuitive, but it’s actually the best way to ensure long-term success.

Like many conveniences in software development, a shared database is a tar pit waiting to fossilize a project. Developers overwrite each other’s changes. The changes I make on the server break the code on your development machine. Remote development is slow and difficult. Avoid using a shared database at all costs, as they ultimately waste time and help produce bugs.