Airline Crew Management Software: Build the Rule Layer or Buy Jeppesen
The threshold is not crew count, it is whether your collective agreement contains work rules your vendor cannot express without a change request. A single fleet type with a modest crew complement on a stable schedule should buy AIMS and stop reading.
On this page
The threshold is not crew count, it is whether your collective agreement contains work rules your vendor cannot express without a change request. A single fleet type with a modest crew complement on a stable schedule should buy AIMS and stop reading. Where the agreement has outgrown the configuration surface, own the rule layer and nothing else: a legality engine with your regulatory and contractual rules runs $150,000 to $300,000 over 18 to 26 weeks. Almost nobody should rebuild the pairing optimiser.
When is off the shelf genuinely the right call here?
Buy, and here is which one. If you operate a single fleet type with a modest crew complement on a stable schedule, AIMS covers that carrier well and the rosters you would get from a custom build would not be better. Say so early rather than discovering it after a discovery phase. This is the most common correct answer in the category.
Buy if you are large and your agreements are conventional. Jeppesen Crew Rostering and Sabre AirCentre have absorbed decades of edge cases you have not thought of yet, and NAVBLUE N-Ops and Crew is a serious option alongside them. A conventional agreement is exactly the case their rule models were built for, so reproducing it is spending money to arrive where you already are.
Keep the optimiser in every scenario, including the ones where you build everything else. Pairing optimisation is a specialist discipline and a good commercial solver, or an open constraint solver applied by people who know column generation, will beat a first attempt comfortably. A developer who offers to write you one is either inexperienced or selling you a decade of work.
The fourth buy case is a discipline test. Treat any product describing autonomous crew assignment by artificial intelligence with suspicion regardless of who sells it, because an assignment carries legal weight under flight and duty rules and a named human has to be accountable for it. If a vendor cannot tell you who signs, that is the answer.
When does a custom build actually pay off?
Build the rule layer when your contract has outgrown the configuration surface. Two rule systems govern every assignment. The regulator's flight and duty limits are published, stable and shared across the industry, which is why vendor engines handle them well. Your collective agreement is unpublished, unique and renegotiated periodically, containing reserve call out windows, minimum days off patterns, trade rights, pay protection and junior assignment rules that were each written to settle a specific historical grievance.
The first trigger is the change request. A clause that is simple in English becomes awkward in a configuration screen, so it gets approximated and a controller corrects the approximation from memory. Pull two years of change request invoices from your vendor. That is where the money goes at a carrier with active negotiations, and it is frequently booked as project spend and never reaches the renewal discussion.
The second is the override. If your controllers routinely bypass the system because they know something it does not, that knowledge is outside the system and no report will surface it. Overrides are the visible edge of an approximated rule.
The third is effective dating. A contract signed in April with provisions starting in October means both versions must coexist and evaluate correctly for the period each covers. Versioned rules with effective dates and a test suite built from real historical rosters is the strongest single argument for building this layer, and it is where vendor systems most consistently disappoint.
The fourth is currency discovered on the day. If crew expire against planned flying and nobody sees it until the gate, you are validating a status flag rather than projecting a fact.
The fifth is the one nobody writes down. Ask your negotiating team whether any clause in the last agreement was shaped by what the software could express. That is a commercial cost with no line item at all.
How do they compare on the things that matter in this industry?
Rules. A vendor engine treats the contract as configuration. A build treats it as versioned code with a test suite, where each rule is an isolated named predicate with test cases written from real historical rosters. Then a new agreement is a set of pull requests with evidence rather than a configuration project measured in months.
Qualifications. Both routes check currency. The difference is timing and shape. Evaluating qualifications as time varying facts, validated across the whole roster span rather than at publication, answers the useful question: whether a crew member will still be current on a specific future date given planned flying and booked training. That lets the training department book recurrent slots against the trips they would otherwise invalidate, moving discovery from the gate to six weeks out.
Optimisation. Vendor solvers are good at minimising credit hours, deadheads and hotel nights. What they optimise less well is crew acceptance, and a technically efficient month nobody wants generates trades, sick calls, open time and a reserve pool burning through by week three. That cost lands in operations rather than in the planning report. The objective weights and the pre publication evaluation layer are worth owning. The solver underneath is not.
Recovery. Planning has hours and optimises cost. Recovery has minutes and optimises damage limitation with four phones ringing. A system that reassigns automatically is unusable, because the controller has to defend the decision to a union representative the following week. Ranking a small number of legal options with consequences stated plainly is the only shape that gets used.
What does total cost of ownership look like at your scale?
Take your annual crew system fee and add every change request invoice from the last twenty four months. Then price the things that appear on no invoice: cancellations traceable to a legality or currency problem discovered on the day, grievances arising from an assignment that could not be evidenced, and any clause your negotiating team shaped around the software.
On the build side, the rule layer runs $150,000 to $300,000 over 18 to 26 weeks in Digital Heroes delivery experience, covering the regulatory legality model, the contractual rule registry with effective dating and a test suite, qualification and currency evaluation across the roster span with forward projection, and controlled assignment with a full audit trail. A full platform adding pairing construction around an embedded solver, bidding, reserve management, recovery decision support and a crew mobile application runs $500,000 to $1,500,000 across 12 to 24 months.
A carrier with roughly 900 crew, separate pilot and cabin crew agreements and a single regulatory regime lands near $264,000 for phase one plus $62,000 of parallel running, and about $1,090,000 for everything. Bidding alone accounts for $210,000 of that and is the most deferrable line in the estimate, which is the most useful fact in the whole exercise.
The drivers are rule surface rather than screen count. Separate agreements multiply directly, since pilots and cabin crew are two rule sets and a carrier with several bases or subsidiaries may carry four. Operating under both a United States flight and duty regime and the European flight time limitation rules roughly doubles the legality model, because the two differ in structure rather than only in numbers.
Afterwards, budget continuing engineering equal to roughly a fifth of build cost annually, which is higher than most software because the rules genuinely change. Add solver licensing for as long as you run pairing, bursty compute around bid build, and the incumbent licence for whatever modules you did not rebuild.
What does the hybrid look like, and when is it the honest answer?
Buy the platform, build the thin layer you actually need. In crew management this is not a fallback, it is the position we argue for in almost every conversation.
Build the legality and currency layer first and run it as a validator beside your existing system rather than as a replacement. It changes nothing about your licence, it catches what the incumbent misses, and it proves itself against real months before you commit further. Amortised over five years plus annual engineering that is roughly $105,000 a year on a $264,000 phase one, sitting alongside a vendor system you keep. Several carriers stop there permanently and are right to.
Keep the solver underneath in every version. Own the objective model that reflects what your crew community reacts to, and own the evaluation layer that shows the reserve consumption a candidate roster implies before you publish it. That combination came to $180,000 in the worked example including solver integration, and it is where vendor defaults will never match your priorities.
Defer bidding indefinitely unless it is your actual pain. It is the single largest discretionary line and it can be added years later against a proven rule engine. Defer recovery support too if your crew control desk is experienced and stable, because a recovery tool nobody trusts is worse than none.
Scope the crew mobile application to four actions: see the roster, request a trade, respond to a call out, submit a report. Everything beyond that drags the interface toward a rewrite of the portal you already dislike.
Which should you choose, by operator size and stage?
Single fleet type, modest crew, stable schedule. Buy AIMS. This is settled, and a build would be a very expensive route to the same rosters.
Large carrier, conventional agreements. Buy Jeppesen Crew Rostering, Sabre AirCentre or NAVBLUE N-Ops and Crew. Their rule models were built for exactly your case.
Any size, agreement your vendor cannot express. Build the rule layer only, at $150,000 to $300,000, running as a validator beside the incumbent. This is the recommendation more often than any other in the category, and it is deliberately unambitious.
Two regulatory regimes with a manual reconciliation between them. Build the rule layer and say it at scoping, because retrofitting a second regulatory model after the engine is built is the change most likely to push a phase one estimate through the top of its band.
Crew acceptance driving trades, sick calls and reserve burn. Build the objective model and evaluation layer around a commercial solver, and leave the solver alone.
Preferential bidding as the genuine pain. Build it last and budget the validation separately, expecting it to exceed the build effort. Seniority based award logic is unforgiving: a defect does not produce a slightly worse roster, it produces a grievance a crew member can evidence.
Whichever you choose, run one full bid period in parallel and treat disagreements as adjudications with your own planning leads rather than as defects. Sometimes the incumbent is the one that is wrong, and finding that out is part of what the exercise is for.
When the shortlist is down to two and you need a tiebreaker, Digital Heroes builds and runs its own products, so the people choosing your architecture live with those decisions on their own revenue. 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.
- Organizations that scaled intelligent automation report an average cost reduction of 32% (up from 24% in 2020), and respondents expect an average 31% cost reduction over the next three years. Source: Deloitte (2022) →
- SHRM's 2025 benchmarking data puts the average cost-per-hire at $5,475 for nonexecutive roles and $35,879 for executive roles - executive hires are on average nearly 7x more expensive than nonexecutive hires. Source: SHRM (Society for Human Resource Management) (2025) →
- 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) →
- McKinsey found that currently demonstrated technologies can fully automate about 42% of finance activities and mostly automate a further 19%, indicating roughly 60% of finance work is technically automatable. Source: McKinsey & Company (2018) →
Frequently asked questions
What does it cost to switch off Jeppesen or Sabre?
In the recommended shape you do not switch off anything. The rule layer runs beside the incumbent as a validator, your licence continues unchanged, and there is no migration to survive.
If you eventually replace modules, the cost is parallel running rather than licence. One full bid period alongside the existing system with formal adjudication of every disagreement came to $62,000 in a 900 crew worked example, and it is not a line to cut.
What happens if our crew vendor changes its pricing?
Look at change requests before the renewal. At a carrier with active negotiations, the money goes on the services charged each time a new contract clause has to be expressed inside a vendor rule language, and those invoices are usually booked as project spend rather than reaching the pricing discussion.
Owning the rule layer is the structural hedge. Once your agreement is expressed as versioned code with tests, a pricing change becomes a decision about which vendor modules to keep rather than a squeeze on your whole operation.
How long does a crew legality engine take to build?
Eighteen to twenty six weeks to a first release, preceded by four to six weeks of rule translation with your crew planning leads. Then one full bid period of parallel running.
Discovery is translation rather than requirements gathering. Every clause becomes a named predicate with test cases, and expect the exercise to surface clauses that two planners interpret differently. That is uncomfortable and it is one of the most valuable outputs of the whole project.
Is AIMS enough for a carrier with two fleet types?
Often yes, and fleet count is not the deciding factor. AIMS covers a carrier with a modest crew complement on a stable schedule well, and a second type does not by itself change that.
What changes it is the agreement. If a reserve call out window or a junior assignment rule cannot be expressed without a change request, and a controller is correcting the approximation from memory, that knowledge is outside every system you own and it is what a rule layer recovers.
Should we build our own pairing optimiser?
No. A good commercial solver, or an open constraint solver applied by people who know column generation, will beat a first attempt comfortably, and rebuilding one is a decade of specialist work.
Own the objective model and the evaluation layer around it instead, which came to $180,000 in the worked example including solver integration. That is where your crew acceptance priorities live, and a vendor default will never reflect them.
Why does preferential bidding cost so much to build?
Because seniority based award logic is unforgiving. A defect does not produce a slightly worse roster, it produces a grievance a crew member can evidence by showing the award violated their seniority position, and that risk profile forces a level of validation most features never need.
Bidding came to $210,000 in the worked example, the largest single line and the most deferrable. It gets its own parallel period against the existing award for a full bid cycle, and the validation routinely exceeds the build effort.
Does operating under two regulatory regimes change the decision?
Substantially, and it usually pushes toward building the rule layer. The United States flight and duty regime and the European flight time limitation rules differ in structure rather than only in numbers, so a system designed around one leaves awkward gaps under the other.
Carriers running both typically maintain a manual reconciliation, which is precisely the hidden work a rule layer removes. Raise it at scoping, because retrofitting a second regulatory model afterwards is expensive and risky.
How do we tell a software problem from a contract problem?
Ask two crew planners to apply the same reserve call out clause to the same scenario. If they differ, you have a contract interpretation problem, and encoding it will make the disagreement permanent rather than resolving it.
The signals that are genuinely structural look different: change request invoices growing every negotiation cycle, controllers overriding the system from personal knowledge, currency problems surfacing at the gate, and a negotiating team shaping clauses around what the software can express.
What tech stack should custom HR software use?
Choose boring and hireable: React or Next.js on the front end, Node.js or Django behind it, and PostgreSQL for data, since Postgres row-level security maps cleanly onto salary visibility rules. That is the Digital Heroes default for HR systems because any future team can maintain it. Be wary of agencies pushing an exotic stack; you will be hiring for it for a decade.
How do I vet a developer or agency for an HR software project?
Ask two questions: show me a project where you handled sensitive employee data, and walk me through how you would stop a manager from seeing salaries outside their team. Teams that have built HR systems answer the second one immediately with role-based access design; teams that have not will improvise. Also ask which payroll APIs they have integrated, because ADP, Gusto, and Paychex each behave differently in practice.
What should I prepare before contacting an agency about HR software?
Bring four things: your current tool list with annual costs, headcount now and projected in two years, the five workflows that waste the most HR hours each week, and any compliance requirements like multi-state employment or union rules. A sample data export from your current system helps too. Digital Heroes scoping calls with this prepared produce a fixed quote in days instead of weeks.
What questions should I ask a development agency on the first call?
Ask who exactly will build it, what happens when scope changes mid-project, what their maintenance terms are after launch, and what they will need from you every week. Then ask them to describe a project that went wrong and what they changed afterward; teams that have shipped at real volume have war stories, and teams claiming a perfect record are hiding something. The scope-change answer matters most: a disciplined shop describes a written change-order process, not a vague promise to be flexible.
How much does custom HR software cost for a small business?
A core HR system covering employee records, onboarding, time off, and documents typically lands between $30,000 and $80,000 for a small business, based on Digital Heroes delivery across 2,000+ projects. Full platforms that add applicant tracking, performance reviews, and time and attendance run $80,000 to $250,000. Most teams under 100 employees start with the core and expand after the first release proves itself.
How long until custom HR software pays for itself?
For companies over 100 employees, payback typically lands in 24 to 36 months across Digital Heroes projects, driven by cancelled per-seat subscriptions and recovered HR admin hours. A 200-person company spending $40,000 a year on HR tools plus a day a week of manual workarounds crosses even faster. Under 50 employees the math usually favors staying on Gusto or BambooHR, and an honest agency will tell you that.
What are the biggest mistakes first-time software buyers make?
Choosing the lowest bid, paying more than 30-40% upfront instead of on milestones, skipping a written specification, and having no maintenance plan for after launch. The most expensive of the four in Digital Heroes rescue projects is the missing spec: without written acceptance criteria, done becomes an argument instead of a checklist, and every disagreement resolves in the vendor's favor. Fix those four and you have avoided most of the ways these projects fail.
Does it matter which tech stack the agency wants to use?
Yes, but not in the way most buyers expect: the goal is boring, popular technology such as React, Node.js or Python, and PostgreSQL, because any future team can maintain it and hiring a replacement developer takes days, not months. The red flag is an agency-proprietary framework or an unusual language, which welds you to that one vendor no matter what your contract says about code ownership. A useful test: could you find three freelancers fluent in this stack within a week? If not, push back.
Can custom software replace ADP Workforce Now?
It can replace the HR layer, meaning records, onboarding, time off, and reporting, while keeping ADP's payroll engine underneath through its APIs, which is what most Digital Heroes clients on ADP choose. Rebuilding payroll tax calculation itself is rarely worth it, because ADP and Gusto maintain tax tables across thousands of jurisdictions. You get your workflows back without taking on tax liability.
Can custom software connect to the tools we already use, like QuickBooks, Stripe, and Google Workspace?
Yes, and connecting your existing tools is one of the main reasons to build custom: mainstream platforms like QuickBooks, Stripe, Shopify, and Google Workspace all publish documented APIs. Budget 1 to 3 weeks of work per integration depending on API quality and how much data flows in both directions. Ask any vendor whether they have integrated with your specific tools before, because quirks like QuickBooks' OAuth token handling and API rate limits get learned on someone's project, and it should not be yours.
Who can build a custom HR software system?
Digital Heroes builds custom HR 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 HR 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 Tara.
React Native Lead · Delhi · 5 posts on the site
Published · Last updated .
