How to Cut a $3,000/mo SaaS Bill Down to $75

I run Obsidian Axis Group on $74 a month. That is not a discount; it is what happens when you stop renting infrastructure and start owning it. Most $3,000/month SaaS bills survive only because nobody ran a real audit. The OIL Framework deletes the waste first, then StackOS replaces what survives with Cloudflare Workers, Supabase, and Resend. OAG's StackOS Build session ($2,000–$3,500) gets the migration done in a single day.

Why This Matters Now

SaaS pricing has compounded for years. Vendors raise prices on renewal, add seat minimums, and bundle features you never asked for into tiers you cannot drop without losing something you actually use. For lower-middle-market companies in the $10M–$100M revenue band, that accumulation is quiet but expensive. A $3,000/month bill that started as a $400/month HubSpot subscription four years ago is not unusual.

The problem is not that SaaS is overpriced in a vacuum. The problem is that most operators never audited the stack deliberately. Tools got added to solve problems, the problems changed, and the tools stayed. The bill is not a pricing problem; it is a defaults problem. And defaults can be fixed.

Your $3,000/mo SaaS Bill Is a Renting Problem, Not a Negotiating Problem

The first instinct most operators have is to call the vendor and ask for a discount. That instinct is understandable and almost always wrong. Negotiating a SaaS contract might get you 10–20% off the current rate. Replacing the rental model entirely gets you 95% off or more. Those are not the same category of outcome.

Every seat, every API call, every storage tier is a line on someone else's income statement, not yours.
The goal is not a better contract; it is a different model entirely.
Most lower-middle-market companies are paying for capability they do not use and redundancy they did not design.
Cutting the bill starts with admitting it exists because of accumulated defaults, not deliberate choices.
Negotiating locks you into the renting model for another year; migrating ends it.

When I built the StackOS approach, the starting observation was simple: every SaaS tool is a managed layer on top of primitives you could own directly. Cloudflare, Supabase, and Resend are not budget alternatives; they are the same infrastructure layer enterprises use. The difference is that you pay for what you use instead of what a vendor's pricing team decided your segment should cost. That is a structural difference, not a discount.

Operating principle: the bill exists because of accumulated defaults, not deliberate choices; every default you reverse puts money back on your side of the ledger.

Run the OIL Framework Before You Touch a Single Tool

The OIL Framework has four steps in a fixed order: Interrogate, Delete, Simplify, Automate. The order is not a suggestion. Every team I have seen try to jump to "automate" ends up with a $3,000/month SaaS bill plus a $500/month Zapier tab on top of it. Automating waste makes the waste faster. That is not a win.

Interrogate: for every tool on the bill, answer three questions. Who uses it? What does it do? What breaks if it disappears tomorrow?
Delete: if the answer to "what breaks" is "nothing we care about," cancel the tool before you do anything else. Delete before you migrate.
Simplify: for what survives deletion, ask whether you actually need the feature tier you are paying for. Most workflows do not.
Automate: only after the stack is simplified do you build automation. Automation built on a simplified, owned stack costs almost nothing to run.

Most $3,000/month bills have $800–$1,200/month of tools solving problems that no longer exist in the business. The Interrogate step surfaces those. The Delete step ends them. You do not migrate a tool you should have canceled. See the full breakdown at /glossary/operational-waste.

Operating principle: delete before you migrate; automating waste just makes the waste faster.

What $75/Month Actually Buys You on Owned Infrastructure

The $75/month number is not a floor you negotiate up from. It is the ceiling you design down to. Here is what that stack looks like in practice:

Cloudflare Workers: compute and edge logic, no server to manage, billed per request at fractions of a cent.
Supabase: Postgres database plus auth plus storage, open-source core, generous free tier, predictable paid tiers.
Cloudflare R2: object storage with no egress fees, a direct replacement for S3 billing surprises.
Cloudflare KV: key-value caching at the edge, eliminates the need for a separate Redis instance.
Resend: transactional email with a clean API, replaces SendGrid or Mailgun at a fraction of the cost.
Stripe: payments, the one tool on this list where vendor lock-in is a reasonable trade for the network and compliance coverage.

I run OAG's entire back-end on this stack for $74 per month total. (OAG receipt: oag.monthly_run_cost) That is not a prototype or a staging environment; it is the production system that handles client intake, billing, and operations. You own the keys. No vendor can reprice, sunset, or hold your data hostage.

For the full technical architecture and the exact configuration that produces the $75/month number, see the StackOS glossary page or download the StackOS Framework PDF for $29.

Three Real Receipts From Companies That Made the Switch

The frameworks only matter if the numbers are real. Here are three production receipts, not case study abstractions.

