In 2023 I wanted a tool that didn't exist. A colleague and I had been talking about what financial analysis would look like if the analysis ran continuously instead of arriving in a monthly deck, and the conversation was good enough that months later we started a company around it.
Then we spent two years mostly not building it.
Not for lack of intent. We hired developers, and the arrangement never worked the way it was supposed to. Every feature went through the same cycle: I'd describe what an owner-operator actually needed to see, someone would build an interpretation of that description, and what came back would be technically fine and operationally beside the point. Then we'd iterate, which meant paying again to close a gap that existed because the person who knew the problem and the person building the answer were different people.
The idea was never the bottleneck. Getting it built was.
What changed
The tooling caught up. Not gradually from where I was sitting — it felt like a threshold, somewhere in 2024 into 2025, where the distance between describing a thing precisely and having a working version of it collapsed.
So we stopped hiring developers and started shipping features ourselves. That business intelligence product went to production with real clients using it. I left that company at the end of 2025, and as far as I know it's still running.
I want to be careful about what that proves. It doesn't prove I became an engineer. It proves that the translation step, the one where a specification gets handed to someone who doesn't share your context, stopped being mandatory for a certain class of tool. That class is bigger than most operators think and smaller than the enthusiasts claim.
What it looks like when the same person does both
The clearest example I've built isn't a business tool at all.
I wrote a setting for a tabletop roleplaying game, and I built a wiki for it with two AI assistants attached. One is player-facing and can only see information players are allowed to have. The other is for the game master and can see everything, including what's hidden and why. Same underlying content, two assistants, different access.
That's an access-control decision, and it took about a minute to make, because I was the person who knew which facts were secret and I was also the person building the thing that would decide what to reveal. There was no requirements document. There was no conversation where I explained the concept of a spoiler to somebody billing hourly.
The business version is identical in shape. A customer-facing assistant and an internal one should not have the same view of your data, and the person who knows where that line falls is almost never the person writing the code. When they're the same person, the line gets drawn correctly in about a minute. When they're not, it gets drawn in a meeting, then redrawn.
The business intelligence work I've done since follows the same pattern. Firms typically run their operations across several disconnected systems, and nobody can answer a simple question about the business without exporting from three of them and reconciling by hand. Pulling those into one live picture isn't conceptually hard. It's just historically been a project, with a budget and a vendor and a timeline measured in quarters. It doesn't have to be anymore.
The site you're reading this on is the same thing at a smaller scale. I designed and built it, and it took days rather than the weeks a brief-and-revise cycle would have cost, mostly because there was no brief. There's no AI anywhere in it. There won't be until it would answer a question a visitor actually has, because building something into a product for the sake of having built it is how you end up with tools nobody opens.
The constraint moved, it didn't disappear
Here's the part that gets left out of most writing on this.
Eighteen months ago, four of us started building a virtual tabletop application — the software people use to play roleplaying games remotely. It was a prototype rather than a venture. No company, no funding, no hires. Just an ambitious premise, deliberately so: one system that could handle any ruleset, including ones that hadn't been written yet.
We're now narrowing it to something much smaller.
Nothing broke technically. Over those eighteen months other teams shipped adjacent products while we were still working toward the general version, and that gap compounds. By the time you notice it, the thing you were building has been partly built by someone else.
So the project is narrowing rather than stopping, and it's narrowing to the smallest version that's genuinely differentiated instead of the grand version we sketched.
The lesson I take from that is uncomfortable and specific. When the ability to build stops being scarce, speed becomes the scarce thing instead. If anyone can build the tool, the advantage moves to whoever builds it first, and a market doesn't slow down for a project that isn't trying to be fast. The bottleneck moved from capability to velocity, and velocity is harder to fake.
What this means if you run a business
Three things, and none of them are “learn to code.”
Build the small internal tools yourself. The dashboard that answers your own recurring question, the automation that removes a weekly hour, the assistant that knows your process. These are exactly the projects that never survive a budget conversation, because they can't be justified against a vendor quote and they're too small to hire for. They're now a weekend.
Don't outsource the specification. If you use a developer, the failure I described earlier doesn't come from bad developers, it comes from the specification being the actual hard part and being the part you handed away. What you can build yourself now is a working prototype of what you mean, which is a far better brief than a document describing it.
And take the speed point seriously, because it applies to your competitors too. Whatever operational advantage you get from building your own tools has a shelf life, and it's shorter than it used to be.
That's what I mean by seeing the truth before setting the goal — the TAG method — See the Truth. Implement Actions. Achieve your Goals. The truth in 2023 was that I couldn't build what I could specify. The truth now is that I can, and so can the person I'm competing with, which changes what the goal should be.