Build vs Buy: When Agencies Should Replace SaaS With Own Tools

Replace a SaaS subscription with your own tool when four things are true. You use a small, stable slice of it. Its price grows every time you add a client or a seat. The workflow is part of how you win or keep clients. And the data it works on sits behind APIs you can actually get access to. If any of those is missing, keep paying. Some tools you should never build, like email delivery, accounting and a full CRM. Whichever way you go, cost both options over two to three years and include maintenance, because that's the line everyone forgets.

I build custom tools for marketing agencies, so you'd expect me to say "build everything". I don't. I've talked agencies out of builds that would have cost them more than the subscription ever did. This is the framework I use in those conversations.

Why this question comes up now

Two things changed.

First, building got cheaper. With Claude Code and a good template, a small team can stand up a working internal tool in days, not months. I showed one end to end in the Google Ads dashboard post.

Second, agency software stacks grew. Reporting, connectors, bulk launchers, creative trackers, pacing alerts, client portals: each one is a reasonable monthly fee on its own. Together, most of them charge per client account, so the bill grows with your client list.

Cheaper building doesn't make every build a good idea. It just means the decision is worth making on purpose.

Step 1: List what you pay for and what you use

Export your subscriptions from your accounting tool or card statements into a CSV with these columns: tool, monthly_cost, pricing_unit, units, owner, features_used, features_total. Then rank them:

import pandas as pd

df = pd.read_csv("subscriptions.csv")
df["annual_cost"] = df["monthly_cost"] * 12
df["usage_share"] = df["features_used"] / df["features_total"]

# High cost, low usage, per-client pricing = first candidates
candidates = df[(df["usage_share"] < 0.3) & (df["pricing_unit"].isin(["client", "account", "seat"]))]
print(candidates.sort_values("annual_cost", ascending=False)[
    ["tool", "annual_cost", "pricing_unit", "usage_share", "owner"]
])

"Features used" is a judgment call. Ask the person who uses the tool every day, not the person who bought it.

Step 2: Run each candidate through four questions

1. Do you use a narrow, stable slice?

If your team opens a reporting tool to look at the same eight metrics for every client, that's a narrow slice. If they use forty features and want more every quarter, it isn't. A narrow, stable slice is cheap to rebuild and cheap to keep running.

2. Does the price scale with your growth?

Per-client, per-ad-account and per-seat pricing grows with your agency. A custom tool's cost mostly doesn't: hosting for ten clients and fifty clients is often the same server. Flat-priced tools are rarely worth replacing on cost alone.

3. Is the workflow part of your edge?

If the way you report, launch or test is something you sell ("our weekly creative testing report"), owning it lets you shape it exactly to your process and brand. If it's commodity work nobody cares about, like invoicing, buy it.

4. Is the data reachable through official APIs?

This is where builds die. Meta, Google Ads, TikTok, Shopify and Klaviyo all have official APIs, but some need approval first. Google Ads needs an approved access level on your Cloud project. Meta needs App Review for advanced access. TikTok reviews every developer app. Check you can get access before you commit. Never build on scraping or unofficial endpoints for anything client-facing.

Four yes answers: strong build candidate. Three: worth a closer look. Two or fewer: keep buying.

Step 3: Cost both sides honestly

Cost it over two to three years, not one month. Here's the structure. The numbers are yours to fill in.

Buying:

• Subscription × months, at the client count you expect, not today's.
• Price increases. Assume some.
• Workarounds: the hours your team spends exporting, reformatting or patching around missing features.

Building:

• Build cost. Your developer's time or an agency's fixed fee.
• Hosting. A VPS, a database, backups, a domain.
• Maintenance. This is the one people skip. Ad platforms change their APIs all the time. Google ships several Google Ads API versions a year and sunsets old ones. In September 2026 it retired developer tokens entirely and moved access levels to Cloud projects. Meta versions the Graph API on a regular schedule. Someone has to keep up. Budget hours every month.
• Your time. Requirements, testing, onboarding the team.

If building wins only when you leave maintenance out, buying wins.

Step 4: Decide what kind of build

"Build" isn't one thing. From cheapest to most involved:

1. Glue automation. Keep your tools and connect them. A nightly script that moves data from the ad platforms into a sheet, or posts pacing alerts to Slack. Often enough on its own.
2. A replica of the slice you use. Rebuild the narrow part of a SaaS tool you actually use, branded and on your server, and cancel the subscription. Reporting dashboards and bulk launchers are the usual ones.
3. An internal platform. One app your team logs into for several workflows: reporting, launches, client onboarding.
4. A product. Your internal tool, made multi-tenant and sold to other agencies. Only go here once the internal version has been used in anger for a while.