500-person seasonal workforce: A seasonal operation running roughly 500 associates (OAG receipt: spirit_halloween.headcount) replaced UKG, ADP, Dayforce, and Kronos with a custom $75/month stack. The enterprise platforms those tools represent would have cost $48,000–$96,000 per year. (OAG receipt: spirit_halloween.system_cost) The custom stack runs the same workforce logic at 1/640th of the cost.
Professional services firm: A services firm replaced Salesforce Sales Cloud Enterprise, which runs approximately $2,000 per year per seat, (OAG receipt: jps.replaced_tool) with an owned CRM layer. The savings came to roughly $1,100 per year per seat. (OAG receipt: jps.savings) Multiply that across even five seats and you are looking at $5,500 returned annually.
Mobile mechanic operation: A mobile mechanic business replaced Jobber Grow at $199/month ($2,388/year) (OAG receipt: mobile_mechanic.replaced_tool) with a purpose-built job management layer. Annual savings: roughly $1,500. (OAG receipt: mobile_mechanic.savings)

None of these were theoretical exercises. They were production systems handling real transactions before and after the migration. The receipts matter more than the framework name. If you want to see the full operational detail behind any of these, the OAG blog has the teardowns.

Rented SaaS vs. Owned Infrastructure: Cost Comparison
Scenario	Rented SaaS (Annual)	Owned Stack (Annual)	Annual Savings
500-person seasonal workforce (UKG / ADP / Dayforce / Kronos)	$48,000–$96,000	$900	$47,100–$95,100
Professional services CRM (Salesforce Sales Cloud Enterprise, 5 seats)	$10,000	$4,500	$5,500
Mobile mechanic job management (Jobber Grow)	$2,388	$888	$1,500
Full OAG back-end (all functions)	Comparable SaaS: ~$3,000–$5,000/mo estimate	$888	$35,000+ (OAG opinion, no external citation)

StackOS: The Four Steps to Move From Rented to Owned

StackOS is the method that produces the $75/month outcome. It has four steps, also in a fixed order: Audit, Architect, Build, Own. Each step has a specific output, not just an activity.

Audit: map every tool, every monthly cost, every integration dependency, every team that touches it. The output is a complete cost and dependency map, not a wish list.
Architect: design the replacement on owned primitives. Decide what gets rebuilt and what gets deleted permanently. The output is a build plan with named tools and named owners.
Build: construct the replacement system. With the StackOS Build offer ($2,000–$3,500), this happens in a single 3-hour live session. The output is a running system, not a roadmap.
Own: you hold the keys, the code, and the documentation. No vendor dependency, no renewal risk, no surprise repricing. The output is a hand-off packet you can give to any technical operator.

The hand-off is the deliverable. If you still need OAG to keep the lights on after the Build session, we did the build wrong. That is not a marketing line; it is the design constraint that forces the system to be simple enough for your team to run. See the full Axis Method for the broader engagement structure when StackOS is one piece of a larger operational fix.

Operating principle: the hand-off is the deliverable; a system your team cannot own without us is a system we built wrong.

Which Path Fits Your Situation

There are three entry points, and the right one depends on whether the SaaS bill is the whole problem or just the most visible symptom of a larger operational structure problem.

StackOS Framework PDF ($29): you want the map, you have technical capacity on your team, and you will run the Audit-Architect-Build-Own sequence yourself. This is the Saturday execution path.
StackOS Build ($2,000–$3,500): you want a working replacement system delivered in a single 3-hour live session, not a document to read later. The output is code and documentation, not advice.
Operations Architect engagement ($3,000–$7,500/month): the SaaS bill is one symptom of a broader operational structure problem. Hiring is chaotic, processes are undocumented, and the team is running on institutional memory instead of systems. The full Axis Method (Diagnose, Stabilize, Document, Hand-off, Compound) addresses the structure, not just the bill.

If the $3,000/month SaaS bill is the only problem, start with the PDF or the Build session. If the bill is sitting on top of process debt, undocumented workflows, or a team running without clear ownership, the Operations Architect engagement (industry term: fractional COO) is the right entry point. The distinction matters because migrating infrastructure on top of an undocumented operation creates a clean technical system inside an operational mess, and that is a different failure mode, not a solved problem.

What Most SaaS Audits Miss (And Why They Fail)

Generic SaaS audits look for duplicate tools. That is a useful starting point, but it is not the real work. The OIL Framework looks for whether the underlying need is real at all. Those are different questions. A duplicate project management tool is a $100/month find. A project management tool solving a coordination problem that disappeared when the team restructured eighteen months ago is a $300/month find, and the generic audit misses it entirely.

Most $3,000/month bills have $800–$1,200/month of tools solving problems that no longer exist in the business.
Integrations between SaaS tools are hidden costs; when you replace the tools, you also eliminate the integration layer, including Zapier, Make, and any custom middleware sitting between systems.
The DefaultFail principle applies directly here: design the replacement to survive a vendor going dark, not just a price increase. If the system fails when Supabase has an outage, you built for the happy path, not for production.
Data portability is a first-class requirement; the audit should flag every tool where your data is difficult to export, because those are the tools with the most pricing power over you.
The audit is not the end of the job; the documented, owned, running system is.

