An aircraft maintenance handover and control app is a single web application that records shift and task handover, non-routine defect cards, deferred defects against the MEL, and controlled company documentation — so that no open work item is lost between shifts and no defect escapes rectification before a Certificate of Release to Service is issued.
Aviathrust’s MSHS is that application, built inside a working EASA Part-145 maintenance organisation rather than in a software studio. It exists because this software was developed by an Engineer for Engineers.
Most maintenance software on the market was designed for airlines. It assumes a planning department, a dedicated IT function, a six-figure budget and a twelve-month implementation. For an organisation with fifteen engineers, four hangar bays and a Compliance Monitoring Manager who is also the Quality Manager and probably also a the safety manager, that software is the wrong shape. So the work stays on paper: a handover scribbled on a whiteboard, defect cards in a plastic wallet, deferred defects tracked in a spreadsheet that one person maintains and nobody else trusts.
MSHS covers the four places where small maintenance organisations actually lose control of information — and nothing else.
What an aircraft maintenance handover and control app does
The app is organised as four modules inside one application, behind one set of individual user credentials:
- Maintenance handover log — a structured, time-stamped, searchable record of what happened on each aircraft during each shift, replacing verbal handover and the whiteboard.
- Non-routine defect card management — raising, tracking, documenting and closing the defects discovered during a maintenance event, so the certifying staff can account for every one of them before release to service.
- Deferred defect management — tracking defects deferred under the MEL with automatic rectification deadlines, traffic-light expiry warnings and per-aircraft reports for the CAMO or owner.
- Controlled document library — publishing the Safety Policy, MOE, maintenance procedures, quality notices and compliance monitoring programmes so that staff can only ever access the current revision, with mandatory read-and-sign tracking.
Each engineer, certifying staff member and support staff member has individual login credentials. Credentials are never shared, and the level of access each person sees is controlled by their role within the organisation. Every entry is attributable, dated and time-stamped.
Shift handover is a regulatory requirement, not an administrative courtesy
EASA Part-145 point 145.A.47(c) requires the maintenance organisation to ensure that relevant information is adequately communicated when tasks and shifts are handed over, and the associated Acceptable Means of Compliance sets out what that information should cover. The procedure itself lives in your MOE. Your auditor will ask to see the records.
Maintenance is the one place in aviation where a quiet, undramatic error can sit dormant for hours or days before it bites. Shift and task handover is communication at its most fragile: a twelve-hour shift, a noisy hangar, fatigue, and a colleague who is mentally already on the drive home. Verbal-only handover is a well-recognised human factors weakness precisely because the gap between what was meant and what was heard leaves no trace — and no trace means no barrier.
The handover module makes that barrier a record.
What the handover log captures
A handover is raised against each aircraft tail sign and each work order processed during the shift. It is documented at the end of the shift, before leaving the facility, and it is raised even when there is nothing unusual to report — because "nothing to report" is itself information the incoming shift needs.
Each log identifies the work order number, the job card number where applicable, and the aircraft registration. The handover notes themselves are written in a word-processor-style editor — close enough to Microsoft Word that nobody needs training on it — with images and documents attachable, so an engineer can paste a photograph of a corroded bracket or attach the marked-up work pack page rather than trying to describe it in a text box.
A complete handover records:
- Planned work completed so far
- Outstanding planned work
- Defect cards raised during the shift
- Defect cards closed during the shift
- Outstanding aircraft parts and material
- General problems encountered
That last item matters more than it looks. A lost torque wrench, a calibration that expired mid-task, a ground power unit that keeps tripping — these are the things that never make it onto a task card and always cost the next shift an hour.
Every log is saved with a timestamp and is traceable to the user who raised it. Logs are listed most recent first, can be filtered by work order, job card, registration or date range, and can be converted to PDF and printed at will.
For a Maintenance Manager, this is the difference between walking the hangar every morning asking questions and opening one screen. For a Compliance Monitoring Manager, it is a sampling population for the audit plan that actually exists.
Non-routine defect card management: nothing escapes the CRS
Defects arrive from two directions. The flight crew reports them from a flight — the industry calls these PIREPs. Engineers, technicians and mechanics find them while accomplishing planned maintenance in the hangar or on the line — MAREPs. Either way, the defect must be evaluated and then either rectified before further flight or deferred as permitted by the approved maintenance data, the Instructions for Continued Airworthiness or the approved MEL.
The risk in a small organisation is not that defects go unrectified out of negligence. It is that a defect discovered at 16:40 on a Friday by a technician who then goes home is simply forgotten. It was never written down anywhere the certifying staff would look.
How the module is structured
Data is organised in a strict hierarchy: Aircraft → Work Order → Defect.
The aircraft fleet is loaded once, in advance, from data supplied by the responsible CAMO — registration, type, manufacturer, year, engine type and owner. An aircraft is created once and never re-entered. Keeping the fleet list current is a named responsibility of the Compliance Monitoring Manager.
At the start of each maintenance event, the responsible certifying staff member creates the work order exactly as issued by the CAMO: work order number, aircraft selected from the fleet dropdown, a short description of the maintenance event ("100 hr Check"), the start date and a status of Open. That selection is what links the work order to the aircraft.
A defect card can never be raised without an open work order behind it. That constraint is deliberate — it is what guarantees that every defect is attributable to a maintenance event and therefore surfaces when that event is being closed.
Raising and documenting a defect card
Raising a card takes four fields: the work order it belongs to, the defect description, the technical log page reference if it is a PIREP (or N/A if not), and the planned task card reference it arose from if it is a MAREP. The reported date defaults to today.
The card is then raised as Open and can be populated with rectification details later — which is exactly how it works in practice, because the engineer who finds the defect is rarely the engineer who fixes it.
Rectification is documented in three separate registers on the card:
- Rectification actions. Multiple actions can be added, each attributed to the person who performed it and dated. Good documentation here means clear, precise, concise actions in simple English; the maintenance data used, quoted with its revision number and revision date; and for every serialised or rotable component, the part number and serial number removed and the part number and serial number installed.
- Hardware and consumables. Item reference, description, quantity, batch number and the person who used it.
- Calibrated tools. Part number, serial number, calibration due date, the date of use and who used it.
That structure is not decoration. It is the evidence an auditor asks for, captured at the moment the work is done rather than reconstructed from memory three months later.
Closing out
Defect cards are grouped by work order and can be filtered to a single work order, so a certifying staff member closing a maintenance event sees every card raised against it in one list, with a defect count and a summary sheet. The card generates a printable PDF task card carrying the actions, the hardware and consumables and the calibrated tools, laid out with Performed and Inspect columns for signature and stamp.
Personnel sign only within the privileges and limitations of their own personal authorisation certificate. Closed cards stay visible under their work order with a Closed status, and the work order itself moves to the archive once it is closed out.
The certifying staff member is responsible for ensuring that every raised defect card is accounted for before the CRS is issued. The module is what makes that responsibility dischargeable rather than aspirational.
Deferred defect management: the calendar that does not forget
Where a defect is assessed against the approved maintenance data, only authorised certifying staff can decide whether it seriously hazards flight safety and therefore whether rectification may be deferred. Where the operator's approved MEL is used, that assessment is governed by the MEL instead. Either way, once a defect is deferred it must be rectified as soon as practicable and within the limits specified in the maintenance data or the MEL.
The failure mode here is not a bad decision. It is a good decision followed by three months of silence.
Traffic-light control
The deferred defect register lists open items grouped by aircraft, earliest rectification deadline first, and tags each one:
- Red — the rectification deadline has expired. An aircraft with an expired deferred defect cannot be released to service unless a Repair Interval Extension has been granted. That privilege belongs to the operator, exercised under a procedure approved by its competent authority, and it is available only for categories B, C and D.
- Orange — due within the next 14 days. This is the working queue: the Maintenance Manager liaises with the CAMO to agree rectification actions and request the necessary work orders.
- Green — due beyond the next 14 days.
The list filters to All, Expired, Due within 14 days or Later, and accepts a custom "due within N days" window for planning around a scheduled check.
MEL categories and automatic deadlines
When a deferred defect is raised, the MEL reference is recorded explicitly (or "N/A" where deferral is under maintenance data rather than the MEL), and the MEL category drives the deadline:
A - As specified in the MEL item - Due Date Entered manually
B - 3 calendar days - Due Date Calculated automatically
C - 10 calendar days - Due Date Calculated automatically
D - 120 calendar days - Due Date calculated automatically
NEF - Non-essential equipment and furnishings — items that do not affect the safe operation of the flight - Due Date Entered manually
Categories B, C and D calculate their own rectify-by date automatically, counted from the day after the defect was recorded, as MEL rectification intervals require. Nobody counts days on a wall calendar, and nobody transposes a date wrongly into a spreadsheet.
The technical log page on which the deferred defect was raised is a mandatory field. A deferred defect always begins with a tech log entry and is always closed with one.
Keeping the CAMO informed
When a deferred defect is raised, the responsible certifying staff member informs the aircraft owner, CAMO or operator the same day. The module generates a per-aircraft PDF list of open deferred defects — one button per registration — showing deferred defect number, description, MEL reference, category, date raised, rectify-by date, TLP raised, TLP closed and status, colour-coded by expiry. That PDF plus a scan of the tech log page is the email.
Closing a deferred defect requires a TLP Close reference; the system will not let the record close without it. Closed items leave the open list and move to the archive.
A word on responsibility, because it matters for how this software is used: the primary responsibility for monitoring deferred defect status rests with the responsible CAMO, owner or operator, and the privilege of extending a rectification interval rests with the operator under its approved procedure. A Part-145 organisation is not required to develop an MEL or technical log procedures, and no one inside the maintenance organisation can extend a deferral. What this module provides is an additional safety barrier — a maintenance organisation's own independent means of ensuring that deferred defects it raised are rectified in time.
Controlled document library: one source, current revision, read and signed
Part-145 organisations run on a documentation hierarchy — Safety Policy at the top, then the Maintenance Organisation Exposition, then maintenance procedures and quality notices, then management system records and forms. Every one of those documents is revision controlled, and using anything other than the current revision is a finding waiting to happen.
The document library publishes them in categories: Safety Policy, Organisation Certificates and Approvals, Maintenance Organisation Exposition, MOE Forms, Quality Notices, Maintenance Procedures and Compliance Monitoring Programmes. Staff access documents only here, which is the only way to guarantee the revision in someone's hand is the published one.
Documents can be flagged as mandatory read-and-sign. A red badge on the module tile shows each user how many mandatory documents they have outstanding, and an "Unread Mandatory Document" banner lists them until they are signed. When you issue a quality notice cascading a lesson learned from an audit finding, an incident or an accident, it stays in front of each person until they have read and signed it — which is what turns "we circulated it" into "they acknowledged it".
Because Part-145 point 145.A.200 obliges you to keep management system records for five years, the system provides a full backup export — database plus every uploaded file — as a single downloadable archive
Why this fits small Part-145, line maintenance and GA organisations
- It runs on what you already have. It is a web application. Any modern browser on any laptop, desktop, tablet or smart device on the shop floor reaches it. There is nothing to install on the engineers' devices.
- It maps to procedures you already wrote. Handover, non-routine defects, deferred defects and document control are already chapters in your MOE. The software follows those chapters rather than asking you to rewrite them around a vendor's data model.
- It is scoped, not bloated. There is no parts procurement suite to configure, no finance module, no planning engine you will never switch on. Four modules, one fleet list, one user directory.
- It starts working immediately. The only real setup is loading the aircraft list, which your Compliance Monitoring Manager is responsible for keeping current anyway. The first handover log is useful on day one.
- It gives the Compliance Monitoring Manager a working evidence base. Handover logs filtered by date range, defect cards grouped by work order, open deferred defects listed by aircraft, and mandatory documents that will not clear from an engineer's screen until they are signed. That is four audit checklists that stop being a paper chase.
For general aviation maintenance organisations and flying schools in particular, the deferred defect register alone tends to justify the change. A training fleet of a dozen aircraft generates a steady stream of small deferrals — an inoperative navigation light here, a frayed seat belt there — and the aircraft fly six days a week. A spreadsheet does not survive that. A well written dynamic software does.
Does any of this sound familiar?
If you recognised your own hangar anywhere in this article — the handover that exists only in somebody's memory, the defect card that surfaced after the CRS was signed, the deferred defect spreadsheet that one person maintains and everyone quietly distrusts — then the problem is already costing you something. It just tends to appear as a finding before it appears as a decision or worse!!
The initial call and consultation are free of charge. No obligation, no sales script, and no pressure to buy anything.
Here is what that call actually involves:
- Around 30 minutes, online, or at your facility if you are within reach in Malta.
- We walk through how your organisation handles handover, non-routine defects, deferred defects and document control today
- You get a straight answer on where your record-keeping risk is concentrated, whether or not you ever become a customer
- If MSHS looks like a fit, we demonstrate it using one of your own aircraft, one of your own work orders and one of your own deferred defects
If the honest conclusion is that your current process is sound and software would add nothing, we will tell you that. It is a small industry and a reputation is worth more than few bucks.
