I think a lot of developers have that dream: You build something on the side, ideally small enough to handle in the evenings, but useful enough that people are willing to pay for it. At some point you add subscriptions, a few users turn into a few more, and if everything goes unusually well, the project slowly becomes more than a hobby. Maybe it does not replace the day job immediately, but it creates options: A bit of independence, some recurring revenue. A system that works for you instead of the other way around. In my case it's unlikely to replace my regular day job, not only because I do not expect FrontierWings to generate enough revenue to make a living, but also because I love (some of) my day job and the team I have the opportunity to work with.
A small Software as a Service (SaaS) business (usually cloud-based) sounds like a cool idea, especially for software developers. We like systems and automation, and we're naturally drawn to the thought of building something once and letting it produce value over time. Compared to client work, meetings, juggling priorities and the usual grind of professional software development, a small SaaS product can feel almost romantic.
Most side projects do not fail because the developer was unable to build the software. Of course, technical execution matters, and bad software will still kill a product quickly. But in many cases the harder problem is figuring out whether enough people care (repeatedly), and whether there is a realistic way to reach them without turning the project into a second full-time job.
From a developer's point of view, FrontierWings is a wonderful project, because there is always something technical to work on. There is the web platform, the simulator client, the telemetry recording, the SimConnect integration, the mission logic, the airport data, the validation rules and all the other small operational details that appear as soon as real people start using something. In other words, there is more than enough engineering work to disappear into for months.
From a business point of view, that development loop is a dangerous trap I'm constantly having at least one leg stuck in.
Because as a builder, for better or worse, I'm good at turning uncertainty into technical work. Questioning the validity or attractiveness of my ideas, I add another feature or try improve existing ones, or work on the UX, onboarding, robustness, whatever. Sometimes that work is useful or even necessary. But it can also become a comfortable way to avoid the more uncomfortable questions: Who is this really for? How do these people spend their time? Why would they care enough to try it? Why would they come back next week? Why would they pay? Why would they recommend it to someone else?
A cool idea is not a market
When you build something like FrontierWings, it is very easy to fall in love with the concept. What it does sounds fun to my ears. But "fun" is not necessarily a business.
Positive feedback is especially tricky. People are friendly, and in niche communities they often want to encourage someone who is building something interesting. They say things like “nice project”, “cool idea”, “looks promising” or “I’ll definitely check it out”. That kind of feedback is not worthless, but it is also not the same as demand.
Luckily, I have already received some first real signals: Someone creates an account, installs the client, accepts a mission, completes a flight, comes back for another one and eventually decides to pay. That matters because each step costs a little more effort than simply saying that the idea is nice.
In my case, the first paying users were a wonderful moment. A few people even bought lifetime access, which honestly felt incredible. But it also needs to be interpreted honestly.
Recurring revenue needs recurring value
First of all, let's talk about the payment option "lifetime support". I'm already doubting my decision to offer this option at all.
A lifetime sale is validation, trust and motivation. It gives the project momentum and it shows that the idea matters enough to at least a few people that they are willing to support it with real money, and not just a little amount. That is a strong signal, especially for a niche hobby product.
But the lifetime sub is not recurring revenue. It does prove that a small group of people already sees great value in the project, and that is encouraging. But it does not prove retention.
One of the biggest misunderstandings around SaaS is the idea that recurring revenue comes from just slapping a subscription model onto a product or service. Recurring revenue only works when the product creates recurring value.
That is obvious in business software. A company keeps paying because the product saves time, reduces errors, automates work or helps to increase the revenue. The payment repeats because the value repeats.
For a hobby product like FrontierWings, the value is different. Nobody uses a flight simulator because they want to save time, right? The value is emotional: immersion, progression, identity, challenge, atmosphere.
So what are some of the reasons to return? Most likely: mission variety, interesting tours, career progression, achievements, badges and visible milestones. This all puts together a sense of pilot identity.
That (I hope) is the kind of recurring value that will pilots motivate to continue to use FrontierWings, even for years to come.
Distribution is part of the product
For developers, marketing feels like something that happens after launch. You build the thing, publish it somewhere, maybe post about it in a few places, and then hope that the right people appear. But that is rarely how it works.
With FrontierWings, the distribution question is: Where do flight sim pilots actually spend their time, and why would they try yet another platform? A generic landing page saying “career platform for flight simulator” is not enough. The product has to communicate the intended emotional hooks as quickly as possible.
A forum post, a video, a blog article can all help explain the same underlying idea from different angles.
This is where many technical founders (including me) struggle, because we tend to explain the mechanism before the emotion. Also, I'd rather work on the platform than grinding the inevitable distribution/marketing loop.
Technical quality does matter, but...
For FrontierWings, the technical foundation matters a lot. If the sim client is unreliable, people will not trust it. If valid flights fail validation, people will get frustrated. If the website is slow or confusing, people will leave. If the mission system feels unfair, the whole career concept loses credibility. So: Technical quality creates trust. But technical quality alone does not create demand.
Every technical detail or feature needs to be scrutinized: Does it help a pilot complete flights more easily? Does it increase trust and reliability? Does it improve retention? Does it help someone recommend FrontierWings to another simmer? If not, maybe it should wait.
That is not always easy to accept, especially when the technical work is fun.
No clear answer yet to the real question
I still pursue the dream of a side project that grows into something meaningful. But I do think many developers take the wrong path.
We often imagine that the main challenge is building the application. In reality, the challenge is building recurring value for a specific group of people, and then finding a reliable way to reach more of those people.
For FrontierWings, that means the key questions, at least for now, are no longer primarily technical. I will have to do community and marketing work (which I'm not really very good at). And that likely will determine whether FrontierWings will grow into a (small) sustainable niche SaaS or whether it remains a tiny but maybe beloved hobby project, maintained for a handful of dedicated bush pilots.
I have no idea how the FrontierWings story will evolve. But I can promise it's here to stay for years to come. I like using it myself. :-)