Just Because You Can Build It Doesn't Mean You Should

With so many tools like Codex, Cursor, Lovable, Replit (the list goes on..), you can build a working solution over a weekend. The question that matters now is whether you should build it yourself…buy it from a vendor…or bring in an expert who has done it before.

Founders are building all kinds of cool things right now: custom CRMs, reporting dashboards, hiring tools, internal automations. Some of it is great. Some of it is quietly refocusing the founder and turning into a second job.

This issue is about making that call. When should you build it yourself? When should you buy a tool that already works? And when should you bring in an expert?

At Modern Operators, we recently built our own accounting system and our own hiring engine, and we build systems for clients too.

So I'll tell you where I'd build and where I wouldn't.

By the end, you'll have three tests to run before you build anything and a simple rule for choosing.

Why This Matters Now

Until recently, building your own software meant hiring developers, so buying was the default for a founder-led business. That default is gone.

The numbers are starting to show it. McKinsey's 2026 State of AI report found that 32% of organizations decided against buying at least one software product or feature because they built it in-house with agentic coding tools (McKinsey, The State of AI, 2026).

I'm not saying software is dying. ETR's July 2026 research still shows software budgets growing, with companies consolidating the tools they pay for. Some tools are getting re-questioned. Plenty are staying put.

What changed is the decision in front of you. For every system your business needs, you now choose between building it, integrating something that already exists, or bringing in an expert. Getting it wrong in either direction costs you.

Say a founder ships a custom CRM over a long weekend. It works great. Six months later, a payment tool changes how it connects. The one person who understands the code is buried in client work. Follow-ups quietly stop, and nobody notices for two weeks.

Nobody planned for that cost. It never showed up on an invoice.

The opposite mistake costs money too. A founder who feels nervous about building ends up buying three overlapping tools and using a little bit of each. Both founders skipped the same step. Neither one asked what the job really needed.

The rest of this issue gives you a way to ask.

Three Tests Before You Build

Software works like dinner. You can cook at home, order from a restaurant, or hire a chef.

Cooking is great when you know how and you enjoy the cleanup. The restaurant wins when the meal is common and someone else already does it well. The chef is for the night you need something special and don't have the skills yet.

Before you build anything, run it through three tests.

Fail one, and you should buy it or bring in someone who has done it before.

🔹 Test 1: Expertise

Can someone on your team explain this domain better than the AI can?

AI writes the code. It doesn't know what a good chart of accounts looks like, or what a hiring manager needs to see at the interview stage. The tool can only be as good as the person directing it.

That's why we built what we built. Our Ledger system syncs in real time with our bank, Stripe, and PayPal. It manages the chart of accounts, runs monthly reconciliation, produces financial reports, and forecasts cash flow. Our hiring engine runs from identifying an opportunity through sourcing, interviewing, and onboarding.

We could build both because we have deep accounting and recruiting expertise in-house. The AI did the typing. Our people knew what to ask for.

Try this check... If the AI hands you a reconciliation report or a candidate scorecard, would you know when it's wrong? If you wouldn't, you can't catch the errors, and errors in money and hiring get expensive fast.

Now flip it. A recruiter can't architect a system. An AI ops engineer doesn't know HR. Put either one alone on the hiring engine and you get half a product. The value sits where the two overlap, and small teams rarely have both people.

🔹 Test 2: Ownership

Who maintains it six months from now?

Last issue I called this Damon's Law: everything you start is a lease on your future attention. Building is the down payment. Every integration that changes, every bug, and every new hire who needs access lands on someone.

When you buy, the vendor carries that load, and a whole team's job is fixing it. When you build, you carry it, usually with whoever happens to be free on a Thursday afternoon.

So ask it plainly. Who owns this? What happens if they take a week off? If you can't name a person and a backup, buy it.

🔹 Test 3: Ceiling

How big can this get before it breaks?

A tool you build yourself is shaped around your company today. That's the appeal. It's also the limit. The ceiling stays invisible until you hit it, and you usually hit it in the middle of a busy quarter.

Test it with three questions. How many people will use this in a year? What happens when one of its connections changes? Could a new hire learn it without you in the room? If the answers feel shaky, the ceiling is closer than you think.

My prediction is my view, not a study. Over the next year or two, plenty of small companies will build their own tools, hit that ceiling, and rip out and replace them. I don't have data on how many. My bet is that a tool built around ten people will need a rebuild before it serves fifty.

Where this is headed?

Agentic labor will keep getting better. The part that lags is knowing what to ask for.

Someone still has to direct it, and that takes expertise small teams rarely have on staff.

So I expect smart founders to add experts or contract them for specific projects, with agents doing the heavy lifting under their direction.

That's my read, and I could be wrong on timing. The shape of it feels right to me, because the tools keep getting stronger while the judgment about how to direct them stays scarce.

Build, Integrate, or Bring in an Expert

Use your answers like this:

• ✅ Build when you pass all three tests: you have the expertise, a named owner, and room to grow.

• 🔹 Integrate when the problem is common and a good tool already solves it. Buy it, configure it, and spend your attention elsewhere.

• 🧠 Bring in an expert when the problem is specific to your business, but nobody on your team knows the domain well enough to direct the build.

How to Apply This (This Week)

1. This week, list every tool you've built with AI or plan to build. Include the half-finished ones.

2. This week, score each one on the three tests. Write yes or no next to Expertise, Ownership, and Ceiling.

3. This week, name one owner and one backup for everything you're keeping. ⚠️ No backup means a risk.

4. This week, pick one build that fails a test and move it to Integrate or Expert. Buy the tool, or book the specialist.

5. This week, write down what your best build would need to handle at twice your current size. If the answer is "I don't know," you've found your ceiling warning.

Final Thoughts

I'd rather you buy a boring tool that works than build something impressive that can’t be maintained over time. Pick one project this week, run it through the three tests, and see which way it points.

If you want help making those calls for your business, schedule a 15 min call with us.

See you next week,

Damon Flowers

Founder, Modern Operators

This is Issue 67 of Modern Operators. We help founder-led businesses install the operating infrastructure that lets their team run without the founder in the middle of everything.