Aviation is one of the harder places to build software, and the hard part is rarely the engineering.
Consider what your platform has to represent. A car collects the passenger, one of your helicopters flies the middle leg, and a chartered jet finishes the trip. That is one journey to your client and one line on the invoice. Your platform probably holds it as three records, because it decided one pilot belongs to one aircraft long before anyone asked how you operate. Your vendor will call that a configuration problem. It rarely is.
The regulatory floor is rising underneath that problem. NTSB data cited in the FAA's Safety Management Systems final rule records 215 accidents involving Part 135 operators between 2015 and 2019, with 121 fatalities. The FAA identified 35 of those as accidents a safety management system could have mitigated. Compliance is shifting from documentation you produce on request to behavior your systems enforce in the moment, and that changes what is worth buying.
The regulated builds I have watched go badly were undone by a data model nobody questioned, not by a technical decision made later.
This is scoped to Part 135 charter and flight operations, leaving reservations, MRO, and ground handling aside. Custom aviation software development gets discussed widely and demonstrated rarely, so everything here comes from one regulated platform in production. It covers what the build had to enforce, how the safety math was validated, what production took, and where buying still beats building. Wider context sits in our custom software development work.
Why off-the-shelf platforms break on multi-leg trips
You have probably already had the workaround conversation. Someone from the vendor walked you through a settings screen, suggested a way around the problem, and that workaround has quietly become permanent.
The distinction worth understanding here will shape your next twelve months. A feature gap can be filled, because the thing you need sits above the layer that was already built. A structural gap in the data model cannot be filled the same way, because everything above it assumes that structure is correct. Helinet Aviation sells one door to door journey, and their platform, Veryon, had no way to represent that as a single trip. The shape of the record was wrong, and no amount of reporting fixes a shape. The full story sits in the Helinet Aviation case study.
What happens when one trip becomes three records
Picture a typical Helinet job. A car collects a passenger, a Helinet helicopter flies the middle leg, and a jet chartered from another operator finishes the journey. The next day, the whole sequence often runs in reverse.
Their old platform tied one pilot to one aircraft and one driver to one car. That single job became three separate operations, and dispatch reconciled them by hand. Change a departure time on one leg, and someone had to go and apply it to the other two.
The cost showed up in places nobody had budgeted for. Hospital reports for the organ transfer work were compiled by hand every month. Each one itemized which flights ran late, whose fault the delay was, and how many organs moved. Clients also had no way to reach the crew running their operation, so anything urgent happened off the record.
The rebuild changed the unit of work from the aircraft to the operation. A single record now holds every leg, across owned, chartered, and subcontracted transport.
"The off-the-shelf system a helicopter charter company was using forced one pilot to one aircraft. Their actual work does not look like that. A single job might start with a car collecting a passenger, move to a helicopter, then a chartered jet, then run the whole thing in reverse. In the old system that was three separate records someone had to keep in sync by hand. Bought software models a transaction. Your business runs on operations." — Antônio Salla, Product Manager, DevSquad
How to tell a settings problem from a structural one
There is a quick test you can run in your next vendor call. Describe a change that alters the relationship between two records rather than the value inside one, then listen carefully to the answer. A setting means the model already supports what you need, and a date on a roadmap means it does not.
Configuration only ever operates inside the model, which is why a rigid model rarely announces itself with a clean refusal. It shows up instead as a hundred small workarounds, each of which looks survivable on its own.
Helinet had a second symptom of the same root cause. Hover performance calculations were hard coded to specific aircraft, so adjusting an aircraft type meant working inside fixed logic rather than editing a record.
I have sat through enough vendor demos to know the tell. When you describe how your operation works and the answer is a settings screen, the data model already decided the answer is no.
Once you have found a structural limit like that, the question stops being whether to leave and becomes when.
The safety layer that sits underneath your dispatch board
The dispatch board is genuinely the least interesting part of a flight operations platform, and that is good news for you.
The interesting layer sits underneath it, and it is the one that can stop a departure. That is also where bought and built software stop resembling each other. Down there, your software is not simply recording decisions. It is making some of them and refusing others, which makes it a different kind of product with a different kind of failure mode. Three pieces of that layer matter most, so it is worth walking through them one at a time.
Weight and balance checks that stop a flight, not just log it
No Helinet pilot can depart without completing a weight and balance check and a scored risk assessment. The system will not accept the flight until both are done.
That enforcement is the entire point. A platform that lets a pilot proceed and simply logs the omission has documented a problem rather than prevented one. That record ends up working against you.
Regulators are moving in the same direction. The NTSB's 2024 special investigation reviewed more than 500 fatal and nonfatal Part 135 accidents from 2010 to 2022. Unsafe loading came out as one of three systemic safety issues. The NTSB recommended the FAA mandate flight manifests and weight and balance documentation for every Part 135 aircraft.
Helinet's simulator covers landing fuel and zero fuel center of gravity, so the calculation runs against the load states the aircraft will actually pass through. A single takeoff snapshot would miss the moment those numbers start to drift.
Center of gravity limits built from each aircraft manual
Each Helinet aircraft is configured directly from its own manual, right down to empty moments, seat positions, and fuel curves. Center of gravity envelopes are plotted per model rather than approximated from a generic shape.
A bought platform ships with a supported aircraft list and a generic envelope, which works well until you add an unrecognized type. At that point you are waiting on a vendor release before you can fly something you already own.
Configuring your own aircraft is a commercial capability more than a technical one, because it decides how quickly a new type enters service.
Hover performance models your own team can update
Rotorcraft operations carry a requirement that almost no aviation software page bothers to mention. Hover performance depends on the aircraft, the conditions, and the load, and Helinet's old platform had it hard coded for a handful of types.
The replacement gives them configurable performance models they maintain themselves, without involving anyone else.
The principle generalizes well beyond aviation. Anything you will need to change should live as data rather than logic, and the test takes one question. Who has to be involved when it changes? If the answer is a support ticket, somebody built it as logic.
Compliance rules your software can enforce automatically
Your rules are already written and already legally binding. Right now, though, the thing keeping them is somebody's attention at the end of a long day.
Encoding a regulation into the software turns a compliance obligation into a system behavior, which is a meaningful upgrade. The previous section covered calculations about aircraft, and this one covers rules about people. People are the harder half, mostly because people have reasons. An operations platform that enforces your own policy is internal use software in the strictest sense of the term.
Enforced ten hour duty rest, with every override logged
Pilots are legally required to rest ten hours between shifts, and the Helinet platform will not let one clock back in before that window closes.
The override is the more interesting design decision. An exception can still be granted, but it requires a stated reason and it gets logged and justified.
So why build the exception at all? Because a rule with no exception path gets circumvented outside the system, and a circumvention outside the system leaves nothing behind. An exception you can audit will always beat a workaround you cannot see.
The same logic extends to judgment calls. A risk score in the orange band routes to the chief pilot or the VP of Operations. Approval never rests with the person who has the most reason to fly.
"The rules your industry already runs on should live inside the software. Pilots are legally required to rest ten hours between shifts, so the system will not let one clock back in before that. If an exception is genuinely needed, they give a reason and it is recorded. Off-the-shelf tools rarely know your rules exist." — Antônio Salla, Product Manager, DevSquad
Currency and training alerts that arrive before the flight
The platform tracks flight logs, hops, night currency, and cross-country time, and training expiry surfaces before a pilot flies out of currency.
Timing is really the product here rather than the record itself. You already know when a currency lapses, somewhere, in a spreadsheet that somebody updates. Getting that warning while there is still time to schedule around it is an entirely different capability.
Same principle as duty rest, applied to qualifications instead of hours.
FAA records that write themselves
When an inspector asks for records, somebody senior usually loses a day to it.
A record produced as a byproduct of the work differs from one reconstructed afterward, and the FAA has grown more interested in that difference. The 2024 Safety Management Systems final rule extended Part 5 SMS requirements to every Part 135 operator. Declarations of compliance are due no later than May 28, 2027, and compliance gets assessed on operational evidence during routine surveillance.
The three records an FAA auditor will ask for
Helinet has to produce three things on demand, and each one is now written by the work itself.
Weight and balance records. Completing the pre-flight check writes the record
Risk assessments. Scored before departure, which is what writes the record
Flight logs. Closing out an operation writes the log
Nothing has to be assembled later, because nothing was ever missing in the first place.
The design principle transfers cleanly to your own build. If a document is required for audit, the action that generates it should also be the action that saves it. No second step, no reconciliation at month end.
One condition comes attached. This only works when the software is where the work actually happens. Adoption and record quality are really the same problem wearing different clothes.
What rebuilding records by hand actually costs you
Reconstruction carries three costs you are probably already paying without measuring any of them.
Time. The records get assembled from scattered data rather than simply pulled
Seniority. The work falls to somebody experienced, because a junior cannot judge what is missing
Accuracy. The finished record is only as reliable as whatever data survived
Helinet's monthly hospital reporting, described earlier, is the clean parallel. What used to be assembled by hand for every hospital client is now generated straight from operational data.
It is worth running that arithmetic against your own last quarter.
How to validate safety calculations before a pilot relies on them
A weight and balance calculation that comes out wrong will clear a flight that should never have left the ground.
In a safety critical build, the validation method belongs in the specification itself. It is not a phase you add at the end, and it is not something you bolt on once the feature works. Ask any vendor how they prove a safety calculation before a pilot relies on it, and notice how few have a real answer ready.
"Get a weight and balance calculation wrong and you approve a flight that should never have left the ground. That is the risk to the pilots and the crew. Software carrying that kind of consequence needs redundancy, layered safety checks, and no margin of error at all. It is not the same job as building a dashboard." — Antônio Salla, Product Manager, DevSquad
Testing with real operational data, not sample data
Every calculation went to staging before it went anywhere near production, and Helinet ran real operational data through it there.
Both teams then walked a full trip together, leg by leg, confirming the numbers held at every stage. More than once the client came back with something wrong or missing, and the team corrected it before release.
That last part is really the whole method. Synthetic test data proves the code does what you told it to do, but not whether what you told it was right. The errors worth catching live in the edge cases that only a real operation produces, and Helinet found several of them.
Why three operational roles signed off, not one
Helinet's VP of Operations, an experienced pilot, and a senior dispatch operator all validated the work.
A single point of contact only ever sees one slice of the system. A dispatcher knows exactly what breaks in scheduling, and has no view of what a pilot needs standing at the aircraft. On complex builds, DevSquad product managers connect with every key role that touches the system so no detail goes missed.
The rule transfers easily enough. Match the number of people approving a safety calculation to the number of roles depending on it. It is slower in the moment, and considerably cheaper across the build.
Seven months to production, and what shipped in the first release
Seven months sounds fast, and the reason it happened is less impressive than the number suggests.
Development began in June 2025, and the platform went into production in January 2026, roughly a month beyond DevSquad's six month average. That is on a build carrying real safety and compliance requirements, and none of it came from working faster.
It came from deciding what did not go in the first release. Helinet's first release covered the operational core and nothing beyond it: dispatch, unified operations, aircraft configuration, weight and balance, and pre-flight checks. Reporting and the operation-scoped messenger were built afterward, once the platform was live and the remaining gaps were visible against real use. Seven months after production, with that second wave of feature work complete, the engagement moved from monthly development down to maintenance and quality assurance.
There was a clear reason behind that sequencing. The operational core had to be correct before anything on top of it was worth building. A reporting layer over the wrong data model just produces wrong reports faster. Live use also made the remaining gaps legible in a way that no requirements session manages.
Deciding what comes out is exactly what a discovery sprint exists to force. It is a short conversation with far more leverage than any technology choice that follows it.
Build or buy against Veryon, FL3XX, and CAMP
Any guide in this category that never recommends buying something is not really giving you advice.
So here is the honest split. The maintenance and airworthiness layer is a solved problem with genuinely good products in it, and the commercial pipeline is close behind. The operations layer between them is where fit tends to break down, and it is the only place where building reliably pays off. Anyone offering custom aviation software development services should be able to draw that line for you without being asked. The same structure shows up in our custom fleet management software guidance for ground operations, with lower regulatory stakes attached.
When buying makes more sense than building
Per tail maintenance tracking, airworthiness and AD compliance forecasting, and inspection scheduling are all well served by CAMP Systems and Veryon. Decades of work sit inside those products.
Charter sales, quoting, and the sales to dispatch pipeline are well served by FL3XX, particularly if your commercial workflow is fairly conventional.
Here is a test you can apply quickly. Describe the workflow to another operator in one sentence. If they nod along, somebody has already built it and priced it below what your own attempt would cost.
Rebuilding a solved layer is an expensive route to somewhere you could already be standing, so integration is usually the higher value move.
When building is worth the investment
Three conditions justify building, and you want at least two of them present.
Your operation spans modes or assets that the bought model cannot hold as one unit of work
Your rules are specific enough that no vendor will encode them for you
What you sell is the coordinated journey rather than the aircraft hour
Helinet met all three. As covered in the opening section, the multi-modal trip broke the data model. The regulated core encodes rules no vendor would write, and what Helinet sells is a door to door journey.
Building the operations layer does not mean building the whole stack. Helinet still pushes engine data to their existing maintenance system rather than replacing it, and that boundary was a deliberate decision rather than a compromise.
What changes in your software budget
The subscription is gone, so Helinet's software spend is now DevSquad plus infrastructure.
Underneath that line item sits a structural change worth more than the number itself. A subscription that re-priced at every renewal became software the operator owns outright.
Compliance costs are moving the other way, and they land on you either way. The FAA estimated quantified annualized costs of $47.4 million across the industry to develop and implement the required safety management systems. That figure uses a 7 percent discount rate over a five year analysis period.
"The clearest return on custom software is the line item that disappears. One aviation operator stopped paying a software subscription entirely and now pays only infrastructure costs. The second return is the reporting nobody has to assemble by hand every month anymore." — Antônio Salla, Product Manager, DevSquad
What to ask before you sign anything
The decision in front of you is smaller than this article probably makes it look.
Take two questions into your next vendor conversation. The first one: what happens when the thing I need to change is a relationship between records rather than a value in a field? Listen for whether the answer is a setting or a date.
The second: how does a safety critical calculation get validated before a pilot depends on it? Listen for whether real operational data and more than one operational role appear anywhere in the reply.
A vendor who cannot answer that second question has told you something genuinely useful, and learning it now costs you nothing. Learning it in year three means you are the one maintaining legacy systems nobody can extend.
Across a hundred plus builds, the projects that went sideways went sideways in discovery, not in engineering. On a regulated operation I want one thing answered before anyone writes code: what does this software have to prove, and to whom?
If you are shortlisting a custom aviation software development company, start with a short discovery engagement. Ask them to give you an honest answer about what should come out of scope, and ask for it in writing.
Custom aviation software development FAQs
The Helinet build reached production in seven months, against DevSquad's six month average, with full safety and compliance requirements in scope. The controlling variable is rarely engineering speed. It is how much scope comes out before development starts, and how quickly the people who own operational decisions can make them. A narrower first release reaches production sooner and teaches you more.
Yes, and the mechanism matters more than the answer. The weight and balance calculation gates the departure rather than logging it afterward, so an incomplete check stops the flight before it starts. Records are written by the action that performs the work. Weight and balance records, risk assessments, and flight logs come out on demand without anyone assembling them.
It depends on whether your limitation is a feature gap or a structural one in the data model. A feature gap can be closed by a vendor release or an integration. A structural gap cannot, because everything above it was built on that assumption. Partial replacement is a perfectly legitimate outcome, and the maintenance layer is usually the piece worth keeping.
Every Part 135 operator must submit a declaration of compliance by May 28, 2027, confirming a working safety management system. The FAA assesses that on operational evidence gathered during routine surveillance rather than on documentation alone. Software that produces evidence as a byproduct of normal work will leave you better positioned than software that produces reports on request.
DevSquad solves complex business problems with internal software users love. Learn more about our custom development services.
Phil Alves is the CEO and Founder of DevSquad and DevStats. He’s built and launched 100+ software products for bootstrapped founders, fast-growing startups, and enterprises. Phil writes about SaaS, product strategy, operational complexity, and building scalable development processes. He enjoys aviation, investing, and learning from other SaaS founders.