Custom Builds FAQs

A Custom Build is a scoped HighLevel implementation designed around a mortgage company's operating model rather than the standard Empower LO product. We map how the company handles producers, branches, brands, leads, borrowers, referral partners, permissions, campaigns, automations, integrations, and operational handoffs, then configure the client-owned HighLevel environment around those decisions.

Teams deploys Empower LO's productized mortgage platform inside Empower LO's white-labeled HighLevel environment. A Custom Build uses a separate white-labeled HighLevel environment that the client pays for and owns, with the architecture and implementation designed around the client's business. Teams is typically more cost-effective for organizations with fewer than 30 producers, while Custom Builds are better when platform ownership or operational complexity justifies the additional investment.

Custom Builds are best suited for mortgage companies with a defined operating model and enough complexity to justify company-owned infrastructure. Common signals include multiple branches or brands, specialized roles and permissions, custom lead ownership, deeper integrations, existing HighLevel technical debt, or a need to standardize how producers and operations work across the organization.

The client does. The client pays for and owns the separate white-labeled HighLevel environment, including its account access and platform relationship. Empower LO receives the access needed to design, build, test, and document the agreed implementation. Any post-launch support or optimization is separately scoped.

The client pays for its white-labeled HighLevel environment and the associated platform relationship. The proposal should also identify responsibility for usage-based services, phone, email, domains, third-party applications, integration vendors, and any other recurring costs required by the approved architecture.

Depending on scope, a build can include account and subaccount architecture, pipelines, custom fields, permissions, lead routing, workflow automation, borrower and referral-partner communication, campaigns, forms, funnels, calendars, producer onboarding, LOS or lead-source handoffs, documentation, training, and launch support. The written proposal defines the actual deliverables.

Often, yes. We can audit the existing account, identify what should be kept, retired, renamed, documented, or rebuilt, and recommend the safest path. Sometimes cleanup is the fastest answer. In other cases, rebuilding the architecture in the client-owned environment creates a cleaner and more maintainable result.

Data migration is not automatic. It may be included when it is specifically listed in the project scope and the source system, permissions, export format, and data quality support a safe import. Before migration, we define what will move, field mappings, duplicate handling, cleanup responsibilities, and validation steps.

Potentially. No specific integration is guaranteed until feasibility is confirmed. Feasibility depends on available APIs, webhooks or exports, authentication, field access, vendor cooperation, security requirements, and the requested workflow. The project scope identifies any additional middleware, third-party work, recurring fees, or client-managed vendor access.

Not necessarily. The right structure depends on lead ownership, brand separation, permissions, shared operational teams, producer autonomy, and how the company intends to administer the platform. Discovery determines when producers should share infrastructure and when separate subaccounts create a cleaner operating model.

We need the company structure, producer and branch model, current HighLevel or CRM setup, lead sources, core workflows, LOS and connected tools, known pain points, required permissions, rollout goals, and the people who can make process decisions. The more clearly the operating model is defined, the more accurately we can scope the build.

The engagement normally moves through discovery, architecture, build, testing, and rollout. We first define what the system should own and how it should work. After architecture approval, we configure and connect the system, test representative workflows, train the appropriate users, and launch according to the agreed rollout plan.

A typical Custom Build may target roughly 30 to 60 days after requirements, access, decision-makers, and approvals are available. Larger multi-branch projects, substantial data cleanup, custom integrations, compliance review, or delayed decisions can extend the timeline. The proposal provides the project-specific schedule before work begins.

Custom Builds are priced after discovery. Pricing depends on the size of the operation, the depth of integrations, the rollout footprint, and any ongoing partnership requested after launch. Before the client commits, we explain the cost, expected timeline, required client inputs, and what is and is not included.

Some Custom Builds begin with a paid discovery or scoping engagement. Before payment, we define what the fee covers, which stakeholders need to participate, what decisions or deliverables the client will receive, and whether any portion is credited toward later work. Those terms are project-specific and should be confirmed in writing.

Yes, when phased delivery is the safest way to meet a deadline or reduce rollout risk. A project may launch the core architecture and highest-priority workflows first, then add business units, integrations, migrations, automations, or producer groups in later approved phases. The proposal should identify what is included in each phase and what must be ready before launch.

The rollout plan should distinguish administrator training from producer onboarding. Administrators need to understand architecture, permissions, ownership, and maintenance. Producers need a simpler role-based experience focused on the records, tasks, conversations, and workflows they actually use. The proposal defines the sessions, materials, rollout groups, and client responsibilities.

Implementation support covers the agreed discovery, build decisions, testing, training, and launch activities in the project scope. It does not automatically create an unlimited support desk for every user or future request. Escalation paths, response expectations, and any post-launch support should be defined before rollout.

The client can operate the system in its own environment using the delivered documentation and training. Many clients retain Empower LO for support, optimization, additional rollouts, or new initiatives, but ongoing partnership is separately defined rather than assumed to be unlimited.