Understand before proposing: how we intervene

There is a kind of friction that keeps recurring in businesses that have grown quickly: systems don’t talk to each other, spreadsheets act as bridges, and technical decisions are put off because nobody has the time to make them properly. And when something becomes urgent, the temptation is to propose technology before understanding what is actually failing.

We do the opposite. We intervene in real systems and take responsibility for technical decisions. What follows is not a ritual or a pitch; it is how we work when the request is concrete and the business is already feeling the friction.

Understand the context

Before designing anything, we need to understand how the business really works: not the version on the slides, but the day-to-day one.

We talk to the people doing the work, look at the flows, and map where information gets lost and where manual work is plugging the gaps. It might be a new employee’s onboarding that runs through email, shared folders and an HR system that never quite lines up. It might be a first-line support queue where the same request arrives by phone, by email and through the customer portal, and nobody knows which version is the official one. It might be the month-end close in accounting, with manual exports and reconciliations only one person knows how to do. It might be stock updates between warehouse and shop, or order tracking that lives in chats and parallel spreadsheets. These signs say more than any wish list of features.

Without this step, the risk is treating the symptom: fixing a form when the problem is how the data moves around, automating a step that should never have existed, or proposing software when what is missing is a clear decision about responsibility.

Understanding the context is technical and operational work at the same time. It is not a workshop put on to impress; it is diagnosis, and the useful result is a shared picture of what works, what fails and who gets stuck when it does.

We also look at what has already been tried. Many businesses carry layers of temporary fixes, and those layers explain why the team is tired and why the next technical proposal needs to be measured.

In the first conversation, the useful questions are simple. Where does the business get stuck day to day? What information gets lost between systems? Who is responsible when something fails? What has been tried before, and why didn’t it work? If there are no answers to those questions, there is no basis for a proposal yet, only a request.

Define the right problem

With the context clear, we cut through the noise. Which problem, once solved, changes how the business runs? Which one merely uses up energy?

The request often arrives already framed as a solution: “we need a portal”, “we need to connect system A to system B”, “we need to automate everything”. The useful question is a different one: what fails in the business if this doesn’t exist? Who gets stuck? Which decision keeps being put off?

Defining the right problem protects the client and protects us. It prevents endless projects, avoids building for the sake of building, and makes it possible to say no calmly when the request doesn’t match what the business needs.

This step also sets limits. A well-defined problem includes what is left out; without that line, the scope creeps and technical responsibility blurs. We prefer a narrow, clear problem to a broad, vague request: the latter sounds more ambitious, but the former is usually the one that can be delivered and maintained.

Choose a proportionate solution

Proportion is the criterion. The solution should fit the problem, the context and the capacity to maintain it.

Sometimes the right answer is a well-made integration between systems that already exist: between warehouse and shop, say, or between support tickets and the ERP. Other times it is automation limited to one critical flow, such as holiday approvals or the initial routing of requests in the inbox. In other cases it is custom software, because the process doesn’t fit a generic mould. And there are times when the best decision is not to build anything: clarify who is responsible, cut a process, or wait until someone on the client’s side takes ownership of what comes next.

What we refuse is a solution picked from a catalogue and applied without context, technology as spectacle, projects inflated to look ambitious, and scale for the sake of scale.

A proportionate solution is one you can explain in operational terms, not only in technical ones. If nobody can say what changes in the business, there is no solution yet, only a wish. The final question is simple: does this reduce friction in a way that can be maintained, or does it just move the problem somewhere else?

Execute with rigour

Once the decision is made, we execute. Rigour here doesn’t mean bureaucracy; it means clear sign-offs, acceptance criteria and respect for what already exists.

With real systems, the work rarely starts from a blank slate. There is technical debt, along with fragile integrations and inconsistent data. Executing with rigour means connecting the new to what already runs without breaking day-to-day operations halfway through; documenting enough for the team to maintain it; and testing what matters, not what looks good in a demo.

It also means taking ownership of the technical decision. When there is ambiguity, we don’t leave it hanging: we choose, we explain, and we remain responsible for the effects of that choice. If a data flow or a point of contact between systems is critical, we treat it as critical: with an owner, a clear standard and a way to correct it.

Rigour includes knowing when to stop: delivering what was agreed, and not opening new fronts just because there are still ideas on the table.

Stay accountable after delivery

A project without continuity is a problem postponed. Systems need maintenance, correction, and someone who understands what was done when the business changes.

That’s why we work on the assumption that our involvement doesn’t end on delivery day. Continuity can mean ongoing support, adjustments, or a clear handover of responsibility to the client’s team. What we don’t accept is delivering and disappearing, leaving the business with something nobody can maintain.

Continuity also means being honest about the end. Projects need a defined end; without one, the work drags on, responsibility blurs and the business pays for it in daily friction. A clear end doesn’t rule out coming back; it stops an open-ended presence from passing for disciplined work.

What we deliberately don’t do

We don’t sell empty narratives about technology, we don’t push generic solutions without context, and we don’t inflate scope to justify staying on. We don’t work without clear responsibility on the client’s side, we don’t start open-ended projects, and we don’t scale up just because “scale” sounds good.

If the request is for spectacle, we say no. If the problem is operational and concrete, we step in. We would rather have a difficult conversation at the start than an expensive correction at the end.

This isn’t posturing; it is method. Without these limits, “understand before proposing” becomes a slogan and stops being a practice.

How to start a conversation with us

If your business has disconnected systems, manual work plugging the gaps, or technical decisions that keep being put off, start there, not with a technology. Bring us the operational problem: the onboarding that stalls, the support queue lost between channels, the month-end close that depends on a parallel spreadsheet, the stock figures that never match, the approvals that live in email. We help you understand what is failing, define what is worth solving and decide on the proportionate path.

The useful conversation starts with the day-to-day friction, not with the catalogue of what technology promises. If you want to talk to us, bring us the point where the business gets stuck. Everything else follows from there.