If you're close to commissioning a custom CRM, you probably want to know what you're signing up for. What happens first? When do you see working software? How does your data move over, and what do you own at the end?
Here's how we run CRM projects, step by step. If you're still sizing the budget, start with how much a custom CRM costs. If you're not sure you should build at all, read custom CRM vs Salesforce or HubSpot first.
Before any code: watching the work
We start by watching the work: who touches a lead or a job, what they need to see, and where things fall through the cracks.
That means talking to the people who actually do it, not only the person who signs off on the project. The office manager, the sales rep, the dispatcher and the bookkeeper each see a different part of the process. We look at the tools they use now: the shared spreadsheet, the inbox, the whiteboard, the old CRM nobody likes.
The questions are practical:
- Where does a new lead come from, and who sees it first?
- What happens when a customer calls about a job that's already booked?
- Which information gets typed into more than one place?
- What report does someone build by hand every week?
- Where do leads or jobs get lost?
The people doing the work know where it breaks. Managers often describe the process as it should run. Both views matter, and the gap between them is usually where the CRM earns its keep.
Step 1: Workflow map and data model, in writing
What we learn becomes two documents, written down before any code:
- A workflow map. Each step from first contact to paid invoice, who does it, and what triggers the next step.
- A data model. The records the CRM holds (customers, contacts, deals, jobs, quotes, invoices, whatever your business actually runs on), how they relate to each other, which fields each one needs, and who can see or change what.
The map also lists the tools the CRM has to connect to and the data that has to come across from your current system.
Why in writing? Because a misunderstanding is cheapest to fix on paper. Your team can read the map and say "that's not how it works" before anyone has built the wrong thing. It's also useful to you on its own, whoever ends up building the system.
Step 2: Scope and fixed quote
The map shows what the whole job looks like. Scoping decides what goes into the first version and what can wait.
A good scope separates:
- The workflow that has to work on day one
- The integrations that matter now, and the ones a simple export can cover for a while
- The data worth migrating, and the old records that can stay in an archive
- The features that can follow in later slices, once your team has used the first ones
The quote is fixed and describes what's included, so you know exactly what you're paying for. Our published range for a web app, client portal or custom CRM is $25,000 to $70,000, and the cost guide explains what pushes a project toward either end.
Step 3: The first slice, the part that hurts most
We don't build the CRM screen by screen in the order it appears in the menu. We start with the part that hurts most: usually the one workflow where leads go cold or jobs fall through the cracks.
The first usable slice typically lands within a few weeks, and your team works in it from then on. Starting there has three benefits:
- The biggest problem gets fixed first. You feel the value early, not at the end.
- The feedback is real. People react to working software very differently from how they react to a document.
- The data model gets tested. If a record or relationship is wrong, it shows up while it's still cheap to change.
Step 4: Weekly slices on a staging site your team uses
After the first slice, we ship in weekly slices on a staging site your team uses for real. Staging is a separate copy of the CRM where new work lands first, so people can try it without risking live data.
Each week follows the same rhythm: we ship the next slice, your team uses it, and you tell us what's wrong, missing or confusing. That feedback shapes the next week. You see working software every week, and you can change priorities as you learn, so the finished CRM feels obvious to the people using it.
This is also where automation comes in: follow-up reminders when a quote goes unanswered, jobs assigned to the right person, invoices sent when work is marked complete. Where it helps, that can include AI, such as sorting and summarizing incoming leads or drafting replies for a person to approve. Our AI solutions page covers how we keep that grounded and reviewed.
Step 5: Data migration and switch-over
Moving your data is its own piece of work, and it's easy to underestimate.
We map your existing records, from spreadsheets, Salesforce, HubSpot or an older in-house tool, into the new data model and import them. Trial imports into staging early in the project help, because messy data (duplicates, free-text fields, three spellings of the same customer's name) shows up long before switch-over day.
Before switching over, we check the import with your team:
- Counts. Does the number of customers, jobs, deals and invoices match what you expect from the old system?
- Samples. People who know the data pick records they know well and check them field by field.
Only when both look right do you switch over. It's sensible to keep the old system available read-only for a while afterwards, so anyone can look something up if a question comes up.
Step 6: Handover
At handover you get the repository, the database, the infrastructure and the documentation, all in your name.
That matters more than it sounds. If the code sits in a developer's personal account, or the database runs on someone else's hosting, you depend on them for every change. With everything in your name, any competent developer can pick it up. There are no per-seat fees, so adding a user costs nothing extra, and no lock-in.
After launch: keep us on, or run it in-house
Once the CRM is live, you have options. You can keep us on for maintenance and improvements, or extend it in-house with your own developer.
Either way, budget for life after launch:
- Hosting. You pay for the servers and database the CRM runs on.
- Maintenance. Security updates, dependency upgrades, and fixes when a connected tool changes its API.
- Improvements. Once your team uses the CRM every day, they'll have ideas. Much of the value comes from the second and third rounds of changes.
What we need from you
A custom CRM is built with your team, not just for it. To go well, a project needs three things from your side:
- A named owner. One person who can answer questions and make decisions quickly, so work doesn't stall waiting for a reply.
- Access to the people doing the work. The workflow map is only as good as the conversations behind it.
- Weekly feedback. Someone on your team using each slice on staging and telling us plainly what doesn't work.
Access to your current tools and data exports helps too, especially for planning the migration.
FAQ
How long does it take to build a custom CRM?
The first usable slice typically lands within a few weeks, and your team works in it from then on. The full scope depends on how much of the business the CRM runs.
Do we have to stop using our current tool during the project?
No. Your team keeps working in the current system while the new one is built on staging. You switch over once the data has been imported and checked.
Who owns the code and the data?
You do. The repository, database, infrastructure and documentation are handed over in your name.
Start with the part that hurts most
Book a 30-minute call (Mon–Fri, 9–5 US Eastern). Bring the spreadsheet or tool that's hurting most, and we'll talk through what a first slice would look like. Prefer to write it down? Send a brief. More on how we build them: custom CRM development.