Choose HubSpot over a custom CRM when its supported configuration covers your brokerage’s borrower file. Build your own CRM only when a requirement that changes a client outcome or a compliance record can’t be met that way. A custom build also needs a budget that lasts as long as the software does. Someone must apply security updates, repair connectors and make every change your team asks for after launch.
Build a Custom CRM or Configure HubSpot
A custom CRM is the better choice when a material requirement fails in HubSpot after supported configuration, and the brokerage can fund a developer to own the software after launch. Configure HubSpot when supported configuration covers the job and your team would rather run an established platform than manage a software project. Sort any list of HubSpot gaps into settings, edition limits and gaps that need new software before you price a build.
Separate an edition limit from a platform limit before you count a gap. HubSpot’s guide to creating custom objects lists them only on Enterprise subscriptions. If your file needs its own record type, the choice is between an Enterprise subscription and a build. HubSpot can still hold the record.
When HubSpot Fits
- Your file stages map to deal pipeline stages, and each client’s details fit contact, company and deal records.
- Your access rules follow record owners and teams.
- The edition that covers your requirements costs less over its life than building and running the same features.
When a Custom Build Fits
- A requirement still fails its acceptance test after configuration at the edition you would buy.
- No supported connector or API route closes the gap.
- A named person or firm will maintain the software, and the budget covers that work every year.
Separate Requirements From Preferences
A requirement is a workflow whose failure changes a client outcome, a compliance record or broker income. A preference is how a screen looks or the order staff click through it. Write each claimed gap as one row before anyone prices a build, so the decision rests on consequences.
Requirements Table for a Brokerage CRM
This example uses common broker workflows. Replace the rows with your own gaps.
| Workflow | Business consequence | HubSpot capability or limit | Custom-build acceptance result |
|---|---|---|---|
| Each broker sees only their own clients | One broker can open another broker’s borrower details | User permissions can limit viewing and editing to a user’s own records or their team’s records | Broker A opens a link to Broker B’s client and is refused |
| Staff without a need can’t see sensitive fields | Personal information reaches people who don’t need it | On Enterprise, Super Admins can restrict view and edit access to a single property for chosen users and teams | A test account without access can’t see the field on screen, in search or in an export |
| One client holds several loans and splits | The post-settlement review uses the wrong balance or lender | Custom objects on Enterprise; on other editions, deals and properties | Each split is its own record, linked to the client and the lender |
| Consent is kept as a history | You can’t show what the client agreed to and when | Each consent can be stored as its own record, such as a custom object on Enterprise | A new consent adds a record and leaves earlier ones unchanged |
| A repeat enquiry joins the existing file | Two files split the client’s notes and documents | Contacts created in the CRM are deduplicated by email address; the manage duplicates tool needs Professional or Enterprise | A second enquiry with the same email updates the existing client |
| The brokerage can leave with all its data | History is lost when you change systems | Record exports cover properties and associations; activities such as notes and calls need a separate route | A full export holds every record, activity and document. Its counts match the live system |
Configuration Issue or New Software
A gap is a configuration issue when a supported setting, at some HubSpot edition, makes its acceptance test pass. It needs new software only when every setting, connector and API route leaves the test failing. Price an edition upgrade against a build before you treat a limit as permanent.
Incorrect: “We need our own CRM because the deal screen shows fields we never use.” That is a configuration issue, and the record layout and its properties can change.
Correct: “Every broker can see every client, and our privacy obligations need each broker limited to their own files.” That is a requirement. Owner-based permissions in HubSpot answer it, so it doesn’t justify a build either.
Define File Stages and Handoff Ownership
Trace one sample borrower file through both approaches before you decide. The table follows a fictional couple refinancing their owner-occupied home loan, from first enquiry to the review after settlement. Each stage names who owns the record and what the CRM must hold.
Sample Borrower File Under Both Approaches
| Stage | Record owner | Configure HubSpot | Build a custom CRM |
|---|---|---|---|
| Enquiry | Assigned broker | A form or import creates the contact, and the broker opens a deal in the first pipeline stage as its owner | The enquiry creates a client record with an owner field your developer builds |
| Consent | Assigned broker | Each consent is stored as its own record or activity on the contact, so later changes don’t overwrite it | Each consent is a row with its version, time and staff member, written once and never edited |
| Document collection | Broker or administrator | Files attach to the contact or deal, and a stage property shows what is still missing | Your developer builds the upload, the storage and the checklist of documents received |
| Lodgement handoff | Broker who lodges | Staff record the aggregator platform’s application reference on the deal | Staff record the same reference, unless you fund a connection to your aggregator’s platform |
| Post-settlement review | Assigned broker | A review date property and a task remind the broker | Your developer builds the review date, the reminder and the report |
Record Ownership and Permission Boundaries
Every client record needs one owner, and the permission rules decide who else can see it. In HubSpot, that owner drives the own-records and team-records permissions. In a custom build, your developer writes those rules and you test them. Decide in advance who takes over a departing broker’s clients, because both systems need a person to reassign them.
Keep consent as a history. A single “consent given” field shows only the latest answer and loses what the client agreed to earlier.
Aggregator Receipt Evidence at Handoff
Most brokers lodge through their aggregator’s platform or an aggregator CRM. Plan for staff to record the handoff by hand unless your aggregator supplies a supported connection for the system you choose. The supported routes for connecting other tools to HubSpot are covered in the guide to HubSpot CRM integration.
Whichever system you choose, the file must hold this evidence before it moves past lodgement:
- the application reference the aggregator’s platform returns
- the lender and the product submitted
- the time of submission and the staff member who submitted it
- a stage that shows “lodged” only after the reference is entered
Trail commission checks after settlement can sit outside both systems. Track My Trail reads your aggregator’s monthly reports and shows which clients discharged, refinanced or dropped off, so neither CRM needs its own commission build.
Assign Responsibility for the Custom Build
A custom CRM belongs to the brokerage only when the brokerage holds the accounts and rights behind it. Write each item below into the development contract and check it before the developer’s last invoice is paid. The test is simple: could a new developer take over next week without the old one’s help?
Ownership Checklist for a Custom CRM
| Item | Who should own it | What the brokerage holds when the developer leaves |
|---|---|---|
| Source code | The brokerage, by assignment in the contract | The code repository in the brokerage’s own account, with build and deployment notes |
| Domain name | The brokerage | Registrar login in the brokerage’s name and email |
| Hosting and database accounts | The brokerage, with the developer as an invited user | Billing and administrator access, plus a list of every service the CRM uses |
| Backups | The brokerage | A schedule, a storage location the brokerage controls and a record of the last restore test |
| Support and fixes | A named developer or firm under a support agreement | Response times, the cost of a fix and the notice period for ending support |
| Access and credentials | The brokerage’s nominated administrator | Every administrator login, API key and secret, changed when the developer leaves |
Security, Incidents, Exports and Recovery
With a custom build, the brokerage answers for its security. The Australian Privacy Principles require reasonable steps to protect personal information from misuse, interference, loss and unauthorised access, modification or disclosure. Someone must apply framework and server updates, watch for failed sign-ins and respond to an incident. A breach likely to cause serious harm is notifiable under the Notifiable Data Breaches scheme, and the data breach reporting steps apply whoever built the system.
Set the export format in the contract: CSV or a database dump for records, plus the original files for documents. Then require a recovery plan that names who restores the system, from which backup and within how many hours.
HubSpot Administrator Responsibilities
With HubSpot, HubSpot maintains the platform and the brokerage administers its account. A Super Admin manages users, permissions, connected apps and any Sensitive Data settings. HubSpot’s acceptable use policy requires data in a sensitive category under privacy law to follow its Sensitive Data Terms. Its Sensitive Data guide lists the feature on Enterprise subscriptions.
Exports and recovery still need an owner. HubSpot exports records as CSV, XLS or XLSX files. Each download link expires after 30 days. Deleted records can be restored for up to 90 days, but permanent deletions can’t be. Keep your own scheduled export if the brokerage needs a copy it controls.
Compare Delivery and Operating Commitments
Both approaches carry cost before launch and after it. A HubSpot configuration replaces most development with a subscription and an administrator’s time. A custom build turns each change into development work. The drivers below decide the total, whatever the hourly rate or subscription.
Cost Drivers for Each Approach
| Cost driver | Configure HubSpot | Build a custom CRM |
|---|---|---|
| Discovery | Map file stages to pipelines, properties and permissions | Write a full specification, including data model and security |
| Configuration or development | Properties, pipelines, workflows and permission sets | Every screen, rule, report and permission, coded and tested |
| Migration | Import client records and match existing contacts | Write import scripts and test them against your current data |
| Training | Train staff on your configured screens | Train staff and write the manual, because no public help exists |
| Hosting | Included in the subscription | Servers, database, backups and monitoring, billed every month |
| Connector upkeep | Apps and API connections, which must run within HubSpot’s rate limits | Every connection, rebuilt when the other system changes |
| Change requests | An administrator changes settings within the edition | A developer changes code, tests it and deploys it |
HubSpot’s API usage guidelines limit a private app to 190 requests per 10 seconds on Professional and Enterprise. Daily limits are 625,000 requests per account on Professional and 1,000,000 on Enterprise. A connector that syncs your whole client list must fit inside those limits.
Why a Smaller Build Still Costs Money Every Year
Cutting the first release to a few screens lowers the build cost. It doesn’t remove the upkeep, because the software still needs hosting, backups, security updates and someone to call when it breaks. Each feature you add later also adds code that needs testing whenever anything else changes. Scope an implementation partner’s ongoing support with the guide to CRM implementation, and plan record transfer and recovery with the guide to CRM migration.
Set Acceptance and Exit Conditions
Write the acceptance tests before you sign the build contract or configure HubSpot, and run the same tests on both. A system that fails one of these tests is not ready for client files.
- Permissions: a broker signed in with their own account can open their clients and is refused another broker’s client, including through search and a direct link.
- Duplicate handling: a second enquiry with an existing client’s email joins the existing record, and staff can merge two records without losing notes or documents.
- Failed handoffs: a file without an aggregator application reference can’t move to “lodged”, and a stalled handoff appears on a list the owner checks.
- Complete export: one export run produces every client, loan, consent record, activity and document. Its counts match the live system.
- Recovery from a sample backup: restoring last week’s backup into a separate environment returns the same counts and opens a sample client file intact.
Then make the decision from the rows that still fail. When every row passes in HubSpot at an edition you can fund, configure HubSpot and keep the budget for administration. When a row that changes a client outcome or a compliance record fails at every edition, build a custom CRM. Do so only with a developer under a support agreement and an administrator who owns the accounts. Without both, the gap stays open in a custom build too, so close it in HubSpot with a documented manual step.
