I have tried CRMs built for sales teams. They assume a sales team: a pipeline with stages, quotas, a manager reading the funnel on Monday, and somebody whose job is data entry. A practice of one has to do the whole loop itself: find the work, quote it, invoice it, collect, renew it, and remember why any of it happened.

Ceremex is that loop in one application. SQLite, Phoenix LiveView, Oban for scheduled work, running on a server I control.

What is actually in it

The CRM half is the least interesting part. Companies, contacts, deals and the interaction timeline, with tags, segments, saved views, custom field definitions and starred contacts. It is what you would expect, and it is there because everything else hangs off it.

The other half is where the time used to go missing:

  • Leads and intake. Lead forms, lead routes, and inbound email captured onto the timeline, so a first conversation is not reconstructed from memory later.
  • Quotes. A money structure with lines and options, plus a public token and an acceptance record: the customer can accept a quote from a link without an account, and the acceptance is evidence rather than a screenshot.
  • Invoicing and collection. Invoices, proformas, credit notes, receipts, payments and advances, payment terms with schedules, receivables, and chases. The chase sequence is the quiet workhorse: a polite escalation that collects an invoice without a phone call and without pretending to be a lawyer.
  • Renewals. Renewal lineage, a renewal book and a queue, and the terms behind them. A renewal that arrives as a surprise is a renewal already lost.
  • Forecast. Layers, targets, quotas, categories and snapshots, so the year has a number that can be compared with what was promised in March.
  • Automation with an undo. Rules fire on events, and every fire writes an undo entry with the actor attached. Automation that cannot be reversed by the person who owns the decision is a liability, and I have been on the receiving end of enough of those.
  • Relationships beyond the funnel. Relationship kinds, referrals, buying committees, and the buyer’s named competitor. Deals are made by people who talk to each other, and a funnel diagram does not have a place to write that down.
  • Scheduling and presence. Cadences, calendar, tasks, booking links, business hours and field visits, which is how a directory of promises stays honest.
  • Memory and the desk. Notes that belong to no record, an inbox for what arrives, and a daily digest email with the four attention queues. A day without opening the app still ends with a follow-up done or two.
  • The unglamorous operations. Health, backup, audit, import, document storage behind a behaviour (local now, an S3 swap later), users and auth with login attempts recorded.

What it works against

The sales-team model of relationships: volume, cadence for its own sake, and a pipeline that flatters a forecast. Also the assumption that a small practice can run on a spreadsheet plus memory, which works until the spreadsheet has forty tabs and the memory belongs to one person who is on holiday.

And against spam. Contacts carry consent for contact, consent for marketing, a do-not-contact flag, a source and a timestamp. The send path reads the person fresh and refuses an opted-out contact rather than queueing it. A system that can mail somebody who said no is a liability with a nice interface.

Where it stands

Working, used daily, still growing. It is also an incubator: the sell-side parts proven here are meant to move into Kanpo later, which is why some of it reads like a laboratory rather than a product. Not for sale. It encodes one person’s practice, and that is the only reason it fits.

OVERBRING project
Ceremex: the commercial loop of a one-person practice
2026
/images/projects/companies/OVERBRING Labs.png

Have something worth building?

A paragraph about what you are working on is enough to start.

Say hello