Build vs Buy Software: Should You Replace a SaaS Tool?

What is build vs buy software?

Build vs buy is the decision between making your own software for a need or paying a vendor for a ready-made product, usually a SaaS subscription. Buy when the need is common, regulated, or tied to a vendor's network. Build when you use a small slice of a large tool, your process is specific, or you pay per seat for people who barely log in. The decision comes down to total cost and who owns the upkeep.

This used to be a question for engineering budgets. It isn't anymore. AI tools now let a non-developer describe an app in plain English and get something working, which changes the "build" side of the math for small, specific tools. It does not change the math for everything. This post gives you a scorecard, a cost worksheet, a prompt to pressure-test your own case, and a worked example.

When does building beat buying?

Building wins in a narrower set of cases than enthusiasts claim, and a wider set than vendors admit. Look for these signs:

• You use a small slice. The renewal invoice covers a full suite. Your team uses a form, a table, an approval step, and a weekly report.
• You bend your process to fit the tool. People paste data into spreadsheets, rename fields to match the vendor's logic, or keep a side document because the tool cannot hold what you need.
• The seat count is the problem. Many people need to submit or view, few need to administer. Per-seat pricing treats them all the same.
• The need is internal and specific. Requests, intake, approvals, trackers, small dashboards, onboarding checklists, vendor lists, event sign-ups. Nobody outside your company needs to interoperate with it.
• You are locked into an export you cannot use. If getting your own data out is painful, ownership has value.

Buying wins when:

• The need is common and well solved. Email, calendar, video calls, accounting ledgers, expense reporting, HR systems of record. A vendor spreads the cost of getting it right across thousands of customers.
• Compliance is the product. Payroll, tax, payments, e-signature validity, security monitoring, anything an auditor will ask about.
• You depend on a network. Tools where your customers, partners, or candidates must also be on the platform.
• You need guaranteed support. If an outage costs real money at 2 a.m., you want a contract and a phone number, not a colleague who built it as a side project.
• Nobody will own it. The most common failure of internal tools is not that they were built badly. It's that the person who built them changed jobs.

How do you calculate what a SaaS tool really costs?

Most people compare the invoice to a build estimate. That compares the wrong things. Use this worksheet for both sides, and fill it in with your own numbers.

Cost of keeping the tool (annual)

Cost of building (first year, then annual)

Two honest notes. First, "hours times a loaded hourly cost" is the line people skip for their own time, which makes building look free. Include it. Second, upkeep is where most build cases fall apart. If you cannot name the person who will own the app next year, treat the build as a prototype, not a replacement.

What does a build vs buy scorecard look like?

Score each statement from 0 (false) to 2 (clearly true) for the tool you are considering replacing. Copy this as is.

BUILD VS BUY SCORECARD

Tool: ____________________   Annual cost: ________   Owner: ________

A. Fit for replacement
1. We use fewer than a quarter of its features.            0  1  2
2. Our workflow is specific to our company or team.        0  1  2
3. People work around the tool (spreadsheets, copy-paste). 0  1  2
4. Most seats are light users (view or submit only).       0  1  2
5. No outside party must use the same platform.            0  1  2

B. Risk of replacing
6. It does NOT handle payments, payroll, or regulated data. 0  1  2
7. A short outage would be an annoyance, not a crisis.     0  1  2
8. We can export all our data today.                       0  1  2
9. IT/security is willing to review a replacement.         0  1  2

C. Ownership
10. A named person will own the app for 12+ months.        0  1  2
11. We can describe the requirements in one page.          0  1  2
12. We can pilot it next to the old tool for one cycle.    0  1  2

SCORING (max 24)
18 to 24: Strong build candidate. Run a pilot.
11 to 17: Maybe. Fix the lowest-scoring section first.
0 to 10:  Buy, renegotiate, or cut seats instead.

If section B scores low, stop there regardless of the total. A great fit does not offset a payments or compliance problem.

Which SaaS tools are good candidates to replace?

These categories tend to score well, because the underlying data is simple and the workflow is yours:

• Intake and request forms with a status and an owner (facilities, IT asks, creative requests, procurement requests).
• Approval workflows that are really "submit, review, approve, notify."
• Trackers and registers: vendor lists, contract renewals, training completions, equipment loans, event registrations.
• Small dashboards that pull a few numbers together for a weekly meeting.
• Lightweight CRMs for a specific team, such as partner outreach or recruiting pipelines for one role family.
• Internal directories and knowledge bases with search over your own documents.

These usually do not:

• Accounting, payroll, tax, and expense systems.
• Identity, security, and monitoring tools.
• Anything customers or candidates log into at scale and expect to be supported.
• Platforms where the value is the other companies on it.

A useful gut check: if the tool's job could be described as "a table, a form, a few rules, and some notifications," it is a candidate. If its job is "stay correct under an audit," it isn't.

