The small software project you are working on today, may become far more important than you think. What begins as a simple tool for a handful of users, can evolve into a business-critical system that people depend on daily. As its importance grows, so does your responsibility to maintain it, improve it, secure it, and support its users - possibly for many years to come!

I don’t consider myself a professional programmer. There are certainly people far more gifted than I am, but that hasn’t stopped me from creating some genuinely useful programs - and a few that have even been commercially successful.

Historically, if you wanted to create an application, you first had to learn a programming language and becoming proficient enough to build anything substantial could take years of dedication. AI has lowered that barrier significantly, but it hasn’t removed the responsibilities that come with creating software. Just because you’re vibe coding your own application doesn’t mean that you shouldn’t follow proven software development practices.

These are some of the things I’ve learned (sometimes the hard way) that I wish I had known when I started. And buckle up because this isn’t going to be a short post.

The backstory

In 2010, while I was working full time for Sonovision Studios, I created what I thought would be a small line-of-business application called SPM (Sonovision Production Manager).

The company had several manual processes that were inefficient and required the same information to be captured at multiple points in the billing workflow. Audio post-production is quite a niche business, and at the time there weren’t any commercial software products that did exactly what we wanted.

So I picked up a book on VB.NET and SQL Server to brush up on my programming skills, and proceeded to write the first version over the December holidays. I had no formal plan, only a picture in my head of how I thought all the pieces should fit together.

Fast forward to 2026, and SPM is now an integral part of that business. It handles everything from quoting to invoicing and even automatically issues purchase orders. I’ve had incredible support from the team at Sonovision over the years, and SPM has evolved into an application that I’m incredibly proud of.

It has also taught me that useful software has a habit of outliving your expectations. What began as a holiday project is still being used 16 years later. It has survived multiple versions of Windows, changes in business processes, compatibility problems, feature requests and countless updates. Creating the first version was only the beginning.

Resist the temptation to reinvent the wheel…but sometimes don’t

Great software empires have been built because someone woke up one morning and thought, “You know, I can do a lot better than this!”…and they did.

Innovation often comes from someone being dissatisfied with the status quo. You may have a genuinely unique idea, or a vision for doing something far better than the software already available. You may also operate in a niche where the problem isn’t that the existing software is bad, there simply isn’t any. In those cases, creating your own application may make complete sense.

At the same time, you need to resist the temptation to develop your own software whenever a perfectly good solution already exists.

Understand that the software you create always comes with a cost, and the primary cost is your time. You’ll spend a significant amount of time creating and perfecting your application. You’ll spend time supporting and training users, responding to feedback and adding new features. You’ll also need to deploy and monitor the software, perhaps even maintain the infrastructure behind it, and ensure that both the application and its data are properly backed up.

It’s an ongoing and relentless cycle. There is always something to do! And when something breaks, you’re responsible. Need a mobile application now? Guess who gets to build it. Eventually, you may need to hire someone to work on the project, or outsource parts of it so that you can free up some of your own time.

The point I’m trying to make is that the decision to create your own software shouldn’t be taken lightly. It might save you from paying someone else a licence fee, but that doesn’t make it free.

Don’t let me discourage you from creating your software masterpiece though. If everyone thought that “good enough” was fine, there wouldn’t be any innovation.

At the same time, it may be more productive and profitable to spend your time elsewhere and focus on problems that don’t already have perfectly good solutions.

Who owns the code?

If you’re developing an application for the company you work for, you should agree in writing who owns the code before you start.

This is particularly important if you expect to retain the rights to the application. You may want to keep ownership because you believe the software could later be sold or licensed to other companies.

People often assume that because an application is a special project, wasn’t explicitly included in their job description or was partly developed after hours, that they automatically own it. That may not be the case.

Under South African copyright law, the general position is that copyright in work created by an employee in the course of employment is owned by the employer. Whether a particular project falls within the course and scope of employment will depend on the circumstances, and your employment contract may contain additional intellectual-property assignment clauses. Some employment contracts claim broad rights over software and other intellectual property created during your employment, including work that may not fall within your usual duties.

If you’re developing an application in your spare time that could compete with your employer, use company information or create a conflict of interest, review your employment contract and get proper legal advice before you start.

It’s far better to reach an agreement about ownership at the beginning, than to argue about it after the application becomes valuable. Litigation is expensive, and disputes over intellectual property can permanently damage relationships and your bank balance.

The work only truly begins after your first release

It’s easy to look at the first working version of your application and think, “It’s finished!” It isn’t. Your first release is the point at which the real work begins.

Until then, the application has probably only had one particularly enthusiastic user - you. Once other people start using it, they’ll find bugs, ask questions and use it in ways you never expected.

They’ll also have ideas. Some of those ideas will be excellent. Some will be completely impractical. Some will be downright stupid. But rest assured, this is point at which you start to pay for your design decisions.

If the software becomes successful, the business will gradually become dependent on it. Processes will be designed around it. Staff will expect it to be available. Management will want reports from it. It may even need to integrate with other systems.

Eventually, what started as a convenient little tool may become the system that stands between the business and its ability to send invoices, service customers or complete its work.

At that point, you’re no longer maintaining a side project. You’re maintaining business infrastructure.

