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 render on the web forms and the phone forms, filter in list views, and come back through the API. Retiring one is a soft delete, so values already recorded stay readable.
A vertical pack renames entities to your trade’s words, so the navigation reads Enquiries and Engagements rather than Leads and Deals. Four packs ship, and a pack is a JSON file you could write yourself.
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.
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 2 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 software 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.
Six fixed stages: Prospecting, Qualification, Proposal, Negotiation, Closed Won and Closed Lost. Renaming or adding to them is a code change, so it is an engagement rather than a setting. Lead and ticket pipelines are configurable in the database and no client draws them yet.
There is nothing to configure and nothing to extend. No rules, no triggers, no branching. Ticket escalation and recurring invoices are the two scheduled behaviours in the product and both are configuration rather than a rule you author.
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.
Customising this product means changing this product. There is no plugin API, no extension points and no hook registry, which is why an update-safe customisation is a matter of how you structure your fork rather than something the architecture guarantees.
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. What you cannot do without code is change the deal stages, add a permission level, 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 2 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. Worth knowing that BottleCRM sends no outbound webhooks, so an integration polls or is driven from the other side.
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.
