The product
A finished CRM, and the engine it is built on.
Everything on this page is built and working today. The CRM is what you use on day one; the engine underneath is why Nazzamis described as an operating system rather than another contacts database.
One engine underneath, not five products beside each other
Fields, forms, permissions, audit, search, import, export and the API are a single layer. Modules sit on top of it. The CRM is the first one — anything added later inherits the whole layer the day it appears, because there is nothing else for it to be built out of.
Configuration is data, not a deployment
Add a field, drag it into a section, decide which roles can read it. Create, edit and detail screens change while you are looking at them. No release, no ticket, no developer, and the same builder shapes every module rather than each one having its own settings page.
Everything is on the record
Every change carries who made it, when, and from which address and browser. Every automation run records what fired and why. When a number looks wrong you can read what happened to it instead of arguing about it.
Records and pipelines
The CRM part, finished rather than sketched.
- Companies, contacts and deals, each with a detail page that shows the full history of what happened and who changed what.
- As many pipelines as you need, with your own stages, and a drag-and-drop board that updates the deal as you move it.
- Board, list and table views of the same data — the board for working, the table for scanning.
- Activities with types, priorities, owners and due dates, and a calendar with month, week, day and agenda views.
- Filters you can save and share with the team, so a view somebody worked out once does not have to be rebuilt.
- A dashboard of widgets you arrange yourself, per person, not per company.
An illustration drawn with the product’s own styles. Sample data.
Configuration instead of development
The part most CRMs make you pay a consultant for.
- Add fields to any module — text, numbers, currency, dates, dropdowns, ratings, formulas, file uploads, links to other records, and a dozen more.
- Arrange them with a drag-and-drop form builder into sections. Create, edit and detail screens all follow the layout you build.
- Show a field only when another field has a particular value, and require it only when it matters.
- Validation rules on your own fields, enforced by the API as well as the form, so an import cannot smuggle bad data past them.
- None of this is a deployment. It is data, it takes effect immediately, and it is reversible.
An illustration drawn with the product’s own styles. Sample data.
Rules that run themselves
Automation you can read afterwards, which is the hard part.
- Trigger when a record is created, updated, or moves to a stage.
- Filter with conditions combined by AND and OR, scoped to a pipeline if you want.
- Act: assign an owner, change a field, send an email, notify someone.
- Every run is logged with what fired it and what it did, so a rule behaving oddly can be read rather than guessed at.
Control and accountability
Who can see what, and what happened to it.
- Roles you define yourself, not three fixed ones.
- Permissions per pipeline, and read or write control on individual fields — a salary field the whole team can see the record of but not the number in.
- Every write is audited: who, what changed from what to what, when, from which address, in which browser.
- Deleted records go to a recycle bin and can be restored. Backups are real database dumps that have been restored in a drill, not a checkbox in a settings page.
An illustration drawn with the product’s own styles. Sample data.
Your data, and the way out
The test of whether a system respects you.
- Import from CSV or Excel with column mapping, a preview of what will happen, and duplicate detection before anything is written.
- Export the whole workspace to Excel, JSON or PDF, on any plan, at any time.
- A documented REST API with scoped keys — a key can be limited to reading contacts and nothing else.
- Webhooks signed with a shared secret and retried automatically, so an integration that was briefly down does not silently lose events.
- An OpenAPI specification generated from the same validation rules the API enforces, so the documentation cannot drift from the behaviour.
Not built yet
Named here rather than implied by their absence.
The AI layer
The name states the intention and the architecture is designed around it — permission-bounded, attributed, never answering from data the asker could not already see. None of it is built. Nothing in the product does anything with AI today.
Shared inbox
Connecting a mailbox so conversations sit beside the deal they belong to. Designed, not started.
Invoicing and payments
Quotes and invoices generated from records, with payment links. The export engine and numbering they need already exist; the module does not.
Projects, HR, inventory, support
The module system was built so these are configuration and a UI rather than four more codebases. That is the plan, and the CRM is the only one built.