Plan for 5 - 10 years - not just next week

When you start, it’s tempting to focus on getting the first version working as quickly as possible.

That makes sense when you’re experimenting, but if the application becomes a valuable tool, it could remain in use for five, ten or even twenty years. The shortcuts you take today, may become the late nights you spend rewriting things properly in the future.

There are countless businesses that still depend on legacy applications that they can’t easily replace. The software may be old, difficult to maintain, and based on technology that is no longer widely supported, but the business has become deeply entrenched in it. Replacing it now would require years of work, significant expense and major changes to established processes.

So its worth thinking beyond your immediate goal, and properly thinking about the foundations you are building on.

Will the programming language still be supported? Are you relying on an obscure framework or poorly maintained dependencies? Is the application tied to a particular operating system or database server?

When I created SPM, I chose VB.NET because it seemed like the quickest and easiest language for the job, particularly since most of the company’s administrative computers were running Windows. I also chose Microsoft SQL Server because the organisation already had an existing SQL Server environment. I’ve frequently regretted the decision to use VB.NET as making the application available to our macOS users has required several workarounds involving Remote Desktop Services. Using VB.NET and MS SQL trapped me in a Windows only ecosystem.

You can’t predict everything that will happen over the next decade, but you can avoid making choices that unnecessarily trap your future self.

Documentation from day one!

When you’re creating an application, everything makes sense because the details are still fresh in your mind. But will you remember all of that in 6 months? How about 3 years? Probably not.

A README file is a good starting point, but its not the end either. Document your application’s structure, key design decisions and dependencies. Explain how to set up both the development and production environments, how releases are deployed, and how the system can be recovered if something goes wrong.

And no, a conversation you vaguely remember having with an AI assistant six months ago is not documentation.

Put comments in your code. Sometimes code looks unnecessarily complicated until you discover that it was written that way to work around a very specific problem. Well-placed comments explain not only what the code does, but why it does it, saving your future self time and maybe even others.

Trust me, when you’re troubleshooting an obscure problem and open a source file you haven’t touched in five years, you’ll be very grateful for the notes and comments you left for your future self.

Source control isn’t optional

Having one folder that is constantly being updated and overwritten is a terrible idea. So is creating multiple folders each time you make a change. That isn’t source control. It’s a cry for help.

Having only a single copy of the project stored on your laptop is also a massive risk. If your laptop is lost, stolen or suffers a hardware failure, the source code goes with it.

Backing up your source code is important, but source control gives you far more than a backup.

You’re going to be making incremental changes to your application regularly. At some point, while adding a feature or fixing a bug, you’re going to break something significant. Would you rather spend hours trying to undo your changes manually, or return to the last known working version of the code?

A source control system such as Git, together with a platform like GitHub, allows you to track exactly what changed, who changed it and why. You can create branches for new work, compare versions, collaborate with others and quickly return to an earlier stable release when something goes wrong in production.

If you’re serious about your project, I strongly recommend taking a short detour to learn Git and GitHub properly. The time you invest upfront will save you a great deal of frustration later.

Don’t develop directly in production

Everyone has a development environment. Some people are fortunate enough to have a separate production environment.

When you’re the only person using an application, it can be tempting to make changes directly to the live system. That habit becomes increasingly dangerous as more people begin to depend on it.

You should have a separate environment where you can develop and test changes, without affecting production. In time, you may also want a staging environment that closely resembles the live system where you can conduct extensive testing.

Before releasing an update, know how you’ll roll it back! Updates fail. Dependencies behave differently. Database migrations go wrong. A feature that worked perfectly on your computer may fail as soon as it encounters real-world data.

Being able to return quickly to the previous stable version is far better than trying to repair a broken production system while users wait.

Backup more than just the source code

Your source code may be safely stored in Github, but that doesn’t mean the application is properly backed up.

What about the database, uploaded files, configuration settings, encryption keys, and other information needed to rebuild the system?

A good backup should allow you to recover the entire service to a point in time, not only the source code! You should also test your backups periodically.

Think through what would happen if your server / hosting environment disappeared tomorrow. How long would it take to rebuild the application? Would you know which version to deploy? Could you recover the data?

Build it-but understand what you’re signing up for

When you build your first real application, everything is exciting. You’ve probably received a few pats on the back, but the whole company isn’t dependent on it yet. You haven’t spent a weekend troubleshooting a serious problem. Nobody is waiting for you to restore access so that they can send invoices.

The difficult part is maintaining it, so plan for the long haul from day one.

Operating systems change. Security vulnerabilities are discovered. Dependencies stop being maintained. Business requirements change, and users continue to ask for improvements.

Being able to maintain software is ultimately more important than being able to create it.

SPM has now been through multiple Windows versions and years of compatibility updates. Keeping it working has required far more time and discipline than creating the first version did.

AI has changed who can create software. It hasn’t changed what it means to own and support software.

By all means, build the application that solves your problem. Experiment, learn and create something useful. Some of the best software begins with one person trying to fix a problem that everyone else had simply accepted - but follow good development practices from the start.

Most importantly, remember that the small side project you’re working on today may not remain small.

The moment other people begin to depend on it; it becomes more than a piece of code - it becomes a responsibility.