# You Can Build Your Own Software Now. Buy the Cheap Tool Anyway.

Published: 2026-09-11T13:00:00.000Z · Author: Rod Amora · Canonical URL: https://rodamora.com/blog/you-can-build-your-own-software-now-buy-the-cheap-tool-anyway

> Replit dropped a seven-figure software contract for an app its own people built, and Berry runs on a CRM we built ourselves. The flip is real. It still does not mean you should start building. Buy the cheap tool first, and build when nothing fits.

Replit sells software, and in 2026 it dropped a seven-figure software contract because an app its own people built with its agent was better than the thing it was paying for. That is the loud version of the story, and Amjad Masad, the CEO, told it in [a post on Replit's blog](https://replit.com/blog/self-driving-company) and again in [an interview with Platformer](https://www.platformer.news/replit-amjad-massad-interview-coding-design-jobs/).

Here is the quiet version, and it is mine. Berry is a service company, not a software company, and today it runs on a CRM, a project management system, an AI interview tool, an internal chat, and [AI agents](https://rodamora.com/glossary/ai-agent), all built by us. Five years ago none of that would have made sense for a company like ours.

Now look at your own firm for a second. You are paying for a dozen tools, you use maybe half of them the way you meant to, and somewhere in the building [somebody has already built a little thing with an AI coding tool](https://rodamora.com/blog/shadow-ai) that is quietly in the path of client work.

So the flip is real. Building your own software is open to a firm your size now, and it was not before.

And it still does not mean you should start building. Buy the cheap tool first. Build when nothing fits, and know before you start that the first version will hurt.

Masad is half right. Maintaining software did get cheaper. What it did not get is free, and who pays for it is the whole question.

## The reason you bought software was never the features

Think about what you were paying a vendor for. Not the features, the features were the sales pitch. You were paying them to carry the forever cost, the bug that shows up on a Sunday, the hosting, the other system that changes its connection and breaks yours, the person who built it and then left.

[CPA.com](https://www.cpa.com/sites/cpa/files/2026-06/Build_vs_Buy_The-decision-framework-for-AI-in-accounting-firms.pdf), an affiliate of the AICPA, the accountants' association, put out a short guide on this in June 2026 and they say it in one line: the real cost of software is not creating it, it's maintaining it forever. I like having a CPA body say that out loud, because it is the part every demo skips.

Now look at what Replit is claiming. They say their internal agent now beats the market-leading products they test, and that the more they build, the less they need to buy. What I read in that is that the forever cost got cheaper for them, because the agent carries it, and that is aimed at the exact thing you were paying the vendor for. That is why the flip matters to you and not only to a startup full of engineers.

What they report, and this is company-reported, nobody outside audited it, is that they dropped that seven-figure contract, and that vendor tools for sorting system alerts and for security testing cost about ten times what running the same job on their own agent did.

The question you should be asking is whether any of that holds for a service firm, or only for a company made of programmers. I can answer that one from my own chair, because we did it, and it was not clean.

## What we built at Berry, and what it cost us

We did not set out to build our own CRM. We went looking for one, the same as you would. We tried the popular ones, Pipedrive, even ClickUp, not the big ones like Salesforce, and in the end we went with the smallest and cheapest, a couple of local CRM services, because that is our rule.

They did not work the way we expected. A lot of what we needed just was not there. They did not connect well to our marketing and our data, the handoff from a closed sale to project management was poor, so the link to payments and to the services we deliver was bad too, and we are a franchise, so a sale also has to hand off to a franchisee, and nothing on the market understood that at all.

So all of those gaps together drove us to build our own CRM, and later the project management system, the AI interview tool, the internal chat, and the agents that now sit inside all of it.

And a lot went wrong. The first versions we built did not work properly. There were a lot of bugs, there was wrong data, and it caused real stress and real problems inside the company, people working from a system they could not fully trust while we fixed it.

Once we got the problems fixed, it was a much better tool than anything we had found in the market, we put AI inside it, and we streamlined a lot of the work with it. It was impossible to buy what we built.

I will say it plainly, because I want you to hear the cost and not just the ending. It was a very complicated and dangerous strategic decision. It got us a level of speed and optimization that an off-the-shelf tool would not have given us, and it also gave us months of a system that was wrong in ways we had to find one by one.

Different seat from Replit, same decision. I did not read about this in a startup interview, I made the call in my own service company, as the CTO and the owner, and I paid for it.

And the rule works from the other side too. A separate franchise sales team at Berry tried HubSpot for their CRM. They ended up leaving it because the cost was way too high, and they came over to the CRM we built. Same rule, run by a different team, landing in the same place.

So is the answer just build? No. Here is the rule we actually run, and it is less clever than the frameworks.

## The rule we actually use: buy cheap first, build when nothing fits

First, we look for a tool that solves the specific problem, at a price we can pay.

Second, we buy the cheapest one that does it, or the one that has the connections to our other systems and the AI we want inside it. Cheapest that fits, not best on paper.

Third, and only if nothing fits, we build it ourselves, because we want it shaped to our workflow and built in a streamlined way, without the twenty features we will never touch.

That is our whole build vs buy rule. It has not changed since before AI, and the CRM story above is just the rule running all the way to step three.

The obvious read of the Replit story is the opposite, build everything now, the vendor is dead. I understand why people read it that way, the seven-figure number is right there. The price of that read is that every tool you build is a tool you now maintain, and the vendor was carrying that for you, and most of the time they were carrying it for less than it would cost you to do it yourself.

So what does "nothing fits" actually mean in a service firm? It means the tool exists but the price is wrong for your size, it wants a per-seat contract built for a company ten times yours, which is exactly what our sales team hit with HubSpot. Or it does not talk to the systems you already run, so your team ends up typing the same thing twice. Or it does not carry the AI you wanted, and the vendor is still bolting a chatbot onto the side. Or it makes your team work the tool's way instead of yours, and you can feel the friction in every handoff.

When you hit one of those, you used to be stuck. You paid for the wrong tool or you paid a dev shop a fortune to build the right one.

That third step is what opened up. That is the flip, and that is all that changed.

## Who owns it in three years

CPA.com's guide has a six-question test, and most of it is sensible. The sharpest question in it is this one: if we build it, who owns it in three years? Who maintains it, supports the people using it, patches the security, handles it when the model underneath changes? Their answer is that if you say "we haven't thought about that," you define it now or you buy.

They are right about the question, and I want to sit on it for a minute, because I disagree with where their answer leans.

Picture the person in your firm who built the little CSV fixer on a Friday afternoon, the one that reformats the export from that one client's system so it drops into yours. They were not being reckless. They solved a problem that was eating an hour a month, with a tool that took them an afternoon, and it works.

The risk did not come from them. It came from the owner who never asked who keeps it running, and what happens the month the client's system changes its export format, and what happens the year that person takes another job.

At Berry the answer to the three-year question is our internal dev team, and from what I have seen, most firms between one and twenty million do not have one. Your honest answer is a person, one person, and CPA.com's warning is aimed at exactly that: when the builder leaves, the tool often leaves with them.

Here is what I would actually tell you, if you sat across from me with no developers and one person who likes the tools. It is risky, yes. So weigh whether the thing helps the company in a strategic way. If that tool gets you a lot of hours back, or lets you deliver a lot more to your clients, I would build it.

Because look at the other side of it. It is not that hard to find someone later on who can fix the tool, improve it, update it, and the whole time you are still collecting the benefit. But if it is something important and you do not build it, you never get the benefit at all, and that is usually the worse strategy. You can buy the benefit from a vendor, fine, do that when you can. When you cannot, and you can see how AI could help your process and the tool is just not out there, it is worth building.

And today the first version does not need a developer. Something like Lovable, or a coding agent like Claude Code or Codex, gets a person who knows the work to a working tool, and keeping that alive later is not the wall it used to be. Take the chance, improve your workflow, and yes, your company will have something to deal with down the road. You will have collected the improvements the whole way there.

One more thing the guide underplays, and it is the thing Replit has that you might not. A built tool drifts. The model changes under it, the answers get a little different, and [nobody notices for weeks](https://rodamora.com/blog/ai-projects-dont-fail-at-your-size-they-go-underground) because nothing crashed. Replit can afford to build because they have a review system that catches that kind of drift, and if you do not have one yet, I wrote about [the four stages of reviewing AI work](https://rodamora.com/blog/the-four-stages-of-reviewing-ai-work) and that is where that argument lives.

CPA.com draws the rest as an iceberg, and their line for it is that AI changed the economics of experimentation, not the economics of operational durability. In plain words, the demo got cheap, and running the thing for three years with real client data did not.

Two of the failure patterns they list matter most for a firm like yours. One is pricing whiplash, vendors moving from per-seat to per-token, so the price you signed at is not the price eighteen months later, and that one hits the buy side as hard as the build side. The other is the model pulling one client's data into another client's work, which they call the failure mode most firms underestimate, and I agree with them.

## How to run the rule this quarter

Here is how I would run it, at the size of the decision, not as a slogan.

Write the problem down in one sentence, and next to it the price you can pay per month. If you cannot write both, you are not ready to buy or to build, you are ready to look.

Then go find the cheapest tool that solves it, or one that carries the connections and the AI you want. Give that search real time, a couple of weeks of somebody actually trying tools, before you let anyone open a code editor. Most of the time this step ends the question.

If nothing fits, weigh the benefit honestly. A lot of hours back, or a lot more delivered to clients, and you build. A small convenience, and you live with the gap or the imperfect tool.

If you build, build the smallest version that does the job, and before it goes live write down who owns it in three years, with a name on it. If you have no developers, the name is the person who will go find help when it breaks, and that is a real answer.

If the tool touches sensitive client data or regulated work, tax filings, anything with a client's personal details, buy it from a vendor who has already built the security, unless your builders can prove they have. That is CPA.com's sixth question and I would not argue with it.

Price the maintenance now, not later. The model changing, the connections breaking, the [tokens](https://rodamora.com/glossary/token) it burns each month. If nobody in the room can estimate it, that is your estimate, and it should worry you a little.

And the Friday CSV fixer is fine. CPA.com says to treat a one-off like that as learning, not infrastructure, and that is the right way to hold it. A tool you can throw away next month is the safest thing you will ever build.

## Where this stops

Two conditions, and I will state them as facts.

First, the build branch costs you a stretch of bugs and wrong data before it pays. Ours did, and we had a team to fix it. Without a team that stretch is longer and you are collecting help as you go, so it only makes sense when the benefit on the other side is real, hours back or more delivered. A tool that gives you neither is not worth that stretch.

Second, regulated work and sensitive client data sit outside this rule. There you buy from a vendor who already carries the security and the audit trail, and you build around them, on top of them, not instead of them.

And the edge of what I have seen. I have not yet built something I wished I had bought, and I have not yet watched one of our tools go stale because its builder left. So the leaving-builder side of this is CPA.com's warning plus my reasoning, not my measured case, and I would rather tell you that than pretend.

The frameworks got longer this year, and the rule got shorter. Buy the cheap tool first, and build the day nothing fits.