How we decide what to build: the questions we ask before writing any code

The usual way software companies decide what to build is to look at what competitors shipped last quarter. It produces products that have every feature and solve nothing in particular.

We work the other way round, and it is slower. Here is the actual process.

The five questions we ask first

1. Walk me through last Tuesday

Not what the process is supposed to be. What actually happened. Who got the enquiry, what they did with it, where it was written down, who had to be told.

The gap between the documented process and last Tuesday is where the software needs to go. It is also where every business has a spreadsheet they are slightly embarrassed about.

2. What do you retype?

Retyping is the clearest signal of a missing join. A quote retyped into an invoice. A WhatsApp enquiry retyped into a CRM. An address retyped into a delivery sheet.

Every instance is a place where two systems that should be one are not. Products, quotes, invoices and projects live next to the deal in TicAte CRM for exactly this reason — the work that follows a won deal is the same record as the deal.

3. What is the thing you check manually every morning?

Whatever a manager opens a spreadsheet to check at 9am is a report that should exist, or an automation that should have fired. Usually the latter.

4. Which part of this is your industry, and which part is just you?

This one matters most, and businesses are often not sure themselves. If every business in your sector tracks Inspections, that is a module. If only you call them Site Audits, that is a configuration. The first we build; the second you define yourself in a minute.

Confusing those two is how CRMs end up with 200 half-used features.

5. What happens when you are not there?

Most small businesses have one person who knows where everything is. That person is a single point of failure, and every process that lives in their head is a process that stops when they are on leave.

Three things that exist because someone explained a problem

Tunnels between pipelines

A business told us their deals did not end when sales won them — they moved to an onboarding team with an entirely different set of stages. They were doing it by creating a second deal manually and hoping nothing was lost. So a won deal in one pipeline can now open a deal in the next one automatically, carrying the account and the history with it.

Layouts per team

Accounts and sales were arguing about which fields belonged on the deal card. Both were right. The answer was not a compromise layout; it was two layouts on one record.

Coexistence, on the WhatsApp side

Every business we spoke to refused the same thing: giving up the WhatsApp app on the owner's phone. For years the industry treated that as customer stubbornness to be overcome with a better pitch. It was not stubbornness, it was a correct assessment of a bad trade. So we built around it — see Coexistence.

What this means if you are evaluating us

You will get asked a lot of questions before anyone shows you a screen. That is not a sales technique. A demo tuned to a process we have not understood is a demo that looks impressive and tells you nothing.

And you will sometimes be told no. If what you need is genuinely yours alone, the honest answer is that configuration will get you most of the way and the last 10% is not worth either of our time. Vendors who say yes to everything deliver a product shaped like a committee.

If that sounds like the conversation you want, start it here.