The build process
A serious system needsa clear build process.
Map the operation. Agree the model. Design the daily work. Build the complete workflow. Prove it with the people who will use it.
The short answer
The build process
A custom CRM build moves through discovery, scope agreement, data modelling, interface design, engineering, migration rehearsals, user acceptance and handover. Wall & Fifth agrees the price and delivery plan against a defined release. We confirm the timeline after checking integrations, source data and client dependencies.
01 / Discovery
See the workflow people actually follow.
We speak to the person buying the system and the people using it. Sales, operations and leadership often describe the same workflow differently. Follow a real enquiry from arrival through qualification, delivery and completion, including the spreadsheets, messages and manual fixes along the way.
The outputs are a workflow map, a record inventory, a connection list and a clear account of the problems the CRM should solve. We identify the internal product owner, the source systems and the people who can approve decisions. Discovery should reduce uncertainty, not simply produce a long feature list.
02 / Scope
Agree what a completed release means.
Define the core records, relationships, lifecycle states and access rules. Decide which system owns each field and how changes move between systems. For every agent, define the source context, proposed action, approval requirement and expected behaviour when information is missing.
Agree acceptance scenarios: an imported enquiry lands once, the right owner sees it, a proposed follow-up can be reviewed, a won deal reaches delivery with its history and the expected report reconciles. The fixed-price proposal covers the defined release, its dependencies, ownership terms and change process.
Set the delivery plan after checking the actual integrations and a sample of the migration data. We do not attach the same eight-week promise to every custom CRM. Client decisions, provider access and source-data quality are explicit dependencies.
03 / Product design
Make everyday work easy to complete.
Design begins with the work people repeat: finding a relationship, updating a stage, assigning a task, reviewing a brief and seeing what needs attention. Fast views and clear record pages usually matter more than a decorative dashboard.
We prototype the key journeys with realistic records, long names, empty states and permission differences. Users review the interface before it becomes expensive to change. The approved design and data model guide engineering together.
04 / Engineering
Build complete workflows, including failure states.
Engineering covers the interface and the underlying behaviour: access control, record updates, integration jobs, retries, event history and reports. The team demonstrates working slices so stakeholders can assess the real system as it develops.
An integration is not complete when one test request succeeds. It must handle expired access, duplicate events, incomplete records and upstream errors. Agent actions require their own review and execution checks. Those details are part of delivering business software rather than a prototype.
05 / Migration & acceptance
Rehearse the move before the business depends on it.
Migration starts in a test environment. We reconcile record counts, field mappings, links, files where accessible and representative history. The client reviews exceptions and signs off the mapping. A delta import, change freeze or another agreed strategy deals with edits made before cutover.
User acceptance follows the agreed scenarios with the actual roles and representative data. We record remaining issues, decide which block launch and agree a cutover and rollback plan. People receive training on the journeys they need, not only a tour of the navigation.
06 / Handover & evolution
Leave the team able to operate the product.
Handover includes the code and access agreed in the contract, deployment instructions, provider configuration, data-export procedures and responsibilities for backups and support. Retained reusable IP and licensing are documented when applicable.
After launch, observe adoption and real errors. Prioritise work against the original goals: fewer handover gaps, less re-keying, clearer next actions. Support and new feature development are separate scopes; continuing product work can use the Embedded Partner model.
Common questions
Before you build.
Clear scope. Clear responsibilities.
A better decision for the business.
How long does a custom CRM take to build?
We confirm the delivery plan after inspecting the requirements, integrations and source data. The plan includes design, engineering, migration rehearsals and user acceptance. A generic timeline would not account for those dependencies.
Who needs to be involved from our team?
An internal product owner, people who use the key workflows and administrators who can provide source-system access. The proposal identifies the decisions, review points and access needed from the client.
Can the scope change during the build?
Yes, through the agreed change process. We describe the impact on cost, delivery and existing work before accepting a change. The original acceptance criteria remain clear.
What happens after launch?
We hand over the agreed code, access and operating documentation, then work under the support arrangement selected by the client. New features can be commissioned separately or through ongoing product development.
Build around the business
Show us where the
work needs to move.
Your current CRM. The way your team works. The handover that keeps getting missed. We’ll start there.
Discuss your CRM Custom CRM builds from £50,000