One Year of Building

The sales team needed something, so I built a front end for it. Then I needed somewhere to put the data, so I spun up a database instance and loaded it. Then support needed something, so I built that front end, spun up another instance, and loaded data that was almost identical to what I'd loaded the week before. Same orders. Same accounts. Same vendors. Shaped slightly differently because I was making the decision fresh each time.

I did that for months.

One year ago this week I shipped my first coding project from scratch, an agent system I built because I wanted to see if I could. I've built a lot since. Most of it worked. Some of it nobody used, which I expected, because the first few of anything are tuition. That part didn't bother me.

This part did. The cost was never the apps. It was rebuilding the foundation under every one of them.

What I was actually doing wrong. I was treating each app as a project. Build the interface, then go find the data, then figure out what shape it needs to be in, then wire it up.

That order feels right because the interface is the part you can see. It's the part you can show somebody. But it means every new request starts with the same archaeology: where does this data live, what does it look like, how do I get it out. I was answering those questions over and over and throwing the answers away.

A business runs on a small set of things that barely change. Ours runs on orders, accounts, vendors, and communication. Build for sales, support, or supply chain and the user experience changes completely while the data underneath stays put.

Once I saw that, the sequence flipped.

The build with nothing to show. In May I started building a web service for the whole company instead of an app for a team.

Every system we run gets pulled into one place, the busiest of them every five minutes. The order system, the CRM, communication channels, phone services, shipping software. All of it mirrored into a single relational database in a standardized shape. Nothing gets cleaned in that process and nothing gets decided. It just lands somewhere consistent.

Six weeks before anything useful came out of it. No interface, no user, no visible result, at a company where I could have been shipping things people would have thanked me for. That's the honest part of this.

I'm still adding to it fifteen weeks later. It was never a project with an end.

What it bought. The clearest case is a tool I'd already failed at once.

I built a knowledge base for the team last October, app first, the old way. It limped. One month I committed to it a single time, which is what a project looks like when nobody is asking you for it.

Two days after the web service went up, I pointed that knowledge base at the shared data and rebuilt it. Same tool, same builder, opposite order. That's the whole experiment, and it's the only reason I trust the conclusion.

It stopped being a knowledge base and became a window onto the company, because nothing was ever in one place before. A sourcing catalog. A margin report. Open purchase orders. A warehouse page. Daily shipping numbers. I pitched none of it. The requests started arriving on their own once people could see their own work in there, and each one was small because there was no data question to answer first. That project has more commits this month than in its first six months combined.

The same thing happens at the smallest scale. Someone covering an unfamiliar account needed to know where it stood. Six purchase orders, five vendors, a rep out for the week. About twenty seconds after I asked the system to dig, it came back with the two that mattered: one marked shipped with no tracking evidence anywhere in ten emails, one silent for seventeen days with its deadline landing that afternoon.

Nobody would fund a week of work to answer that question. So before, it didn't get answered. It got a shrug, or a day of phone tag in Slack that ended in roughly the same place.

That's the part I didn't anticipate. The value isn't in the big builds. It's that one-off questions become worth answering properly, because answering them costs minutes instead of a week. Now the request is the only part that takes any thought.

What it doesn't fix. Standardized data doesn't tell you what's worth building. I still put things in front of the team that don't fit how they work, and the data model has nothing to say about that. That failure mode didn't go away, it just got cheaper to recover from.

It also doesn't clean anything. Our mirror is a faithful copy, and a faithful copy of six systems that disagree is six systems that disagree in one place. Standardizing the shape is not the same as fixing the contents, and I've caught myself treating the two as the same thing.

And a foundation is only worth what gets built on it. If I'd stopped in June, I'd have spent six weeks producing a database nobody asked for.

Where this goes. I wrote here five weeks ago that a presentation is a rationing system. Our best knowledge about a client segment reaches clients exactly one way, a person building a presentation by hand, one client at a time. That caps us at how many presentations someone can make.

The unprompted requests are the early version of the way out. Nobody asked me for a margin report because they wanted a margin report. They asked because they could finally see their own work sitting in one place and started noticing what was missing from it. That's a person moving from doing the work to shaping how the work gets served.

The next question after that is bigger. Not how do I build this for this client, but when a client who looks like this asks, how should our system respond. Answer it once and it holds for everyone who fits. Same expertise, no longer rationed by one person's calendar. That only works if the data is already standardized, which is the whole argument for the boring layer.

I'm one year in and I spent most of it building the same foundation repeatedly before I understood it was a foundation. If you're building things right now and it feels like you keep starting over, you might not be bad at this. You might just be building in the wrong order.

Next issue: a search tool for care leavers in the UK, where the data layer is a 69-item scoring rubric run across all 153 councils. It's behind a password gate while we test it.

P.S. Ask me in six months whether the team is building their own tools or whether I'm still the one making them.