Custom CRM for a Multi-Brand Sales Organization

A growing multi-brand organization was running sales on spreadsheets: leads slipping between brands, no shared follow-up discipline, no management view of the pipeline. Off-the-shelf CRMs were either too heavy or priced per seat in a way that punished growth. We built a purpose-built CRM on a mainstream PHP/Laravel stack — lead capture from web and campaigns, pipeline stages per brand, automated follow-up reminders, role-based access and a live management dashboard. Here is when building a CRM is defensible, and how this one was structured.

The challenge

Multi-brand sales organisations have a structural problem single-brand companies do not. The process differs per brand — different stages, qualification criteria and cycle lengths — while management needs one consolidated pipeline view. Spreadsheets handle neither half. Enterprise CRMs demanded a configuration project and ongoing administration nobody wanted to own; lighter tools were cheap per seat until you multiplied seats by brands by growth.

Our approach

We are generally sceptical of building CRM software. It is a mature category and most companies should buy. The case here rested on three conditions: the process was genuinely non-standard across brands, per-seat economics penalised the growth trajectory, and the required feature set was narrow enough to build in months rather than years. Absent any one of those we would have said buy. Given that, we built ruthlessly narrowly — what this team does, not what CRMs generally do. No marketing automation, no quoting engine, no forecasting. The second principle was that adoption is the whole product: a CRM the team avoids is worse than a spreadsheet, because it also gives management false confidence.

Architecture and key decisions

The stack choice is the one people question. Laravel is not exciting, and that is the point: a CRM outlives whoever built it.

How we sequenced the work

We mapped the existing process first, including the parts happening in WhatsApp and personal notebooks, which is where the real process lives. Then the smallest useful system — leads, contacts, one pipeline — into one brand's hands early. Then role-based access, automated lead capture with source attribution, follow-up automation, and the dashboard last. Reporting built before the data model has survived real users produces beautiful charts of unreliable data.

What to look for if you're commissioning this

First, seriously test whether you should buy — our build vs buy tool exists for this. If you build, ask who else can maintain the stack, how reporting is generated, and whether it stays fast at ten times the record count. Ask what happens if the relationship ends: you should hold code, database and hosting credentials without asking permission. Plan adoption explicitly. The dominant killers are scope creep into quoting and invoicing until you have an accidental ERP, building for management reporting rather than for the salesperson, and migrating dead spreadsheet rows as though they were history.

Typical cost and timeline

General ranges for this class of work, not this client's figures. A focused custom CRM — leads, contacts, one or two pipelines, basic reporting — typically runs two to four months. Add multi-brand pipelines, role-based access, campaign integration and a live dashboard and four to seven months is realistic. Ongoing cost is hosting plus a maintenance retainer, materially lower than per-seat licensing once user counts pass a modest threshold. See our app cost estimator and pricing.

The outcome

The system is in daily production use across brands. Leads arrive in one place regardless of which brand's campaign generated them, follow-ups no longer depend on memory, and management reviews the pipeline from a live dashboard instead of a month-old export — which changes the kind of questions leadership can usefully ask.

Frequently asked questions

When does building a custom CRM actually make sense?

When your sales process is genuinely non-standard, when per-seat licensing scales badly against your growth plans, or when the integration work needed to make an off-the-shelf tool fit approaches the cost of building. If none of those apply, buy — the category is mature. We turn down more custom CRM requests than we accept.

What does a custom CRM cost to run compared with a subscription?

A built system converts a per-seat operating cost into an upfront build cost plus fixed hosting and maintenance. That is favourable at higher user counts and unfavourable for small teams. The crossover depends on seat count, growth rate and how much maintenance the system needs, so model it honestly over three years rather than comparing month-one figures.

Why PHP and Laravel rather than something more modern?

Because maintainability over a decade matters more than novelty. Laravel is stable, extensively documented, and the hiring pool is deep, so the organisation is not dependent on one agency or one developer to keep the system alive. For an internal system expected to outlive its authors, boring technology is a deliberate risk-reduction decision, not a compromise.

How do you get a sales team to actually use it?

By minimising what they type, automating lead capture and source attribution so records create themselves, and designing screens against real time pressure rather than around reporting requirements. Beyond design, adoption needs an internal owner, real training and a period of parallel running with whatever the team uses today.

If spreadsheets have stopped scaling with your sales operation, book a free 30-minute technical session through our contact page. For how we scope builds like this, see custom application development.