Before Writing Code: The 5 Questions We Always Ask Our Clients

In many projects, the first conversation starts with a solution:

“We need a system.”
“We want a dashboard.”
“Can you integrate this software with our machines?”

At Simplico, we deliberately slow this moment down.

Not because we don’t like building software — we do — but because writing code too early is one of the most expensive mistakes in system development.

Before any architecture diagram, database schema, or hardware discussion, we always begin with five questions.
These questions are not technical. They are clarity questions.

They exist to protect our clients from building the wrong system very efficiently.

Question 1: What decision or action should this system make easier?

Most requests describe features.
We focus on decisions.

A dashboard is not a goal.
An API is not a goal.
Even automation is not a goal.

The real question is:

What decision is currently slow, risky, or unclear?
Who makes that decision?
What happens when the decision is delayed or wrong?

When a system improves decisions, value becomes obvious.
When it only adds screens, complexity quietly grows.

Question 2: What problem exists even if software didn’t exist?

This question often feels uncomfortable — and that’s a good sign.

If software disappeared tomorrow:

Would the problem still exist?
Is this a process issue, a communication issue, or a responsibility issue?

We ask this because software amplifies reality:

A clear process becomes faster
A broken process becomes chaos at scale

By understanding the problem without software, we design systems that stabilize, not magnify pain.

Question 3: Where does information start, and where does it end?

In system integration projects — especially those involving machines, sensors, or multiple departments — problems rarely come from code.

They come from unclear boundaries.

We map:

Where data is created (human, machine, external partner)
How it changes
Where it becomes a decision, report, or action

This helps us decide:

What should be automated
What should stay manual
Where software should integrate with hardware — and where it shouldn’t

Good systems respect boundaries.
Bad systems blur everything together.

Question 4: What must remain flexible in the next 2–3 years?

Most systems don’t fail immediately.
They fail quietly, when the business changes.

We ask:

Which parts of your operation are stable?
Which parts are likely to change (volume, regulation, partners, machines, markets)?

This guides critical design decisions:

Where we avoid hard-coding logic
Where configuration matters more than features
How to design software that survives hardware replacement

Flexibility is not about future-proofing everything —
it’s about choosing where to be flexible.

Question 5: How will you know this system is working?

Not in theory.
Not in KPIs written for a proposal.

But in daily reality:

What feels easier?
What disappears from your daily frustration?
What no longer needs explanation?

If success cannot be described simply, the system is probably too complex.

This question keeps us honest — and keeps the project grounded in real outcomes.

Why These Questions Matter

These five questions often change the project direction.

Sometimes the result is:

Less software than originally planned
No hardware integration at all
A phased approach instead of a “big system”

And sometimes the result is a much stronger system — because it is built on clarity, not assumptions.

This is why we position ourselves not just as developers, but as consulting partners in system design and integration.

A Simple Decision Diagram We Use

The purpose of these questions is not discussion for discussion’s sake. They lead to clear decisions about what to build, what not to build, and what to postpone.

Below is a simplified version of the decision flow we often sketch together with clients:

flowchart TD
  A["Business Pain or Goal"] --> B{"Is this a decision problem?"}

  B -- "Yes" --> C["Who makes the decision?"]
  B -- "No"  --> D["Fix process, clarify roles"]

  C --> E["What information is missing?"]
  E --> F{"Can this be solved without software?"}

  F -- "Yes" --> G["Process / policy fix"]
  F -- "No"  --> H["Design system boundary"]

  H --> I["Software-first design"]
  I --> J["Integrate hardware only if it adds value"]

This diagram helps everyone align early: