I run production systems I could not write a single line of. A CRM. A content engine that grades its own writing and refuses to publish when it sounds like a machine. Systems that keep working after I close the laptop. I never became an engineer. Here is what actually changed, and why more people can build than anyone is admitting.
I ran a partner agency. I implemented it, recommended it, and put clients on it who trusted my judgment. So when I say what comes next, it is from the inside, not the cheap seats.
Here is what I watched, over and over. People bought HubSpot the way you buy a name. They bought the brand and the story, as if the software would log in and do the work for them. It never does. No software does.
And the model, stripped of the branding, is a ladder that only climbs. It starts you on a "starter" tier that cannot really do much of anything, priced to feel reasonable. Then it moves. I watched small businesses get talked onto an 800-dollar-a-month marketing stack that drifted toward 1,200, for tools they used a fraction of, on contracts they could not walk away from. For that size of company, that is not a stack. It is a toll.
At some point I stopped seeing the tool and started seeing the toll. And I had a plain thought, not an angry one. I could build a right-sized version of this myself. I am not an engineer. I never became one. That is the whole point of this story.
The first thing I built was Billy. Nothing exotic. A place to see my deals and track deal flow, the exact job I had been renting HubSpot to do. But building it taught me the thing this essay is actually about, and it was not what I expected.
If I could describe what I wanted clearly enough, I could get exactly that. Not the vendor's version. Not the closest tier they would sell me. Exactly what I asked for.
That moved the work. The hard part was never the code. It was the requirements. Knowing precisely what I wanted, writing it down so a capable model could execute it, then choosing the right tool for each job: an advanced model to build the tricky part, a leaner and cheaper one to run it once it worked. That is a decision an operator makes, not an engineer.
And then it stopped being about replacing the CRM at all. Once you can build exactly what you specify, you stop copying the tool you left. I built things HubSpot never gave me. Landing pages built to a real framework, StoryBrand, the hero and the guide in the right places, instead of a template chosen by a vendor who never met my customer.
The software still did not work itself. That was never going to change. But the work had moved. It was no longer clicking through someone else's product. It was saying, precisely, what I wanted, and knowing it when I saw it.
Here is the part people get wrong, and I got wrong first. The temptation is to build. The moment you realize you can make anything, you want to make it now. I have felt that pull hard enough to build a product in a single night, just because I could.
That is the trap. The build is the easy part now. The leverage is upstream, in the requirements.
What I learned the expensive way is to spend far more time than feels natural on the business requirements before a single thing gets built. Write them stringently. Then hand them back to the model and ask it to poke holes, tighten them, find what you left vague. Iterate on the spec, not the code. Do that until the requirement is airtight, and the build becomes almost boring.
Then build in small chunks. One well-specified piece at a time, choosing how much intelligence each piece actually needs. Because the cadence people fall into is think, build, think, build. That is the dopamine loop. It feels like progress while it quietly burns the weekend. The cadence that actually works is slower, and it is not sexy: think, think, think. Check, check, check. Vet, vet, vet. Then build. By the time you build, every hard call is already made.
Let me make it concrete, because "I build my own software" is easy to say and easy to doubt.
Billy is my CRM. I built it to see deals and track flow, and it grew from there. Today it does the job I used to pay three separate companies for. It replaced Pipedrive and HubSpot for the pipeline. It replaced Instantly for outbound. One system I specified, doing the work of three I used to rent, shaped exactly to how I actually sell.
The content engine is the second exhibit. It drafts in my voice, and it will not publish a piece that reads like a machine wrote it, because I built that check into the tool itself.
None of these are demos. They run. They do real work in a real business, mine.
Now the fair question. If I cannot read the code line by line, how do I know it is right?
The honest answer is that I got burned learning where the edges are. That product I built in one night got scrapped completely. We started over. The lesson was not "build faster." It was the opposite. Start much smaller, and hold the cadence: think and check and vet until the requirement is airtight, then build. I learned that ratio by ignoring it and scrapping a weekend.
On verification I will be straight about the limit. I do not eyeball the code and pronounce it correct. I cannot. Instead I make the system check its own work, recursively. Ask it to review its output, then review the review, then find what could be better, because there almost always is something. I build the checking into the thing itself. My content engine will not publish a piece that reads like a machine wrote it, because I made it grade its own writing and refuse. That is not a trick. It is the discipline that has to replace reading every line.
Is that as safe as an engineer who reads every line? No. I am trading one certainty for another: not "I verified the syntax," but "I specified it tightly, built it in pieces small enough to judge by behavior, and made it audit itself." I catch what is wrong by what it does, not by what the code says. And because the pieces are small, when I am wrong, the damage is small too.
That is the real shape of building this way. It is not magic and it is not free. It is a different discipline, and you have to actually hold it.
Here is what this actually bought me, and it is not what people assume. They assume the win is free software. It is not. The win is the cost structure.
When you rent your stack, your costs are fixed, and they only climb. You pay the same 800 or 1,200 a month whether you used the tools hard or barely logged in. When you build it, the economics invert. I carry almost no fixed overhead. I control the cost of every part. And most of what I spend is now usage-based and metered. I pay for the intelligence I actually use, when I use it, not for a seat I am renting in case I need it.
That is a different kind of freedom than saving money. Fixed cost is the thing that caps how much one person can run. Metered cost does not.
The tradeoff is real. The maintenance and the risk are mine now. There is no vendor to call. But my answer to that is not to patch things by hand forever. It is to build the maintenance itself: recursive loops where agents catch issues and resolve them, the same discipline I use to build everything else, pointed at keeping it running. I am not all the way there yet. That is the direction, and it is the bet. Upkeep, like building, becomes something you specify instead of something you grind.
So back to where this started. People bought HubSpot for the brand and the story, as if the software would do the work for them. It never did. That was always the quiet lie in the pitch.
What changed is not that the software finally works itself. It still does not. What changed is who gets to build it. For most of my career, the person with the idea and the person who could build it were two different people. That gap is where a lot of good ideas went to die, mine included.
The gap is closing. The software still will not work itself, and it never will. But for the first time, I do not need it to.
I did not learn to code. I learned to deploy intelligence in a way that lets me own my own tech stack and bring more customized solutions to the brands I work with.