The Vibe-Coding Reckoning

I've never been a stranger to building things. Early on, while I was building the TAMP, I taught myself VBA and a bit of HTML. I understood databases. I built spreadsheets sophisticated enough to automate real parts of the business — sheets that did actual work, not just held numbers.

But there was a ceiling, and I knew exactly where it sat. The real software — the full systems my practice ran on — still meant hiring people who could do the things I couldn't. I had the ideas and the domain knowledge. What I didn't have was a way to turn them into working software myself.

That changed about two years ago.

The tools got good enough that I — a finance guy, not an engineer — could describe what I wanted and watch it come together in front of me. I've built more working software in the last two years than in the decade before it. Real tools that do real jobs. If you've heard the phrase "vibe coding," that's the loose name for it: you steer with plain language, the AI writes the code, and things that used to take a team and six months take you an afternoon.

Let me be clear about one thing before I say anything else. The promise is real. This is the most genuinely exciting shift I've seen for people like us in a long time. The barrier that kept you out of your own technology is lower than it has ever been.

That's the 80% everyone shows you. It demos beautifully, and it should — because it's real.

Here's the 20% nobody puts on the slide. I've hit all of it myself, and I'd rather you hear it from someone who's been in it than learn it the hard way.

The foundation gives out

The first thing that happens is you go fast. Too fast. You describe a feature, it appears. You describe another, it appears. It feels like magic right up until the thing collapses under its own weight — because in the rush, nobody laid a foundation. The structure was never there, so every new piece makes it shakier. More than once I've had to stop, throw away real work, and rebuild from the ground up, exactly the way I described a couple of letters ago. Scope creep isn't a risk here. It's the default setting.

Connecting the dots is the hidden tax

I once built two systems that were supposed to work together and found out they couldn't — the data on one side never carried cleanly to the other. That's the same "nothing talks to anything" problem I've spent three letters describing, except this time I'd built it myself. Making separate pieces actually connect to each other is most of the real work. It's also the part the demo never shows you.

You have to know to protect yourself

This one I've mostly watched from the outside, and it worries me more than any mistake I've made myself. An advisor trying to build something gets stuck. To get unstuck, they paste a set of live security keys — the digital keys to real client data — straight into a chat window. Sometimes the tool catches it and stops them. A lot of the time, nothing does. Nobody warned them. There was no guardrail, no training that kicked in. Securing your data, protecting your clients' information, doing it the compliant way — those are all things you have to *know* to do. The tools will happily let you skip every one of them and never say a word.

It never becomes "done"

One of the automated processes I built got stuck, quietly spawned a duplicate of itself, and drifted out of sync until I noticed and fixed it by hand. Software isn't something you build once and walk away from. It's something you keep alive. Something is always breaking, changing, or needing a human to step in — and when you're the one who built it, that human is you. Every time.

You own less than you think

I lost a stretch of work I was certain lived safely in the cloud. It didn't. It was sitting on a single machine, and when that changed, it was gone. "It's in the cloud" is something we all say and rarely check. Where your work actually lives, who actually holds it, and whether it's genuinely yours — those aren't technical footnotes. They're the whole question of ownership, and the build-it-yourself path answers them quietly, in ways you don't notice until the day you need to.

So what do I actually want you to take from this?

Not "don't." I mean that. I would never tell you to sit out the most empowering shift our industry has seen. If you want to build, build — you'll learn things about your own business you can't learn any other way.

But go in with your eyes open. The demo is the easy part. The foundation, the connections, the security, the upkeep, the ownership — that's the actual job, and it doesn't end when the app finally works. It starts there.

Here's what I did about all of it, and it's the part that surprised me most. When I kept hitting these walls, I stopped trying to out-prompt them and started building systems *around* the AI instead. Two of them mattered most.

The first is a discovery process I run before any code gets written. It forces the boring questions to the front — what exactly am I building, who is it for, what does "done" actually look like — and it ends in a written blueprint the AI has to build against. Most people skip this part, because it's slower and less fun than prompting and watching something appear. Skipping it is why so many of these projects quietly fall apart.

The second I call a harness — a structure around the AI so it can't run wild. Instead of one open-ended chat trying to do everything, the work gets broken into small pieces: one agent plans, another builds a single slice at a time, and a third checks the result against the blueprint before it's allowed through. The project's memory lives in the project itself, not in a chat that forgets. And the part that writes the code is walled off from anything dangerous — it can't deploy or touch a client's keys on its own, because a human has to approve that first.

None of that is glamorous, and that's exactly the point. Everyone wants the speed; almost nobody wants the discipline underneath it — and that discipline is the whole difference between a flashy demo and something you can actually run a business on. Getting AI to reliably finish real work isn't a prompting trick. It's a system you have to build and then keep maintaining. It turned into a second job sitting on top of my first one. I was willing to do that. Someone running a full practice usually can't be, and shouldn't have to be.

Which means the real question was never *"can I build it?"* You can. The real question is the one every business owner already knows how to ask: given everything it actually takes — the building, and the discipline around the building — what's the right way for me to get it?

There are really only three answers. Build it yourself. Hire someone to build it. Or piece it together from what's already out there. Three real paths — each with a very different answer to who does the work, what it costs, and what happens when it breaks.

That's the next letter.

Talk soon,

Ryan Borer

Founder & CEO, AdvisorCRM