Why a freelance CFI tool can't live inside a flight school tool

The original plan was one product. A single piece of software for flight schools that, as a bonus, freelance CFIs could also use. One codebase, two buyers, twice the market.

I killed that plan on day one.

When a tool is built for both the captain and the airline, it serves neither.

Two different airplanes

A freelance CFI runs a sole-proprietor business. They schedule their own lessons, set their own rates, invoice their own students, manage their own currency, and don't answer to a chief. A flight school is a fleet — multiple instructors, multiple aircraft, multiple students, a chief CFI, an ops manager, a Part 141 syllabus or a Part 61 program, and a dispatcher who decides who flies what when.

The two run on different airplanes. Different sized cabins, different crew, different procedures. You don't fly a 172 the way you fly a King Air. You don't build for both with the same UI.

The split

So Trim became the B2C tool for freelance CFIs. AutoBrief became the B2B tool for flight schools. Two products under one company. Different surfaces, different pricing, different sales motions, different first-screen experiences. The shared substrate (auth, scheduling primitives, the endorsement engine) lives in libraries underneath. The shared brand (TarmacLabs) sits above.

Same logic that makes a flight school keep separate manuals for the 172 and the King Air. Same operator, same hangar, different procedures. The procedures must match the airplane.

What this opens up

There's a third lane — custom software for aviation partners. That's the software-solutions side of the company. The two products are the public face; the custom work is the foundation that funds them. Different customers come in through different doors.

That clarity came on day one and has held since.