Courier Company Software: Build Custom or Buy OnFleet?
Two thresholds decide it: roughly 150 jobs a day, and roughly four distinct pricing models. Under both, on standard point to point work with no customer asking for an interface, buy OnFleet or Circuit for Teams and spend the difference on drivers.
On this page
Two thresholds decide it: roughly 150 jobs a day, and roughly four distinct pricing models. Under both, on standard point to point work with no customer asking for an interface, buy OnFleet or Circuit for Teams and spend the difference on drivers. Above them, and particularly once someone applies rate card rules by hand every week, a build starts to pay at $60,000 to $130,000 for a first release and $150,000 to $400,000 for a full platform in Digital Heroes delivery experience. Our honest observation is that courier companies build too late rather than too early.
When is off the shelf genuinely the right call here?
If you run under roughly 150 jobs a day on standard point to point work, with fewer than four distinct pricing models and no customer who has ever asked you for an interface, buy. OnFleet and Circuit for Teams will run that business well for a few hundred to a couple of thousand dollars a month, and Onro and Dispatch Science are worth evaluating in the same bracket. Building custom software at that scale is a hobby competing with hiring drivers, and drivers win.
These products are strong at what they were built for: getting a route planned, a driver moved and a delivery confirmed. If your operation is execution shaped rather than revenue shaped, meaning your pricing is simple and your billing is a monthly export, they are the correct purchase and nothing here should tempt you off them.
Buy is also right when the problem is dispatch discipline rather than software. A tool will not create a process. If your dispatchers assign on gut feel because nobody has written down what the pharmacy contract's on time clause costs you when it is missed, write that down first. Several operators who have done that exercise found their existing tool became adequate once the rules existed anywhere outside a dispatcher's head. The same applies to consolidating pricing: if you can merge three legacy rate structures into one, that is the cheapest improvement available to you and it works whether you build or not.
When does a custom build actually pay off?
The clearest signal is that you employ someone whose actual job is moving data between two systems. Re-keying email and portable document format run sheets into dispatch for two to three hours a day. A billing clerk reconciling proof of delivery against invoices. A Friday that is a settlement spreadsheet day for one or two people, which is roughly a hundred days a year of salary sitting between two systems.
The second is that you cannot produce per job margin by account, which means you are pricing renewals blind. Courier margin does not live at the company level, it lives in whether the hospital account that looks like your best customer is actually losing money on unbilled waiting time.
The third is an enterprise account lost or declined in the last year on an integration or proof of delivery requirement. That is a revenue number you can name, which makes it the easiest case to take to a board.
The fourth is rate card structures your software cannot express. Zone rates for one account, per mile for another, per piece with a minimum for a pharmacy run, a flat monthly dedicated route, waiting time after fifteen minutes billed in six minute increments, after hours multipliers, a weekly indexed fuel surcharge. Execution tools were not built to price any of that, which is a statement of purpose rather than a fault.
The fifth is that your market differentiator is an operational capability your software cannot represent at all, which is the case that quietly caps growth.
How do they compare on the things that matter in this industry?
Rating. This is the dividing line in the category. Ask any product to price a job with a zone base rate, a per piece minimum, twenty two minutes of waiting time billed in six minute increments, an after hours multiplier and a fuel surcharge indexed weekly, then produce both a billable line and a driver payable line from the same record. If the answer is an export to a spreadsheet, that spreadsheet is your rating engine and always will be.
Offline reliability. Hospital loading docks, underground parking and rural routes mean signal loss every day, not as an edge case. Ask what happens when a driver captures four deliveries underground, force quits the app and reconnects two hours later after dispatch reassigned one of those stops. You want to hear about a local write ahead queue, repeatable sync and a defined conflict rule. If capture depends on a live call, drivers work around it by texting photos, which is where you started.
Proof of delivery as evidence. Ask how long signature images and photographs are retained, in what form they can be exported, and whether the record carries device location, timestamp and driver identity in a way you could put in front of a customer disputing a job from eighteen months ago. This is legal evidence rather than a feature, and retention terms belong in the contract.
Contract awareness in assignment. Ask whether the dispatch board knows what a missed on time clause costs on a specific account, or whether it treats every job as equally urgent. Most execution tools do the latter, and that is where margin leaks without anyone seeing it.
What does total cost of ownership look like at your scale?
On the buy side, take three years of licence honestly, then price the people the tool requires: the re-keying hours, the billing reconciliation, the settlement spreadsheet day. Then price what you cannot see. Credits issued on disputed deliveries because a timestamped record could not be produced in time. Unbilled waiting time on hospital docks, which is the accessorial most often lost and the one that most often turns a favourite account into a loss maker. And the enterprise accounts declined because you could not answer the electronic ordering question.
On the build side, the spine of a dispatch board with contract aware assignment, an offline first driver app with configurable proof of delivery capture, and a rating engine writing a billable and a payable line for every job runs $60,000 to $130,000 in 12 to 16 weeks. Adding per account invoicing posted through your accounting system's interface, driver settlement statements, a customer intake interface and white label tracking runs $150,000 to $280,000 over 6 to 9 months. Enterprise electronic data interchange connections, document extraction on the dispatch inbox, after hours booking, per job margin analytics and legacy migration take it to $280,000 to $400,000 over 9 to 12 months. A regional courier at roughly 350 jobs a day with 70 drivers and nine pricing structures lands at $294,000 across ten months.
Below $60,000 you get a dispatch board without a rating engine, which leaves the spreadsheet exactly where it is. Then budget 15 to 25 percent of build cost a year, so $44,000 to $74,000 on that example, plus mobile platform upkeep because Android and iOS change annually and an app that stops installing is an outage, driver device replacement, per message charges if you run notifications, proof of delivery storage held for years, and a support commitment covering the hours you actually operate rather than office hours.
What does the hybrid look like, and when is it the honest answer?
For couriers between roughly 150 and 350 jobs a day, this is usually the right answer and almost nobody offers it. Keep OnFleet or Circuit for Teams for execution: routing, the driver app, the tracking link. Keep QuickBooks or NetSuite for finance and post into it through its interface rather than building a ledger. Then build only the revenue layer those tools were never designed to hold.
That layer is the rating engine and settlement. Contracts and rate cards held as data with effective dates, a rule set per pricing structure with its accessorials, minimums and exceptions, and a job that produces both a billable line and a driver payable line from the same completion record. Add itemised driver settlement statements visible in the app, which is the change your operations manager notices first because disputed pay calls drop to near zero. Costed as a phase, the rate card model and rating engine together sit near $68,000 on the worked example, well under a full build.
The real cost of the hybrid is the boundary. Your rating engine depends on completion data coming out of a product you do not control, so its export format and its retention terms become your concern, and proof of delivery images living in someone else's system are still your legal evidence. Get retention and export in writing before you build against it. If you later decide the execution side needs to come in house too, you will already own the hard part, which is a materially safer sequence than starting with the driver app.
Which should you choose, by operator size and stage?
Under 150 jobs a day, simple pricing, no interface requests: buy OnFleet or Circuit for Teams and stop. Write your contract terms down somewhere other than a dispatcher's memory.
150 to 350 jobs a day with more than four pricing models: keep the execution tool and build the rating engine and settlement layer. This is the highest return spend available to most couriers of this size, and it does not put your drivers through a change.
Any size, where an enterprise account has been lost on an interface or proof of delivery requirement: build the spine, because that requirement will keep arriving. Name the account and the annual value in the business case; it is the cleanest argument in this category.
Above 350 jobs a day across medical, legal or pharmacy work with compliance obligations: build the full platform, phased. Release one is dispatch, the driver app and the rating engine, roughly 40 percent of budget in 12 to 16 weeks, with two to three weeks of parallel running on a subset of drivers before the fleet moves. Put driver settlement live early in the middle phase rather than late. Run document extraction in shadow mode for about three weeks before it releases anything, because a driver dispatched to the wrong suite in week two costs you the customer service team's trust in the queue permanently.
Coming off CXT or Key Software's Xcelerator: budget three to six weeks for migration as its own phase, load the historical proof of delivery archive as read only so old disputes stay answerable, and expect rate card cleanup to surface accounts nobody remembers agreeing to. Whoever builds it, own the repository, the cloud accounts and the pipeline from day one with the hosting bill in your name. At Digital Heroes the client owns the code from the first commit, and it matters here because your proof of delivery archive is evidence you may need for years.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- Salesforce's field-service research (State of Service / field service trends, survey of 5,500+ service professionals) found that 74% of mobile workers report increasing workloads and 47% say appointments don't go as planned due to customer miscommunication, unaccounted-for parts, or insufficient appointment lengths and travel times. (The separate claim that admin tasks consume ~30% of a technician's hours is NOT supported by the report - the seventh-edition data instead states technicians spend about 18% of working hours, ~7 hours/week, on admin, and only ~32% of time interacting with customers.). Source: Salesforce (2024) →
- ServiceTitan's KPI guide cites an average first-time fix rate near 80% (90% ideal) and describes strong technician-utilization rates as falling in the 60-80% band, with average travel time typically 30-60 minutes depending on service-area size. Source: ServiceTitan (2026) →
- The average developer spends more than 17 hours a week dealing with maintenance issues such as debugging and refactoring, and about four of those hours on 'bad code' - waste that equates to nearly $85 billion annually worldwide in opportunity cost. Source: Stripe (2018) →
- 88% of organizations are concerned about employee retention, and providing learning opportunities is respondents' #1 retention strategy; career progress is cited as people's top motivation to learn, yet only 36% of organizations qualify as 'career development champions.'. Source: LinkedIn Learning (2025) →
Frequently asked questions
We use OnFleet today. What would building actually change?
One thing above all: pricing. OnFleet is a strong execution tool and it was not built to compute zone rates, per piece minimums, waiting time in six minute increments and a weekly indexed fuel surcharge, nor to produce a driver payable line beside the billable one. If someone applies those rules by hand every week, that person is your rating engine. Everything else you might gain is secondary, and the sensible move is to build the rating layer beside OnFleet rather than replacing it.
What does it cost to switch off our current courier platform?
Migrating from CXT or Key Software's Xcelerator is three to six weeks as its own phase: customers, contracts, rate cards, open jobs, open receivables and the proof of delivery archive extracted into staging and reconciled against legacy reports line by line. Load historical proof of delivery as a read only archive so disputes on old jobs stay answerable. The unbudgeted part is rate card cleanup, which surfaces accounts nobody remembers agreeing to. That is unpleasant and it is also the point.
What happens if our vendor changes per driver or per job pricing?
Seat and job based pricing means your bill tracks your growth directly, which is fine until a seasonal peak or a new contract lands. The defences are a volume band negotiated at signature, an export clause covering proof of delivery images and not just job records, and knowing that the rating and settlement layer alternative sits near $68,000 so a renewal becomes a comparison. Check the retention terms in the same conversation, because those images are legal evidence you may need after you leave.
How long before dispatchers and drivers are actually using a custom system?
Twelve to sixteen weeks to a first release, and that release is deliberately the pieces they touch: the dispatch board, the offline driver app and the rating engine. Customer facing pieces come later, because operations has to trust the system before customers do. Plan two to three weeks of parallel running with a subset of drivers before cutting the fleet over. That period is where the offline edge cases surface, and no office test produces them.
Is Circuit for Teams enough once we pass 200 jobs a day?
For execution, often yes. Volume alone is not what breaks these tools; pricing complexity and settlement are. A 300 job a day operation on two rate structures with monthly flat billing can stay on one comfortably. A 180 job a day operation across medical, legal and pharmacy work with eleven rate structures cannot, and the difference shows up as a person spending Fridays in a spreadsheet rather than as a performance problem in the app.
Can we keep our dispatch tool and build only the billing side?
Yes, and between 150 and 350 jobs a day it is usually the right call. Contracts and rate cards held as data with effective dates, a rating engine producing a billable and a payable line from the same completion record, itemised driver settlement in the app, and invoices posted into QuickBooks or NetSuite through its interface. Your drivers experience no change at all. The trade is a dependency on completion data and image retention from a product you do not control, so settle both in writing first.
Can we cut the offline driver app to save money?
No, and this is the one line we would refuse to economise on. Hospital loading docks, underground parking and rural routes mean signal loss every single day, and if capture depends on a live call your drivers will work around it by texting photos, which is the problem you paid to solve. Ask any candidate to describe a local write ahead queue, repeatable sync and the conflict rule when dispatch reassigned a stop while the driver was offline.
What does medical courier compliance add to the decision?
A signed business associate agreement with your developer and your hosting provider, encryption of patient linked data at rest and in transit, role based access so a driver sees only assigned stops, and an audit log of every read and write on those records. Ask any packaged vendor whether they will sign the agreement before you evaluate anything else, because a product that will not is not a candidate. Ask a builder how identifiers are scrubbed from error reporting and application logs, which is where teams actually leak.
What should I prepare before contacting a software development agency?
A one-page brief beats a 40-page requirements document: the business problem in plain words, who will use the system, the 5 to 10 workflows it must handle, the tools it must connect to, and your budget range and deadline driver. You do not need wireframes, a specification, or technical vocabulary; producing those is the agency's job during discovery. Stating a budget range up front is the single best move, because it gets you honest scoping instead of a quote engineered to win the meeting.
Is Housecall Pro enough for a growing HVAC or plumbing company, or do we need custom software?
Housecall Pro holds up well to roughly 10 to 20 technicians on standard residential jobs, with its Essentials plan listing around $129 per month for up to five users. The ceiling appears with commercial work: multi-visit projects, progress billing, equipment service history, and inventory are thin, which is when owners start managing the business in exported spreadsheets. Use the spreadsheet count as your signal: three or more recurring workarounds mean the tool no longer fits.
Can I get my customer and job history out of ServiceTitan or Jobber if we switch to custom software?
Yes. Jobber and Housecall Pro both provide CSV exports of clients, jobs, and invoices, and ServiceTitan data comes out through its API and report exports, though attachments and full audit history take extra work. Budget 2 to 4 weeks of migration effort inside the project for cleaning, mapping, and verifying records, and run both systems in parallel for at least two billing cycles before cutting over.
What features should the first version of a custom field service app include?
Version one needs the daily loop and nothing else: job creation, a drag-and-drop dispatch board, a technician mobile app that works offline, photo and signature capture, and invoicing that reaches your accounting system. Customer portals, route optimization, inventory, and reporting dashboards belong in phase two. The test for every feature is whether a dispatcher or technician touches it every day; if not, cut it.
What should I have ready before I contact a development agency about field service software?
Bring your current workflow, not a feature list: how a job moves from first call to paid invoice today, where it breaks, what tool you use now with its monthly bill, and the workaround spreadsheets your team maintains. Add your integration list (accounting system, payment processor, phone system) and an honest budget range. A good agency can scope accurately from that in one or two calls, while a vague request for an app like ServiceTitan costs you weeks of discovery.
Should we start with an MVP or build the full field service platform in one go?
Start with an MVP that can run one real crew for one real week: scheduling, dispatch, job completion with photos and signatures, and invoicing. That slice typically costs $40,000 to $70,000 and ships in about 12 weeks, and technician feedback then decides phase two. Teams that built the full platform up front reworked 30 to 40 percent of it after field use in Digital Heroes experience, which is the most expensive way to discover what dispatchers actually need.
Who owns the code when an agency builds our field service software?
You should own it outright, and the contract must say so: source code, designs, documentation, and every account (hosting, app stores, domains) registered to your company rather than the agency's. Work-for-hire terms with ownership transferring on payment are standard at reputable agencies, and it is how Digital Heroes contracts every build. Walk away from any proposal where you license the platform instead of owning it, because that recreates the vendor lock-in you were leaving ServiceTitan to escape.
How much should a small business budget for its first custom app or website?
For a focused first build, most small businesses land between $8,000 and $60,000: roughly $8,000 to $45,000 for a custom website and $25,000 to $60,000 for an internal tool or simple web app, based on Digital Heroes delivery across 2,000+ projects. Customer-facing products with payments, logins, or a mobile app start around $40,000. Quotes far below these bands usually mean a template with your logo on it, not software shaped around your workflow.
At what point does it make sense to switch from ServiceTitan to custom software?
The switch usually pencils out once your ServiceTitan bill passes roughly $75,000 a year and your team still maintains workaround spreadsheets beside it. ServiceTitan keeps pricing quote-only, and the quotes owners share in Digital Heroes scoping calls run several hundred dollars per technician per month on annual contracts, so a 30-technician shop can spend a full custom build's budget every 12 to 18 months in fees. If ServiceTitan fits your workflow cleanly, stay; the case for custom is a workflow the product forces you to bend.
Who can build a custom field service management software system?
Digital Heroes builds custom field service management software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other field service management software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
Related guides
More from Eleanor.
VP Client Services · UK & EU · London · 1 post on the site
Published · Last updated .
