How to Hire a CRM Software Development Company

Before hiring a CRM software development company, settle one question: do you need a custom CRM at all? Most businesses do not. HubSpot, Zoho, Pipedrive and Dynamics cover the ordinary case, and the right developer will tell you so. If you have checked and the answer is still custom, this guide covers what to put in the brief, how to compare developers, what the contract must say, and the Australian privacy obligations that come with holding customer data in a system you own.

First, the question most people skip

A custom CRM is worth building when your sales or service process is unusual enough that an off-the-shelf product fights it: a quoting process with many steps and approvals, records that have to link to jobs, assets or sites in ways a standard contact-and-deal model cannot, a regulated workflow that must be followed exactly, or integration with a core system that no CRM vendor supports. It is not worth building because the subscription feels expensive, because a vendor’s layout is annoying, or because someone wants “our own system”. Those are configuration problems, and they are much cheaper to fix than a build.

Ask any developer you talk to whether they would configure an existing CRM instead. If they never say yes, they are not advising you.

Writing the brief

One to two pages. Who uses the system and how many of them. The records it holds (contacts, companies, deals, jobs, assets) and how they relate. The five to ten things people do in it every day, in plain words: “log a call”, “send a quote from a template”, “see every job for a customer”. The systems it must connect to, with the accounting package named. The reports the owner needs. What is wrong with whatever you use now. And the two or three things that make your process different, because those are the reason you are building.

Leave out technology choices. A good developer will propose those from the brief, and the proposal tells you whether they have understood it.

Comparing developers

Ask for a CRM they built that is still in daily use. Two or more years old, and a phone call with the business that uses it. Not a case study; a conversation about what broke and how it was fixed.

Ask how they handle the first version. A custom CRM should launch with the five daily tasks working well and nothing else, then grow. A developer who proposes building everything in one go is proposing a longer, riskier project.

Ask about data migration. Your contacts and history live somewhere now, probably in spreadsheets and an old system. Moving them cleanly is a project inside the project, and a developer who has not mentioned it has not thought about it.

Ask who owns what. Code, database, hosting account, documentation. The answer is you, from day one.

Ask what happens after launch. Response times, who fixes a bug on a Friday afternoon, how new features are priced, and what you would need in order to take the system to another developer.

Fixed price, time and materials, or retainer

Developers price custom work in one of three ways, and each suits a different stage. A fixed price suits the first version, once the scope is written: you know the cost, the developer carries the risk of estimating badly, and changes are priced separately. Time and materials suits work that cannot be scoped in advance, such as untangling old data or integrating with a system nobody fully understands; insist on a cap and weekly reporting. A monthly retainer suits the period after launch, when the business wants a steady stream of small improvements and someone on call. A proposal that is time and materials with no cap for the first version is a proposal to find out what it costs after it is built. Ask for the first version fixed, exploratory work capped, and support on a retainer you can cancel.

What the contract must say

The scope, in the same plain words as the brief. A fixed price for the first version, or a clearly bounded time and materials arrangement with a cap. Milestones you can check. Ownership of all code and data by you, with the source code delivered to a repository you control. Where the system is hosted and where the data sits, which for most Australian businesses should be an Australian region. Security requirements: multi-factor authentication, access per person, backups, and access removed when the engagement ends. Handover: documentation, a walkthrough, admin credentials. Support terms and prices for after launch. If any of these is missing, ask before signing.

Privacy obligations in Australia

A CRM is a database of personal information, and in Australia the Privacy Act’s Australian Privacy Principles govern how it is held. APP 11 requires an organisation to take reasonable steps to protect personal information from misuse, interference, loss and unauthorised access, and to destroy or de-identify it when it is no longer needed. The OAIC’s guide to securing personal information is explicit that outsourcing the build or the hosting does not move the obligation: if you hold the data, you are responsible for how the developer and the host protect it. That is why the security clauses above belong in the contract. The Australian Cyber Security Centre’s small business cyber security guide covers the practical minimum.

Want this as a one-page checklist? Ten things to settle before you hire a CRM software developer, on one A4 page.

Download the checklist (PDF)

A worked example

This is a hypothetical, not a client. Take an equipment hire company in Townsville with 25 staff. Its process links customers to hire contracts, to individual machines, to service history and to invoices in MYOB. Two off-the-shelf CRMs were tried and both treated a machine as an afterthought. The brief describes the records and the eight daily tasks. Three developers respond: one proposes a full build with every feature in six months; one proposes configuring an existing CRM, which the business has already tried; one proposes a first version with the eight tasks and the MYOB link in ten weeks, then monthly additions. The third is the right shape. The contract names the business as owner of the code, puts the data in an Australian cloud region, and sets support terms. Migration of the old spreadsheet data takes a fortnight of the ten weeks and is the part the staff remember.

How High10 helps

High10 builds custom CRM systems for Australian businesses whose process does not fit the standard products, and configures HubSpot and connects CRM automation where an existing product will do. We start by telling you which you need. Every project is quoted in writing after a scoping call, you own the code and data from day one, and the first version launches with the daily tasks working rather than everything at once.

Frequently asked questions

Should I build a custom CRM or use HubSpot or Zoho?

Use an existing product unless your process is unusual enough that it fights you: complex quoting and approvals, records that link to jobs or assets in ways a standard model cannot, a regulated workflow, or a core system no vendor connects to. Configuration is far cheaper than a build, and a good developer will say so.

How long does a custom CRM take to build?

A first version covering the daily tasks and one integration typically takes eight to fourteen weeks, including data migration and testing. Larger systems with several integrations run six months or more. Launching a small first version and adding to it monthly is faster and safer than building everything at once.

What should I check before signing with a CRM developer?

That you own the code and data, where the data is hosted, security requirements written into the contract, a scope in plain words, milestones, support terms, and a live system they built two or more years ago that you can ask the owner about.

What does custom CRM development cost in Australia?

It depends on the number of record types, integrations and users, and on how much data has to be migrated. We quote each project in writing after a scoping call rather than publishing figures. Our guide to custom CRM development costs covers the market ranges.