Ever had one of those daunting projects where you're asked to build a custom CRM from scratch, and you think, "Well, that's impossible"? I had that moment two years ago with a client who needed their CRM ready in just 14 weeks. Not your typical timeline. But here's the thing: using our 5-phase playbook, it was not only doable but surprisingly smooth. Stack Overflow and Postman were my daily companions. And yes, I learned more than a few lessons along the way.
Phase 1: Discovery and Scoping (Weeks 1-2)
Most CRM projects fail before a single line of code is written. I mean that. The failure happens in a conference room, usually around a whiteboard, when everyone nods along to vague requirements and nobody asks the uncomfortable questions.
With this particular project (a mid-size logistics company in Birmingham, around 80 staff), I spent the first two weeks doing almost nothing but listening. Workshops, recorded Zoom calls, and a shared Notion doc where stakeholders could dump every workflow they wanted the CRM to handle. The document grew to 47 pages. A lot of it was contradictory. That's actually fine, contradictions in a discovery doc are free; contradictions discovered in week 11 cost you a sprint and a client relationship.
What You're Actually Mapping
The goal in discovery isn't to capture every feature. It's to map the data relationships and the user roles that will shape every architectural decision downstream. I use Whimsical for flow diagrams at this stage. Quick, shareable, and clients can comment without needing an account.
By the end of week 2, you need four deliverables locked:
- A prioritised feature list, split into MVP and post-launch buckets
- An entity-relationship outline (not a full schema yet, just the nouns: contacts, deals, pipelines, tasks)
- User role definitions with permission levels written in plain English
- A signed-off timeline with named milestones, not vague phases
That last one is non-negotiable. "Phase 2 complete" means nothing. "Contact import and role-based access live in staging by day 28" means something.
---
Phase 2: Architecture and Tech Stack Decisions (Week 3)
One week. That's all I give this phase, because I've seen teams disappear into architecture debates for a month and ship nothing.
For this project, the stack was: Node.js with Express on the backend, PostgreSQL for the database, React on the front end, and the whole thing deployed on DigitalOcean managed Kubernetes. We used Prisma as the ORM because the schema was going to evolve quickly and Prisma's migration workflow is genuinely good for that.
Honestly, the stack matters less than people think. What matters more is:
- Will every developer on this project know this stack without a steep ramp-up?
- Does the architecture support the permission model you mapped in Phase 1?
- Can you add a new entity type (say, "supplier") in week 10 without rewriting the auth layer?
That third point is where I've been burned before. Back in 2021, Seahawk had a SaaS project where we bolted on multi-tenancy in week 9. Took four days to retrofit what should have been a day-one decision. Never again.
For authentication, I default to Auth0 unless there's a compelling reason not to. It handles the edge cases (password resets, MFA, social login) that eat junior developers alive.
---
Phase 3: Core Build Sprint (Weeks 4-9)
Six weeks. This is the engine room. And if your scoping was solid, this phase is actually the most straightforward part of the whole project.
I split this into two three-week mini-sprints with a hard internal review at the midpoint.
Sprint A: Data Layer and API (Weeks 4-6)
Nothing touches the front end until the API contract is agreed. Full stop. I document every endpoint in Postman before writing a controller, which sounds tedious but saves about two weeks of "wait, what does this endpoint return?" conversations later.
The database schema gets its first real pass here. For CRMs, the tables that always get underestimated are the activity log table and the custom fields table. Every client wants custom fields. Building a flexible custom_field_definitions table properly from day one is about four hours of work. Improvising it in week 11 is a nightmare.
Sprint B: Front End and Workflows (Weeks 7-9)
React with TanStack Query for server state management. I tried rolling with plain useEffect and local state on a smaller project in 2022. Never doing that to myself again, TanStack Query handles caching, background refetching, and optimistic updates in a way that makes CRM interfaces feel snappy without heroics.
For the UI component layer, we used shadcn/ui on this project. It's not a component library in the traditional sense; you own the code, which means you can actually customise it without fighting the library. For a CRM with a pipeline view, a contacts table, and a task board, that flexibility matters.
One thing that consistently slips in this sprint: empty states. A CRM with no data looks broken if you haven't designed for zero-state screens. Build them early. Clients demo to stakeholders with empty databases and first impressions stick.
---
Phase 4: Integrations and Data Migration (Weeks 10-11)
This is where most agencies underquote and underplan. I've seen it every time.
The Birmingham logistics client needed integrations with their existing Xero accounting setup and an older Salesforce instance they were migrating away from. Two weeks sounds tight. It was, but we made it because we'd stubbed the integration points back in Phase 3.
For the Salesforce migration specifically, we used their Bulk API 2.0 to extract the data, then ran it through a Node script that mapped their field structure to ours. The script took a day to write and three days to iterate on because Salesforce data is almost never as clean as clients believe it is. Budget for data cleaning. Always.
A few things I check before calling an integration "done":
- Failure handling: what happens when the third-party API goes down?
- Webhook idempotency: can you safely process the same event twice without doubling records?
- Rate limits: are you inside them under realistic load?
The Xero developer docs are actually decent, for what it's worth. The OAuth 2.0 flow is well documented and their sandbox environment works reliably.
---
Phase 5: QA, Hardening, and Handover (Weeks 12-14)
Three weeks for QA sounds generous until you're in it.
Week 12 is structured testing. I give the client a ClickUp board with every test case written as a task, they test, they mark it, they attach a Loom if something breaks. This gets real users clicking real flows, which always uncovers things that a developer-run test misses. Someone will try to paste 4,000 characters into a "notes" field. Someone will import a CSV with smart quotes in it. You want to find this now.
Week 13 is the fix sprint. No new features. Bug fixes and performance work only. I run Lighthouse against every key page. I also run k6 load tests against the API, not because the client asked for it, but because finding a slow query under 50 concurrent users in week 13 beats finding it after go-live.
Week 14 is handover and go-live prep.
The handover documentation I produce covers:
- Infrastructure overview (what's running where, how to scale it)
- Database backup and restore procedure, tested and verified
- How to add a new user role without touching code
- Known limitations and the backlog items we deferred
That last one is important. Be honest about what didn't make the cut. Clients respect it, and it sets up the next phase of work cleanly rather than leaving unspoken debt hanging over the relationship.
One Last Thing on Go-Live
Stagger it. We soft-launched to 10 users on day 92, watched the logs for 48 hours using Datadog, then opened it to the full 80-person team. That 48-hour window caught two edge cases in the pipeline stage transitions that hadn't shown up in testing. Nothing catastrophic, but the kind of thing that would have generated 15 support tickets on day one if we'd gone full-steam.
Go-live is not the end. It's just when the real user behaviour data starts arriving.
---
FAQ
How much does a custom CRM like this typically cost?
Honestly, it varies enormously, but a 14-week project scoped at this level with a small team (two back-end developers, one front-end developer, one project lead) typically runs between £60,000 and £120,000 depending on the complexity of integrations and data migration. If you're seeing quotes under £30,000 for a full custom build, push hard on what's actually being built versus configured from an existing template.
Can you build a custom CRM on WordPress?
You can, but I wouldn't for anything above about 500 records or 20 concurrent users. WordPress's data layer isn't designed for relational CRM workloads. At Seahawk we've built contact management layers on top of WordPress for smaller clients, but for anything serious, a proper back end with a relational database is the right call.
What's the biggest mistake teams make on CRM builds?
Under-specifying the permissions model. Everyone focuses on features and forgets that a CRM with 80 users needs a nuanced answer to "who can see what deal?" before you write a single API route. Retrofitting role-based access control at week 10 is painful in a way that's hard to describe until you've done it once.
Do you always use this exact tech stack?
No. The stack I described worked for this project's team and constraints. I've shipped CRMs on Laravel and Vue, on Django and React, and once on a Next.js full-stack setup that I was sceptical about but actually worked well. The architecture principles stay the same. The tools flex.
In the end, the custom CRM project was not just a challenge but a revelation. That tight 14-week window? It forced us to innovate, adapt, and deliver. Turns out, constraints can be a catalyst for creativity. Who knew deadlines could teach us so much about our craft? It's projects like these that remind me why I co-founded Seahawk Media in the first place.