How do you replace a SaaS tool step by step?

1. Pull a usage report. Ask the tool's admin for logins, active users, and which features were touched in the last 90 days. This is your evidence, and it often ends the debate on its own.
2. Write the one-page requirement. List what people actually do in the tool: who submits what, who approves, what gets reported, what notifications go out. Leave out what the tool could do.
3. Run the scorecard and the cost worksheet. If the scorecard lands below 18 or the numbers don't beat the license plus workarounds, stop.
4. Talk to IT and security first. Ask about data classification, sign-in (single sign-on), where internal apps may run, and whether a review is required. It is much cheaper to learn this before you build.
5. Export your data and check it. Pull a full export from the old tool. Confirm it opens, the fields make sense, and nothing is missing. This is the migration plan and your safety net.
6. Build the smallest version. One workflow, one team. Use the spec prompt below to get the requirement into a form an AI builder or developer can act on.
7. Pilot next to the old tool for one full cycle. If the process runs monthly, run it for a month. Compare outputs. Track what users complain about.
8. Name the owner and write a short runbook. Who fixes it, who approves changes, where the data lives, how to restore it.
9. Cancel at renewal, not before. Give notice according to your contract. Keep the export for the retention period your company requires.

What prompt helps you decide, and write the spec?

Paste this into a general-purpose AI assistant. Fill in the brackets with real details. Do not paste confidential data, customer records, or contract terms into a tool your company has not approved.

I'm deciding whether to replace a software subscription with a small
custom app. Act as a skeptical advisor, not a cheerleader.

Tool: [name]
What we pay: [annual cost] for [number] seats
What we actually use it for (every task, in plain words):
[list]
Features we never use: [list or "not sure"]
Workarounds we use today: [list]
Data it holds: [types of data, and whether any is sensitive,
regulated, or about customers]
Who would own a replacement: [role, or "nobody yet"]

Do four things:
1. List the strongest reasons NOT to replace it, specific to what I
   described.
2. Tell me what hidden costs I am probably underestimating on the
   build side.
3. Tell me what questions IT, security, or legal would likely ask.
4. If, and only if, it still looks reasonable, write a one-page
   requirements spec: users and roles, the data each record holds,
   screens, rules and approvals, notifications, reports, and what
   must be imported from the old tool.

Mark every assumption you made so I can correct it.

What to check in the answer:

• Does the spec match what people really do? Read it to the two or three heaviest users of the old tool. They will spot the missing step in seconds.
• Are the risks specific or generic? If the "reasons not to" could apply to any tool, push back and ask for ones tied to your data and workflow.
• Did it invent requirements? AI assistants fill gaps with plausible features. Delete anything nobody asked for.

Where not to trust it: legal and compliance conclusions, security claims, and cost figures. It can list the questions to ask. It cannot tell you your company's policy or what your vendor contract allows.

What does a worked example look like?

These numbers are invented to show the method. Use yours.

A communications team pays for a project and request management platform. The license covers 45 seats at an assumed $30 per seat per month, so $16,200 a year. The usage report shows 9 people log in weekly. The other 36 submit requests a few times a quarter. The team uses a request form, a status board, an approval step for the director, and a monthly report. They don't use time tracking, resource planning, or the template library.

Workarounds: someone rebuilds the monthly report in a spreadsheet by hand, about three hours a month. Another person nudges approvers by email, roughly an hour a week.

Scorecard: fit section scores 9 out of 10. Risk section scores 8 out of 8 (no regulated data, short outage tolerable, export available, IT willing to review). Ownership scores 5 out of 6: a coordinator will own it, requirements fit on a page, and the pilot can run for a month. Total 22 of 24. Strong candidate.

Cost view: the build side has a few days of the coordinator's time to specify and test, a platform subscription, AI usage while building, and about two hours a month of upkeep. The keep side has $16,200 plus about 7 hours a month of workaround time. The build is likely cheaper, but only if the coordinator really does own it. If she leaves and nobody inherits it, the savings vanish. So the team writes a one-page runbook and gets the director's sign-off on ownership before starting.

They pilot for one monthly cycle with both tools running, compare the reports, fix two missing notifications, and cancel at renewal.

Also notice what the team decided not to do: they did not replace the company's expense system, which the same coordinator found annoying. It failed section B.

Can you build the replacement without a developer?

For small internal tools, often yes. The harder part is being precise about what you need, which the spec prompt above helps with, and being honest about ownership and security afterward. If you want to try, Remy is a product agent that builds a full-stack app from a plain-English description, including the database, sign-in, and a live URL. A typical first build takes about an hour. Pricing is $99 a month ($79 billed annually) for the platform, plus AI tokens at cost, which the pricing FAQ puts at roughly $100 to $500 from idea to deployed app. The code is standard TypeScript in a git repo you own, though cancelling the subscription takes the apps offline.