Custom franchise software
Every franchise system and every multi-location business has one process that no packaged product covers — the calculation, the approval, the field workflow or the integration that makes the brand what it is. You do not have to build an entire platform to get it. Gorilla Dash builds the custom module inside the system your network already logs into, on top of the locations, people, permissions, reporting and integrations that are already there.
Custom franchise software is software written for one brand’s way of operating rather than for a market of brands: the screens, fields, rules, calculations, approvals, reports and integrations that a particular network needs and that no off-the-shelf franchise management system ships. It can be delivered two ways. It can be a bespoke system built from an empty repository, which means paying to build logins, permissions, a location hierarchy, a customer database, reporting, notifications, billing and integrations before anybody sees the feature that was actually wanted. Or it can be a custom module built on top of a platform that already has all of that, which means paying only for the part that is genuinely yours.
The need is close to universal because franchise systems are not variations on one business. Two networks of the same size, sold through the same brokers and reporting the same royalties, can run completely different operations underneath. A home services brand schedules crews against jobs and needs materials costed back to each job. A food brand runs production schedules, waste tracking and a commissary. A fitness brand sells class packs that create a liability until they are used. A signage or print brand runs a quote, a proof approval, a production stage and an installation crew. A childcare brand lives on staff-to-child ratios and waitlists. Every one of those is normal, none of them is exotic, and none of them is in a product you can buy — which is why the operations team ends up running the most important part of the business in a spreadsheet that only one person understands.
That gap is where custom development for franchise and multi-location businesses belongs, and the question is only where the custom code sits. Building a whole platform from scratch means eighteen months and a seven-figure budget to arrive back at features every competitor already had, plus the ongoing cost of maintaining them. Bolting on a point solution means a second login, a second database and a reconciliation problem. Building the module on top of an existing franchise platform means the new work is only the part nobody has built, and it inherits the multi-location data model, the permission system, the audit trail, the reporting and the integrations from day one. That is how Gorilla Dash builds custom software: the base platform is the foundation, and the custom module is the floor you actually asked for.
Custom development is scoped and quoted per network after a discovery session — this page describes what can be built and how the work runs, not a price list. The timescales on this page, including the six to twelve weeks quoted for a first release, describe typical projects rather than a commitment; the dates that apply to your project are agreed at scoping. Ownership of the custom code and the support arrangement are set out in the development agreement we sign with you. Your data remains yours and remains exportable through the API whatever happens to the module.
Six steps from the spreadsheet somebody is already maintaining to a permissioned module every location uses.
Almost every custom requirement already exists somewhere as a workaround — a spreadsheet, a shared document, a form, a weekly email, an offline database, a process that runs in one manager’s head. That workaround is the specification. We sit with the people who maintain it, watch a real week go through it, and write down the decisions it encodes rather than the features somebody imagines wanting.
Most requirements are sixty to eighty per cent platform and twenty to forty per cent brand. Locations, staff, customers, permissions, notifications, documents, approvals, dashboards and exports are already built. We map your requirement onto what is there and are direct about the remainder — the part that has to be written — because that remainder is what you are paying for.
You get a written scope: the screens, the fields, the calculations, the permissions, the reports and the integrations, with a fixed quote and a date. Anything that is not needed for the first release is named and deferred rather than quietly included, because a first release that ships in eight weeks teaches you more than a complete one that ships in eight months.
The module is written into Gorilla Dash, not beside it. It appears in the menu behind its own permissions, reads and writes the same locations, people and sales records as everything else, is covered by the same automated tests, deploys through the same pipeline, and is backed up, monitored and supported like every other part of the system.
A pilot with two willing locations for a few weeks finds the things a specification cannot: the exception nobody mentioned, the field that needed to be optional, the report head office actually opens. Changes at pilot stage are cheap. Changes after a ninety-location rollout are not.
The module rolls out to the network with training material in your own knowledge base, and from then on it is maintained as part of the platform. Upgrades are regression-tested against it, so the custom work does not become the reason the network cannot take a new release — the failure that eventually kills most bespoke systems.
Custom work in a multi-location business is rarely one big idea. It is usually a short list of specific things, and almost all of them fall into these categories.
A new section in the menu with its own records, list views, filters, forms and detail pages — job costing, production scheduling, asset registers, inspections, waste tracking, membership liability, fleet, whatever the network runs on. It sits behind its own permission so head office, regional managers and locations each see the right slice.
The data your industry keeps that ours does not assume: extra fields on customers, companies, locations, staff, sales and enquiries, with the right types, validation and reporting, so the information lives on the record instead of in a notes box nobody can filter.
Stage-based processes with the gates your brand requires — a quote that needs a manager’s sign-off above a value, a proof approved by the customer before production starts, a compliance check completed before a job closes — each stage recorded with who did it and when.
The arithmetic that is specific to your agreements and your industry: job costing and margin, commission splits, rebates, unusual royalty and marketing-fund structures, tiered or usage-based pricing, allowances and deductions — calculated consistently for every location instead of differently in every spreadsheet.
The numbers your leadership actually runs the network on, scoped by role: a custom dashboard for the board, a regional view for field managers, a single-location view for the franchisee, and benchmarking that ranks locations on the measure your brand cares about rather than a generic one.
Point of sale, accounting, payroll, e-commerce, delivery platforms, quoting and estimating tools, industry-specific systems and the legacy database nobody wants to touch — connected by API, webhook or scheduled sync, so the data arrives in the platform instead of being re-keyed. Where a system has no API, we build the import.
What your customers, members or clients log into: an account portal, an ordering or booking flow, a members’ area, a supplier or contractor portal, or an internal store for franchisees — carrying your brand, on your domain, reading the same records as head office.
Work that should happen without anybody remembering it: scheduled jobs, triggered notifications, escalations, document generation, and AI agents scoped to your own data — drafting a reply, classifying an enquiry, summarising a location’s month or checking a submission against your standards.
Years of customers, sales, jobs and documents moved out of the old system with the relationships intact, deduplicated, mapped to locations and verified against the source totals — because a custom module with no history is a system people keep two of.
The version the person outside head office uses: a phone-shaped screen for technicians, drivers, inspectors and store staff, with photo capture, signatures and the small number of fields somebody will realistically complete standing in a car park.
Structures that do not fit a flat list of locations: area developers and master franchisees, regions and clusters, joint ventures, company-owned versus franchised locations, and multi-unit owners who need one view across everything they own and nothing across anybody else’s.
If your team builds too, the module is exposed through the same authenticated REST API as the rest of the platform, with the same keys, scopes and rate limits — so your developers can build against it without being blocked by ours.
The comparison that matters is not custom versus packaged. It is where the custom part sits.
| What you are comparing | Build a platform from scratch | Packaged product plus workarounds | Custom module on Gorilla Dash |
|---|---|---|---|
| Time to the first thing a user can open | Nine to eighteen months, most of it on foundations | Immediate, but the gap is never closed | Typically six to twelve weeks for a first release |
| What you pay to build | Logins, permissions, locations, customers, reporting, billing, integrations — then your feature | Nothing, and then the cost of the workaround forever | Only the part that is genuinely specific to your network |
| Where your data ends up | In a new database, separate from everything else you run | Split between the product and the spreadsheets beside it | In the same database as your locations, people, sales and marketing |
| Who maintains it in three years | You do, including the developer who wrote it leaving | Nobody — the spreadsheet is not maintained, it is inherited | We do, as part of the platform your network already pays for |
| What happens at upgrade time | Every upgrade is a project you fund | The product moves and the workaround silently breaks | The module is regression-tested with every release |
| What franchisees have to learn | A second system, with a second login | A process that is different in every location | One more section in the system they already use daily |
| Risk if it does not work out | The full build cost, already spent | The process stays manual and the cost stays hidden | The scope of one module; the rest of the platform is unaffected |
The network below is a composite and the timings are indicative, but the sequence is how custom work on the platform is designed to run.
Week 0
A franchisee
A ninety-location home services brand has one franchisee costing every job in a spreadsheet — labour hours, materials, subcontractors, travel — because the platform tracks the sale but not what the job cost to deliver. Three other owners have asked for a copy. Head office has no idea what the network’s true job margin is, in any location.
Week 1
Head office and Gorilla Dash
Discovery goes through a real fortnight of jobs. Customers, locations, staff, the sale, the invoice and the reporting are already in the platform. What is missing is a job record that hangs off the sale, a materials list, an hours entry and one margin calculation — four screens and two calculations, not a system.
Week 3
Head office
The written scope covers the job record, costing entry, a per-job margin, a location margin report and a permission that lets a franchisee see only their own jobs. Scheduling crews and a supplier price list are named as a second phase and left out, so the first release ships in eight weeks instead of six months.
Week 11
Two pilot locations
Two locations run every job through it for a month. Two things surface immediately: technicians will only enter hours from a phone, and warranty rework has to be costed against the original job rather than as a new one. Both are changed while only two locations have to relearn anything.
Week 16
The network
The module goes to all ninety locations with a guide in the brand’s own knowledge base. There is no second login, no new password and no data migration for franchisees, because the customers and sales the jobs attach to were already theirs in the platform.
Month 6
Leadership
Job margin by location sits in the same benchmarking view as revenue and marketing spend, because the module writes to the same database as everything else. The brand can see which locations are winning on price and which are winning on execution — a question it could not previously ask at all.
Every network arrives at custom development from one of a handful of dead ends.
The problem
The team has evaluated every product in the category and every one covers most of the business and misses the part that matters. So the most important process in the network runs in a spreadsheet, is different in every location, and cannot be reported on.
What good looks like
The spreadsheet becomes the specification for a module inside the platform. The parts every product already covers stay where they are; only the part nobody built gets written, and it reports like everything else.
The problem
A development agency has quoted a bespoke franchise management system. Read the scope and most of the budget is logins, permissions, a location hierarchy, a customer database, dashboards, notifications and integrations — everything that is identical in every franchise network and nothing that is specific to this one.
What good looks like
Keep the differentiated part of that scope and drop the rest. Building on an existing platform removes the foundation work from the quote entirely and removes it from the maintenance bill for as long as you run it.
The problem
A packaged vendor has agreed the feature is a good idea and put it on a roadmap with no date. It has been there for two years, because a product company builds what most of its market wants and your requirement is specific to your brand.
What good looks like
A scoped module has a quote and a delivery date, and it is built for your operating model rather than diluted until it suits everybody. Where a requirement genuinely is general, we say so and build it into the platform instead.
The problem
A separate tool was bought for the gap. It works, but it holds its own copy of locations and customers, it has its own logins to administer, its numbers never quite match the main system, and every report that needs both is assembled by hand.
What good looks like
A module on the platform reads the same records rather than copying them, so there is one customer, one location and one set of numbers. Where the point solution is genuinely better, we integrate with it properly instead of replacing it.
The problem
A custom system built years ago still runs, but nobody understands it, the framework is unsupported, the hosting is somebody’s old account and every change is quoted as a risk. The network is trapped between paying to maintain it and paying to replace it.
What good looks like
Custom modules live in the same codebase, tests and deployment pipeline as the rest of Gorilla Dash and are maintained by the team that maintains the platform — so the module has the same support arrangement as the software around it.
The problem
Without a system for it, ninety locations have produced ninety processes. Head office cannot compare them, cannot enforce the brand standard and cannot tell whether a struggling location has a demand problem or a process problem.
What good looks like
One module makes the process the same everywhere while still allowing the variation the brand permits, and produces the comparison that shows which locations run it well.
Not because the code is cheaper, but because most of the code does not have to be written twice.
Authentication, roles and permissions, the organisation and location hierarchy, customers and staff, documents and media, notifications, audit history, exports, billing and the API are built, tested and in production across networks today. A custom module starts on top of all of it.
Custom records sit beside sales, enquiries, marketing, calls and reviews in the same database, so a custom measure can appear in the same dashboard and benchmarking view as revenue — instead of becoming another number somebody exports and pastes.
Adoption is where most custom software quietly fails. A module inside the platform your locations already open every day is one more menu item with the permissions they already have, which is a far shorter conversation than a new system.
Backups, monitoring, security patching and support cover the custom module too, and every platform release is regression-tested against it — so custom work never becomes the reason a network is stuck on an old version.
The base platform is priced per location with unlimited team members, so putting a custom module in front of every manager, technician and part-time staff member does not add a per-seat cost — which matters most for exactly the field workflows custom modules tend to cover.
Point of sale, accounting, email, SMS, calendars, payments, websites and the public REST API are already connected, so a custom module can consume data that is already arriving rather than starting with an integration project of its own.
Custom records are exposed through the same authenticated API and export tooling as standard ones. The commercial terms are in the development agreement, but technically your data leaves the same way everybody else’s does.
A field, a permission, a column on a report or a new rule is a change request against a module that is already understood, not a re-engagement with an agency that has moved on to other clients.
Custom franchise software is software written for one brand’s operating model rather than for a market of brands — the screens, fields, workflows, calculations, reports and integrations a particular network needs and that no packaged franchise management product ships. It can be built from scratch as a bespoke system, or built as a custom module on top of an existing platform so that only the brand-specific part has to be written. Gorilla Dash builds it the second way.
Because the shared part of a franchise system — locations, staff, customers, marketing, sales, royalties, reporting — is only most of the business. The remainder is the operating model that makes the brand distinct: job costing, production scheduling, class-pack liability, proof approval, staff ratios, inspection regimes. Packaged products are built for the shared part, so the distinctive part ends up in spreadsheets. Custom software for multi-location businesses exists to close that specific gap.
On top of an existing platform, in almost every case. In a from-scratch quote the majority of the budget goes on foundations that are identical in every franchise network — authentication, permissions, the location hierarchy, a customer database, reporting, notifications and integrations — before anybody sees the feature that motivated the project. Building on a platform removes that work from the build and from the maintenance bill for as long as you run it.
New modules and screens, extra fields and record types on existing records, stage-based workflows and approvals, calculations and pricing logic, reports and dashboards, integrations and imports, customer-facing portals and storefronts, automations and AI agents, permission structures such as area developers and multi-unit owners, and API endpoints for your own developers. Everything in that list is open to discussion at scoping, with the exception of the platform’s security model and its multi-tenancy, which are what keep every network’s data separate.
A first release is typically six to twelve weeks from an agreed scope, with a pilot in one or two locations before the network sees it. Small additions to an existing module — a field, a permission, a report column, a new rule — are usually days. What sets the timeline is how much of the requirement is genuinely new rather than how large the requirement sounds.
Custom development is quoted per scope after a discovery session, on top of the base platform at USD $52 per location per month with unlimited team members. There is no fixed price list because the honest answer depends entirely on how much of your requirement already exists in the platform — which is the first thing discovery establishes, and which we tell you before you commit to anything.
That is set out in the development agreement and it varies by arrangement. Some networks fund a module outright and want the ownership terms to reflect that; others prefer a lower cost and are happy for the capability to become part of the platform. Either way, your data is yours and remains exportable through the API. We agree ownership and support in writing before development starts.
It should not, because the module is part of the same codebase rather than a plugin bolted to the outside. It ships with automated tests that run on every release, and the release pipeline is designed so that a change that would break it fails before it reaches production. This is the single biggest structural difference between a module on a maintained platform and a bespoke system that eventually cannot be upgraded.
Usually yes. The platform already connects to a range of point-of-sale, accounting, e-commerce, delivery and marketing systems, and new connectors are built by API, webhook or scheduled sync. Where a system has no usable API, the practical route is a scheduled file import or a database extract, and we will tell you honestly at discovery which of those applies to your system.
Yes. Corporate-owned chains, dealer and distributor networks, member associations, licensee models and multi-brand groups have the same structural problem: many locations, a head office that needs to compare them, and an operating model no packaged product covers. The location hierarchy, permission model and reporting work the same way whether the locations are owned, franchised or licensed.
Yes, and that is the default. Custom modules use the same permission system as the rest of the platform, so access is granted by role and scoped by location: head office sees the network, a regional manager sees their region, a franchisee sees their own locations, and a multi-unit owner sees everything they own and nothing more.
The records a custom module creates are exposed through the same authenticated REST API and export tooling as standard records, so they can be extracted in bulk in a documented format. The software itself stays with the platform unless the development agreement says otherwise, which is one of the terms worth settling before the work starts rather than after.
Yes. Custom records get the same API treatment as standard ones — authenticated endpoints, named keys at organisation or location level, documented payloads and webhooks — so an in-house team can build reports, apps or integrations against the module without waiting on our release schedule.
Show us the process your network runs outside its software and we will tell you what already exists in the platform, what would have to be written and what it would take — book a demo with our team.
Book a Demo