I Used to Build Everything Myself

When I had to build everything myself

When I started my first company, I did almost everything myself. We had raised our first money from friends and family and bootstrapped the rest, so there was rarely anyone else to hand a problem to.

In a given week I’d be in a data center with a field technician, racking servers, routers and switches and running cable. Then I’d configure the network gear, get circuits turned up with the service providers, and install Linux on the boxes I had just racked. Then I’d go home and write the software that was supposed to run on them: the backend, the front end, the database, the user interface, and the billing system that decided what a call cost. When something broke in production, the pager, the logs and the code in the logs all belonged to me. Somewhere in there I was also the product manager, which mostly meant talking to customers and learning that what they needed was not what I had assumed.

I’ve written about being every department at once, so I won’t repeat the whole org chart here. The short version is that I learned whatever the business needed that week. This post is about what that work was made of, and how different the same work looks today.

What the platform was made of

The platform was built on open-source VoIP. Asterisk handled the calls and the voice applications. OpenSIPS handled SIP signaling, registration and the routing logic in front of Asterisk. MediaProxy relayed audio for users behind NAT routers. The business logic lived in Python, called from Asterisk through AGI, and it talked to a billing system I wrote myself because nothing off the shelf priced calls the way we needed.

Routing was where engineering met the spreadsheet. Least-cost routing meant choosing, per call, the cheapest carrier that could still deliver acceptable quality, and the two rarely agreed. Geolocation routing meant sending a user to the nearest region so a call didn’t cross an ocean twice. Both were code, and both were business decisions wearing a config file.

Underneath all of it was a data center I had cabled by hand, and later a move into early cloud infrastructure, mostly to lower our cost structure and put servers closer to users on three continents. The migration had to happen with customers on the phone, so it happened one region at a time, with a way back at every step. I describe that move in the case study on going from one data center to three continents.

Where it failed, and what that taught me

None of those pieces failed in a tidy way. A single call crossed all of them. Signaling could succeed while the audio went nowhere. The routing engine could pick a carrier that answered quickly and billed badly. A careless retry could run the billing logic twice for one call. Each of those was a distributed systems problem, and I was solving them before I knew the term. The VoIP platform’s distributed systems lessons have their own post.

Operations taught the rest. A hard drive that fails in a cabinet forty minutes away doesn’t have a retry button. A carrier that degrades at two in the morning doesn’t open a pull request. You learn to design for the failure you haven’t seen yet, to keep state somewhere you can reconcile later, and to know which layer a problem lives in before you touch anything. Most of what I believe about architecture, reliability and running systems started in that building.

How I build now

These days, when I have an idea, I open a terminal and start a conversation.

I use AI-assisted development for most of the work I used to do by hand: exploring an idea before committing to it, sketching the design, generating a first implementation, writing tests, reviewing code, researching a library I haven’t used, troubleshooting, writing documentation, and scripting deployments. The assistant does the first pass. I read every line.

FedPath, which helps small businesses find and evaluate federal contracts, went from an idea to a working product far faster than I could have managed alone. Useful Little Tools is a collection of small browser tools built the same way, for the things I kept searching for. The Berkeley Omnium site and the Berkeley Bicycle Club site were built with an assistant in the loop, and so was the site you’re reading. None of these needed a rack, and none needed a drive to a data center.

On Yippify client work the gain is different. The code still has to meet security and accessibility requirements, and it still goes through review, tests and a pipeline before it reaches production. The assistant drafts the migration, the test and the infrastructure module. A person still owns what ships.

What surprised me is how much of the old job this replaces. The assistant is the field technician for a different kind of rack. It handles the first hour of research, the boring parts of setup, and the scaffolding I used to type from memory. Some of what it writes is wrong in ways that look right, and the reason I catch it is that I’ve been bitten by the real version before.

What hasn’t changed

Writing code was never the hardest part. It wasn’t the hardest part in the data center and it isn’t now. The hard parts were working out which problem was worth solving, what the solution had to survive, which trade-offs to accept, and keeping the thing running once people depended on it. AI compresses the typing and leaves the understanding to me.

Speed doesn’t improve the decision. The assistant generates code quickly, and whether the code makes sense is a separate question that is still mine to answer. A faster way to build the wrong thing is still the wrong thing, only sooner, which is why I care more than ever about not building work nobody needed.

Experience shows up as earlier recognition. Years of troubleshooting production systems, running infrastructure and leading teams mean I see the retry without an idempotency key, or the schema that will hurt at ten times the data, before the code runs. The assistant will happily write both. I’ve learned to ask it why not, and to check its answer.

Building a product is still not building a business. Software got cheaper. Customers didn’t. Finding people with the problem, understanding what they will pay for, and keeping them around is as hard as it was when the servers were mine.

Learning is still the job. I learned Asterisk from mailing lists and SIP from packet captures. Now I learn by reading what the assistant wrote and checking it against what I know. AI is a big shift, and I’ve worked through several before it. Adapting to the next tool is nothing new. It is most of what the career has been.

Why I still build after more than two decades

I moved into engineering leadership a long time ago, and I still write code. What changed is where the time goes: less on scaffolding, more on the idea, the design, and finding out quickly whether anyone wants the thing. That was the part I liked in the first place. The rack, the cables and the late-night pages were the price of admission.

AI lowered that price. The reason I keep paying it is the same as it was when I unpacked the first server. There is a problem, I can see a way to solve it, and I want to find out whether I’m right.

Short answers