The person building this business app, anken.ai, works on restoration sites. Days on the tools, and the app after that. Not a full-time engineer.
Why a contractor is building its own app is set out on the what we do page. This piece is a record of how it has actually been built. We went back through the commit history (the record of changes) and are writing it down honestly.
The first commit was “the whole lot”
The oldest entry in the record says this.
Initial commit: business management SaaS, whole lot
Which means it went into version control later than it went into being built. At first it was just written locally, and only once it had taken shape did the record start.
This is not the part to copy. Had the record started from day one, far more of “why it was built this way” would have survived. The 38 commits that exist now only cover the story from partway through.
More commits renamed things than added features
Looking back through the history, this one surprised even us.
The same page has been renamed three times.
商品マスタ → 倉庫・商品 → 在庫・商品That is “product master” → “warehouse & products” → “stock & products”.
The status on a job changed too.
引き合い → 見積中That is “enquiry” → “estimating”.
And so did the name of the printed sheet we hand to subcontractors.
施工指示書 → 案件シートThat is “works instruction sheet” → “job sheet”.
None of these added a single feature. All that changed was the words on screen.
We did it anyway, because words that mean nothing on site had crept in. “商品マスタ” (product master) is software-world language. It is not something anyone says on our sites. “引き合い” (enquiry) was just as bad — people disagreed about whether it meant before or after the estimate went out.
Renaming the paper mattered most. Called a “施工指示書” (works instruction sheet), the person handed it reads it as being instructed. What we actually want is for them to work through the plan with us, sheet in hand. So it became a “案件シート” (job sheet).
If the words are wrong, it does not matter how many features there are — nobody uses them. We think the same holds for a written estimate on a building job.
Removing was harder than adding
The history has a run of entries like this.
- Simplify the job page by status
- Simplify the screens, round two
- Merge the prep list and the works checklist into one “site list”
- Job status: four buttons → one badge plus a menu with confirmation
- Remove the key-location field (folded into the free-text field)
These are commits that delete things we had built.
The “key location” field was one we added ourselves and then removed ourselves. It seemed useful at the time, but in practice it was quicker to type “collect from XX Estate Agents” in the free-text field. The more fields there are, the more you feel obliged to fill them, and the more you stall.
Where four buttons sat side by side, people were so worried about pressing the wrong one that they pressed none of them. Once it became one button with a confirmation, the hesitation went.
The unglamorous thing that site work exposed
Three commits went entirely on this.
- Stop the screen jumping, everywhere (fix the height of the body)
- Remember and restore the scroll position per tab
- Give the body a fixed height and scroll only the inside
The problem of the screen moving on its own.
Sitting at a desk, it barely registers. On site it is different. You are holding it one-handed, up a stepladder, with gloves on. If the line you were reading slides down the moment something loads, you have to find it again.
We also added undo afterwards. Bulk ordering, or generating everything at once from a template, now come with a confirmation and a way back. Working one-handed from site, you press things you did not mean to press. A system you can recover from beats a system you cannot get wrong — the second one is not realistic.
Not typing the same thing twice
Originally, after building the line items on an estimate, you then built the list of work to do on site all over again. The same thing written twice.
So now the site list is drafted automatically from the line items. Write “wallpaper replacement, 40 sqm” on the estimate, and it comes out with the site-side checklist items and a rough idea of the materials already in place. If it is wrong, you correct it.
This is one of the parts we hand to AI. It has settled into not generating from nothing, but producing a rough draft that a person then corrects. It is not clever enough to be left to it, and not using it at all would be a waste — that is roughly the distance we keep.
What we have not managed yet
Honestly, then.
- The development database and the production database are not separate. They will be split before the first customer comes on
- The iPhone side is not finished (the layout works, but behaviour on sites with poor signal has not been nailed down)
- The list of features we want to build is growing faster than it shrinks
There are few of us, so development only moves so fast. There is always more we want to build than we can.
Why we still build it ourselves
Hand it to an outside firm and it would probably be faster, and tidier.
We still build it ourselves because the day someone notices “you cannot press that with gloves on”, it can be fixed that day. Put a spec, a quote and a wait for the next meeting in between, and that observation usually just evaporates.
Building work is the same: whether you can fix what you noticed, there and then, is what separates a good finish from a poor one. Site or app, we do not think that changes.
We are preparing to make anken.ai available to construction and interior firms and trades outside our own. We cannot yet give a date or a price. When they are settled, we will say so here in OS Notes.
On the technical choices, there is also why we chose Supabase.