Technology Decisions for Growing Companies

Technology decisions are among the harder kinds of decisions companies face — not because the technical options are that complex, but because they involve genuine uncertainty about the future, real trade-offs between competing goods, and a lot of pressure to look decisive.

What follows is not a playbook. It is an attempt to describe how I think about the decisions that come up most often, and what makes them easier or harder to get right. The right answer in any specific situation depends on context that I can not know from here.

Build vs. buy

This is the question that comes up most often, and the one that gets the most confidently wrong advice. The correct answer depends on a combination of factors that most frameworks oversimplify.

The standard advice is: buy commodity, build differentiation. That is broadly right but too coarse to be useful. The interesting question is which things are actually differentiating for your specific business at this specific stage.

A few things worth thinking through:

What does "build" actually cost? The direct cost of building something includes development time, but the ongoing cost — maintenance, upgrades, support, documentation, onboarding — often exceeds it. Software that runs for three years costs roughly three years of maintenance, not three months of development.

What does "buy" actually constrain?Vendor lock-in is real but often overstated. The question is not "could we switch?" but "what would we lose, and at what cost, if we needed to?" For most SaaS tooling, the switching cost is manageable. For deeply integrated infrastructure components, it is not.

What stage are you at? A company finding product-market fit has different build-vs-buy calculus than one that is scaling a proven model. In the former, buying almost everything and moving fast is usually right. In the latter, the economics of some components shift, and building in-house becomes more defensible.

What is the team good at?Building something means someone has to own it. If the team does not have the expertise to build it well, "build" means building a mediocre version that you maintain indefinitely. Sometimes buying a good solution is just more honest about your constraints.

Cloud infrastructure decisions

Most companies face a version of this decision multiple times as they grow: which cloud provider, how much managed infrastructure versus custom, how much to invest in platform engineering versus shipping product.

Provider choice

AWS, GCP, and Azure are all mature enough that the choice between them matters less than it used to for most use cases. The decision is usually better made on team familiarity, specific service requirements, and commercial terms than on abstract capability comparisons.

Multi-cloud is often presented as a risk management strategy. In practice, it significantly increases operational complexity and is worth doing only when you have a specific requirement that justifies it — regulatory, geographic, or contractual — not as a default.

Managed services vs. self-managed

The trend toward more managed services is, in my view, correct for most companies. Running your own Kubernetes cluster, your own message queue, your own database cluster — each of these requires operational expertise and attention that most teams should not be spending.

The exceptions are usually cases where the managed service does not match your performance requirements, where the cost at your scale becomes prohibitive, or where you have very specific compliance requirements that the managed service does not meet.

Platform investment timing

This is one of the harder sequencing questions. Investing in platform infrastructure too early means you are building for a future architecture that may not materialise. Investing too late means you are operating with fragile manual processes as you scale.

A rough heuristic: when you notice that your deployment process is a recurring source of friction, when incidents are repeatedly caused by inconsistent configurations, when onboarding new services takes longer than it should — those are signals that platform investment is lagging your needs.

Technical debt

Technical debt is one of those terms that gets used so broadly it has almost lost meaning. It is useful to distinguish between a few different things that often get lumped together.

Intentional debt is a deliberate trade-off: you take a shortcut now because the value of speed exceeds the cost of the shortcut. This is often correct. The problem is when the debt is not acknowledged, not tracked, and not paid down when the value/cost ratio flips.

Accumulated complexity is different. It is the result of many reasonable decisions made without full visibility into each other — code that made sense when written but has become opaque through layered changes. This is harder to address because there is no single decision to reverse; you are untangling a knot.

Outdated dependencies are their own category. Security vulnerabilities, deprecated interfaces, end-of-life dependencies — these tend to accumulate silently until they become blocking.

How much technical debt matters depends heavily on what it is slowing down. Debt in a part of the system that nobody touches is a theoretical concern. Debt in the critical path for deploying new features, or in components that have frequent incidents, is real cost. It is worth being specific about where the debt actually is and whether it is causing real friction before allocating time to address it.

When to get outside perspective

I am obviously not a neutral party here, but I will try to be honest about this.

Outside perspective is most useful when:

The problem is hard to see from inside. Teams develop blind spots — areas where the current approach is so embedded that alternatives are hard to imagine. An outsider who has seen a lot of different situations can sometimes name things that are hard to name from inside.

There is a specific decision with high stakes and limited precedent.Architecture choices, make-vs-buy decisions on significant components, technical due diligence for M&A — these are situations where the cost of being wrong is high enough to justify the cost of getting an independent view.

The team lacks specific expertise for a particular phase. A team that has never scaled past twenty engineers faces genuinely novel problems at fifty. Someone who has been through that transition can compress the learning curve.

Outside perspective is less useful when the problem is primarily one of execution — something you already know how to do and just need to do — or when the bottleneck is something other than a technology decision.

I am more useful as a thinking partner on decisions than as someone who tells you what the right answer is. Most of the time, the people closest to the problem have better information than any outside advisor. What they sometimes lack is a framework for thinking through it, or an external perspective to pressure-test against.

A few things I have found useful

These are not rules, but they come up often enough to be worth naming.

Separate the decision from the timing. The question of whether to do something and the question of when to do it are different questions. Treating them as one tends to produce either premature decisions or delayed ones.

Write down what you think is true and why.Technology decisions are often made in the middle of other pressures, without anyone recording the assumptions behind them. When the situation changes, those unrecorded assumptions become invisible constraints. A short written record of "here is what we decided, here is what we believed at the time, here is what would change the decision" is worth more than it costs.

Distinguish reversible from irreversible. Reversible decisions can be made faster with less information. Irreversible ones — or ones with high reversal costs — warrant more deliberation. Most technology decisions are more reversible than they feel in the moment.

Be honest about what you do not know. Technology decisions often involve genuine uncertainty about the future. Acknowledging that uncertainty — rather than collapsing it prematurely into false confidence — tends to produce better decisions and better preparation for when things turn out differently than expected.