Has someone already done it better?

As developers, we have an incredible privilege: access to an endless array of solutions. From free libraries to paid APIs and ready-made systems that cost as much as an hour of a team’s work. It’s a blessing. But—as with any blessing—we must be careful not to let it become a curse. Like Midas, who delighted in turning everything he touched into gold—until he touched something he shouldn’t have.

Decisions to “build, buy, or rent” are usually associated with business dilemmas like warehouses, fleets, or offices. But in our industry, this question takes on a more technological form—choosing a framework, library, or boilerplate. Should we write something from scratch? Or integrate a ready-made solution? In an era of cheap, readily available products, this dilemma is more frequent than ever.

Not all technological decisions are equal. Choosing Cron to run a simple hourly process may seem straightforward—until the business asks that process to do X, Y, and Z. Then you hear, “We should’ve done this differently.” Who’s to blame? It doesn’t matter—what matters is that now it’s a problem for the business, you, and soon the customers.

It’s similar with bigger decisions: you choose a queuing system that doesn’t support LIFO, and suddenly the business needs it. Or you go with WooCommerce for an online store, and then you hear, “It’s too slow!” Sounds familiar? That’s why we are all responsible for choosing technology—developers, managers, and business owners. Our decisions have real consequences, and their effects will come back to us sooner or later.

Of course, you could argue that managers are responsible for business decisions—it’s their job, after all. Unfortunately, it’s not that simple. As a developer, you’re also responsible if you don’t inform the manager about the potential consequences of a chosen solution. If you don’t mention that integrating with a specific API involves trade-offs like dependency on an external provider, lack of system control, risk of price increases, or even blocked access during issues, who will be blamed when everything falls apart?

Examples abound, especially in today’s world, where outsourcing functionality has become the norm—from payment systems to databases to entire infrastructures. It’s no coincidence we see the rise of serverless solutions—today, you can rent almost everything that forms the foundation of your business. But this requires making informed decisions and carefully distinguishing what is essential from what may become a problem in the future.

It’s a bit like the English saying: “Measure twice, cut once.” The choices you make today can determine future success or failure—that’s why we need to learn to minimize risks and align technologies with real business capabilities and goals.

How to make a good decision

Over the years, I’ve observed how similar problems arise in various projects. Always the same chaos: some want an “off-the-shelf” solution, others demand “full control,” and there’s always a boss on the horizon wanting a free solution… ideally yesterday. To bring order to this process, I created a simple framework that helps developers think more business-mindedly and make better technological decisions.

Choose what’s best for you

Start by choosing the solution that’s easiest and most sensible for you as a developer. This could be the cheapest option, the fastest to implement, or the one that best fits the existing architecture. This is your first intuitive choice for implementation. You already know why you’re choosing it: perhaps due to a lack of team competencies, time constraints, or simply its simplicity.

But don’t stop here. Now comes the hardest part—analyzing how this solution will impact the business. Why is this difficult? Because developers rarely think in these terms. Even you, dear reader, might think integrating with X is a great idea, but are you sure it’s the best solution for the business? Here’s what you need to consider:

1. Trade-offs

   What compromises must you accept if you go with this solution? This includes constraints for customers and the company’s growth. For example: does the chosen API impose restrictions that will hinder future development? Might one feature need some tweaks to accommodate this solution? Does its integration require changes from the business that may be inconvenient for them? Does this choice erect “walls” around the further development of your product?

2. Risks

   What risks does this solution bring? These could be technical issues like lack of support, security vulnerabilities, or insufficient documentation. But look beyond: what costs will it generate in the future? How will it impact customers, such as login issues, lack of archival functions, or slow performance? Remember, for the business, any customer difficulty can mean potential revenue loss.

3. Benefits

   Finally, look at this solution through the lens of business benefits. Will implementing it save time and money? Does it eliminate everyday problems the company struggles with? Or does it introduce value customers will appreciate? Sometimes solutions don’t bring direct business benefits but minimize team frustration and increase work efficiency—which also holds value.

Why is this important?

Analyzing these three points allows you to make more informed decisions. This way, you’ll know what limitations your choice carries and what risks may come with it. Such analysis is not just about technical utility but also understanding the long-term impact on the business.

It’s no surprise that many companies abandon solutions that are theoretically good technologically but practically lead to problems, like account blocks by external payment providers. These are situations that can sink an entire business.

On the other hand, be realistic—not every decision will be perfect, and compromises are unavoidable. But with a clear picture of the risks, you can make decisions that minimize risk and maximize benefits.

Summary

A developer is not just about code—your technological decisions impact the business as much as decisions by managers or business owners. With thoughtful approaches, you can avoid chaotic choices and build trust between technology and business. Sometimes the best solution is a ready-made product, and other times it’s building from scratch. The key is knowing when to apply each approach.

Don’t reinvent the wheel, unless you must.

Alex