Use case
Custom CRM Software
Custom CRM projects rarely fail on the CRM. They fail on the six systems underneath it, none of which anyone is excited to build.
Two things up front. We sell source code you clone and run on your own infrastructure, not a hosted CRM, so there is nothing here to sign up for. Many people looking for custom crm software should buy something off the shelf. Pipedrive, HubSpot, and other established products already cover standard sales workflows, often for less than the cost of custom development. If your business tracks leads through stages and closes deals, compare those products before deciding to build.
The case for building gets stronger when the thing you need to track is not a deal. It may be a matter, a placement, a property, a patient, a shipment, or a grant application. If every product requires you to rename core fields, that mismatch can also affect reporting.
When custom can be the right call
Three situations can justify the added development and maintenance.
Your record is something custom
A recruitment agency tracks one candidate against many roles and one role against many candidates. A law firm tracks a matter with billable time, documents, and a limitation date. Forcing either into a pipeline works right up until you need a report out of it.
The workflow is the product
If how you move work through your business is a competitive advantage, a fixed set of vendor stages may prevent you from representing that workflow accurately.
Seat pricing has gone silly
Forty people at $80 a month is $38,400 a year. That number changes the arithmetic, particularly when most of those seats need read access and nothing more.
What does not justify it: disliking the interface, wanting a feature that is on the roadmap, or a general feeling that you could do better. Those concerns may not offset the cost of building and maintaining a CRM.
What a CRM needs beneath the pipeline
Teams often plan the pipeline and automations first, then discover how much supporting work sits underneath:
Six common CRM systems
- Records with fields that changeUsers will request new fields over time. If adding one requires a migration and a deploy, routine configuration becomes development work.
- Activity historyCalls, emails, notes, and status changes need attribution and timestamps so users can see what happened to a record.
- Permissions per teamSales sees their own accounts, managers see the region, finance sees the numbers and none of the notes.
- Import and exportNew customers often arrive with a spreadsheet, and they may later need a complete export of their data.
- Search that worksAcross records, notes, and attachments, fast enough that people use it instead of scrolling.
- An audit trailRecord who changed sensitive values and when, so the team can resolve discrepancies.
These systems may not differentiate the product, but production users are likely to depend on several of them. Include them when estimating a custom CRM.
“The pipeline is one part of the estimate. The systems beneath it often require more work.”
$38,400
the annual cost in this example for 40 seats at $80 a month; use your actual seat count and vendor price
6 systems
records, history, permissions, import, search, and audit, all of which support routine CRM work
1 record type
a practical first scope to test with a real user before modelling the rest of the business
A practical build order
Start with the tenancy model and one useful record type. This limits the amount of work you need to revise after people use the system.
Five steps, in this order
Start from a base that has already solved tenancy
Accounts, organizations, membership roles, and invitations are the layer everything else scopes to. Mistakes here can leave later queries without the right organization boundaries, and adding organizations to a single-user schema requires changes across the data layer. This is a useful part to take from a template.
Model one record, not the whole domain
Pick the thing your business revolves around. Give it a list view, a detail view, and notes. Put it in front of the person who will use it every day, then revise the model from their feedback before expanding the scope.
Make fields data, not schema
A typed core with a flexible attributes column on top means adding a field can be a row rather than a release. Postgres supports this pattern with JSONB, which can reduce schema changes when fields vary by customer.
Let the agent write the boring layer, with rules
The template ships editor rules that describe how backend features are structured, how errors reach central middleware, how data fetching uses the typed SDK, and how tests are written. Those constraints give an agent project-specific conventions to follow, but its output still needs review and testing.
Add reporting last
Reporting requirements become clearer after people use the system. Delaying the dashboard until then reduces the risk of building metrics around assumptions that the workflow does not support.
After validating the workflow
Testing one record type with a real user gives you evidence before you expand the model, reporting, and automation.
What you would start from here
There is no CRM in this stack, and that is deliberate. What it gives you is the layer underneath one: organizations as the unit records belong to, roles and invitations, a Hono backend with Prisma and Kysely on Postgres, an admin app for looking things up when a customer emails, and Stripe billing if you intend to sell it rather than just use it. Add the collaboration pack and you also get teams and per-project permissions, which is usually how CRM access ends up being modelled anyway.
The record types, the stages, and the workflow are yours to write. That is the part that should be specific to you, and the reason to consider custom software in the first place.
A useful decision test
Seat pricing matters, but it does not show whether a custom data model is necessary.
Describe what your business tracks. If the answer is "we track deals through stages until they close", Pipedrive already targets that workflow and includes the supporting systems above. If the answer is "we track a candidate against many roles and a role against many candidates, and each has a compliance date", a standard sales pipeline may represent the relationships poorly and make reports harder to trust.
The shape of the record is a useful test alongside cost, interface quality, and vendor plans. If it does not fit a deal pipeline, start by validating one custom record type without rebuilding tenancy, activity history, and permissions.
The packs and screens below show the starting point. Compare what they include with the six supporting systems above, then estimate the record types, workflow, and reporting that remain specific to your business.
Two ways to install features
Same features underneath, different starting point. Either command resolves what the packs depend on, copies the source into your repository, and merges the Prisma schema.
Take a template
A landing page, a design system, a themed layout, and the features already wired into it. Rebrand it, put your product in the middle, ship.
npx @hype-stack/cli template$ hype-stack compose
Compose your own design
Your design and your choices, without rebuilding auth, billing, or notifications. Tick the packs you want and the CLI wires them into the open-source starter.
npx @hype-stack/cli composeInside the stack
What each pack gives you
Source code, not a dependency. Every pack lands in your repository across the surfaces the feature touches.
Authentication, organizations, roles, sessions, and a full admin app, powered by Better Auth on your own Postgres.
- Email & Google login
- Organizations & members
- Roles & permissions
- Admin app & dashboard
Packs in this stack
Every pack ships real source code: frontend, backend, and admin surfaces where the feature needs them. The ones this stack installs come first; the rest can be composed in later.
Questions, answered
More stacks
Turn your ideas into
Real applications.
Start free and own every line you ship. When you want more, one All-Access license unlocks every premium pack and template for a year.