White-Label vs Custom Build: The Client Portal Decision

The real question: do you want a brand or a codebase?

Firms comparing white-label software and a custom build are usually buying the same thing — client-facing software that carries the firm's name — and the decision is whether owning the codebase underneath is an asset or a liability for an accounting practice.

Put plainly: white-label buys the brand on someone else's maintained platform; a custom build buys the brand plus every responsibility of a software company. The right answer depends on which of those responsibilities the firm actually wants.

What a custom build genuinely gets you

A custom build gets you total control: any workflow, any screen, any integration, no vendor roadmap to wait on and no subscription to renew. For a firm whose portal is a genuine differentiator, that control can be worth its cost.

It also gets you ownership in the strict sense — the code is an asset the firm holds, and no vendor decision can change the product underneath you. These are real advantages, and firms with in-house development capability do exercise them.

What a custom build makes you responsible for

Ownership means operations: hosting, backups, security patching, dependency updates, privacy compliance, uptime, and a development relationship that must outlive the person who built version one. Each is manageable; together they are a second business run alongside the practice.

• Security patching and dependency updates, forever
• Hosting, backups and uptime — including during tax season
• A PIPEDA-aligned privacy posture, designed and maintained by the firm
• Every new feature at development prices, on development timelines
• Key-person risk: the developer who built it will not always be available

What white-label actually means in practice

White-label means the platform carries the firm's identity — name, logo, colours, tagline, letterhead and email display name — and runs on the firm's own domain or an instant branded subdomain, while the vendor maintains the code underneath.

In SpidNums, branding is per-firm configuration: clients sign in to a portal that looks and reads like the firm's own software, engagement letters and emails go out under the firm's name, and multi-tenant isolation keeps each firm's data separate with fail-closed controls. Reselling under your own brand is an invited model, not a workaround.

Data residency and security under each model

Under a custom build, residency and security are design decisions the firm must get right and keep right. Under white-label, they are inherited from the platform — SpidNums hosts in Canada (ca-central-1) with a PIPEDA-aligned posture and per-tenant data isolation.

Neither model is automatically safer. A well-run custom build can be excellent; the honest comparison is between the platform's security work and the security work the firm will realistically sustain for years — including the years when it is busy.

The cost model: flat subscription vs open-ended build

SpidNums is USD $1,200 per firm per year, everything included, unlimited clients and team members. A custom build has no list price: an initial build, then ongoing hosting, maintenance and every future feature — a cost that is open-ended by construction.

The comparison is a model difference, not a gotcha. A subscription is a known recurring cost with no asset at the end; a build is capital plus an ongoing obligation, with an asset that must be maintained to stay one. Firms should price the second honestly — including the partner hours that will manage it.

When a custom build is the right call

A custom build makes sense when the software is the business: a firm productising a unique client experience, workflows no vendor supports, an in-house development team already on payroll, or requirements a multi-tenant platform genuinely cannot meet.

Most practices are not in that position. They want the brand, the domain and the client experience — which is the exact slice white-label delivers — without acquiring a software operation whose demands peak, unhelpfully, at the same time of year the practice does.

A short decision checklist

Six questions settle most cases: who patches security issues in April; who owns residency and privacy compliance; what year five really costs; who builds the second feature; what happens when the original developer moves on; and whether clients would notice any difference beyond the brand.

• Who handles security updates during tax season?
• Who designs and maintains the privacy and residency posture?
• What does year five cost under each model?
• Who builds the second feature, and at what price?
• What is the plan when the original developer is unavailable?
• Would clients notice any difference beyond the brand — and is it worth the cost?