I'm only ever building one thing

I wanted a better way to reach the businesses I want to work with. Not a mass blast, and not another subscription to a generic sales tool built for somebody else's process. I built my own instead: something that checks a lead is real before anyone spends a minute reaching out, then puts the whole outreach motion in one place instead of scattered across a spreadsheet and tools that didn't talk to each other.

That wasn't a side project pulling time away from client work. It was the company doing the one thing it actually does, whether the job in front of me is a client's product or my own pipeline.

I've stopped treating client projects and internal tools as two separate piles of work. They're the same pile. The same move, over and over, just pointed at different problems.

every problem becomes a capability

The move is always the same. Something keeps costing time or attention, over and over, and instead of pushing through it again I build the thing that makes it stop costing that time. Then I own that thing. It doesn't disappear once the job that prompted it is done.

I did not set out with a theory about this. I built the first one because I was tired of doing the same manual check over and over, not because I had a plan to build a system of systems. The pattern only became visible after I'd done it a few times, when I noticed I kept ending up in the same place: something recurring, then something built, then something kept.

three problems, the same move

The outreach tool is one example. Reaching the businesses I want to work with used to mean juggling a lead list, a sales tool that wasn't built for how I actually work, and a separate manual step for checking whether a contact was even real before I spent time on it. None of that work was hard. It just ate time, and none of that time ever turned into anything I kept. I built one system that handles all of that: it checks a lead before it's treated as workable, and the outreach itself happens from wherever the lead already lives, instead of switching between tools.

That system connects to a second one I built. When a lead clears the check, it can trigger a prototype built specifically for that business, generated automatically, with a link ready by the time I need it. The two systems feed each other. A validated lead doesn't just sit in a list. It can turn into something real without me manually stitching the steps together myself.

The third one is more technical, but the shape is identical. The standard tools for turning a design into working code do it by taking a picture of the design and having an AI guess at how to rebuild it, and guessing usually loses detail. I built something that skips the guessing. It pulls the actual pieces out of the design file itself, the real components, not a picture of them, and turns those into building blocks a developer assembles into a finished screen inside the real app. There's a verification step built into the process too, one that checks the finished result against the original design at more than one screen size before anything is considered done. Getting that verification step right mattered as much as the extraction itself. A tool that pulls real components but gets the check wrong is not actually trustworthy, and trust is the entire point of skipping the guesswork in the first place.

Three different problems, three different systems. Same move each time.

the work pays twice

Every one of these paid twice. The first payment is obvious: the immediate problem goes away. Outreach stops being a mess of manual steps. A prototype stops being something somebody has to build by hand for every prospect. A design stops losing detail on the way into code.

The second payment is the one that actually compounds. The capability doesn't disappear once the problem that prompted it is solved. It stays. The next time that same friction shows up, dealing with it costs almost nothing, because I already own the thing that handles it.

For a long time I weighed the two kinds of work differently in my head. Client work felt like the real work because someone was paying for it directly. A tool I built for myself felt like something I was doing on the side, in the gaps. That distinction does not hold up once I actually look at what each one returns over time.

A client project has a start and an end. Once it ships, most of what I learned building it stays in my head as experience, not as something I can hand off to the next project directly. A capability is different. It sits there, already built, ready to be used again without me having to relearn or rebuild anything.

This is where client work and internal tools stop being two different categories, at least in my experience. What I learn shipping something for a client sharpens the tools I use on my own work. The internal tools I build make the next client project faster, because I'm not starting from zero on a problem I've already solved once. It ends up being one system getting better, not two separate efforts running side by side.

how I decide what's worth building

This isn't a case for building everything myself. Most problems are one-offs, and a one-off is usually cheaper to buy, borrow, or push through once than to build a system around.

What decides it for me is whether the friction is going to come back. If it's going to show up again on the next job, and the capability is something I can actually own instead of renting from somebody else's tool, I build it. If it's not going to recur, or if something off the shelf already gets me most of the way there, I don't. Building the wrong thing costs just as much as not building the right one.

I ask a second question too: is this actually mine to own, or am I just recreating something that already exists and works fine. Rebuilding something that is already solved well by somebody else is not a capability, it is wasted effort dressed up as ambition. The test is not whether something is annoying. Plenty of things are annoying once and never again. The test is whether I can see myself doing this same kind of thing, in some form, on the next project too.

this is also how I work in general

This isn't just how I run the company. It's how I try to treat everything.

Most things I do, I try to treat as raw material instead of a one-time event. A hard task done once makes the next similar task easier, if I actually pay attention to what made it hard the first time. I don't want to solve the same problem the same way, from scratch, every single time it shows up. That's wasting the lesson.

I notice this most when I am doing something for the second or third time. The first time is always slower, and usually a little clumsy, because I am learning the shape of the problem while I am solving it. The second time is where the payoff shows up, if I paid attention the first time around.

That is really what building these tools comes down to for me. It is not really about efficiency for its own sake. It is about not wanting to relearn the same lesson from scratch, over and over, when I already paid for it once.

The question I ask myself isn't just how I get through something. It's what getting through it leaves me with once it's done.

None of these projects are really separate from each other. They're deposits into the same system, and that system gets a little better every time I add to it.