A sales pipeline shaped around how your team actually sells — for companies whose process does not fit a generic CRM, and who would rather own the code than rent the seats.
public/images/solutions/crm-pipeline.pngThe pipeline board. Stages are defined per team, and deals ageing past their stage SLA surface before the weekly review rather than during it.
Who it's for
Sales teams of roughly 5 to 50 people who have hit the wall on a generic CRM — either on cost per seat, or on the fact that their sales process genuinely does not look like the one the tool assumes. Distributors with territory rules, agencies with multi-stage proposals, and B2B teams with long approval chains are the common cases.
The problem
In the words operators use, not the words software vendors use.
Website form to one inbox, WhatsApp to a rep's phone, a trade-show list in a spreadsheet, referrals mentioned in a meeting. There is no single arrival point, so there is no way to know what the actual conversion rate is.
Deals sit in stages long after they died because closing them as lost is a small admission of failure. The forecast is consequently optimistic in a way everyone knows about and nobody corrects.
Every CRM asks for information that benefits the manager and costs the rep. When logging a call takes ninety seconds, calls do not get logged, and the activity history that reporting depends on is fiction.
Someone pulls a CSV, pivots it, and emails a deck. By the time it is read it is three weeks stale, and nobody can drill into a number to see what it is made of.
Territory rules, split commissions, distributor tiers, approval chains, quote versioning — the things that make your business specific are exactly the things a generic CRM makes you work around with custom fields and discipline.
What it does
Feature lists organised by technical module tell you nothing about whether the software fits your team. These are grouped by the person who lives in them.
One arrival point for every lead, whatever channel it came from, with assignment that happens automatically rather than in a morning meeting.
The account model most B2B teams actually need — companies with several contacts, several open deals, and a relationship history that outlives any one of them.
Stages that describe your process, not a vendor's idea of one.
Designed around the fact that reps will only log what takes seconds. Everything that can be captured automatically is.
The single feature that most reliably increases close rate, because most deals are lost to silence rather than to competitors.
The permission model is where generic CRMs get expensive, because visibility rules are usually a paid tier.
Numbers that are current, and that you can click into until you reach the individual deal.
A CRM that cannot talk to the rest of your stack becomes another silo.
Screenshots
Every screenshot uses generated demo data. No real customer, student or member record appears anywhere on this site.
public/images/solutions/crm-deal-timeline.pngA deal timeline. Emails and stage changes land here automatically; only the notes required a human. That ratio is what determines whether a CRM's data is trustworthy.
public/images/solutions/crm-territory-rules.pngTerritory rules as configuration. In most generic CRMs this specific screen is either a paid tier or a consultant engagement.
public/images/solutions/crm-forecast.pngWeighted against committed. Showing both is what stops the forecast conversation from being an argument about optimism.
public/images/solutions/crm-mobile-log.pngMobile logging. Two taps to record a call outcome, because anything longer than that does not get done between meetings.
public/images/solutions/crm-permissions.pngThe permission editor. Field-level visibility matters more than people expect — margin is the usual example.
Roles & permissions
Publishing this table is unusual. It is also the fastest way to show that the system was designed for a real deployment rather than for a demo.
Visibility is enforced at the query layer, so a rep outside a territory does not receive the record and then have it hidden — the record never leaves the database.
| Capability | Admin Full configuration | Sales Manager Own team and territory | Sales Rep Own records | Executive Read-only, all data |
|---|---|---|---|---|
| Own leads and deals | Admin: Full | Sales Manager: Full | Sales Rep: Full | Executive: View |
| Team leads and deals | Admin: Full | Sales Manager: Full | Sales Rep: — | Executive: View |
| All leads and deals | Admin: Full | Sales Manager: — | Sales Rep: — | Executive: View |
| Reassign an owner | Admin: Full | Sales Manager: Edit | Sales Rep: — | Executive: — |
| Edit deal value | Admin: Full | Sales Manager: Edit | Sales Rep: Own | Executive: — |
| View margin and cost fields | Admin: Full | Sales Manager: View | Sales Rep: — | Executive: View |
| Apply a discount above threshold | Admin: Approve | Sales Manager: Approve | Sales Rep: — | Executive: — |
| Change pipeline stages | Admin: Full | Sales Manager: — | Sales Rep: — | Executive: — |
| Define territories | Admin: Full | Sales Manager: View | Sales Rep: — | Executive: View |
| Bulk export | Admin: Full | Sales Manager: Own | Sales Rep: — | Executive: View |
| Delete a record | Admin: Approve | Sales Manager: — | Sales Rep: — | Executive: — |
| API keys and webhooks | Admin: Full | Sales Manager: — | Sales Rep: — | Executive: — |
| Audit log | Admin: View | Sales Manager: — | Sales Rep: — | Executive: View |
Technical architecture
Skip this section if you are not technical — nothing later depends on it.
ASP.NET Core over PostgreSQL with a React front end. The two decisions that shape everything are the activity feed's write pattern — append-only, denormalised for read — and the permission model, which is applied as a query filter rather than as a post-fetch check.
Clients
Application
Async work
Data
A permission model this granular benefits from being expressed in a type system rather than in convention.
Relational core for the objects that need integrity, JSONB for the custom fields every CRM deployment invents.
Reps live in lists of thousands of rows. Virtualisation is not optional at that size.
Start with the database you already run. Add a search cluster only when the data justifies operating one.
Two-way email capture is what makes the activity log honest, and both major providers have first-class APIs.
Assignment rules, SLA checks, digests and sync are all scheduled work that must be observable.
Operationally simple at this scale, with isolation enforced somewhere a developer cannot bypass by accident.
Deployed to your cloud account, containerised, with the database in a managed service. Single-tenant per customer by default; the multi-tenant path exists for firms reselling the CRM to their own clients.
Notable engineering decisions
This is the section that separates a system somebody built from a system somebody screenshotted.
Every CRM build has to answer this early, because retrofitting it is expensive. There are three viable patterns and each is correct in a different situation.
Database per tenant. Strongest isolation, easiest compliance story, trivially simple per-tenant backup and restore. Costs: migrations must be applied N times, connection pooling gets awkward past a few hundred tenants, and cross-tenant reporting requires a separate pipeline. Right answer when tenants are few, large, and regulated.
Schema per tenant. A middle ground that in practice inherits the migration pain of the first pattern without inheriting all of its isolation benefits. We rarely choose it.
Shared schema with a tenant discriminator. One database, a TenantId on every table,
one migration. Operationally by far the simplest, and the only pattern where cross-tenant
analytics is a query rather than a project. The risk is obvious: one query that forgets
its filter is a data breach.
We default to the third, with the filter enforced where a developer cannot forget it — a global query filter at the ORM level, driven by the tenant claim on the authenticated principal. Queries that omit the filter return nothing rather than everything. Bypassing it requires an explicitly named call that exists in exactly one place in the codebase, is covered by tests that assert on cross-tenant leakage, and is what the audit log watches hardest.
For a client with a hard regulatory isolation requirement, we use database-per-tenant and accept the operational cost. The point is that this is a decision with a real trade-off, not a default to be inherited from a tutorial.
The activity timeline is the most-read screen in any CRM and the most-written table. Every email sync, stage change, call log, task completion and field edit produces a row, and the volume outgrows the deal table by two orders of magnitude within a year.
Three decisions keep it fast:
Append-only. Activities are never updated or deleted. A corrected note is a new activity superseding the old one. This removes update contention entirely, makes the table safe to partition by time, and means the audit trail is the same object as the feed rather than a parallel structure that can drift from it.
Denormalised at write. The actor’s name, the record’s title and the activity’s display summary are written onto the activity row rather than joined at read time. Names change rarely; timelines are read constantly. The trade — a background job that rewrites denormalised names when a user is renamed — is worth it many times over.
Partitioned by month, with the hot partition indexed differently. Recent activity is queried by record; historical activity is queried by date range for reporting. Those want different indexes, and partitioning lets them have different ones.
The result is a timeline that opens in a few milliseconds on records with thousands of activities, which matters because it is the screen a rep looks at before every call.
The tempting implementation of “a rep sees only their own deals” is to fetch and then filter. It is wrong for two reasons: the database does work that is thrown away, and sooner or later some endpoint returns a count, an aggregate, or an export that was computed before the filter was applied.
Instead, a user’s permission grants are resolved once per request into a filter expression that is composed into every query against a protected entity. A rep’s query for deals is physically different SQL from a manager’s. The consequences:
Field-level permissions work the same way, projected at the query rather than nulled afterwards. When a rep is not permitted to see margin, the margin column is not in the SELECT — so it cannot leak through an API response, a CSV export, or a debug log.
Every integration story starts with “we’ll fire a webhook” and gets interesting when the receiver is down for an hour.
Webhook deliveries are persisted before they are attempted, retried with exponential backoff, and moved to a dead-letter queue after a bounded number of failures — where they are visible and manually replayable rather than lost. Each delivery carries a signature and a monotonic sequence number per subscription, so a receiver can detect gaps and reordering rather than assuming it saw everything.
This is unglamorous and it is the difference between an integration that works in a demo and one that survives a year in production.
A seeded demo with generated companies, contacts and a full activity history is available during a call. No real customer data is used anywhere.
Nobody deploys a CRM as-is, and we would be suspicious of a vendor who claimed otherwise. The core — records, pipeline, activities, permissions — transfers directly. The work is in your specific stage definitions, territory rules and integrations.
FAQ
Often, no — and we will say so. If your process fits HubSpot or Pipedrive, buy it; you will get a better product for less money than any bespoke build. Custom becomes the right answer when the process genuinely does not fit (territory and commission rules are the usual culprits), when per-seat cost at your headcount exceeds the build cost within about two years, or when the CRM has to sit inside a larger system you already own. We would rather lose the project than build you something you should have rented.
By capturing automatically everything that can be captured automatically, and by making the remaining manual actions take seconds rather than minutes. Email sync, stage-change tasks and mobile-first logging do more for data quality than any training programme. If a rep has to open a laptop to log a call, the call does not get logged.
Yes, and it is a scoped part of the project rather than an afterthought. Companies, contacts, deals, notes and — importantly — activity history all migrate. Attachments and email history are the parts that vary by source system, so we confirm what is exportable from yours during discovery.
For most clients, nothing — you get a single-tenant deployment with your data in your database. The multi-tenant architecture matters if you intend to resell the CRM to your own customers, in which case the isolation model is already built rather than retrofitted later, which is much harder.
You own both. Source in your repository, database in your cloud account, no export restrictions and no per-seat licence. If you stop working with us, everything keeps running.
Related
Operational systems built around how your business actually works — not around what an off-the-shelf product assumes.
Learn moreSenior engineers embedded with your team, at your cadence — with the person who writes the code being the person you talk to.
Learn moreWe will show you the working system, tell you honestly what would need changing for your operation, and give you a range before you commit to anything.
30 minutes · We reply within one business day.