Daniel Harris ran a poll this morning: would operators switch to revenue-share software pricing? WingStack.ai charges a percentage of revenue instead of a flat fee, arguing the software only earns when you do.
We think both options in that poll are the wrong question.
The flat-fee problem
Start with what operators actually pay. A safety management system can run $70K a year. We've seen crew records systems priced at $15K for a bare-bones deployment: no integrations, no eligibility logic, just a database with a login page. That's $85K annually for two systems that don't talk to each other, before you count the hours your team spends re-keying the same certification data into both. And when the renewal comes up, you have no room to negotiate. Your five years of safety reports live in their schema.
The revenue-share problem
Revenue-share pricing increases the bill as you grow. You pay more when you fly more, even if the software does nothing different. In a business with charter margins, handing software a percentage of top-line is a rough trade. And you still don't own the code, the data, or the exit.
It's the same lock-in with a different invoice.
The third model
Open source the software. Make the money on services.
When the code is open, access is free. You pay people who understand Part 135 operations to implement and support it.
The economics work because the incentives finally point the same direction. The provider gets paid for work, rather than unused subscriptions or a share of the operator's revenue.
The integration problem disappears by design, too. When SMS and crew records share a codebase, a certification update flows straight to flight-readiness status. At one operator, that's 40 hours a month back, a chief pilot's time that was going to chasing paperwork instead of flying the operation. It also meant never standing up a technical records department. That's not a line item on a software quote, but it's the biggest number in this whole argument.
Full disclosure
Open source isn't free. Someone still hosts it, configures it, and keeps it compliant as regulations move. That's the services business, and we're not pretending total cost drops to zero. What drops is the lock-in, and that changes every negotiation you have afterward.
The role everyone should be hiring
This model needs an engineer working with the customer to build software around their operations and data. Palantir gave that role a name twenty years ago.
For years that looked like a Palantir eccentricity. In 2026 it's the fastest-growing role in software. Hiring for engineers working directly with customers is up more than 1,000% year over year. OpenAI, Anthropic, and Google Cloud are all hiring them. Amazon Web Services (AWS) says it will embed thousands of them directly inside customer teams. These companies are investing in engineers who help customers put software into use.
Operators can budget for the same kind of work: an engineer who builds on open code using the operator's own data. Vendors are moving toward that service model too. We expect the work of running and adapting software to become the paid part, with the code available free.
What we're building
We are funding two products that will be available soon.
SMS helps operators report, investigate, and close out safety events as an alternative to systems costing $70K a year.
Crew Records tracks certifications, qualifications, sim training, and flight logs, and computes eligibility automatically. At $15K a year, the bare-bones incumbents give you a database with a login page and no integrations. Ours shares a codebase with everything else, which is the entire point.
Both are written with Claude Code, by ForIT engineers who review every change. Crew Records went from its first commit on 30 March 2026 to an airline's system of record by August. SMS started on 6 June.
That speed is what makes the model work. When code is cheap to write, the value moves to the people who understand the operation and keep the software right, which is exactly the part worth paying for.
Who this is for
Talk with us if you want to own your software and data. This model will not suit every operator yet, especially those who are happy with their current vendors and costs. I expect it to become more widely useful.
Benjamin Thomas
ForIT Team
