How Should Technology Be Chosen for a New Digital Product?

Choosing technology at the start of a product attracts more energy than almost any other early decision.

Not because the decision is unimportant. Because every decision gets treated as equally weighty: the data model and the UI component library are discussed in the same meeting with the same seriousness. One of them will outlive several rewrites; the other can be swapped over a weekend.

A more useful frame is to sort choices by how reversible they are. The effort spent deciding should be inversely proportional to how easily the decision can be undone.

The ones that are hard to undo

Some decisions spread through the system over time, and removing them later amounts to rebuilding. This is where the thinking belongs.

The data model. How data is structured determines what the product can do later. A badly modelled relationship gets compensated for with an endless supply of workarounds in the application layer. Changing the database product is hard; changing the shape of the data is harder.

Hosting and the runtime model. Where and how the system runs — your own servers, a managed platform, something serverless — affects everything from deployment to monitoring. This decision is as operational as it is technical: who intervenes, at what hour, with what access?

Identity and authorisation. Who users are and what they can reach touches every layer of a product. Changing it later usually means migrating data as well.

Depth of coupling. Using a provider and shaping your product around that provider's concepts are different things. The second quietly inflates the cost of ever leaving.

For these four, the question to ask is not which option is most modern but what the exit looks like if this turns out to be wrong.

The ones that are easy to undo

Plenty of other choices are local and bounded: the component library, the styling approach, the test runner, formatting rules, and in many cases the application framework itself.

These are not trivial. But when they turn out badly, the cost stays at the level of a module or a screen. Long deliberation in this category costs more than it saves.

The practical rule is straightforward: for reversible decisions, choosing quickly and moving beats searching for the best option.

For the hard ones, a small experiment usually resolves things faster than a longer discussion. A few days of prototype — against the shape of your real data, your most awkward query, or your most critical integration — settles most of what a meeting would spend weeks on. The point is not to produce code but to test an assumption; the prototype can be discarded afterwards.

Team capability is an input, not a constraint

The most frequently ignored variable in these discussions is the people who will use the technology.

A tool the team already knows usually produces better outcomes even when it looks weaker on paper. With a familiar tool the team is only solving the product; with an unfamiliar one it is learning the product and the tool simultaneously, and many of the decisions made in those first months get reversed later.

This is not an argument against ever learning something new. It is an argument for putting the cost of learning into the plan. Left out, it reappears as delay and is usually attributed to the wrong cause.

The second question is hiring. How easily can you find people to work with this? For small teams that constraint surfaces a couple of years in, at the point where it is most expensive to solve.

Requirements come before trends

A technology being popular does not make it right for your problem. Popularity is not meaningless either — more users means more solved problems and better documentation.

The right order is to write the requirements first. Does the product need to be real-time, will there be heavy concurrent writes, is reporting demanding, does anything need to work offline? Answering those narrows the field quickly.

Without written requirements the discussion inevitably drifts toward preference, because there is nothing concrete to compare options against.

Running the thing is also a selection criterion

Technology is usually evaluated on the development experience: how pleasant it is to write, how rich the ecosystem is. Once the product is live, most days are spent not writing it but running it.

The questions on that side are different. How does a new version go out, and how long does rolling it back take? When something breaks, where do you look — do logs, metrics and error tracking come with it, or are they a separate project? Are there backups, and has a restore ever actually been tried?

The answers depend far more on the runtime model than on the language. A managed platform absorbs much of this burden and takes some flexibility in exchange. Running your own infrastructure does the reverse: more control, and more responsibility.

For small teams the deciding question is usually this: at three in the morning, how many people can respond when something breaks? If the answer is one, any choice that reduces operational load is the right one even when it looks technically weaker.

Write down the scale assumption

Two opposite mistakes get made about scale, and both are expensive.

The first is building for load that never arrives. It delays the first release and spends the team's attention on solving a problem that does not exist yet.

The second is ignoring a constraint you already know about. If the product is going to run at a particular volume on a particular date — a campaign, a season, an enterprise customer going live — learning that afterwards costs considerably more.

The way through is to write the assumption down rather than estimate it privately: what volume is expected in the first year, where that number comes from, and at what threshold the architecture gets revisited. Those three sentences prevent most of both the unnecessary complexity and the unnecessary surprise.

Ecosystem and continuity

Choosing a tool means looking not only at what it does today but at what stands behind it.

The signals are simple: are releases regular, do security updates arrive promptly, do questions get answered, is it supported by more than one organisation. Tools maintained by a single company or a single person are not bad — they carry a different risk, and that risk should be taken knowingly rather than by accident.

For commercial products the same question is asked through pricing and data portability. We looked at that side separately in custom development versus an off-the-shelf platform.

Writing down the decision and the reasoning

The most skipped step in choosing technology is not the choice but the record of it.

When nobody a year later can answer "why did we pick this," one of two things happens: the decision is treated as untouchable and defended past its usefulness, or it is changed at the wrong moment because the context was lost.

The record does not need to be long. Which options were considered, which requirement was decisive, which trade-offs were accepted, and under what conditions this should be revisited — a few paragraphs will do.

The habit also ends arguments. When the topic is reopened six months later, the conversation resumes from the record instead of from nothing.

The most valuable part of the record is usually the options that were rejected, because that is where the answer to "why didn't we just use X" sits a year later.

In closing

Choosing technology is rarely an exam with one correct answer. Most products can be built successfully with several reasonable options.

What separates outcomes is not the choice but how it was made: knowing which decisions are permanent, moving quickly on the ones that are not, and leaving the reasoning behind in writing.

In our software consulting work, this discussion usually opens not with a list of tools but with a question about which decisions will still be in place two years from now.