Don't build it yourself

Let’s say you want to sell fitness supplements.

❌ Don’t build a shopping website.

Let’s say you want to create a novel dating app.

❌ Don’t build a credit card processor.

Let’s say you want to start a SaaS business.

❌ Don’t build a container orchestrator.

Use off-the-shelf solutions whenever possible and work around the limitations.

It’s a common misstep for engineering teams to roll out a custom solution just because one feature doesn’t precisely fit their use case.

If you hear this phrase: “But we’re unique [this way], so what’s available is not good enough” — that’s a red flag.

If you already have a system in your stack that could be replaced by something off the shelf, investigate whether it’s time to chop it.

The thing is…

Imagine how far ahead you would be if you focused most of your engineering resources on solving the business use case unique to your business.

Tech strategy is not about deciding what to build. It’s mostly about defining what not to build.

The more effort you can expend on solving the problem domain unique to your business, the farther ahead you’ll be.

Here’s a funny way to look at it.

The internet boom was easy because the infrastructure was already in place.

Imagine how fast Amazon would grow in the 1990s if, instead of starting with e-commerce on top of the internet, they’d start with the infrastructure because they didn’t like TCP/IP.

Not very fast.

P.S. I’m passionate about this because we, as engineers, love to solve problems with code and are incredibly creative in justifying the need for a custom solution.

I’m shouting this because I often need to remind myself of this. I have a /home/taj/dev folder full of started custom projects. 😅

What’s a project you regret building custom after it became much harder than you’d thought it would be to build? Let me know.

Best regards,

Taj

All writing