The questions we ask before writing a line of code

Most software projects arrive as a list of features. "We need a portal. A dashboard. Logins for the team."

We set the list aside — not because it's wrong, but because it's an answer to a question nobody has asked out loud yet. Before we write a line of code, we want to understand the problem well enough to describe it back to you better than you described it to us.

Here's what that actually looks like.

Who touches this process today?

Not who owns it on the org chart — who actually does the work. The person who exports the spreadsheet every Friday. The dispatcher who keeps the "real" schedule in a notebook because the system is always out of date. The bookkeeper who fixes the same data entry mistake every month.

These people know where the process actually breaks, and they're rarely in the first meeting. Software designed without them gets worked around, not used. So we ask to talk to them, and we ask what they do step by step — not what the procedure says they do.

What does "done" look like?

A vague goal can't be finished. "Better visibility" isn't done. "The Friday report takes ten minutes instead of three hours" is done. "Nobody re-keys an order twice" is done.

Once done is concrete, scope decisions get easy. Anything that moves you toward done goes in. Anything that doesn't can wait. Most of the original feature list usually can.

What happens if we build nothing?

This one surprises people, coming from a company that builds software for a living. But it's the fastest way to find out what a problem actually costs.

If the honest answer is "not much, it's just annoying," that's worth knowing before you spend real money. If the answer is "we lose half a day a week, and we've burned out two hires doing it," now we both know what the project is worth, and what it's reasonable to spend on it.

Where does the data live today?

Spreadsheets. An aging CRM. Email threads. Someone's head. Most operational pain isn't a missing app — it's the same information living in three places that don't agree with each other.

Knowing where the data lives, and which copy people actually trust, often changes the shape of the whole build. Sometimes it changes whether there's a build at all.

Answers describe problems. Feature lists describe software.

This is the heart of it. When you scope from a feature list, you're pricing the construction of software. When you scope from answers, you're solving for an outcome — and the outcome often needs less software than anyone expected.

A real example, lightly disguised. A client asked us for "a dashboard." Reasonable request. But when we asked who touches the process today, we found the real story: every Monday morning, one person spent three hours copying numbers from the inventory system into the accounting tool by hand, then building a report on top.

A dashboard would have made that report prettier. It wouldn't have touched the three-hour ritual underneath it.

What they actually needed was an integration — the two systems talking to each other directly, with a simple report on top. It was a smaller build than the dashboard they asked for, it cost less, and it removed the pain instead of decorating it.

Sometimes discovery kills the project

We'll be honest: every so often, the answers add up to "don't build this." The tool you already pay for can do it with some configuration. The problem is a process problem, and software would just automate the mess. The cost of the pain is lower than the cost of the fix.

When that's the case, we say so. A killed project costs a few conversations. A built-but-wrong project costs months and real money. Telling you not to build is a good outcome. It's the whole reason to ask first.

Start with one question

domandas means "questions", and this is why. The right questions, asked early, are the cheapest engineering work you'll ever buy.

So here's one to start with: if your team could stop doing one manual ritual tomorrow, which one would it be?

Tell us which one it is