Qmulus MRO Platform — Build Roadmap

Qmulus Aviation · Confidential

MRO Platform
Build Roadmap

A complete replacement for EBIS5 and Tekmetric — built aviation-native, FAA-compliant, and designed around the customer experience modern aircraft owners expect.

Phases

12–18

Months

Part 145

Compliant

Full

EBIS Replacement

↓ Future-proof architecture

Project timeline

Month 1 Month 4 Month 7 Month 10 Month 14

Architecture

Future-proof by design

The biggest risk in building your own platform isn't the build — it's locking yourself into the same trap you're escaping from. Every architectural decision below is designed to ensure that swapping any vendor is a two-week project, not a six-month one.

Seven design principles

01 — FUNDAMENTAL PRINCIPLE
Own your data. Rent your services.
Every external platform — SMS provider, payment processor, file storage, AI API — should be treated as interchangeable. Your system should never care which provider is doing the work, only that the work gets done. Your PostgreSQL database is the permanent record. Everything else is a delivery mechanism.
non-negotiable

The adapter pattern

Never call Twilio, QuickBooks, or the Anthropic API directly from your app logic. Every external dependency gets a thin abstraction layer. Swapping providers becomes a config change, not a rewrite. Your app calls SMSService.send() — it never knows or cares what's underneath.

high value · low cost

Your schema is sovereign

Never use a vendor's ID as your primary key. Use your own UUIDs. Store their ID as a secondary reference (twilio_message_sid, qbo_invoice_id). If you switch vendors, you drop their column — you don't rebuild your schema. This is exactly the EBIS problem in reverse.

high value · low cost

Event-driven architecture

Instead of systems calling each other directly, publish events to an internal queue. When you swap Twilio for SignalWire, you rewire which service listens to the sms.send event. The work order system never knows. New integrations plug in without touching existing code.

medium value · worth it at 3+ integrations

Version your own API

Your backend API should be versioned from day one (/api/v1/workorders). When you build a mobile app, a SprintBach integration, or expose data to a customer portal, you can evolve the API without breaking existing consumers.

low cost · high future value

Open formats for compliance records

FAA records need to outlive any software platform — potentially by decades. Store 8130-3s as PDF/A (archival standard), structured data as JSON with a published schema, field names in plain English. If you need to prove compliance in 15 years, you hand the FAA PDFs — not database dumps.

§145.219 · non-negotiable

Infrastructure portability

PostgreSQL is standard — it moves from Railway to AWS RDS to a self-hosted server without changing code. S3-compatible storage means Cloudflare R2, AWS S3, and Backblaze B2 all speak the same protocol. Docker containers run anywhere. Avoid managed services with proprietary APIs for critical infrastructure.

phase 3+ priority

The adapter pattern — how it works in practice

Your app calls

Adapter layer

Swappable providers

Swapping Twilio → SignalWire: change one line in config. Your work order module never touches.

Event-driven architecture — adding integrations without touching existing code

Work order closed

Internal event bus

SMS notification

→ Twilio adapter

Invoice created

→ QuickBooks adapter

8130-3 generated

→ PDF service

Archive record

→ retention store

SprintBach sync

→ add later

Adding SprintBach integration: write one new listener. Zero changes to existing consumers.

Vendor risk scorecard — run this before adding any dependency

Before adding any external service, answer these questions

If you can't answer "yes" or "we have a plan" to each row, reconsider the dependency.

Question	Why it matters	Qmulus answer	Risk if no
Is there a self-hostable alternative?	Your escape hatch if they get acquired or shut down	SMS: Yes (Asterisk) Storage: Yes (MinIO)	vendor-dependent
Do they use an open protocol?	SMTP, S3 API, OAuth — standard protocols mean alternatives exist	R2/S3 = S3-compatible SMS = industry standard	high lock-in
How hard is data export?	If you can't get your data out easily, you're locked in	QB: CSV export exists Twilio: logs exportable	migration cost
What's the realistic replacement?	If they doubled their prices tomorrow, what would you do?	Named for each service in adapter layer	no exit strategy
Does your schema reference their IDs?	If yes, you've already partially locked in	Their IDs = secondary fields only. Never PKs.	schema dependency
Can you run without them temporarily?	Graceful degradation means outages don't stop your shop	Queue-based — retries if provider is down	single point of failure

What to build now vs later — pragmatic priority

Own your data in your own database

The non-negotiable. Every critical record lives in PostgreSQL first. External systems are notified, not responsible. If QuickBooks goes down, your invoices still exist. This is the lesson EBIS taught you — don't pay it twice.

build in phase 1

Adapter pattern for every external service

Takes one extra day per integration to build correctly. Saves weeks per provider swap. Every SMS call, every storage call, every AI call goes through an interface — never directly to the vendor SDK.

build as you go

Your own UUIDs as primary keys everywhere

Zero cost to implement in Phase 1, enormous cost to fix later. Vendor IDs (Twilio SIDs, QuickBooks invoice IDs) are stored as secondary reference columns only.

build in phase 1

API versioning on your own backend

Start at /api/v1/ from day one. Costs nothing to set up, prevents breaking consumers when you evolve the API for mobile apps, SprintBach integrations, or customer portals later.

build in phase 1

Event-driven architecture for integrations

Worth building once you have three or more external integrations talking to each other. Not necessary in Phase 1 — but design the work order close flow with event publishing in mind from the start.

phase 2–3

PDF/A archival format for compliance records

FAA records need to outlive your software by decades. Build 8130-3 generation to output PDF/A from day one in Phase 4. Structured data as JSON with plain-English field names.

phase 4

Full containerization and infrastructure portability

Docker containers, infrastructure-as-code, multi-region redundancy. Do this when you're ready to scale or when the business demands it — not in Phase 1. Over-engineering for portability you won't need for 2 years is its own risk.

phase 5+

On timeline estimates

Phases 1–3 (core usable system) achievable in 6–7 months of focused development. Full EBIS replacement including compliance and migration realistically 12–14 months. Building alongside running Qmulus — add 30% to each phase.

On FAA compliance

EBIS remains the system of record during the parallel run period. Your RSM language change should be drafted early and reviewed by your FSDO before Phase 4 begins — not after. Budget for a FSDO meeting.

On the migration phase

EBIS historical data has years of inconsistencies and workarounds. Do not begin the migration until you have validated a full test export. Run parallel for a minimum of 90 days before decommissioning EBIS.

On the differentiator

No aviation MRO software currently does customer experience well. The digital estimate approval flow with per-squawk photos and one-tap approval is genuinely novel in this market. Build Phase 3 carefully.