Writing
What I ask before I build anything
Most of what I'm asked to build shouldn't be built. Not because it's a bad idea, but because something simpler would do. Here are the questions I go through before anything gets made, in the order I ask them.
Where does this information live right now?
The first answer is nearly always "in Dave's head" or "on the whiteboard in the shop". That isn't a software problem yet. It's a recording problem. Before anything else I want to know who knows the thing, when they know it, and what they would have to do to write it down. Often the whole first month is getting that one fact captured once, by the person who knows it, at the moment they know it. Everything else depends on that.
Who types it, and how many times?
I count. A crew's hours might be written on a paper card, typed into a spreadsheet by the foreman, retyped into payroll by the office, and typed a fourth time into a job-cost report. Four entries, three chances to get it wrong, and one person who knows which copy is right. If I can't get that down to one entry, I haven't done anything worth paying for.
Does the software you already pay for do this?
Most businesses I meet own Microsoft 365 and use it for email. Behind that email are shared lists, approvals, workflows, and a place to keep records that talk to each other. A surprising number of problems are solved by setting those up properly. That costs nothing extra, and I would rather tell you that than sell you something.
When it doesn't reach, I build. Sometimes that's small: a piece that reads an incoming email and does what a person used to do with it. Sometimes it's a whole application. The problem decides, not my preference.
What happens when it's wrong?
Every system gets a bad entry eventually. The question is whether the system notices. I would rather make a wrong entry impossible than catch it later: if a field is a date, you can't type words into it; if a job is closed, you can't charge to it. Where that can't be arranged, the system checks itself overnight and writes up what didn't add up, so someone looks at three things in the morning instead of three hundred.
Could someone use it with no training?
I hand it to the person who will actually use it, not the person most excited about it, and I watch. If they can't finish the task in a few minutes without being told anything, it isn't finished. The foreman entering hours at the end of a twelve-hour day is the judge, and he is a hard one.
Can a machine read it?
This one is newer. Everything I build now is set up so that a program can read it and understand it: what a column means, what a status is, what belongs to what. That is what lets you ask, in plain words, what a job cost last week and get an answer that names its source. It costs almost nothing to do at the start and is very hard to add afterwards.
Then I build
By the time those are answered, what to build is usually obvious, and smaller than anyone expected. That is good news for everyone except whoever was hoping to sell the big system.