The Questions to Answer Before Choosing Any Technology

There is a moment in every digital project when the team sits down to choose technology. They evaluate vendors, compare features, request demos, and review pricing. It is a moment of high energy and low visibility: decisions are made focusing on what the tool does and rarely with clarity about what the system must sustain.

When this conversation happens without answering some prior questions, the chosen technology answers them by default, according to its own logic. And default answers rarely match what the business actually needs.

The Order Is Not Arbitrary

In the previous articles of this series, I argued that the most common problem in digital growth is not the lack of tools but the absence of systemic architecture, and that designing the ecosystem before implementation is the condition that allows that ecosystem to grow without breaking.

What follows is the concrete level of that idea: four questions that must be answered before choosing any technology. They are organizational design questions that, when not formulated in advance, technology ends up answering by default.

The order in which they are asked matters. Each builds on the previous one.

First Question: Where Does the Business Logic Reside?

Every organization has its own rules: how prices are calculated, which conditions apply by customer segment, how available stock is determined, what criteria govern promotions. These rules define the business with the same precision as any strategic document.

The question is whether those rules live in a place the organization controls or whether they are embedded in the data model of an external platform.

When this question is not answered before implementation, the vendor answers it: business logic ends up stored where the system allows it, structured according to categories that do not always match the reality of the operation. Changing a rule later requires first understanding how the system interprets it, turning every business change into a technical project.

It is a pattern we see frequently: pricing logic lives in three different places at once, each department assumes its version is the valid one, and no migration solves the problem because the original omission was not technological but structural.

Second Question: How Does Information Flow Between Areas?

Information has producers and consumers. The marketing team produces campaign data; the commercial team consumes it to understand customer behavior. The ERP produces stock data; e-commerce consumes it to show availability. Logistics produces delivery data; the customer experience team consumes it to manage claims.

When those flows are not defined, each area works with its own version of reality. Teams synchronize manually, through spreadsheets or exported and re-imported reports. Decisions are made based on data that do not necessarily match each other.

The question is not technical in its formulation but has direct technical consequences. Defining who produces each piece of data, who consumes it, and where it lives as the source of truth determines how systems are integrated and which events trigger synchronizations. Without that prior definition, integrations are built to respond to symptoms rather than solving the underlying cause.

Third Question: Which Parts of the System Can Change Without Affecting the Rest?

This is the question of modularity, expressed in business terms.

Businesses change. Channels multiply, markets evolve, competitive conditions force adjustments in pricing, processes, or team structures. The ability to adapt to these changes without destabilizing what already works is not an accidental technical attribute: it is the result of having designed it in advance.

When this question is not answered, the cost of any change becomes unpredictable. Adding a new channel requires touching the system’s core. Changing a payment provider requires reviewing the entire order flow. Every intervention creates lateral risk because dependencies are not clearly defined.

The concrete answer defines which elements are core — they must remain stable because everything else depends on them — and which elements are peripheral: they can be modified, replaced, or expanded without affecting the system. That distinction is a design decision, not a consequence of the chosen technology.

Fourth Question: Who Governs the Core Rules?

The previous three questions produce definitions. The fourth determines who sustains them over time.

Every digital ecosystem has rules that structure it: how the catalog is updated, how development priorities are decided, who approves a change that affects multiple systems. When those decisions do not have an explicit owner, they are made in a dispersed way: by the team facing the most urgent problem, by the vendor proposing the fastest solution, or by the team that happens to have the most technical context at the moment.

The result is not visible chaos but silent drift. The ecosystem gradually takes the shape of the urgencies shaping it rather than a strategic intention. It is exactly the mechanism described in the previous article: the ecosystem that no one designed, built by default.

Defining governance does not mean concentrating all decisions in one person. It means clearly defining which decisions require central criteria and which can be delegated without compromising system coherence.

What These Questions Reveal Together

Answering these four questions before choosing any technology does not guarantee a perfect implementation. What it guarantees is that the chosen technology will be evaluated according to business criteria, not according to what the market offers as a standard.

Together, these questions reveal something deeper than the current state of the ecosystem: they reveal the organization’s real capacity to grow without losing coherence. When the answers are clear, growth reinforces the structure. When they are not, growth exposes it.

The next level of this discussion explores what happens when these questions are not asked in time: projects that are executed well, that meet their objectives, and yet generate dependency and technical debt because they were not designed for what comes next.