Your Real Options

I ended the last letter with the question that actually matters. Not "can I build it?" — you can. The real one is this: given everything it takes, what's the right way for me to get the technology my practice needs?

I've been down every road on that map. Let me walk you through them honestly — including where each one is genuinely the right call. There are three. Then there's a fourth I'll come back to.

Option one: build it yourself

The appeal is obvious. You're in control, the tools can be cheap, and whatever you make is yours. If you've got the itch — and some of you do — this is the most fun you'll have.

Here's the honest cost. It isn't the prompting; that's the easy part. It's everything I described last letter: the discovery, the blueprint, the guardrails, the system that checks the AI's own work, the upkeep. Done right, you're not a prompter — you're the architect and the quality control for a one-person software team. Building something you can actually trust means standing all of that up and keeping it running forever. When something breaks at nine o'clock the night before a client meeting, the person who fixes it is you. When a law changes, or a carrier changes a form, or a custodian changes a feed, the person who has to notice and update the thing is you. It never becomes "done."

Who is this genuinely right for? The owner who *wants* to build, who finds it energizing, and who will keep at it long after the new-toy feeling wears off. That's a real person. It's just a smaller group than the noise suggests — and there's no shame in knowing you're not in it.

Option two: hire someone to build it

Now you're handing the building to someone who does it for a living. Your time goes back to your practice. That's a real gain.

The honest cost here is two things. The first is money — and not the one-time kind. Software isn't a purchase, it's a payroll line. It needs maintenance, and maintenance is ongoing. The second is dependency. When you hire a builder, you take on a relationship you can't easily leave. When they get busy, raise their rate, or move on, you're holding something only they fully understand — and now it's live inside your business. You've also picked up a new job: managing a developer. And however good they are, they will never know your practice the way you do.

Who is this right for? The firm with a real budget, a clearly defined need that isn't going to keep shifting, and the stomach to manage a technical vendor for the long haul.

Option three: piece it together

This is what almost everyone actually does. You don't build anything — you buy the best tool for each job and wire them together. Best-of-breed. It feels like the safe, professional choice.

You already know the honest cost, because I've spent four letters describing it. Every tool is another subscription and another login. Every connection between them is a seam somebody has to maintain — and that quietly breaks the day a vendor changes something on their end. *You* become the integration layer, the thing holding the stack together, and that job never ends. And the AI you bolt on top is only ever as good as the fractured data underneath it.

Who is this right for? The firm that genuinely needs a few specialist tools and accepts the seams, the subscriptions, and the babysitting as the price of having exactly the pieces it wants.

What all three have in common

Step back and look at them together, because the real decision is hiding in plain sight.

The hard question was never "how do I get the software?" All three get you software. The hard question is the one underneath it: *who does the upkeep, and what happens when it breaks or the world changes?* Because it will break, and the world will change — a form, a rule, a feed, a vendor, a law. Maintenance and updates aren't a phase you finish. They're a permanent tax. And on all three of these roads, you pay it the same two ways: with your own time, or with someone you hire and manage.

That's the whole honest map. Build it and maintain it yourself. Pay someone to build and maintain it. Or assemble it and spend your career holding the seams together.

The fourth path

Here's what I've noticed. Most of the owners I actually sit down with don't want any of the three. They don't want to become a builder. They don't want to manage a developer. They don't want to be the integration layer for the rest of their career. They want the *outcome* — technology shaped to their practice, that they own — without the second job every one of these paths quietly hands them.

For a long time, that was just tough luck. You had three roads, and you picked your poison.

I think there's a fourth road now. It's what my team and I have spent the last two years building toward — I prototype it, and our engineers turn it into real, working software. It's the reason for every letter that came before this one.

That's the last letter.

Talk soon,

Ryan Borer

Founder & CEO, AdvisorCRM