A custom CRM for your team

Configure, integrate or build?

Configure an existing CRM when its records, permissions and workflows meet the requirement after a reasonable setup. Test the difficult workflow with sample data before deciding that a custom application is needed.

Add an integration when the core system works but information is copied manually between tools. A bounded connection can address that gap while keeping familiar screens and records.

Build a custom CRM when essential workflows, access rules or integrations cannot be supported adequately by the available product. Include the responsibility for operating and maintaining the application in that decision.

Our own product, Corcava, is also an option to evaluate for connected CRM, projects, time tracking and invoicing. A custom-development discussion should begin with the requirements an existing product does not meet.

Start with one complete workflow

For a hypothetical service business, the first release might capture an enquiry, link it to a company and contact, assign an owner, record the next action and hand a won deal to delivery. A useful acceptance check follows that whole path. Advanced forecasting, a mobile app or automated email campaigns can be separate decisions.

Bring examples of the records and exceptions your team works with. A shared email address, two contacts at one company and a deal owned by a departing employee expose different requirements. Use sanitized samples for the initial brief.

Agree the rules before importing data

Access: define who may view, edit, reassign and export records. A hidden button does not enforce permissions. Reports, attachments, background jobs and integrations need the same data boundaries as the main screens.

History: decide which changes must be recorded, who can view that history and how long it is retained. Requirements such as an audit trail are part of the implementation scope.

Migration: map source fields, preserve useful identifiers and agree duplicate rules. Rehearse the import, inspect rejected rows and reconcile counts and relationships before cutover. Include a recovery plan and a decision about changes made in the old system during the move.

How delivery is scoped

Map the workflow. Describe the users, records, current problems and dependencies. The output is a bounded release plan with exclusions and acceptance checks.

Prove the uncertain part. Review the existing code or test the critical external integration before estimating a broader build. Confirm provider access, API limits and who owns changes on the other side.

Deliver and review. Implement the agreed workflow with permission checks and recovery behavior. Review working examples using representative data, including unauthorized access, duplicate submissions and a failed integration.

Pilot and hand over. Rehearse migration and deployment, introduce the system to the agreed users, and document setup, operations and remaining work. Assign owners for support, backups, restore checks and future changes.

What changes the estimate?

The number of connected workflows matters more than a screen count. Imported data quality, access rules, reporting, attachment history, external APIs and rollout constraints can change effort. A proposal should distinguish the first release from hosting, provider charges, maintenance and later development.

Useful handover deliverables include source access, build and deployment instructions, data mappings, integration configuration, acceptance evidence and known limitations. Agree what belongs in the engagement and who will run the application afterward.