Test the workflow before commissioning the software

Choose an existing CRM when it can handle your essential daily work after sensible configuration. Consider a custom CRM when a repeatable, important part of that work still needs awkward workarounds, and you can fund both the build and its ongoing care. If one missing connection is the problem, an integration may be enough.

The decision is not determined by team size or the fact that you currently use spreadsheets. Start with a specific failure: a request loses its owner, staff enter the same information twice, or a report cannot answer a question the business needs to act on. Then test which approach actually fixes it.

This guide is a way to compare the options before buying a subscription or commissioning development. It is not a recommendation to build every business tool yourself.

Compare three options, not just two

  • Configure an existing CRM: use its fields, stages and permissions to represent your process. This is a good candidate when the main job is keeping contacts, opportunities and follow-up organised.
  • Connect or extend existing tools: keep the CRM for customer records and add the missing connection or a small specialist tool. This is worth testing when the problem sits between your website, calendar, quoting system and CRM.
  • Build a custom system: create the workflow and interface around requirements that the tested alternatives cannot meet acceptably. You take on responsibility for maintaining that software, even when someone else develops it.

Custom fields alone do not establish a need for custom development. For example, HubSpot supports custom properties, with limits and some features depending on the subscription. Check the actual plan you would buy rather than assuming the trial or demonstration includes everything you need.

An integration also has limits. Decide which system owns each piece of information and what happens when updates fail. Connecting two tools without that agreement can leave two different versions of the same customer record.

Describe one real piece of work

Choose a frequent process that causes trouble and write it from start to finish. For an enquiry-driven business, it might be: a request arrives, someone takes responsibility, a conversation is recorded, an appointment changes and a colleague continues the work.

For each step, note who acts, what they need to see, what they may change and what counts as complete. Record exceptions too: the same person contacts you twice, a colleague is away, or the customer changes their mind.

Replace vague requirements with observable outcomes. Instead of “better lead management”, try “a colleague can take over an enquiry and see the last conversation and next task without asking the original owner”. Instead of “calendar integration”, specify which calendar updates which appointment and how a failed update becomes visible.

Separate an essential business rule from a habit. If the team can adopt a clearer shared process, configuration and training may solve the problem. If an unavoidable rule cannot be represented without hiding important information in notes, that is a more useful reason to investigate development.

Run the same trial on each serious option

Use fictional or properly anonymised records during the comparison. Give the person demonstrating each option the same tasks, then let a future user try them:

  • Bring a website enquiry into the system and assign its owner.
  • Handle a second enquiry from the same person without losing the history.
  • Reassign the work to a colleague and show the next action.
  • Change an appointment and check the calendar connection, including a failed update.
  • Sign in with a limited user account and check what it can see and change.
  • Export a sample customer with the related records you would need to move elsewhere.

For each task, record works as configured, needs an integration, needs custom development, or cannot meet the requirement. Note any manual copying and which paid plan or extra service is involved. Do not give a system a pass just because a feature name appears on its pricing page.

For a proposed custom build, ask for a small prototype of the hardest workflow before expanding the scope. A prototype can test whether the process makes sense; it does not prove that permissions, recovery or everyday operation are ready for production.

Compare the total cost over the same period

Request estimates against the same scope and planning period. You might use two years as a comparison window; that is a budgeting choice, not a universal payback deadline.

Include these categories for every option:

  • Getting started: process design, configuration or development, data cleanup, migration and testing.
  • Daily operation: subscriptions, hosting, integrations, email services, monitoring and the time spent administering the system.
  • Keeping it usable: training, support, bug fixes, security updates and changes to connected services.
  • Future changes and exit: new requirements, export work, documentation and a handover to another supplier.

A one-off development quote and a monthly licence price are not comparable totals. Ask what each excludes. For a configured CRM, check the plan required for the actual workflow. For custom software, agree who pays for maintenance and how changes are estimated.

If you expect less manual work, measure the current task and repeat it during the trial. Estimate the time saved from those observations. Keep that separate from extra sales you hope to generate: neither a new interface nor fewer clicks establishes a revenue increase.

Test how you would move your data

“There is an export button” is not a complete migration plan. Decide which records, relationships, notes and files matter, then inspect an export and test importing it into a separate destination.

HubSpot's record-export documentation, for example, distinguishes current property values and associations from activities such as calls and notes, which have separate export routes. That is a useful reason to test the contents of an export rather than judging it by its filename.

Custom development does not automatically remove dependency on a supplier. Agree who controls the repository and hosting accounts, what access and documentation will be handed over, and what another developer would need to run the system. Check these arrangements before the project starts.

Give maintenance a named owner

Before launch, decide who receives failure alerts, who can restore the system and who handles changes to connected tools. Record how much interruption and data loss the business can tolerate, then ask the supplier to demonstrate the corresponding recovery process.

Permissions deserve a practical test. Hiding an edit button is not sufficient protection. OWASP's authorisation guidance recommends denying access by default and checking permissions on every request. In a CRM trial, ask a developer to verify that a limited account cannot access another team's restricted records through a direct request either.

Backup coverage also needs checking. For example, Supabase documents that database backups exclude files stored through its Storage API; they contain the file metadata instead. If a system uses that setup for attachments, the recovery plan must account for the files separately. Ask for a restore test that includes the documents your team needs, not only the contact table.

These are operational responsibilities to budget and assign. A hosted platform may take care of parts of them, but the scope needs to be explicit in either approach.

What MarciCRM illustrates

My MarciCRM work brings property enquiries, communication statuses and follow-up into one environment. It separates work across Spain, Thailand and Dubai and connects with calendars and websites. Those are concrete workflow requirements, rather than a generic wish for “more CRM features”.

That example does not prove that a custom CRM will be cheaper or better for your company. Its useful lesson is to describe the work precisely enough to compare solutions. The wider connection between the website, advertising and follow-up matters whichever software you choose.

Make a decision you can explain

I would keep the configured CRM option when it passes the essential trial tasks and the operating costs are acceptable. I would investigate an integration when the CRM works well but a specific handover fails. I would consider a custom build when the remaining gaps affect essential work, have been demonstrated rather than assumed, and justify a funded maintenance plan.

Before asking for a proposal, prepare the workflow, its important exceptions, the systems it must connect to, the access rules and the records you need to preserve. Include the result of any trial. This gives a developer something more useful than a long feature wish list.

If you are deciding between these options, send me a short description through the contact page. Your message reaches hello@davidbuka.com. Tell me what the team does today, where it gets stuck and what you have already tested. We can use that to scope the next step.

Sources checked on 14 October 2026. The cover is an original editorial illustration, not a photograph of a client system.