Deciding on Technology

Deciding what type of technical solution to use is always shaped by three main constraints: the limits of technology, the capabilities of the team, and the long-term needs of the organization. Each introduces uncertainty, and understanding their role is critical.

Limits of Technology

For most application and web development, technology isn’t the limiting factor. Nearly every problem has multiple viable solutions already available. Real limits usually appear in fields like AI, game development, physical sciences, medical tech - in other words, domains where we are reaching the limits of known technology.

For the rest of us, the real challenge isn’t whether the technology exists, but which technology to choose. And that choice depends heavily on many things but, in particular: the capabilities of the engineering team responsible for it and the goals and guiding vision of the organization.

Capabilities of the Team

Most teams don’t get to build a new group from scratch. They inherit an existing set of skills, interests, and bandwidth. While many engineers can stretch into new areas, not all want to-and even when they do, new stacks introduce cognitive load, context switching, and long-term maintenance costs.

Because of this, leaning toward familiar technologies often makes sense-even at the expense of some performance. For instance, choosing C++ or Rust for CPU-intensive APIs might seem tempting, but if no one on the team knows those languages, the gains would need to be extreme to justify the cost. You’ll likely need to hire or rely on a single fast learner.

And even once the solution is built, you need to plan for who will support it. That’s where organizational context becomes decisive.

Vision of the Organization

An organization’s goals and identity shape which technical burdens are worth carrying. Complexity is easier to justify when building solutions core to the business mission, but less so for commodity functions.

Take feature flagging as an example. Most companies don’t need to reinvent it. Commercial systems like LaunchDarkly or Flagsmith already solve the problem at scale, with analytics, targeting, and governance built in. Building your own is rarely worth it: you’ll end up replicating functionality that’s been solved many times over, and divert resources from areas that actually differentiate your business.

But there is a place where some complexity may be necessary: integration “glue.” It’s unlikely that an off-the-shelf product will perfectly align with your company’s specific workflows, data flows, or brand experience. Retailers, for example, often need to stitch together ecommerce, marketing, analytics, and CMS platforms in ways that streamline internal workflows and reduce friction for end users. The complexity there is unique to the business. That’s where custom engineering effort does pay off-because the integration layer is where your company’s differentiation actually lives.

In other words, not all complexity is created equally. Commodity systems are best outsourced; the “glue” that ties them together often justifies custom investment. This “federated architecture” approach accepts that no all-in-one solution will fit and requires careful planning.

Planned vs. Unplanned Complexity

Why not just pick an all-in-one vendor solution? For some organizations, it’s the right call-especially if customization isn’t a priority and the solution can hold up for the next few years.

But vendors often overpromise. “Highly configurable” usually translates to expensive and painful to implement or maintain. Just because you can configure something doesn’t mean you should.

The key difference is whether complexity is planned or unplanned. Planned complexity means you know upfront that engineering investment will be needed to build and maintain a solution. Unplanned complexity creeps in when you start simply, rely too much on vendor promises, and end up with brittle systems that aren’t future-proof after ad-hoc additions of customizations.

Final Thoughts

For companies that are building technology to support the business and not building a business around a technology, choosing the right technical solution is rarely about chasing the newest tech. It’s about balancing what’s possible with what’s practical - measured against the skills of your team, the priorities of your organization, and the long-term cost of complexity. Think hard about building commodity solutions. Differentiation usually lives in the glue: the integrations, workflows, and user experiences that set your company apart. By approaching these decisions with intention-understanding where to accept simplicity and where to invest in complexity-you avoid short-term wins that turn into long-term burdens and instead create solutions that serve both the business and the people who build and maintain them.