Custom software is software that is usually done for one client, one environment and limited user base. It’s specific use case means, it won’t be sold more than once, which translates to high enough price to cover development costs. And then some.

So why do companies decide to order and pay for custom software over and over again? Custom software has one big advantage over regular off-the-shelf one. It is adaptable to whims and fancies of a customer. Hence, the name custom. Now, here is a public secret. Companies, specially wealthy ones, dig adaptable. You see, where smaller companies don’t have (many) defined processes, big companies are set on tightly defined processes, usually certified by ISO 9001 or similar standard. Off-the-shelf solution is just not an option, as changing a process would cost a lot of money, time and resources.

As a developer with a career in building custom applications, I have done and seen my share of mistakes and fallen into several pitfalls. This series is here to help you (and also future me) avoid them as best as possible.

In part I of the series, I will be blabbering about project architecture and discover last year snow in monolith vs microservices debate. We will cover how to start, how to continue and how to take care of the accumulated tech debt.

Part II will be focused entirely on how to integrate your software with third party software. There is always something to integrate with in custom software business and it is better to be prepared.

Part III will touch the topic of what happens when your custom software gets resold to another and another and another customer. Main focus will be on how to handle new requirements and hopefully not mess up existing and future deployments.

Last but not least, a disclaimer. This series is made of findings I gathered in my career of building custom software. As many things in software, it definitely does not present the only right way. In some cases you might also find it completely wrong. Good. Let me know.