serendipity is a customer engagement app with its parts on show

A customer engagement reference, not a library

The one line description calls it an open source toolkit for building performant, high-quality applications, and the README expands that into customer engagement: applications that connect customers, products, people and operations. The second half is the more useful sentence, because it tells you the domain model is CRM shaped rather than generic.

What that model contains is named in the screenshots section of the README, which is the only place the user facing surface appears: a Home welcome page, navigation through a navigation bar, a command bar and a sidenav, and Customer Engagement sections for accounts and contacts. Behind those screens the Party Service manages leads, opportunities, accounts and contacts, so the four entity names are the domain.

Nothing is published as a package. There is no version on a registry, no releases on GitHub, and the README gives you no install command, which is consistent with a repository that is meant to be read, forked and run rather than consumed.

A progressive web app in front of a BFF

The front end is a Progressive Web App described as an Angular 22 plus Angular Material M3 single page application. Between it and everything else sits the component that decides the shape of the whole system: a Backend for Frontend, a Spring Boot 4.0.1 service whose stated job is to serve the PWA and proxy API requests.

That middle layer is the interesting decision. The browser never talks to the microservices directly, so the BFF is where session concerns, aggregation and the API surface for one client live. It also means the PWA is served by the same service that fronts the APIs, which is a deployment decision as much as an architectural one.

The stack list in the README is version-pinned rather than described loosely: Angular v22, Angular Material M3 at v22.1.1, Spring Boot v4.0.1, Spring Cloud 2025.1.0 and Java 25. Those are current generation numbers across the board, and they are the reason the project reads as a starting point for new work rather than an upgrade of something older.

Core services split identity away from party data

Two core services are named, and the split between them is the point.

Identity Service is Keycloak, providing OpenID Connect for authentication and OAuth 2.0 for authorization. That is the conventional choice and it is what makes the security section short: OpenID Connect for authentication, OAuth 2.0 for authorization, TLS to encrypt data in transit and AES to encrypt data at rest. Four claims, no hand written token handling.

Party Service is a Spring Boot microservice holding the CRM data, managing leads, opportunities, accounts and contacts. Keeping identity in Keycloak rather than in the same service means the BFF and the Party Service deal with tokens instead of passwords, and it means the identity layer can be replaced without touching the domain data.

Underneath both sits Spring Cloud 2025.1.0, so the two services are part of a service platform rather than two standalone Spring Boot applications, though the README does not say which discovery, gateway or configuration components are actually enabled.

Camunda 8.9 for tasks, form-js and bpmn-js for the screen

Workflow is a separate orchestration service: Human Tasks Service, running Camunda 8.9 for BPMN 2.0 orchestration. Human tasks are the reason this is worth naming separately from the party data, because an approval step on an opportunity is a process with a state machine, not a status column.

The browser side of that is web based tooling from bpmn.io. Serendipity uses form-js to render forms and bpmn-js to display BPMN 2.0 diagrams. So a process definition can be drawn and inspected inside the same application that runs it, rather than in a separate modelling tool, and the forms a task needs are rendered by the same component library.

Those two libraries are the only non framework UI dependencies the README names, and they sit alongside Angular Material rather than replacing it. The visible text stops here, so which form element types are covered and whether the diagram viewer is read only are questions the source answers rather than the README.

Reporting is not in this repository

The Reporting Services group contains one entry: Report Service, described as separate reporting infrastructure, with a link to a separate repository, js-docker, as where it lives. Everything else in the architecture list is inside this tree.

That makes this an incomplete system if you take the list at face value. Accounts, contacts, leads, opportunities, identity and human tasks are here; whatever the report service stores, renders and schedules is not. So a reader planning an evaluation has to visit the second repository before they can answer the question of where analytics output is produced, and has to reconcile two codebases rather than one.

The documentation list does acknowledge that the pieces are separately documented: there are pages for the BFF component, for the architecture guide, for the developer guide, for concepts including authentication, for an administration guide that covers Docker, and a roadmap.

Versions are pinned in the README and checked by a script

The README does not say current, latest or recent. It names exact numbers: Angular v22, Angular Material M3 v22.1.1, Spring Boot v4.0.1, Spring Cloud 2025.1.0, Java 25.

There is a reason for that precision visible in the tree. A file called `_check_versions.py` sits at the repository root, which is the kind of script you write when a dependency moves underneath you and the README quietly stops matching the build. The leading underscore and the root placement suggest it is meant to be run directly rather than imported, and its purpose is verification rather than configuration.

The rest of the root is documentation and branding: `ai.md`, a `.hermes.md`, a `.knowledge/` directory, editor configuration for `.continue/` and `.continuerc`, an `.agents/` directory, `divider.png` and `serendipity-logo.svg`, plus `CONTRIBUTING.md` and the usual `.github/` and `.gitignore`. The four directories at the front end and back end are where the code actually lives, and `website/` is what generates the documentation site.

The AI harness configuration ships inside the repository

More of the project's working method is committed than in most application repositories. Alongside the code there is `.agents/`, `.continue/` with a `.continuerc` config, a `.hermes.md` instruction file, a `.knowledge/` directory and a top level `ai.md`. Together those are configuration for coding agents and for an editor assistant, kept in the same tree as the application they describe.

That choice has a documentation counterpart. One of the documentation pages in the README list is Build with AI, under the path `docs/build-with-ai/harness-engineering/overview`, so writing the application with an agent harness is treated as a topic worth a guide rather than as an accident of how the code was produced.

For a reader this is a shortcut. The instruction files often state the conventions a project would otherwise only reveal through its build configuration, and here they sit beside the version pins that say the same thing about dependencies.

AGPL-3.0, no releases, and documentation as the only path in

The licence is the GNU Affero General Public License v3.0, with the full terms in the LICENSE file at the root. For a toolkit meant to be deployed and modified, that is the clause to read first, since the network use provision is what matters for a service built on it.

There are no tagged releases at all, so there is no version to pin for Serendipity itself, even though every dependency in the stack list is pinned to a number. The last push on main landed on 30 September 2026, so the tree moves while the release history stays empty.

The README also has no command of any kind. Getting started is delegated to a hosted guide at robinyo.github.io, with separate pages for installation, for trying or upgrading the system, and for Docker administration. The screenshot sections in the README are headings with captions and no visible images behind them, so what the interface actually looks like is something the documentation site has to answer too.

Editorial conclusion

Fit for a team that wants a worked reference for how an Angular front end, a Spring Boot backend for frontend, Keycloak and Camunda fit together in one deployable shape, and the repository is unusually explicit about which version of each piece it targets. Not fit as a library to import, since nothing here is published to a package registry and the README has no install command of its own. Before evaluating it, read the hosted Get Started guide rather than the README, note that the report service lives in a different repository, and take the AGPL-3.0 terms seriously if the plan is to deploy a modified version as a service.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository