Client portals and custom tools: when to build and when to buy

Buy off-the-shelf software when your process looks like most businesses in your industry, and build custom only for the part that is genuinely unique to how you work. Compare the two on three-year cost at your real number of users, not the first invoice. For many growing businesses, the best answer sits in the middle: keep the standard tools and connect them, then build a small custom piece, like a client portal, where nothing off the shelf fits.

This guide gives you a fair way to make that call, with examples from property management and building.

Signs you’ve outgrown spreadsheets and off-the-shelf tools

Most businesses don’t need custom software. But there are some clear signs you’ve reached the limit of what you have:

• Double entry. The same details get typed into three systems, and they don’t match.
• The master spreadsheet. One file runs the business, only one person really understands it, and everyone’s scared to touch it.
• Customers asking for updates. Your team spends hours answering “where’s my job up to?” by phone and email.
• Workarounds on workarounds. Staff export from one tool, fix it in Excel and import it into another, every week.
• Paying for a lot, using a little. You’re on a big platform’s top plan for one feature, or stacking add-ons to fill gaps.
• The process doesn’t fit. Your software forces steps that don’t match how you actually work, so people skip it.

One or two of these is normal. Several at once, costing hours every week, is when it’s worth looking at options.

A common version in building: the sales team tracks enquiries in one tool, the estimator works in spreadsheets, the site team uses a job app, and clients get updates by whoever remembers to text them. Each tool is fine on its own. The trouble is in the gaps between them.

Off-the-shelf first: what it does well

Off-the-shelf software should be your starting point. It has real advantages:

• Fast to start. You can be using it this week, not in three months.
• Someone else maintains it. Security updates, bug fixes and new features are the vendor’s job.
• Tested by thousands of users. The common problems have already been found and fixed.
• Easy to hire for. New staff may already know the popular tools in your industry.
• Lower upfront cost. A monthly fee instead of a build project.

For standard jobs like accounting, payroll, email, rostering and general CRM, building your own rarely makes sense. These are solved problems. Before you look at custom, try the leading tools in your industry properly, with a real trial on real work, not a ten-minute demo.

Where custom earns its keep

Custom software is worth it when it supports the part of your business that sets you apart, or removes a bottleneck no product handles well. Good candidates:

• Client or customer portals. A place where clients see their job status, documents, approvals and next steps, without calling you.
• Your own process, built in. A quoting or assessment workflow that reflects years of experience that off-the-shelf tools don’t capture.
• Joining systems that don’t talk. A small layer that keeps your CRM, job management and accounting in step.
• Industry gaps. Niche requirements where available products are too generic, too expensive, or built for another country.

For example, a builder might use standard tools for accounting and scheduling, but build a client portal where buyers see selections, variations and progress photos in one place. That’s the part clients notice, and it’s specific to how that builder runs a job.

Be wary of building custom to replace something that works fine, or because the off-the-shelf product has one annoying feature. The cost of owning software doesn’t stop at launch.

Comparing three-year cost, not the first invoice

Off-the-shelf looks cheap because the first month is cheap. Custom looks expensive because the build is paid upfront. Neither tells the whole story. Compare total cost over three years.

Here’s a simple illustration, using made-up round numbers. Say a platform costs $50 per user per month, and you have 15 users. That’s $750 a month, or $27,000 over three years, before add-ons, and more if you hire. Now add the staff hours spent on workarounds. If three people spend two hours a week each on double entry, that’s six hours a week for three years. Put your own hourly cost against it.

Then price the custom option the same way: the build, plus hosting and support for 36 months, plus a realistic budget for changes. Sometimes custom wins. Often the standard tool still wins once you count everything. The point is to compare like with like, using your own numbers. Our guide to what custom software costs explains how those build quotes are put together.

The middle path: connecting tools you already have

Before you build anything, check whether connecting your existing tools solves the problem. Many of the pain points above, like double entry and missed updates, come from systems that don’t talk to each other, not from bad software.

Connecting tools usually means:

• A new enquiry in your website form creates a contact and a job automatically.
• A status change in your job system sends the client a text update.
• An approved quote creates an invoice in your accounting software.
• A small portal page pulls information from your existing systems, so clients can see it without new data entry.

Connections need looking after too. Vendors change their software, logins expire and a step can quietly fail. Make sure someone gets an alert when a connection stops working, and that there’s a simple list of what connects to what.

Done well, this costs a fraction of a full custom build, keeps vendor-maintained tools doing the heavy lifting, and can be changed as you grow. Where it doesn’t go far enough, you build just the missing piece.

Example: a maintenance request portal for a property manager

Picture a property management business running a few hundred rentals. Tenants report maintenance by phone, email and text. Requests get lost, photos sit in someone’s inbox, owners ask for updates and tradies call for access details. The property management software handles leases and rent well, but its maintenance tools don’t fit how this agency works.

A sensible approach:

1. Keep the core system. Leases, rent and trust accounting stay in the property management software. That’s not worth rebuilding.
2. Build a simple request form. Tenants log a request with photos, the property address and access details. It replaces scattered calls and emails.
3. Add triage rules. Urgent issues like no hot water or a burst pipe go straight to the on-call property manager. Routine jobs go into a queue.
4. Route to tradies and owners. The approved tradie gets the job details. Owners approve anything over their agreed limit with one tap.
5. Send automatic updates. Tenants and owners get a text when the job is booked, completed and invoiced.

The custom piece is small and focused on the one process that was causing the most pain. Everything else stays on tools the agency already pays for. Our property page has more on how this works for agencies. Land developers face a similar choice with interactive estate maps.

Questions to ask a developer before you commit

If you decide to build, these questions separate a solid project from an expensive headache:

• Can we start with a fixed-scope first version? A small version that solves the main problem, at a fixed price, before anything bigger.
• Who owns the code, and where does it live? Ideally in a repository in your own account, with access you control.
• What framework are you using? Common, well-supported technology makes it easier for another developer to take over.
• Where will it be hosted, and who pays for it? Get the hosting account in your business’s name.
• What documentation will we get? At minimum: how it’s set up, how to deploy changes, and a list of every account and login.
• How do you handle security and personal information? Especially if clients or tenants enter their details.
• What does support cost after launch? Bug fixes, updates and small changes, and how quickly they respond.
• What happens if we stop working together? How handover works, and what you’ll receive.

Good developers welcome these questions. If someone avoids them, treat that as your answer.

Where to start

Write down the three tasks that waste the most time each week and which tools are involved. Try fixing them with the software you have, or by connecting it, first. If a gap remains that’s specific to how you work, scope the smallest custom piece that closes it, and price it over three years.

If you’d like a second opinion, we build custom software and portals and provide hosting and support once they’re live, and we’ll tell you if off-the-shelf is the better fit. You can talk through your idea with us.