Owning and building an experimental aircraft quietly turns you into several people at once.

You’re the builder, the operator, the maintenance manager, the compliance officer, and—whether you intended it or not—the historian of the airplane. Regulations don’t care that these roles live in one human brain. They still expect clarity, traceability, and continuity over time.

Most of the tools available today were not designed for that reality. They are built for fleets, flight schools, or certified aircraft ecosystems where responsibility is distributed across organizations. As an individual builder-owner, you end up stitching together paper logs, PDFs, spreadsheets, reminders, and mental notes—and hoping nothing important falls through the cracks.

In an earlier post, I described a simple but opinionated model for dealing with this complexity:

Paper → Scans → Dashboard

Paper logbooks remain the legal and historical source of truth. Scans preserve and protect those records. A dashboard sits on top—not to replace them, but to help you think, organize, and remember.

SlingologyMX is an experiment built directly on that model.

---

What SlingologyMX Is — and Isn’t

SlingologyMX is a lightweight maintenance and compliance dashboard designed specifically for experimental aircraft builders and owner-operators.

It is not a digital logbook.
It does not replace your paper records.
It does not claim regulatory authority or completeness.

And that’s intentional.

At its core, SlingologyMX assumes that your airplane’s true history lives elsewhere: in handwritten logbooks, signed entries, and scanned documentation that you control. The dashboard exists to index, relate, and surface that information in ways that are hard to do with paper alone.

Think of it as a structured memory aid with opinions about how things connect.

What it is:

• A way to organize maintenance, directives, equipment, and subscriptions into a coherent system
• A place where relationships are explicit, not implied
• A reminder engine that derives notifications from real records instead of free-form to-dos
• A tool built for individual builders, not organizations

What it isn’t:

• A replacement for paper or scanned logs
• A fleet management platform
• A hosted service that owns your data

Alright—now we open the hood and show how the thinking works.

---

How the Pieces Fit Together

Most maintenance tools treat entries as isolated facts: a log line here, a reminder there, a due date somewhere else. That works until the day you try to answer a simple but loaded question like:

“Why is this inspection due, what does it apply to, and what evidence do I have that it was last completed correctly?”

The dashboard is designed so those answers fall out naturally—because the connections are already there.

Equipment: The Anchors

Everything starts with equipment. Engines, propellers, avionics, accessories—anything with a serial number, service requirement, or directive trail.

Equipment entries are intentionally boring. They don’t describe work. They exist to answer one question cleanly:

What physical thing does this apply to?

Directives: Requirements With Context

Directives attach to equipment. They represent external requirements—manufacturer bulletins, service letters, ADs (when applicable), or builder-imposed rules.

A directive knows:

• What equipment it applies to
• Whether it is one-time, recurring, or conditional
• How compliance is tracked (calendar, hours, cycles)

Crucially, directives don’t say how compliance was achieved. They define what must be satisfied.

Maintenance Entries: Evidence, Not Expectations

Maintenance entries are records of work performed. They can stand alone, or they can explicitly reference one or more directives.

This creates a clean separation:

• Directives define obligations
• Maintenance provides evidence to directive compliance actions

When a maintenance entry references a directive, the system can infer compliance without guessing.

Subscriptions: Standing Assumptions

Some things don’t come from directives at all. Oil changes. Condition inspections. Builder-defined practices.

Subscriptions represent standing expectations—recurring maintenance or checks you expect to perform, even if no manufacturer ever wrote them down.

Subscriptions don’t generate work evidence. They generate future intent.

Counters: Tracking Use, Not Dates

Some maintenance doesn’t care about the calendar. It cares about how much the airplane has been used.

Counters exist to track hours or cycles—things like oil changes, inspections, and component lifetimes. They move only when you update them, and they reflect real usage rather than assumptions.

Counters are used by directives and subscriptions to calculate what’s due next, and they directly influence which notifications appear.

Counter updates are always explicit. You might update a counter after a flight, when reconciling with your paper logs, or when correcting historical data. There’s no background automation quietly changing values.

Every counter keeps a history of changes. This makes it possible to understand why a counter has its current value and to reconcile the dashboard with your records later. It’s there for clarity, not enforcement.

Notifications: Derived or Handwritten

Notification are either system or manually created.

A large set of notifications are generated from:

• Directives
• Subscriptions
• Maintenance entries
• Equipment counters

Each notification knows:

Tracking happens in two dimensions:

• Calendar-based (dates, intervals)
• Counter-based (hours, cycles)

This allows the dashboard to answer questions like:

• What’s coming due soon?
• What’s overdue?
• What moved because I just logged maintenance?

Not every reminder can—or should—be derived from rules.

Manual notifications let you create reminders directly for things that don’t fit cleanly into directives or subscriptions: follow-ups, one-off checks, or “don’t forget to look at this again” items.

System-generated notifications are derived and repeatable. Manual notifications are situational and intentional. Both appear in the same notification view, but only system-generated ones can be regenerated automatically.

Manual notifications exist to support judgment, not replace it.

Export and Import: No Lock-In

Your data should always be portable.

SlingologyMX supports export in:

• JSON for complete, structured backups and migrations
• Excel for human-readable review, audits, and sharing

Exports are scoped per aircraft context, so you get clean, focused datasets.

Import is supported only from previously exported JSON. This allows you to restore data, move between hosted and self-hosted instances, or recover from experiments—without turning import into a fragile data-conversion feature.

---

Feedback, Forks, and Source Code

This project is intentionally open in two different ways.

First, SlingologyMX includes built-in ways to send feedback directly, report bug, feature ideas, and small “this feels awkward” notes. This is an early-access tool, and shaping what it becomes matters more than polishing what it already is.

Second—and more importantly—the entire codebase is available on GitHub.

If you want to:

• Clone it
• Self-host it
• Modify it for your own workflow
• Treat it as a starting point rather than a finished product

You’re welcome to do so.

This isn’t a closed platform and it isn’t designed to create lock-in. Your data should always be yours, and your ability to walk away should always exist. If the hosted version ever stops being useful—or stops existing—the project should still survive on your terms.

Improvements, experiments, and forks are all fair game. Even if none of them ever come back upstream, that’s fine. The point is autonomy.

---

Early Adopter Reality Check

SlingologyMX is an early-adopter experiment.

That means a few important things, stated plainly and without euphemism.

This tool may change significantly. Features may be reworked or removed. The service could pause—or disappear—if it no longer makes sense to maintain. This is not a commercial product with uptime guarantees, SLAs, or a roadmap promised in stone.

Because of that, your paper logbooks and your own scanned records must always remain your source of truth. The dashboard is a convenience layer, not an authority. If you use SlingologyMX, you should also use the export tools regularly and keep your own backups. Assume impermanence, design accordingly.

If at some point the project moves forward, pauses, or ends, the intention is to give users enough notice to export their data. But the safest assumption is still the simplest one: nothing replaces records you physically control.

---

Access and Next Steps

For now, access is intentionally gated.

This keeps the feedback loop manageable and the expectations aligned. If you have an access code, you’re welcome to explore the system, stress it, and tell me where it breaks—or where it quietly helps.

This project will either earn its way forward through usefulness, or it won’t. Experimental aviation works the same way.

The following access code can be used for the first 20 early adopters: