Ground Handling Operations Software: Build Custom or Buy INFORM GroundStar?
The condition that decides it is not turn volume, it is whether you can prove a milestone.
On this page
The condition that decides it is not turn volume, it is whether you can prove a milestone. If you run a single station with a handful of airline contracts and a stable schedule, buy or build nothing: a shared roster, a radio and a competent duty supervisor genuinely work at that size. Once you run multiple stations with different licence scopes, or you regularly absorb delay penalties you believe were not yours because your evidence is a supervisor's recollection, a build starts to pay. A first release at your busiest station runs $70,000 to $150,000 over 12 to 18 weeks, and the full platform runs $200,000 to $500,000.
When is off the shelf genuinely the right call here?
INFORM GroundStar, Ink Aviation and TAV Technologies all serve this market and are used by real handlers at real scale. GroundStar in particular has absorbed a great deal of genuine allocation complexity over many years, and if your operation fits its model, buying it and configuring your processes toward it is a better use of capital than reproducing that engine.
Buy, straightforwardly, if you run a single station with a stable schedule and a handful of airline contracts. Software is overhead at that size, and it comes with a running cost you will resent within a year. The duty supervisor with a radio and a printout is not a failure of technology, it is a proportionate control for a small operation.
Buy anything the airport or the airline already provides. You are not building a collaborative decision making platform and you are not replacing a carrier's departure control system. Your build, if you have one, is the record that proves what your people did, and nothing wider than that.
And buy time rather than software if your ramp process is genuinely undefined. If your turnaround sheets are filled in after the turn rather than during it, that is a supervision problem first. Instrumenting an undisciplined process produces expensive, late timestamps, which in a dispute is worse than no record at all, because it is evidence against you.
When does a custom build actually pay off?
Build when two or more of these hold.
- You operate multiple stations with different licence scopes, layouts and collective agreement terms, and no single configured system covers them all comfortably.
- You regularly absorb delay penalties you believe were not yours, because the airline holds a system entry and you hold a recollection.
- Your ground support equipment (GSE) pool is unmeasured, so fleet purchasing decisions rest on opinion.
- Qualification currency lives in a spreadsheet beside a roster that can technically assign anyone to anything.
- Chargeable extras are captured on paper, and you suspect, correctly, that a meaningful share never reaches an invoice.
What makes this category unusual is that the return is countable. Two numbers, both visible within a quarter of going live at one station: delay penalties avoided, and extras billed that previously were not. That is rare in operational software, where the case normally rests on a general efficiency story, and it means you should insist on measuring rather than accepting one.
The mechanism is capture, not analytics. Milestones recorded at the moment they happen, by the person doing the task, with their identity and the device position attached: chocks on, ground power connected, doors open, first bag on belt, last bag, doors closed, pushback commenced. Those are the boundaries where responsibility transfers between parties, and they are exactly the timestamps currently reconstructed from memory an hour later.
How do they compare on the things that matter in this industry?
Five questions, all answerable before you sign anything.
Offline behaviour on the ramp. Coverage drops behind an aircraft. Ask what happens to a milestone captured with no signal, and what the reconciliation rule is when it arrives late. If the answer is improvised, the record will not survive a dispute.
Constraint modelling per station. Ask how the system holds licence scope at this airport, break windows and mid shift task change rules under your collective agreement, and walking time between stands. Configuration gets most systems most of the way. The remainder is currently your supervisor, and the gap is where a build earns its place.
Does qualification block or report? A system that can propose an unqualified assignment and rely on a supervisor catching it will eventually produce an audit finding. Enforcement at assignment time is a different design from a currency report.
Chargeable event capture at point of service. Ask whether an extra requested by an airline representative on stand can be recorded on the same device as the milestone, with the requester's name attached. If extras still route through paper, your billing leak is untouched no matter what else the system does.
Who holds the evidence. Your timestamp record is what you take into every delay dispute and every contract renewal. Ask what an export looks like, how far back retention runs, and whether you can extract it if you leave. A vendor controlling access to that record has a hand in your negotiating position with your customers.
What does total cost of ownership look like at your scale?
Take a handler running six stations, roughly 90 turns a day at the largest, three airline customers with penalty bearing service level agreements. A first release at the busiest station only prices out as ramp milestone capture with offline queueing and reconnect reconciliation at $42,000, live staff and equipment allocation against a moving schedule at $38,000, delay evidence with source attribution and a dispute pack export at $21,000, schedule ingestion from airline movement messages plus one airport operational feed at $19,000, and devices, mounts, cases and rollout at $9,000. That is $129,000 across 16 weeks.
Phase two over the following ten months adds chargeable event capture and per turn billing at $52,000, GSE telematics with usage based maintenance at $46,000, qualification enforcement with expiry forecasting at $34,000, airline facing reporting at $29,000, rollout across the remaining five stations at $58,000 and multi language at $17,000. That is $236,000, so the platform totals $365,000. Note the shape of that: five extra stations cost less than the billing module alone.
Running cost is 15 to 20 percent of build a year and it is unusually hardware weighted. A ramp destroys screens, so plan a replacement rate and hold spares at every station. Telematics units carry a connectivity subscription per asset. Retention needs a deliberate policy, because disputes surface months after the turn.
Against that, put your own numbers: penalties absorbed over the last twelve months where you believed the cause was not yours, and extras you can find by sampling a fortnight of paper turnaround sheets against the invoices that followed. Both are countable this week.
What does the hybrid look like, and when is it the honest answer?
Buy the platform, build the ramp. This is the arrangement we would propose to most multi station handlers and it is rarely offered, because it is less profitable to sell.
Keep GroundStar, Ink Aviation or whatever resource management system you run at the stations where its model fits, and let it keep doing allocation and rostering. Build only two things on top: milestone capture with offline behaviour and identity attached, and chargeable event capture at point of service. Those are the pieces that generate the two countable returns, and neither requires you to replace an allocation engine that already works.
That layer alone, milestone capture at $42,000 plus delay evidence at $21,000 plus chargeable event capture at $52,000, is around $115,000 rather than $365,000, and it leaves the packaged system in place. Many handlers end up with a genuine mix: packaged at the stations whose shape matches the product, custom at the stations with an unusual licence scope or an agreement the configuration cannot express.
The hybrid stops working when your packaged system cannot accept externally captured milestones, or cannot export allocation state in a form the capture app can use. Test that in week one, with a real file, before you commit to either direction. And keep the airport feed conversation running in parallel regardless, because obtaining an operational data feed is a commercial negotiation at every airport and it should never be a launch blocker.
Which should you choose, by operator size and stage?
Single station, stable schedule, few contracts. Neither. Shared roster, radio, competent supervisor. Spend the money on making sure turnaround sheets are completed during the turn rather than after it, which costs nothing and is the foundation of everything above.
Two or three stations, penalties starting to bite. Build the evidence layer only, at roughly $70,000 to $90,000 for capture plus delay evidence at one station, and roll it to the others. Do not touch allocation yet. Baseline your absorbed penalties before go live so the quarter after is a measurement rather than an argument.
Four to eight stations with differing licence scopes. The $129,000 first release at your busiest station is the right shape. Prove capture and allocation there, then roll out one station at a time from about month five, each faster than the last. Sequence rollout by airport feed availability rather than by traffic, because the feed negotiation is the unpredictable part.
Large multi country handler with a big equipment fleet. The full platform toward $500,000 becomes defensible, but phase it and take chargeable event capture before telematics. Billing is the least interesting feature in the build and frequently the one that funds the rest, while telematics carries hardware purchase and installation across a fleet and wants its own budget cycle.
Whatever size you are, one rule holds. Whoever designs this spends a full shift on the ramp before anything is estimated in detail. Gloves, noise, weather and the distance between stands decide whether the application is used or left in the office, and no discovery workshop substitutes for standing there.
When you are ready to turn this into a specification, Digital Heroes has delivered more than 2,000 projects with a named team you can speak to before you sign, rather than a bench you meet in month two. You keep the specification either way.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- Comparesoft reports the field-service industry-average first-time fix rate is about 80%, best-in-class providers reach roughly 90%, scores below 70% put the business at risk, and providers exceeding 70% FTFR saw customer retention around 86%. Source: Comparesoft (2024) →
- PTC identifies the leading causes of failed first visits as parts unavailability (the single most-cited complaint, named by 51% of field service executives), technicians lacking the required equipment or skills, and insufficient time allocated to the job - making parts logistics and skills-based dispatch the highest-leverage fixes. Source: PTC (2023) →
- 88% of customers say good customer service makes them more likely to purchase from a brand again in the future, quantifying the direct revenue link between support quality and retention. Source: HubSpot (2024) →
- The NRF discontinued its long-running annual shrink report, stating that a broad study of retail shrink 'is no longer sufficient for capturing the key challenges and needs of the industry' - important context that qualifies how POS/shrink benchmarks should be cited going forward. Source: Retail Dive (2024) →
Frequently asked questions
What does it cost to switch off a packaged system like GroundStar?
Less than in most categories, because the asset you care about is mostly ahead of you rather than behind. Historical rosters and allocation records have limited value once you are capturing your own milestones, so the migration is normally reference data: stations, stands, staff, qualifications with expiry dates, equipment and handling agreement terms.
The real cost is parallel running. Keep the incumbent live at a station while the new capture layer runs alongside for four to six weeks, and compare the turnaround records. If they disagree, you have found either a capture problem or a configuration assumption, and both are cheaper to fix before cutover than after.
What if our resource management vendor changes pricing or per station terms?
Get three numbers before renewal: annual cost per station, what a new station costs to add including configuration consultancy, and the cost and lead time of a change when a collective agreement or licence scope changes. That third number is the one that sets how responsive your operation can be.
The hedge is to own the evidence layer. If your timestamp record and your chargeable event history sit in a system you control, a vendor change costs you an integration rather than the loss of your negotiating position with airlines. That is the part worth owning even if you never build anything else.
How long until the first station is actually live?
Twelve to eighteen weeks. Week one is a full shift on the ramp for whoever is designing it. Milestone capture and the offline model take weeks two to eight, allocation overlaps from about week six because it consumes the same person and equipment state, and rollout to the second station begins once the first has run for a few weeks.
The pacing risk is not engineering, it is airport feed access. Start that commercial conversation immediately and design so the system runs on airline movement messages alone if the feed is late.
Is Ink Aviation or TAV Technologies a better answer than building?
Where their model matches your operation, yes, and the test is specific rather than general. Ask how each expresses your licence scope at a particular airport, your collective agreement rules on break windows and mid shift task changes, and a shared equipment pool. If those are all configuration, buy.
If any of them needs a workaround that ends with a supervisor holding the real answer in their head, you have found the gap a build fills. It is entirely reasonable to run a packaged product at the stations it fits and build for the two that it does not.
How much does each additional station add?
Far less than the first. In the worked six station example, five additional stations cost $58,000 in total against $129,000 for the first one alone. That holds only if licence scope, agreement terms and airport interfaces were modelled as configuration from the start rather than assumed away.
The variable is the airport feed. A station where the operational data feed needs a lengthy commercial negotiation costs the same to develop and much more in calendar time, so sequence rollout by feed availability rather than by traffic volume.
Will better milestone capture actually reduce delay penalties?
It changes the default outcome of a dispute rather than winning every one. Some disputes are commercial rather than factual and evidence will not settle those. But when you hold a timestamped record with the identity and position of the person who captured it, and the airline holds a figure entered later, the party with the weaker evidence is no longer automatically you.
Expect two findings in the first quarter. A share of what you were absorbing was not yours. A smaller share genuinely was, and is now visible early enough to fix the underlying cause.
Should we build the billing module or handle extras in our finance system?
The finance system is not the problem. The leak happens earlier: an extra is requested on stand, written on paper, and either keyed in weeks later or never. No accounting package can invoice what it never hears about.
Capturing the chargeable event on the same device as the milestone, with the requesting airline representative's name attached, closes it at source and then feeds whatever finance system you already run. Around $52,000 in a typical build. Sample a fortnight of paper turnaround sheets against the invoices that followed and you will have your own payback figure before commissioning anything.
Who owns the timestamp record if an agency builds this?
You should own the repository, the cloud infrastructure accounts and the unrestricted right to bring in another firm, agreed before kickoff. In handling this is commercially direct rather than a matter of principle: the timestamp record is your evidence in every delay dispute and every contract renewal.
Set the retention policy deliberately rather than accepting a default, because disputes surface months after the turn and an audit log that has rolled off is the same as no record. Ask the same question of any packaged vendor: how far back does retention run, and what does an export look like.
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.
What are the biggest mistakes companies make when building custom field service software?
Four mistakes cause most failures: scoping only the happy path so offline work and job reassignment surface later as change orders, leaving QuickBooks sync until the end instead of designing for it, skipping technician input until launch, and having no post-launch support plan. Across 2,000+ Digital Heroes projects, failed field service builds almost always failed on process, not programming. Every one of these is prevented in the scoping phase, which is why discovery matters more than the framework.
Can I build my product on a no-code tool like Bubble instead of hiring developers?
For testing whether anyone wants the product, yes, and Bubble's paid plans start at $29 a month, which is the cheapest validation you will ever buy. The ceiling arrives with complex data relationships, heavy integrations, performance at a few thousand users, and the fact that you cannot export a Bubble app to servers you control. A path many Digital Heroes clients take: prove demand on no-code, then rebuild custom once revenue justifies it, treating the no-code version as a paid prototype rather than a foundation.
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.
How many SaaS seats do we need before building custom becomes cheaper?
The crossover usually shows up between 20 and 50 seats on premium tiers. Salesforce Enterprise lists at $165 per user per month, so 40 users cost about $79,000 a year in subscriptions, which is real money against a custom system you would own outright. Run the comparison over three years: if subscription spend beats the build cost plus 15-20% annual maintenance, custom wins on price before you even count workflow fit.
What happens to my software if the agency shuts down or we stop working together?
Nothing dramatic, if the engagement was set up correctly: the code sits in your repository, hosting runs on your cloud account, and a handover document explains how to deploy and operate the system. Any competent replacement team can then take over in days rather than months. If the agency controls the repo, the servers, or the domain, fix that now, because renegotiating access during a dispute is the most expensive place to discover the problem.
How do I calculate whether custom software will pay for itself?
Divide the build cost by the monthly benefit, where benefit is hours saved times loaded hourly cost, plus subscription fees replaced, plus any revenue the software unlocks. Three staff saving 10 hours a week each at a $40 loaded rate is about $62,000 a year, which pays back a $60,000 build in roughly 12 months. Across Digital Heroes internal-tool projects, 12 to 24 months is the normal payback range, and anything projecting under 6 months usually means the spreadsheet is hiding costs.
Do my field technicians need a native mobile app, or will a web app work?
If your technicians ever work in weak signal, you need a native or offline-capable app, because a plain web app fails exactly where field work happens: basements, mechanical rooms, and rural routes. Cross-platform frameworks like React Native or Flutter give one codebase for iPhone and Android with full offline storage, which is how Digital Heroes builds most technician apps. A web app is the right call for the office dispatch console, where connectivity is guaranteed.
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.
How many people should be working on my software project?
Three to five for a typical focused build: a project lead, one or two engineers, a designer, and part-time QA, which is the standard shape across 2,000+ Digital Heroes projects. Larger platforms justify 6 to 10, but a ten-person team on a small first version usually signals bill padding rather than horsepower. What predicts success is whether a senior engineer is writing your code daily, not the headcount on the proposal.
How big a team does it take to build field service management software?
The standard Digital Heroes team for a field service build is five to six people: a project lead, a designer, two or three developers split across the mobile app and backend, and a QA tester who works on real devices in real signal conditions. Bigger is not better; experience with offline sync is. The riskier pattern is the opposite, a single developer quoting the entire system alone.
Can we migrate years of data out of our current system into new custom software?
Almost always yes, through CSV exports or the vendor's API, and migration should be scoped as its own workstream with field mapping, a dry run, and a planned cutover window rather than an afterthought. The real time sink is rarely moving the data; it is cleaning it, since years of duplicates, free-text fields, and inconsistent formats surface all at once. Pull a full export from your current vendor before committing to anything new, because some SaaS plans restrict exports on lower tiers.
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 Rohan.
Director of Web Platform Engineering · Delhi · 2 posts on the site
Published · Last updated .
