A surprising amount is a setting rather than a change: fields on any entity, your own vocabulary, the invoice your customers receive, your working week. The rest is Python and Svelte, and the source is yours either way.
MIT licensed, so nothing here needs our permission. Ask us when it is faster than doing it.
These are the ones people pay consultants for elsewhere. Every one is a screen an administrator already has, on the web app, and most of them on the phone too.
Your organisation defines them: text, number, date, dropdown, checkbox. They show on every record page and form, on the web and the phone, filter in list views, and come back through the API. Retiring one is a soft delete, so values already recorded stay readable.
In the hosted app, on Plus and Pro, you add the record types your business runs on, such as properties, vehicles or venues, with their own fields and links to other records. Each gets a list with search, filters and saved views, tags, CSV import and export, notes, a board grouped by one of its dropdown fields, and webhooks when a record is created, changed or deleted.
An industry app renames entities to your trade’s words, so the navigation reads Enquiries and Engagements rather than Leads and Deals. Four apps ship (professional services, real estate, education admissions, events and weddings), you install them from Settings, Apps after seeing what each will add, and removing one keeps your records.
Design the document your customers actually receive, with your own header, terms and layout, and preview it before it goes out. This is the one templating surface in the product and it is a real editor rather than a colour picker.
Business hours and holidays per organisation, which the two SLA clocks on every ticket count against. A ticket raised on Friday evening is not breaching by Monday morning because the calendar knows you were shut.
Who a ticket goes to, and what happens when it sits too long. Configured from Settings, applied by a background scan every five minutes, and no code involved.
As many deal pipelines as you sell through, each with its own stages marked open, won or lost, and the number of days a deal may sit in a stage before it is flagged. Lead pipelines get the same treatment. Admins edit them on the web or the phone.
Pick the events, paste a URL, and a signed request goes to Slack, Zapier, n8n or your own endpoint whenever one happens, retried if it fails. No code on the CRM side.
Canned responses your agents apply in one click, a tag vocabulary you own including merging duplicates, and rules for whether and how a closed ticket can come back.
Worth knowing before you decide whether to build or to ask. This page used to name the wrong stack for the backend entirely, so here it is checked against the repository.
Django 6 and Django REST Framework, Celery for background jobs, PostgreSQL with row-level security for tenant isolation. A new model, a new endpoint or a new scheduled job is Python, and the RLS rules are a real constraint on how you write it rather than a formality.
SvelteKit 3 with Svelte 5 runes and Tailwind 4. Pages, forms and list views live here. The web app is a client of the same public API as everything else, so a screen you add has no privileged access.
A Flutter app for Android and iOS against that same API. A feature is not finished on one client, so a change that adds a screen on the web usually wants its counterpart here, which is worth costing in from the start.
The open-source code is free in all three columns. What the right-hand two buy is our time, scoped and agreed in writing before anything is built.
Freeforever
Your team, your pace
Get a quotescoped first
Most teams start here
Get a quotescoped first
Build what is not there
Each of these is possible as a build. None of them is a screen you can open today, and assuming otherwise is the expensive kind of surprise.
Admins can write automation rules: when a record changes and the conditions hold, set a field, assign, create a task, notify or send a webhook. What a rule cannot do is branch, wait, or run on a date, so a multi-step process with timers and if-else paths is code or another tool.
Two roles, ADMIN and USER. Access is role plus ownership plus organisation, enforced in the API. Finer-grained permissions are real work rather than a settings screen, and worth scoping properly before you assume them.
The reports that exist are fixed: ticket analytics by agent and queue, a weighted pipeline view, and receivables in aging buckets. You cannot assemble your own from a widget library, because there is no widget library.
Invoice templates exist and are genuinely good. Email is not templated: the messages the system sends are fixed, and inbound mail becomes a ticket rather than a campaign.
There is no plugin API and nothing to install from a settings screen. The backend has a few registration points that another Django app installed beside it can use, such as adding record types of its own, but most customising still means changing this product, so keeping it update-safe is a matter of how you structure your fork.
The stack, the settings surface and the API schema are all in the open repository.
More than you would expect, and less than the word "customize" usually implies. Without touching code you can define fields on any entity, rename entities to your own vocabulary, design the invoice your customers receive, set your working week and holidays, and configure ticket routing, escalation, macros, tags and reopen policy. Deal and lead pipelines and their stages are settings too, and so are outbound webhooks and automation rules that act when a record changes. In the hosted app, Plus and Pro add record types of your own, with their own fields, lists and boards. What you cannot do without code is add a permission level, build a branching or scheduled workflow, or build a report that does not already exist.
Python for the backend: Django 6, Django REST Framework, Celery and PostgreSQL. Svelte for the web app: SvelteKit 3 with Svelte 5 runes and Tailwind 4. Dart and Flutter for the phone. If your team has a Django developer, the backend will feel entirely ordinary, with the exception of row-level security, which shapes how every query has to be written.
That depends on how you make them, and we would rather be straight about it: there is no plugin system to insulate you. Customising means changing the source, so surviving an update is about keeping your changes narrow and separable, the ordinary discipline of maintaining a fork. Our engagements are built that way, and it is the first thing we would talk about.
Branding and field modelling is usually one to two weeks. A new module, or anything that has to land on both the web app and the phone, is more like three to six. We scope it in writing before anything starts, and the estimate names what is included rather than a range.
Usually, and the reason is structural rather than a promise: every entity is writable over a documented JSON API with JWT auth and an OpenAPI schema, and the mobile app is a client of it. If your other system has an API, the integration is work rather than a research project. Events flow the other way through signed outbound webhooks, so another system can be told when a lead arrives or a deal is won rather than having to poll.
Yes, and it is the common path. Take the source, get it running, use it for a quarter, and you will know what you actually need rather than what you thought you needed. We can pick up an existing fork; bringing the diff to the first conversation makes it a much shorter one.
Bring the process you are trying to run rather than a feature list. Half the time the answer is a setting you already have, and we would rather say that than sell you a project.