The reason most audits fail is that they produce a report instead of a replacement. A 40-page spreadsheet of your current SaaS tools does not save you a dollar. A running system on owned infrastructure does. That is the difference between an IT audit and a StackOS audit. See operational waste for the full taxonomy of where the money actually goes, and visit the OAG home page to see which engagement tier fits your current situation.

Sources

No external sources were cited in this article. All receipts are OAG-internal and listed in the OAG receipts section below.

OAG receipts cited

oag.monthly_run_cost
spirit_halloween.headcount
spirit_halloween.system_cost
jps.replaced_tool
jps.savings
mobile_mechanic.replaced_tool
mobile_mechanic.savings

Frequently asked

What SaaS tools can be replaced with Cloudflare Workers and Supabase?

Quite a few. Cloudflare Workers handles compute, routing, and edge logic that most teams run on Heroku, Render, or a managed Node server. Supabase handles Postgres, authentication, and file storage, which replaces parts of Firebase, Auth0, and S3 in most stacks. Add Cloudflare R2 for object storage, Cloudflare KV for caching, Resend for transactional email, and Stripe for payments, and you have replaced the core of what most lower-middle-market companies pay for in SaaS. The things this stack does not replace well are purpose-built vertical tools, like industry-specific compliance software, where the regulatory layer is the actual product. For everything else, the primitives cover it.

How long does it take to migrate off a $3,000/month SaaS stack?

The OIL Framework audit typically takes a few hours to a day depending on how many tools are on the bill and how well-documented the current stack is. The actual migration on the StackOS Build path takes one 3-hour live session. What takes longer is the Interrogate step, because you have to get honest answers from the people who use the tools. The common failure mode is skipping the Delete step and migrating everything, which means you rebuild the same bloat on cheaper infrastructure. If you run Interrogate and Delete correctly first, the Build session is fast because you are only building what actually needs to exist.

Is self-hosted infrastructure harder to maintain than SaaS for a small operations team?

It depends on what you build and how you document it. A system designed to be owned by your team, with clear documentation and no exotic dependencies, is not harder to maintain than a SaaS stack. It is often easier, because you are not tracking renewal dates, negotiating contracts, or adapting to vendor-driven UI changes. The StackOS default stack uses managed services at every layer, so there are no servers to patch. Supabase manages the database runtime; Cloudflare manages the compute runtime. Your team owns the configuration and the code, not the infrastructure operations underneath it. The hand-off documentation is what makes it maintainable, not the tools themselves.

What is the StackOS framework and how is it different from a standard IT audit?

A standard IT audit produces a report listing your current tools, their costs, and which ones overlap. StackOS produces a running replacement system. The four steps are Audit, Architect, Build, Own. The Audit step asks the same questions a standard audit asks. The Architect step designs the replacement on owned primitives instead of recommending cheaper SaaS alternatives. The Build step constructs the system in a live session. The Own step hands everything to your team with documentation. The output is not a slide deck. It is code, configuration, and documentation your team can run without outside help. That is the functional difference. See the full detail at the StackOS page.

What should I cut first when I audit my SaaS bill?

Start with tools where the answer to 'what breaks if this disappears tomorrow?' is 'I would have to check.' If the person responsible for a tool is not certain what it does in production, it is almost certainly safe to cancel. The second cut is tools that integrate only with other tools you are already planning to cut. Removing one tool from an integration chain often makes the other tools in the chain redundant too. Third cut is storage and backup tools where you are paying for capacity you are not using. Most teams have two or three of these on their bill. The OIL Framework Interrogate step surfaces all of these before you touch anything.

Can a 10-person company actually run on $75 a month in software costs?

Yes, with the right stack design. OAG itself runs end-to-end on $74 a month. The $75/month figure assumes you have replaced the core infrastructure layer with owned primitives, Cloudflare, Supabase, R2, KV, Resend, and Stripe, and that you have deleted the tools that were solving problems that no longer exist. What is not included in that number is industry-specific vertical software where the regulatory or network value is irreplaceable. Stripe is on the list because the compliance and network coverage justifies the vendor relationship. Everything else is a design choice, not a requirement. A 10-person company with clean operations and a simple stack can get to $75 a month.

What does an Operations Architect do that an IT consultant does not?

An IT consultant typically scopes, installs, and exits. An Operations Architect (industry term: fractional COO) diagnoses the operational structure, stabilizes it, documents it, and hands it back to your team running better than when we arrived. The Axis Method stages are Diagnose, Stabilize, Document, Hand-off, Compound. The goal is that at month three or month six, your team does not need us anymore because the system we built is documented well enough for them to own. An IT consultant's success metric is a working installation. An Operations Architect's success metric is a team that can run and improve the system without outside help. The hand-off is the deliverable, not the build.

Talk through it.

If any of this is applicable to where you are, book a 30-minute scoping call. No pitch deck.

Book a call →