Last week, I wrote this because, interestingly, in my last three meetings, customers focused on in-house developed applications.

All three proudly mentioned how cheap and customized they were. They even spoke about them with such excitement.

I have seen this countless times, and it usually doesn’t end well—especially if your company’s core business isn’t technology.

I hope to share some insights you might find useful.

So let’s dive in.

Remember, you're relying on custom applications built by just one or a few people.

You've become dependent on the people who built these applications, making upgrades and maintenance difficult without them.

Hiring replacements isn’t simply plug-and-play.

It takes time to learn any codebase. If documentation isn’t done properly, it becomes nearly impossible. So, what do you do then?

In my experience, most coders without formal training don’t document well.

Do you plan on offering a competitive compensation package?

Check with your HR to see if you can offer competitive packages. There’s a reason programmers have lucrative salaries: they are few in number and in high demand.

If they’re underpaid, they become flight risks.

When they decide to leave, you're forced to improve their packages because of your complete dependence on them.

This then becomes a cycle until they finally leave.

By now, we’ve established the costs associated with people. Now, let’s move on to the costs of highly customized applications.

Custom applications have a coupled architecture with complex workflows.

When you change a coupled application, it is linked to many workflows or departments.

Changing one part affects another part. Because of this, it feels easier not to make changes to avoid breaking things.

Breaking things = impacting the business.

As a result, this creates a cycle.

Instead of moving away from it, companies continue to build on top of it.

On the other hand, off-the-shelf applications are often decoupled. When you need to replace something, you only have to replace that specific software.

If these reasons are not enough…

When you reach the point of having to replace it, are you prepared for the impact of its failure?

Most companies decide to change when it’s too late. How much downtime is acceptable for your company?

This is especially important for critical software related to sales, logistics, or operations, as the impact on the business can significantly affect sales or customer service.

But…

I'm not saying that in-house developed applications are bad practice, but it's important to seriously consider whether they are truly necessary.

I always recommend…

If it will give you a competitive advantage, then it’s worth considering.

That’s it for this week! See you next Tuesday!

Ciao!