Our working hours are 9 to 5. But the time a site actually finishes varies.
Some days we get away early. Other days, by the time everything is cleared up, the light has gone. What is fixed is not a time on the clock but “until the day’s work is done.” The rest of the job starts there.
Back at the office, or once we are home, we work through the logistics for whatever came in that day. Sometimes we look things up at traffic lights on the drive. Because the finish time is unpredictable, the time available for this is unpredictable too. This is the least organised part of how we work.
Over the next few posts we will write about what happens when you try to turn this work into an app, and where it gets stuck. It is not finished. We are writing as we build.
Three jobs, every time an order comes in
We take three jobs in a normal week, up to eight in a busy one. Twenty minutes each at the very least. Some take considerably longer.
And all three happen on ten jobs out of ten. This is not something we do occasionally. Including the stock check, we start from scratch every time.
1. Look up the product code
Decide which product to use and note the code.
This is not just picking from a catalogue. It is checking whether that product’s specification fits the job. Is there a fire rating requirement? What is the substrate? How will it look where it meets what is already there? Even within “wallcovering,” some codes work and some do not.
2. Place the order with the wholesaler
Take the codes and copy them into the wholesaler’s form, or LINE, or email.
What we are doing is transcription. Codes and quantities that are already written down somewhere get written out again somewhere else. Each wholesaler wants it in a different place and a different format, so it cannot be done in one go.
3. Check the lead time
Confirm the materials will arrive in time for the job.
There are two parts to this as well. When the material arrives. And how many days the work takes. Add the two together and decide whether it meets the date we gave the client. If it does not, we change the product code, reorder the work sequence, or go back and discuss the date. Which takes us to step 1 again.
Why it happens at night
None of the three can be done while working on site.
Your hands are dirty. You are up a stepladder. The catalogue and the computer are somewhere else. Even phoning the wholesaler means stopping work.
So it happens afterwards. Which means:
- Do it back at the office → you get home later
- Do it at home → work comes into the house
- Do it while driving → it comes in fragments, and things get missed
Which of the three it turns out to be depends on that day’s site. You cannot plan for it.
Put in hours, it looks like this.
Say the site finishes at five. An hour to get back. Longer if the traffic is bad. Six o’clock at the office. Then about three hours of desk work. You finish at nine. And that is an early day.
On top of that, logistics comes last in the order of desk work. Quotations, invoices and sorting photographs come first; logistics gets whatever time is left. The work that needs the most judgement arrives when you are least able to give it.
This is nearly every day.
The real cost is not the overtime
Overtime is the visible, easily counted cost. But we do not think that is where the real trouble is.
The quality of the decisions drops.
Both “does the specification fit” in step 1 and “will it arrive in time” in step 3 are judgement calls. Something you could settle in five minutes with a clear head does not settle at all with a tired one. And if it does, you place the order without being sure.
Then that doubt carries into the next morning. You get to site wondering whether you got it right. You think about it while working. Your attention goes again.
The problem was never “not enough time.” It was that we were pushing thinking work into the hours when we cannot think.
We are building an app
Could these three be finished on a phone, while still on site? That question is why we started building the job management app we now use internally.
In theory it looks simple. Pick a product code, have it turn straight into the order message, and have the information you need for the lead-time decision come out alongside it.
But what stopped us, once we started building, was not the technology.
What stopped us was putting it into words
We build with AI now. Say “I want a screen like this” and something working comes back. It is fast.
The problem is that we are not describing it correctly.
Specifically, it gets stuck in these places.
We leave out what has become obvious to us. Writing “look up the product code” does not say that it means “check whether the specification fits the job.” To us that goes without saying, so it drops out of the description. Build from that and you get a product-code search box and nothing more.
There are more exceptions than rules. The product is discontinued. There is an equivalent but the colour number differs. The stock is at a different wholesaler. The same code shifts colour between lots. Site work is made of handling exceptions. Try to describe them all and you never finish. Leave them out and what gets built is unusable.
The order is not fixed. We wrote 1 → 2 → 3, but in practice you move back and forth. Sometimes the lead time makes you change the code; sometimes you decide only after asking the wholesaler about stock. Build a screen with a fixed sequence and it will not match reality.
The worst part is that a wrong understanding still produces something that works.
Describe it badly and the AI still builds something reasonable. An error tells you it is wrong. When it runs, the wrongness is hard to see. You use it for a few days before realising it is not the shape of your actual job. Then you rebuild.
What we are doing now
It is not solved, but one approach has started to feel right.
Write out one real job from start to finish, without generalising.
Not “look up the product code,” but: that room in Katsushika last week — what we looked at, what we checked, where we hesitated, and what we chose in the end. In order, exactly as it happened.
Do that and the judgements you were skipping come out in writing. Steps like “we check stock here before deciding” — which we had not consciously noticed until we wrote them down — start to appear.
We have only done this for a handful of jobs so far. For now, it is the most reliable thing we have.
To be continued
In this series we plan to cover:
- Breaking down the product-code job for one real case
- What we wrote out before handing it to the AI, and what we noticed doing it
- Where the thing we built turned out different from what we expected
We are not only going to write about what went well. Where we had to rebuild, we will say so. We hope it is useful to anyone else trying to turn their own working practice into software.