AI coding is making it easier to attempt a familiar developer ambition: replace a subscription service with software you can operate yourself. OccupySaaS is pursuing that ambition with compatible alternatives to Salesforce and Auth0. Its public repositories give us a useful way to inspect the promise, because the working code and the unfinished operating work are documented together.

TL;DR

  • SalesCompel has an early persistent Go/PostgreSQL customer-record slice. Its separate Vue exploration prototype uses synthetic data and keeps edits in memory.
  • ZeroAuthy records checks with named Auth0 clients, and the OpenID Foundation lists a particular commit for three provider profiles. That is a bounded conformance self-certification scope.
  • The SalesCompel roadmap records unfinished milestones and no production certification. Compatibility has to be evaluated against the customer's actual features and workflows.
  • Hosting the replacement assigns the company an operating job. The early backend guide makes access removal a concrete example: an authorized database operator deletes a provisioned token's stored digest row.

Why rebuild a Salesforce alternative?

Salesforce advertises Pro Suite at $100 per user per month in US dollars, billed annually. Its page also offers lower-priced plans and a free suite, so that figure is one specific paid-plan example. It demonstrates why the number of people using a system can matter to its recurring bill. It gives us no basis for calculating savings from an early replacement with different functionality.

OccupySaaS calls per-seat pricing a tax on growth. Its proposed response is to publish compatible software that companies can run themselves. A company can then choose where to host it, who operates it and which changes it accepts, within the project's license and the limits of its own capabilities.

The site's protest language includes a claim about laid-off engineers. I haven't verified those employment histories. Its timeline dates ZeroAuthy's public project to October 14 and SalesCompel's to October 15. The November 2 peg is the fresh Hacker News discussion. There is no newly established launch announcement here.

For a prospective user, the useful part of the story is the relationship between that motive and the implementation. Existing customer data and company-specific workflows make leaving expensive even when an alternative is available to download. Compatibility aims to reduce part of that migration cost.

How compatible software can preserve an application

An application often talks to a service through a software client. That client sends requests to a server and expects particular responses and behavior. A compatible replacement can accept the same kind of requests at a different destination. Preserving that interface can save changes throughout the application that uses it.

The meaningful unit of evidence is the behavior your workflow needs. Can the client create and retrieve the expected record? Does an update preserve the fields the application depends on? Do the expected permission boundaries remain in place? These are proposed acceptance questions for a migration rehearsal. A screenshot of a familiar-looking interface cannot answer them by itself.

ZeroAuthy's compatibility matrix is useful because it names client libraries and versions. It also distinguishes behaviors checked through clients from behaviors covered by server-only tests. That makes it possible to ask a narrower question than whether a replacement is compatible with an entire vendor platform.

The distinction helps an evaluator decide where to investigate next. A recorded check can establish a starting point for that client and behavior. The customer's actual configuration, data and security expectations still require their own evidence. We did not run a migration or the project's test suite for this episode.

Open-source CRM scope: a backend and a separate prototype

SalesCompel's README describes an early tenant-isolated Go/PostgreSQL candidate. The implementation guide lists persistent Account and Contact operations, limited queries and provisioned bearer authentication. It also describes a localized record editor and the candidate's exclusions.

A separate Vue exploration prototype lets people inspect proposed Account and Contact screens using synthetic records. Its edits remain in memory and do not call the backend. Both surfaces can be useful at this stage. They answer different questions: the candidate provides a bounded persistent service, while the exploration prototype helps people examine a proposed interface.

Authentic repository screenshot showing SalesCompel's separately labelled exploration prototype. This is repository imagery, not a demo we executed.

For evaluation, I would write down which surface a demonstration is using before interpreting its behavior. A change visible in a local prototype has a different meaning from a write verified against persistent storage. The README gives readers enough information to keep those observations separate.

The remaining roadmap is equally important. No full program milestone has a recorded exit-gate pass. Production certification has not been reached. The scope estimate runs to hundreds of additional bounded work packages, with explicit caution that the estimate is not a delivery forecast.

That public accounting is helpful. A team can use it to identify gaps affecting its own migration rather than filling them in with assumptions about what a compatible name implies.

What ZeroAuthy's OpenID listing covers

The OpenID Foundation's table lists zeroauthy commit 38b4229 for Basic OP, Config OP and Form Post OP. I checked the Foundation's row rather than relying solely on the badge in the project's README.

The Foundation defines self-certification as an entity's formal declaration that an identified deployment conforms, through testing, to a particular protocol profile. That is useful evidence with a defined scope. Security review, operating reliability and compatibility with an entire commercial platform require their own evidence.

ZeroAuthy's roadmap places multi-factor sign-in and an operational hardening sweep in later work. An evaluator should read those limits alongside the recorded achievements. For a system entrusted with customer logins, an unsupported requirement can be enough to stop the production decision even if the supported slice is useful elsewhere.

The table's displayed certification dates and the repository's stated approval date differ. This article relies on the observed commit/profile listing and makes no claim about an exact approval day.

Who removes access after an employee leaves?

This is the detail that makes the ownership question concrete. SalesCompel's early backend guide says:

To revoke a provisioned token, delete its digest row through an authorized DB operator. Token lifecycle, public login and OAuth refresh are future work.

Source excerpt from the early SalesCompel backend guide. The quote is re-typeset and labelled as an excerpt, with file and commit attribution.

A token is the access credential in this procedure. Its digest is the fingerprint stored in the database. Removing that row is an authorized operator's documented job for this early candidate. The source does not promise a completed general offboarding product around the step.

For a company considering self-hosting, I would put that procedure into the rehearsal. Identify the operator, establish how the action is authorized and verify that the intended access has stopped. Those are recommendations for a future test. This episode reports the documented procedure.

The same reasoning applies to the other responsibilities discussed in the episode. Backups need an owner. Recovery needs evidence. A permission boundary should be evaluated with the actual workflows that use it. The software license and the people operating the service belong in the same budget conversation. Somebody still gets the dinner-time page.

Maintenance remains after AI coding

An older report supplies a useful parallel. On October 21, PostgreSQL committer Robert Haas described AI-assisted bug discovery outpacing human review, and linked the pressure to late feature reversals and the version nineteen delay. Models can draft fixes while people still check correctness and project standards. This dated explanation is maintenance context; it supplies no measurement of OccupySaaS's defect rate or review capacity.

The stated clean-room policy also acknowledges contractual risk around competitive API observation. Its provenance rules exclude confidential employer material. Apache licensing gives permission to use the code within its terms, while a company's legal review remains separate. A policy file cannot settle every possible dispute for a future operator.

Verdict: NEEDS REVIEW

I'd test the supported slices because a compatible open server can create an exit option. I'd keep production gated on the customer's migration evidence and a named owner for the service. The strongest next step is a rehearsal using the workflows the company actually needs, with the early implementation's documented limits left visible.

FAQ

Is SalesCompel a finished Salesforce replacement? Its README describes an early candidate and a separate exploration prototype. No full program milestone has a recorded exit-gate pass, and production certification has not been reached.

Does ZeroAuthy's OpenID listing establish full Auth0 compatibility? The Foundation lists a particular commit for three protocol profiles. Broader product compatibility and operating requirements need separate evidence.

Does self-hosting eliminate costs? The company still needs infrastructure and operators. The episode makes no measured savings claim and recommends evaluating maintenance and migration alongside licensing.

Sources

This article expands on an episode of **The Daily Diff, a five-minute daily video on what shipped and what broke in tech.
Watch the episode · Subscribe on YouTube · the written diff lands in your inbox every morning at thedailydiff.dev.

Video transcript and primary sources