Start at the lowest level that solves the problem.

What I'd build, and what I wouldn't

Good candidates for most performance agencies:

• Client reporting dashboards across Meta, Google and TikTok. The data is reachable, the metrics are stable, and per-client pricing hurts. See how to automate client reporting.
• Bulk campaign launchers from a sheet or template. See creating Meta campaigns from Excel.
• Spend pacing and anomaly alerts. Small, high-value, and mostly glue.
• Creative testing trackers tied to your own naming conventions.
• Internal ops portals that pull from your project management tool, ad platforms and Shopify into one view.

Don't build:

• Email sending infrastructure. Deliverability is a full-time job. Use Klaviyo or your ESP and integrate with its API.
• Accounting, invoicing, payroll. Regulated and boring in the best way. Buy it.
• A full CRM. Build views on top of one if you need them, not the core.
• Anything that needs compliance work you can't staff. Health data, payments handling and similar.
• Tools you use a little of, but where that little changes every month. You'll be rebuilding forever.

Step 5: Reduce the risk of building

If you decide to build, these lower the risk a lot:

• Run both in parallel for a month. Keep the subscription until the new tool has matched it on real clients. Then cancel.
• Own the code and the accounts. The repository, the cloud account, the domain and the API apps should be in your agency's name, not your developer's. If a contractor builds it, put that in the contract.
• Use the platforms' official API apps in your name. If your developer's app is the one approved by Meta or Google, you don't really own the tool.
• Write the boring docs. How to deploy, how to add a client, what to do when a token expires. One page is enough.
• Keep the scope small. Ship the slice you use. Say no to "while we're at it" until the first version has been in use for a few weeks.
• Plan maintenance. Either someone on your team owns it, or you pay someone to. Put API version upgrades on a calendar.

A worked example: replacing a reporting tool

Here's how the framework plays out on the most common case I see: an agency paying per client for a cross-platform reporting tool.

The slice. The team uses one dashboard template per client: spend, conversions, revenue, ROAS, CPA, and a week-over-week comparison, across Meta, Google and TikTok. They never touch the tool's alerting, its white-label editor or its two hundred connectors. That's a narrow, stable slice. Question 1: yes.

The pricing. It's per client account, so every new client adds to the bill. Question 2: yes.

The edge. The weekly report is something they mention in sales calls, and they want it in their own brand with their own commentary format. Question 3: yes.

The data. All three platforms have official reporting APIs. Getting access means a Google Cloud project with an approved access level, a Meta app with ads_read, and an approved TikTok developer app. That's a few weeks of paperwork, but it's all doable. Question 4: yes.

Four yeses, so we cost it. The build is a nightly sync into one table plus a branded dashboard, roughly what I describe in the client reporting guide. Maintenance is real: API version upgrades a few times a year per platform, the odd broken token, and small requests from the team. Once that's on the build side of the spreadsheet, the agency can see where the lines cross for their client count. They run both tools side by side for a month, then cancel.

Now flip one answer. If the team actually used the tool's alerting, its connectors and its client-facing editor every week, question 1 becomes a no. The rebuild gets three times bigger and never stops growing. That's a keep-buying answer, even with per-client pricing.

Common mistakes

Building because it's fun. If no one can name which subscription gets cancelled, it's a hobby project.

Underestimating approvals. App review and API access can take longer than the build. Start them first. I wrote a field guide to app review for exactly this.

Rebuilding the whole SaaS. You don't need their settings page, their integrations marketplace or their onboarding tour. Rebuild what you use.

Forgetting the client view. If clients log in to the old tool, the new one needs logins, permissions and branding on day one.

No owner after launch. Tools without an owner rot. Something breaks, nobody fixes it, the team goes back to spreadsheets.

A one-page decision checklist

• We use less than a third of this tool's features, and that set is stable
• Its price grows with our clients, accounts or seats
• The workflow is part of how we win or keep clients
• The data is available through official APIs, and we can get access
• Three-year cost of building, including maintenance, is lower than buying
• We know who owns it after launch
• We'll run both in parallel before cancelling

Five or more ticked: build it. Fewer: keep paying, and revisit next year.

How Scalvo can help

This is most of what we do. If there's a subscription you'd rather own, our custom tool replicas service rebuilds the part you use, on your server, in your name. If you want to turn an internal tool into something you sell, see SaaS product build. If you'd rather start with glue automations and see what sticks, the AI automation sprint is the place. Or book a call and bring your subscription list.