A CRM shaped by the work, not the demo

Why it exists

Most CRMs ask you to adopt someone else's sales process. You get their stages, their fields, their idea of what a deal looks like — and then spend the first month bending your work to fit, or paying a consultant to bend the tool back.

The alternative is usually a spreadsheet: perfectly shaped to how you actually work, and hopeless at everything else — no permissions, no history, no way to capture a lead, no way to tell what changed last month or who changed it.

This product is an attempt at the middle. The pipeline is data you define. The fields are yours, down to which roles can see each one. But underneath it behaves like real software: every change is recorded, every record belongs to exactly one account, and the reporting is computed from history rather than guessed.

What we believe

Your process is not a configuration mistake

Pipeline stages, offerings and custom fields are first-class records, not settings buried three menus deep. If your process changes, you change it — you do not file a ticket.

Access control belongs in the data layer

A field hidden with CSS is not hidden. When you restrict a field to admins here, it disappears from the form, the list, the filter builder, the activity timeline and the parameters the server will accept. The same single rule decides all of them, so they cannot drift apart.

Numbers should mean what they say

"Won this month" is a surprisingly hard question, because the answer depends on when each deal actually crossed into Won — information a live table has already forgotten. Rather than approximate it with creation dates, the product materialises the history of every record as it changes and reads metrics from that. It is more machinery than the easy answer needs. It is also the difference between a number you can quote and a number you have to caveat.

Say what the software does, not what it will do

Everything described on this site is working today. Where something is partial — the MCP integration, for instance — it is labelled as a preview and the limitation is spelled out. We would rather lose a deal on a missing feature than win one on a misunderstanding.

How it is built

SWARE CRM is a server-rendered Ruby on Rails application using Hotwire for interactivity — Turbo for page updates and Stimulus for behaviour. There is no single-page-app front end, which keeps pages fast, accessible and simple to reason about.

Data lives in PostgreSQL, with custom fields stored as indexed JSON so they are searchable and filterable rather than inert. Background work — email sync, virus scanning, analytics projection — runs on Sidekiq. Files are stored in object storage and served through the application so access is always checked.

Every change ships with tests, including browser-driven tests that exercise the real interface, and the whole suite plus static security analysis has to pass before anything merges.

What we have chosen not to do

• No open sign-up. Accounts are created deliberately and people join by invitation.
• No feature-gated plans. Plans differ by team size and support, not by withholding permissions or the API.
• No invented social proof. You will not find fabricated testimonials or logos on this site.
• No certification claims we have not earned. We describe the controls that exist; we do not imply audits we have not had.