Aviation Software Development Company: How to Choose One
Airlines, airports and maintenance organisations buy very different software from very different suppliers. Here is what an aviation software development company actually does, the certification and data standards that constrain the build, and how to evaluate one.
Search for an aviation software development company and you will mostly find ranked lists. They are easy to write and they age badly. NAVBLUE, which appeared on plenty of them, now redirects to Skywise, which describes itself as an Airbus digital services company born from the merger of NAVBLUE solutions and Skywise Digital solutions. A ranking published two years ago is already pointing at a company that no longer exists under that name.
The more useful question is what you are buying, and what makes buying it different from buying software anywhere else. Aviation is a regulated safety system. The record your software holds may be the evidence an authority inspects, and the retention period is written into law rather than into your data policy. This guide covers what these firms build, who the three buyers are, which standards constrain the work, and the questions that separate a genuine aviation supplier from a competent generalist.
The short version
- An aviation software development company builds the operational and enterprise systems airlines, airports, maintenance organisations and aerospace suppliers run on, which is a distinct discipline from certified airborne avionics.
- Airlines, airports and MROs are three different buyers with different clocks, different regulators and different data. Strength in one does not transfer automatically to the others.
- DO-178C governs software that flies, and the FAA recognises it in AC 20-115D as an acceptable means of compliance. Most operational aviation software is not airborne software and does not need it.
- What most projects do inherit are record keeping and security rules: 14 CFR Part 145 sets retention in law, EASA Part-IS now requires an information security management system, and ICAO Annex 19 puts safety management behind all of it.
- The interoperability standards you inherit (Spec 2000, iSpec 2200, IATA NDC, ACRIS) usually decide the integration budget, which is the line item buyers underestimate most.
- Evaluate a vendor on regulatory fluency first and technology second, because the engineering is checkable and the domain knowledge is where generalists quietly fail.
What an aviation software development company actually does
An aviation software development company builds the systems that airlines, airports, maintenance organisations and aerospace suppliers use to run their operations, ranging from maintenance and airworthiness records through flight and crew operations, airport resource systems, parts marketplaces and the retail systems that sell a seat. The technology stack is often unremarkable. The constraint is what makes it a specialism.
That constraint is regulation expressed as data. When a repair station records work on an aircraft, 14 CFR Part 145 requires those records to be kept in English, in a format acceptable to the FAA, for at least two years from the date the article was approved for return to service, and to be available for inspection by the FAA and the National Transportation Safety Board. That single rule dictates retention policy, language handling, export format and access control before anyone has drawn a screen. Build the schema without knowing it and you will rebuild the schema.
It is worth separating two things that get conflated. Certified airborne software, the code inside a flight control computer or a flight management system, is developed under a formal design assurance regime and is a specialist industry of its own. The much larger category is operational and enterprise software: the systems that plan the flight, roster the crew, allocate the stand, track the component life, source the part and sell the ticket. Most firms describing themselves as an aviation software development company work in the second category. Both are legitimate. Confusing them when you write your brief will waste months.
Airlines, airports and MROs are three different buyers
Airlines, airports and maintenance organisations buy different software, on different timescales, under different regulators, and a supplier credible to one is not automatically credible to the others. Because they share a vocabulary, the gap between them is easy to miss until a project is already underway.
An airline is a network business under constant optimisation pressure. Its systems plan routes, assign aircraft, roster crew against flight time limitations, plan fuel and payload, and manage disruption when weather or a technical fault unpicks the schedule. On the commercial side it prices, sells and fulfils the seat. The margins explain the urgency. IATA's industry statistics put global airline revenues at 1,009 billion dollars in 2024 against a net profit of 37.7 billion, and forecast that 2026 net profit will fall to 23.0 billion dollars, a 2.0 percent net margin worth about 4.50 dollars per departing passenger. Software that cannot show a return does not survive that arithmetic.
An airport runs fixed infrastructure and a passenger flow through it. Its systems allocate stands, gates and check-in desks, drive baggage handling, manage security and border queues, coordinate ground handling and publish flight information. The pressure is throughput against a footprint that cannot grow quickly. ACI World and ICAO reported global passenger traffic reaching roughly 9.5 billion in 2024, about 104 percent of 2019, with projections exceeding 12 billion by 2030. Airports absorb that growth largely through better coordination rather than new concrete.
An MRO, meaning a maintenance, repair and overhaul provider, or a continuing airworthiness organisation, governs whether an aircraft may legally fly. Its systems track component lives and maintenance programmes, raise work orders and task cards, control parts and their traceability paperwork, and produce the airworthiness release. The clock here is an aircraft on the ground earning nothing. The consequence of a bad record is not a support ticket but a question over whether an aircraft was lawfully returned to service. Our explainer on what MRO means in aviation covers the discipline itself, and aviation MRO software covers the systems in detail.
| Buyer | What the software governs | The clock it runs against | Primary regulatory pressure |
|---|---|---|---|
| Airline | Network, fleet, crew rostering, fuel, disruption, retail and fulfilment | Schedule integrity and thin net margin | Operator rules, flight time limitations, distribution standards |
| Airport | Stands, gates, baggage, passenger and border flow, ground handling | Turnaround time against fixed infrastructure | Aerodrome operator rules, security, information security |
| MRO and CAMO | Component lives, work orders, parts traceability, airworthiness release | Aircraft on ground and legal airworthiness | Part-145 and Part-CAMO, record retention, occurrence reporting |
What aviation software development services cover
Aviation software development services is a broader phrase than most vendors admit, and the honest scope of an engagement runs from discovery through architecture, integration, build, test, audit support and long-run maintenance. The part buyers consistently underestimate is integration, because aviation systems almost never run alone.
Discovery maps the workflow and the regulation together
Discovery in this industry covers two things at once: the operational workflow and the regulatory surface around it. A discovery that produces user stories without naming the rules that govern the data has done half the job. The output should say which records the system will own, which authority can demand them, and how long they live.
Architecture and data modelling carry the long-run risk
Airworthiness, traceability and safety data are append-heavy and evidentiary. A record that can be silently edited is a record that cannot be defended in an audit, so immutability, versioning and attribution belong in the schema rather than in an application feature.
Integration is where the aviation software development budget goes
A new platform typically has to exchange data with maintenance and engineering systems, parts catalogues, departure control, flight planning, crew systems and finance. Many of those are decades old and speak fixed formats. Ask an aviation software development company to size the integration surface, system by system, before it quotes. A supplier who cannot name the systems they will connect to has not scoped your project.
Build, test and the maintenance that follows
Assurance work follows the criticality of the scope. Not every project needs a formal design assurance package, but every project touching regulated records needs traceability from requirement to test. Ongoing maintenance is not optional either, since regulations change and an unmaintained compliance feature quietly stops being compliant.
The clearest signal in a vendor conversation is what they ask about, not what they claim. A firm that opens by asking which regulator holds your approval and which records the system must produce has built in aviation before. A firm that opens with its technology stack is telling you where its experience actually lies.
Airline software and what airline solution providers sell
Airline solution providers sell into two loosely connected halves of the business: operations, which moves aircraft and crew, and commercial, which sells and fulfils the seat. Understanding which half a supplier serves prevents most mismatched shortlists.
On the operations side the systems handle network and fleet planning, crew pairing and rostering under flight time limitations, flight planning and fuel optimisation, dispatch, and disruption recovery. Skywise, the Airbus digital services company formed by merging NAVBLUE and Skywise Digital, organises its offering around exactly this shape, covering planning and operations control, flight operations, technical operations and ground operations. That structure is a fair map of what an airline operations stack contains, whoever supplies it. Our guide to flight operations software goes through the operational layer in depth.
On the commercial side the standards do much of the shaping. IATA's NDC programme defines an XML based data exchange format built around offer and order management, letting airlines create and distribute offers across channels rather than pushing a fare through legacy distribution alone. Its companion, ONE Order, replaces the separate booking, ticketing and accounting records with a single order. If you are building anything that touches airline retailing, these standards are the ground you build on rather than an integration you bolt on later.
There is a third category that fits neither half neatly: shared industry infrastructure. SITA describes itself as the tech backbone of the air transport industry, founded in 1949 by 11 airlines and still governed by its members, serving airlines, airports and governments across more than 200 countries. Industry owned utilities of this kind occupy a position no ordinary vendor does, which matters when you are deciding what to build versus what to consume.
Airport systems and what airport software developers build
Airport software developers build systems that allocate a fixed set of physical resources against a moving schedule, which is a genuinely different engineering problem from anything on the airline side. The aircraft is a visitor. The stand, the gate, the belt and the desk are the assets under management.
The core is usually an airport operational database (AODB) holding the authoritative flight record, feeding resource management for stands, gates and check-in, plus baggage handling, flight information display, and increasingly a collaborative decision making layer that shares milestones between the airport, the airlines and ground handlers so everyone is working from the same turnaround picture. Passenger processing, from self service bag drop to biometric boarding, sits on top.
The hard part is that an airport is a coordination problem across organisations that do not report to each other, which is why data standards matter more here than almost anywhere else in aviation. Airports Council International runs the ACRIS working group, which sets out to standardise information and data exchange across the aviation community, and ACI also publishes an airport data dictionary that it positions as complementing IATA's Airline Industry Data Model and the air traffic management information reference model by focusing on airport-driven use cases. Anyone who has implemented against one of these models has met the real problem; a proposal that invents a bespoke integration format for each partner is a sign nobody on the team has.
Airports also now sit inside a formal information security regime. Under EASA's Part-IS rules, Delegated Regulation (EU) 2022/1645 reaches design and production organisations and aerodrome operators, while Implementing Regulation (EU) 2023/203 covers maintenance organisations, CAMOs, air operators, training organisations and air traffic management service providers. Both require an information security management system (ISMS), and EASA is explicit that an existing ISO/IEC 27001 certification is not sufficient on its own because Part-IS adds provisions specific to aviation safety.
The certification standards that decide how the software gets built
Certification requirements in aviation software depend on where the code sits, and getting this classification right at the start is the single highest leverage decision in the whole project. Applying an airborne standard to a back office system wastes a fortune. Missing one where it applies stops the aircraft.
Software that flies: DO-178C and ED-12C
Airborne software is governed by RTCA DO-178C and its identical European counterpart EUROCAE ED-12C. The FAA's Advisory Circular 20-115D, dated 21 July 2017, recognises both, describing the standard as "an acceptable means, but not the only means, for showing compliance with the applicable airworthiness regulations for the software aspects of airborne systems and equipment in type certification or TSO authorization." The same circular recognises the supporting documents that go with it: DO-330 for tool qualification, DO-331 for model based development, DO-332 for object oriented technology and DO-333 for formal methods.
Design assurance levels A to E
The rigour applied under DO-178C is set by the design assurance level, which comes from the system safety assessment rather than from anything about the code. Level A software is that whose failure could contribute to a catastrophic failure condition, and the levels step down through hazardous, major and minor to Level E, where there is no safety effect. More severe means more objectives, more independence between the people who build and the people who verify, and a far larger evidence package.
Ground systems and airworthiness security
Systems used in communication, navigation, surveillance and air traffic management follow a parallel track under DO-278A and ED-109A, which AC 20-115D names alongside DO-178C when it lists the supplements that apply to both. Airworthiness security has its own process specification in DO-326A and ED-202A, reflecting that a deliberate cyber attack on an aircraft system is a distinct hazard class from a random failure.
| Where the software sits | Governing standard | What drives the rigour |
|---|---|---|
| Airborne systems and equipment | DO-178C and ED-12C, recognised by FAA AC 20-115D | Design assurance level A to E from the system safety assessment |
| Ground CNS and ATM systems | DO-278A and ED-109A | Criticality of the ground function to safe operation |
| Airworthiness security | DO-326A and ED-202A | Threat and vulnerability assessment against aircraft systems |
| Operational and enterprise software | No airborne certification; organisational rules apply | Record retention, traceability, occurrence reporting, Part-IS |
The regulations that shape the data model
Regulation reaches operational aviation software mainly through record keeping, organisational approvals and reporting duties, and each of those translates into a concrete schema decision rather than a policy document. This is the layer that catches generalist suppliers.
Organisational approvals define your boundaries. Under EU Regulation 1321/2014, a Part-145 organisation performs the maintenance while a Part-CAMO organisation manages an aircraft's continuing airworthiness. They are separate approvals with separate responsibilities, and software that blurs them produces records nobody can rely on. In the United States the equivalent repair station regime sits in 14 CFR Part 145. If a vendor cannot describe this seam, they have not built for a maintenance customer.
Reporting duties are clocks in your architecture. A certificated repair station must report any serious failure, malfunction or defect of an article to the FAA within 96 hours of discovering it. That is a workflow requirement with a hard deadline, and a system that cannot surface a reportable event inside that window is a liability rather than an asset.
Safety management sits above all of it. ICAO Annex 19 consolidated the industry's safety management requirements, and its second edition, published after Amendment 1 was adopted in 2016 and applicable from 7 November 2019, extended safety management system provisions further across the industry, including to organisations responsible for the type design or manufacture of engines and propellers. Any system capturing hazards, occurrences or risk assessments is feeding an SMS, and it should be built knowing that. We cover the systems layer in aviation safety management software.
Taken together these rules explain why aviation data models look conservative. Append only histories, explicit attribution of every signature, versioned reference data and long retention are not architectural preferences here. They are how the record survives contact with an auditor.
The interoperability standards you inherit
Aviation runs on published data standards, and inheriting the right ones is usually cheaper than inventing an integration format, so a vendor's familiarity with them is a fair proxy for real experience. These are the ones that come up most.
On the materials and engineering side, the ATA e-Business Program maintains a family of specifications that most maintenance and supply chain systems touch. Spec 2000 is the industry standard for permanent part identification, shipping and receiving information and traceability, covering marking methods from barcodes and data matrix through RFID, and it spans eighteen chapters from procurement planning to the authorized release certificate. iSpec 2200 is described as the global aviation industry standard for the content, structure and electronic exchange of aircraft engineering and maintenance information. S1000D, maintained jointly with AIA and ASD, governs technical publications. Spec 42 addresses digital information security, Spec 2300 covers flight operations data exchange, and Spec 2500 standardises aircraft transfer records.
On the commercial and passenger side the IATA standards already described do the same job for retailing, while airports work from ACRIS. The pattern is consistent across all of them: the industry has already agreed on the vocabulary, and the cost of ignoring that agreement lands on you at integration time.
Parts and traceability deserve a note of their own because they are where a data standard becomes a business. A serviceable part carries its release documentation, and the value of a parts platform is largely the confidence that the paperwork and the part have not drifted apart. We built an aircraft parts marketplace with AI driven pricing and blockchain secured settlement for exactly that reason: in a market where provenance is the product, the record has to be as trustworthy as the component. If that mix of regulated data and commercial platform is the shape of your problem, our aviation and aerospace practice is where that work lives.
Sizing the aviation software market honestly
The aviation software market is real but poorly measured, and the market sizing figures that circulate deserve more scepticism than they usually get. Most originate as press releases from research firms whose methodology is not published, and the same segment routinely carries wildly different values depending on who drew the boundary. Quoting one to justify a build is a weak argument.
What can be measured is the industry the software serves, and those numbers are published by bodies with a reason to be accurate. IATA's fact sheet puts global airline revenues at 1,009 billion dollars in 2024, rising to a forecast 1,165 billion in 2026, against passenger numbers growing from 4.78 billion segment passengers in 2024 towards a forecast 5.09 billion in 2026. ACI and ICAO count roughly 9.5 billion airport passengers in 2024 with more than 12 billion projected by 2030.
Read together, those two series describe what funds aviation software. Volume grows steadily; profitability does not. IATA forecasts a 2.0 percent net margin for 2026, down from 4.2 percent in 2025. An industry moving more people on thinner margins has to get more out of the same aircraft, stands and crews, and that pressure is the budget. It also explains why aviation buyers are so hard headed about return on investment: the business case has to survive a fuel price shock.
The three kinds of aviation software supplier that lists blur together
Ranked lists of aviation software development companies usually mix three categories a buyer cannot substitute for one another, which is why they are so hard to act on. Separating them takes a minute and saves a shortlist.
Platform vendors sell a product you adopt. Amadeus, SITA, Skywise and the large maintenance suites sit here. You configure them and you integrate with them, but you cannot commission one to build your idea.
Specialist aviation software vendors sell narrower products into a single segment: a maintenance and engineering system, a crew rostering tool, an airport resource manager. Same relationship as a platform vendor, smaller footprint, usually deeper in one domain.
Custom development firms build what does not exist yet. An aviation software development company in this sense is the relevant choice when your operation is genuinely unusual, when the platform is itself the business you sell, or when the problem lives between systems no product spans. Idealogic sits in this third group.
A list that ranks Amadeus against a forty-person development shop compares a product with a supplier relationship. Work out which you need before comparing names.
How to evaluate an aviation software development company
Evaluating an aviation software development company means testing domain fluency first and engineering second, because engineering ability is comparatively easy to verify while domain knowledge is where a capable generalist quietly fails. A logo wall proves that somebody signed a contract, which is not the same as knowing whether the work was any good. Better to ask questions with checkable answers.
Start with the regulatory ones. Which regulation governs the records this system will hold, and for how long? Then go and check the answer against the rule. Ask them to explain the difference between a Part-145 organisation and a Part-CAMO organisation, or between an airline operations system and an airport operational database. You are listening for bounded, specific answers. Fluent generality is what a sales team produces when the delivery experience sits somewhere else.
Standards literacy is the next filter. Ask which data standards they have implemented and in what context. A firm that has worked in maintenance or supply chain reaches for Spec 2000 or iSpec 2200 without prompting, a firm in airline retailing talks about NDC and orders, and a firm in airports knows what ACRIS is for.
Then put the certification question to them directly: does your scope require DO-178C? For most operational software the right answer is no, delivered with a clear explanation of why and what applies instead. Anyone claiming DO-178C experience on a maintenance tracking project has either misunderstood the standard or is hoping you have.
Discount the phrase "FAA compliant" entirely. Approval in aviation attaches to a product and its design approval holder, not to a subcontractor. AC 20-115D is written for applicants, design approval holders and developers of airborne systems and equipment, and what gets approved is the article itself, through type certification or a TSO authorisation. No authority certifies a software development company as such. A supplier can legitimately say it delivered work into a programme where the design approval holder obtained approval, and that claim you can go and verify. A compliance badge on a marketing page gives you nothing to check.
Only then verify the engineering. Ask for a production system you can look at, an architecture they will defend in detail, and evidence of integrating with legacy operational systems under real load. Ask who will do the work and whether those people have shipped in this industry. Finally, check they will still be there in three years, because regulations change and compliance features rot.
| What to test | The question to ask | The signal you want |
|---|---|---|
| Regulatory fluency | Which rule governs these records, and for how long | A specific citation you can check, not a general reassurance |
| Organisational literacy | What is the difference between Part-145 and Part-CAMO | A clean explanation of responsibilities and boundaries |
| Standards experience | Which aviation data standards have you implemented | Named specifics such as Spec 2000, iSpec 2200, NDC or ACRIS |
| Certification honesty | Does my scope require DO-178C | A reasoned no for operational software, with what applies instead |
| Engineering evidence | Show a production system and a legacy integration | Something verifiable, with the named team who built it |
Build, buy, or compose your aviation platform
The build, buy or compose decision in aviation follows the same logic as anywhere else, with one twist: the regulated core of your data is usually the part you should own outright, and the commodity around it is the part worth renting.
Buying makes sense when your process is standard and time to live matters more than fit. You configure rather than build, and you accept the vendor's model of your operation. Composing puts your own workflow and user experience on top of a packaged or shared core, so you own what differentiates you and rent the ledger, the catalogue or the records spine. Building earns its cost when your operation is unusual, when the platform is itself the product you sell, or when the problem lives in the integration between systems no single product spans.
The failure mode worth naming is buying a packaged product for a non standard operation and then customising it until it is a custom build with none of the advantages of one. If your requirements list is mostly exceptions to how the product works, that is the signal. Our general framing of the tradeoff is in build versus buy for software.
What an aviation build costs and how long it takes
Cost in aviation software tracks the regulatory surface and the integration count far more than the feature list, which is why credible vendors quote after discovery rather than before it. Two projects with identical screens can differ several times over in cost because one owns regulated records and talks to nine legacy systems while the other does neither.
Three drivers do most of the work. The integration surface is usually the largest: every external system is a protocol, a data mapping, a test environment and an owner to coordinate with. The regulated record surface is next, because immutability, attribution, retention and export never appear in a feature list. Operational criticality is third, since a system people depend on during a live turnaround needs availability engineering that an internal reporting tool does not.
Timelines follow the same logic. A focused platform covering one workflow end to end with a few integrations is a matter of months for a senior squad. A multi domain system carrying a deep compliance surface is a multi quarter programme with a standing team. The general drivers behind an estimate are laid out in our custom software development cost guide; the aviation multiplier is almost always integration and records.
The practical advice is to scope the smallest system that runs one real operational workflow end to end, prove the record it produces would survive an audit, and expand from there. Choosing an aviation software development company is easier once you have that first slice defined, because a precise brief exposes vague suppliers faster than any reference check.
Frequently asked questions
An aviation software development company builds the systems that airlines, airports, maintenance organisations and aerospace suppliers run their operations on: maintenance and airworthiness records, flight and crew operations, airport resource and passenger systems, parts marketplaces and supply chain platforms, and the retail systems that sell a seat. The defining trait is not the technology but the constraint: the software sits inside a regulated safety system, so the data model, the audit trail and the record retention rules are engineering requirements from the first sprint rather than paperwork added at the end. Most firms serving this industry work on the operational and enterprise side rather than on certified airborne avionics, which is a separate discipline governed by DO-178C.
They serve three different buyers with three different clocks. Airline software optimises a network, a fleet and a crew roster against schedules, flight time limitations and fuel, and on the commercial side it sells and fulfils the seat. Airport software runs a fixed piece of infrastructure: stands, gates, baggage systems, passenger flow and the resource allocation that keeps aircraft turning. MRO and continuing airworthiness software governs whether an aircraft is legally allowed to fly at all, tracking component lives, maintenance programmes, work orders and the airworthiness release. A vendor strong in one of the three is not automatically credible in the others, and treating the three as one market is the most common scoping error buyers make.
It depends entirely on where the software sits. Software that flies falls under RTCA DO-178C and its European twin EUROCAE ED-12C, which the FAA recognises in Advisory Circular 20-115D as an acceptable means of showing compliance for the software aspects of airborne systems in type certification or TSO authorisation. Ground systems used in communication, navigation, surveillance and air traffic management follow DO-278A and ED-109A. Airworthiness security has its own process specification in DO-326A and ED-202A. Most operational software, including maintenance records, flight planning support, airport resource systems and parts platforms, is not certified airborne software at all, but it still has to satisfy the record keeping, traceability and information security rules that apply to the organisation running it.
No, and a vendor who claims otherwise is either confused or selling. DO-178C governs software in airborne systems and equipment approved through type certification or a Technical Standard Order authorisation. A crew rostering tool, a maintenance tracking system, an airport resource allocation platform or a parts marketplace is not airborne software and does not need a DO-178C data package. What those systems do need is a defensible audit trail, correct handling of regulated records, and an information security posture that satisfies rules such as EASA Part-IS. Ask a prospective vendor which regime applies to your specific scope. A precise answer is a good sign; an eager yes to every standard is not.
Test domain understanding before technology. Ask which regulation governs the records your system will hold and how long they must be retained, and check the answer against the rule. Ask them to describe the seam between a continuing airworthiness management organisation and a maintenance organisation, or between an airline operations system and an airport resource system, since fluency there separates people who have shipped in aviation from people who have read about it. Ask which data standards they have implemented, naming specifics such as Spec 2000, iSpec 2200 or ACRIS. Then check they can actually engineer: architecture, integration under load, and a production track record you can verify.
A credible engagement usually starts with discovery that maps the operational workflow and the regulatory surface together, then moves through architecture and data modelling, integration work against the systems that already run the operation, build and test, certification or audit support where the scope requires it, and long-run maintenance. The integration layer is usually the largest and most underestimated part, because aviation systems rarely run alone: a new platform has to exchange data with maintenance and engineering systems, parts catalogues, departure control, flight planning and finance. Ask any vendor to size the integration surface explicitly before quoting.
It tracks scope and regulatory depth rather than feature count. A focused platform covering one workflow end to end, with a small number of integrations and a clear audit trail, is a matter of months for a senior squad. A system that spans several operational domains, integrates with legacy operational systems, and carries a deep compliance surface becomes a multi-quarter programme with a standing team. The reliable predictor is not the screen count but how many external systems you must exchange data with and how much regulated record keeping the platform owns. A scoped discovery against your real operation is the only way to set an honest timeline.
Buy the commodity, build the difference. Packaged products exist for common shapes of operation precisely because those operations resemble each other, and adopting one is usually the fastest route to running software when your process is standard. Custom work earns its cost where your operation is genuinely unusual, where the platform is itself the business you are selling, or where an integration and data problem sits between systems that no packaged product spans. A common middle path is composing your own workflow and user experience on top of a packaged or shared core, so you own the layer that differentiates you and rent the layer that does not.
More from the journal
How to Build HIPAA-Compliant Software
HIPAA compliance is an engineering problem before it is a legal one. The Security Rule reads like a requirements document once you stop treating it as legal text. Here is how to implement it.
Banking Software Development: Systems, Regulation, and Cost
Banking software development is the engineering of the systems a bank runs on: the ledger, the channels, the payment rails, and the compliance layer around them. What each layer does, which rules bind it, how to integrate a legacy core, where crypto fits, and what a build costs.
Clinical Trial Management Software: How It's Built
Clinical trial management software runs the operational side of a trial. Here's where it sits among EDC and eTMF, the data model, CDISC integration, 21 CFR Part 11, and what it takes to build.