Nanobox CRM
Customizing fields and stages
Adapt Nanobox CRM to how your business actually works: add custom fields, define record types, reshape pipeline stages, and change behavior at the source level.
A CRM that fits your business beats a feature-rich one that doesn't. Because you own Nanobox outright and get the full source, customization happens on two levels: configuration you do in the app, and deeper changes you make in the code. Most teams never need the second level, but it's there, and that's the whole point of owning the software you run.
Custom fields
Every record type (contacts, companies, deals) can carry fields beyond the defaults. Add the fields your workflow depends on: a license number for a contractor, a renewal date for a subscription, a referral source for a lead. Fields you add show up on records, in list views, and as columns you can map during a CSV import. [TODO: confirm where custom fields are managed in the app (settings panel vs. an admin area) and which field types are supported, e.g. text, number, date, dropdown, checkbox.]
Record types
Out of the box Nanobox models the standard CRM objects: contacts, companies, and deals. If your business thinks in other terms (properties, matters, patients, jobs), you can relabel or extend these to match. Lighter changes are configuration; structural ones (a brand-new object with its own relationships) are a code and schema change, which you can make because Drizzle ORM defines the schema in TypeScript you can edit. [TODO: confirm how far record-type customization goes in-app before it requires a code change.]
Pipeline stages
Your pipeline should mirror your real sales or service process, not a generic template. Rename stages, add or remove them, and reorder them so a deal's position reflects where it actually is. Teams running multiple processes (say, new business and renewals) often want more than one pipeline. [TODO: confirm whether multiple named pipelines are supported in-app and how stages map to deal records.] After changing stages, rebuild any saved views that filtered on the old names.
Workflows and deeper changes
This is where ownership pays off. Need a field that auto-populates, a validation rule, a webhook when a deal closes, or an integration with a tool you already use? You have the source. The stack is approachable (Next.js, TypeScript, Postgres, Drizzle, better-auth), so a developer can change behavior directly instead of waiting on a vendor's roadmap or paying for an add-on tier. There are no AI features to work around and no per-seat metering to fight. If you'd rather we make a change for you, that's available too. Either way, the software bends to your business instead of the other way around.