Build, Don't Buy: When to Make It Yourself

A RevOps manager can build a small tool that checks a sales handoff for missing information, replacing a recurring spreadsheet exercise and another ticket in the engineering queue. That makes building worth considering. It doesn't make the resulting software free to own, and the ownership cost is where a surprising number of promising projects get their math wrong.

The decision starts with the work you need done. A handoff checker, a shared customer database, and a payment system might all appear in the same app, but they are three different decisions. Treating the whole thing as one contest between building and buying makes both options look more extreme than they need to be.

_Revised September 10, 2026. The original publication date is retained._

The line moved for small, specific tools

AI coding tools make it possible to describe behavior, inspect a first implementation, and revise it without writing every line yourself. That changes who can attempt a small internal tool. The person who understands the sales process can participate directly instead of translating everything through a backlog and waiting for a developer to become available.

That capability still needs verification. Claude Code's own guidance emphasizes giving the agent a way to verify its work, such as tests, expected output, or screenshots, and separating exploration and planning from implementation when a task needs it. A first version is part of the process. Evidence that it behaves correctly is another part.

For the handoff checker, the first useful version might accept an exported file, identify missing fields, and produce a downloadable exception list. It doesn't need to write to the CRM yet. It doesn't need a new customer database, billing, messaging, or a dashboard full of charts. Its value comes from removing one repeatable annoyance accurately.

This kind of scope is why the old reflex of buying every tool deserves another look. A commercial product may solve a broader problem than the one you have. If you mainly need a few checks against your own rules, configuring a large platform can become more work than implementing those checks. You should compare the actual alternatives, including the setup each one requires.

But the opposite mistake is just as easy. A demo of a narrow checker can make rebuilding the entire CRM seem like the natural next step. It isn't. The narrow tool inherited an export format, an identity system, a source of customer truth, and a team process. Replacing those supporting systems adds responsibilities that the demo never had to carry.

Count ownership on both sides

Use a cost worksheet that gives building and buying the same treatment. Include initial setup, training, ongoing administration, software charges, outside help, and the cost of changing your mind. Avoid comparing a vendor's annual invoice with the price of the AI subscription used during one productive weekend. Those figures describe different amounts of work.

Here's an illustrative comparison, not a quote or a claim about typical prices. Suppose the commercial option costs $250 a month and takes twelve hours to configure. At an assumed internal labor value of $75 an hour, its first-year cost is $3,900 before ongoing administration: $3,000 in subscription charges and $900 in setup time.

Suppose the custom version needs twenty-four hours to build and test, costs $30 a month to run, and takes two hours of maintenance each month. On the same labor assumption, that is $1,800 to build, $360 to run, and $1,800 to maintain. The first-year total is $3,960. The cheap hosting bill wasn't the total cost.

Now change the fit. If the commercial option leaves the team doing three hours of manual cleanup each month, add $2,700 of annual work. If the custom option needs six hours of monthly maintenance instead of two, its maintenance alone becomes $5,400. The decision turns on fit and ownership, not on which invoice looks smaller in isolation.

Treat those estimates as ranges when you have weak evidence. Ask what happens if the build takes twice as long, the subscription adds more seats, or the integration needs outside help. A choice that only wins under the happiest assumptions isn't ready for a confident recommendation. It may still deserve a small experiment with a fixed spending limit.

Also separate the value of a person's time from money you can stop spending. If an internal employee builds the checker, their salary doesn't become a new cash invoice. Their time still has an opportunity cost. If the project delays an important operational fix, that displaced work belongs in the decision even when accounting doesn't book it as a software expense.

Buy the foundation, build the awkward bit

Many good answers combine the two approaches. Keep the established system of record and build a small interface or validation layer around it. The custom part can express the team's rules without taking ownership of every capability underneath. That is often a better fit for a non-coder builder than replacing an entire platform at once.

Payments make the distinction concrete. Stripe Checkout provides a prebuilt checkout experience that can be hosted by Stripe or embedded. A business can build its own ordering workflow around that service without also designing every payment-entry screen. The integration still has work to do, including interpreting successful and failed payment outcomes, but the purchase of a foundation narrows the custom responsibility.

Apply the same reasoning to the handoff checker. Start by reading an approved export. If that saves enough time to justify integration, connect read access to the existing CRM. Only consider writing corrections after the team has agreed which changes are safe, how they will be reviewed, and what happens when a person edits the same record at the same time.

The sequence gives you stopping points. The export-based version may be all the business needs. It may reveal that the real problem is inconsistent field definitions rather than a missing tool. Or it may produce evidence that justifies a more connected version. Each outcome is useful because the business hasn't committed to a large replacement before learning anything.

Write down the boundary in plain language. The checker flags missing handoff information; the CRM remains the customer record; the account owner approves corrections. If a proposed feature doesn't fit that statement, decide whether it belongs in the tool at all. Scope grows one reasonable request at a time, which is why the boundary needs to be explicit.

An export path matters on the buying side too. Before signing, ask for a sample export containing the records and relationships you care about. Verify that another person can use it. A vendor saying you own your data isn't the same as showing that your team can move it somewhere else without a reconstruction project.

The maintenance question needs a person's name

Who will notice if the checker quietly stops reading a new field? Who can restore yesterday's working version? Who pays the hosting account when the card expires? Those questions sound mundane because they are. They also describe the difference between software someone made and software a team can depend on.

The owner doesn't have to write every fix from memory. They do need access, a documented way to reproduce a problem, and enough understanding to judge whether a proposed fix solved it. AI can help with maintenance, but it doesn't become accountable for the business process. The organization still needs a person who will follow a failure through to a verified result.

For a small internal tool, a short operating note can carry a lot of that burden. Describe where the data comes from, what the tool changes, where it runs, how to check its health, and how to go back to the manual process. Keep account ownership with the business. A useful tool shouldn't depend on someone remembering which personal account created it.

Test the awkward inputs before inviting the team. Try an empty export, a missing column, a duplicate record, and a file from last month. Check whether the tool explains the problem without changing the input. Then have someone who didn't build it complete the real task. Their confusion is information you won't get from another pass through your own familiar screen.

Decide how much dependency is acceptable. A weekly report that can be recreated manually has a different maintenance burden from a dispatch board everyone needs at eight in the morning. If failure stops revenue-generating work, reliable support and recovery deserve a larger budget. A purchase may be worth its price because someone else is contractually responsible for part of that burden.

Buying still requires judgment. A vendor can provide support while leaving your configuration, data quality, and team adoption entirely to you. Ask what support actually covers and how quickly a blocking issue gets attention. A support link on a pricing page doesn't tell you whether someone will help untangle your particular workflow.

I would decide after the smallest credible trial. Run the custom checker on representative data, try the commercial workflow against the same cases, and compare finished work. Include the colleague who will maintain it and the people who will use it. Their experience matters more than the builder's excitement or the salesperson's clean demonstration.

Then write down why the chosen option wins and what would change the decision. A higher user count, a new reporting requirement, or the loss of the maintenance owner might justify revisiting it. That isn't a failure of the original choice. It is what happens when the business outgrows the assumptions the choice was based on.

The smartest thing to build is often the smallest thing that lets you stop fighting the software you already own.