A project called OccupySaaS hit the Hacker News front page this week with a simple pitch: laid-off engineers building open-source, drop-in replacements for expensive software-as-a-service (SaaS) platforms. Per its site, targets include Auth0 and Salesforce. If you pay per-seat fees for business software, this is worth understanding, and you can use the idea today to audit what you're paying for.
Here's what the project says it is, what it doesn't tell us yet, and a practical way to decide whether any alternative could save you money.
What OccupySaaS says it is
Per the OccupySaaS site, it's a protest movement. Its builders are laid-off engineers who create open-source replacements for popular SaaS products. The stated goals are to eliminate per-seat pricing and vendor lock-in.
The method, according to the project, is clean-room reverse-engineering. That means working from public documentation rather than copying a vendor's code, then using AI to help build compatible alternatives. "Drop-in" means the replacement is meant to work with the tools and integrations you already have, so you don't have to rebuild everything around it.
I can only report what the project claims. I haven't seen evidence here of how finished, secure, or well-supported any of these replacements are, so treat them as something to watch rather than something to switch to tomorrow.
Why per-seat pricing stings
Per-seat pricing means you pay for each person who has an account, usually every month or year. It's simple to buy, but costs climb every time you add a teammate, contractor, or part-time helper. Small teams feel this quickly, because a few extra seats can be a large share of the budget.
Lock-in is the second pain point. The longer your data and workflows live in one product, the harder it is to leave. OccupySaaS positions open, compatible alternatives as a way around both problems.
How clean-room reverse-engineering works
In plain terms, a clean-room approach tries to avoid copying someone else's protected code. The builders study only what's publicly available, such as published documentation describing how a service behaves, and then write new software that behaves the same way. The aim is compatibility without taking the original code.
That's the project's description of its own method. Whether any specific replacement stays on the right side of a vendor's terms or the law is a question for lawyers, and it's one to keep in mind if you're thinking about relying on one for your business.
A 20-minute subscription audit you can do now
You don't need OccupySaaS to benefit from the idea. Try this with a spreadsheet, on a laptop or desktop.
Step 1: List every paid tool
Open your bank or credit card statements for the last three months and search for recurring charges. Also check your email for words like "receipt," "invoice," and "renewal." Put each tool in a row with its monthly or annual cost.
Step 2: Count real users
For each tool, note how many seats you pay for and how many people actually signed in during the last 30 days. Most admin dashboards have a users or activity page under Settings or Admin. Unused seats are the easiest savings, and you can often remove them right away.
Step 3: Check how you'd get your data out
Look in each product's settings or help pages for "export." Try exporting a small sample, such as contacts or a handful of records, as a CSV file. If you can't find an export option, that's a lock-in warning sign worth knowing about before your renewal date.
Step 4: Mark what's critical
Flag tools that handle sign-in, customer records, or payments. Those carry the most risk if something goes wrong. Login systems in particular, the category Auth0 sits in, protect everything else you use, so they deserve the most caution before any change.
Step 5: Note renewal dates
Add each renewal date to your calendar with a reminder 30 days ahead. That gives you time to downgrade, negotiate, or move without being forced into another year.
How to judge any open-source alternative
If you or someone on your team looks at a replacement from OccupySaaS or anywhere else, ask a few questions first:
- Who maintains it? Look for recent updates and active contributors on its public code page.
- Is there documentation? You want clear setup and upgrade instructions.
- Who handles security? Self-hosted software means you're responsible for patches and backups, unless someone hosts it for you.
- Can you test it safely? Try it with dummy data, separate from your real customers or employees.
- What's the exit plan? Open formats and exports matter just as much going out as coming in.
Open source can remove license fees, but it doesn't remove the cost of running and securing software. For a team without technical help, a paid product may still be the cheaper option overall.
What to watch
The project is new, and its own description is the main source of detail so far. Things worth watching include which SaaS categories it targets next, whether the replacements prove stable, and how the vendors respond. The idea itself, that you shouldn't pay more every time your team grows or be trapped by your own data, is one you can act on today.
Your next step: Spend 20 minutes on the audit above, and cancel or downgrade at least one unused seat before your next renewal.
