Three weeks from frustration to SaaS: how Claude wrote 90% of the code for an airline ticket search service

The Best Products Are Born from Personal Pain. This phrase has long become a startup cliche, but reality sometimes serves up cases that restore its original meaning. A Russian developer spent three weeks turning frustration with flight searches into a fully-fledged SaaS service, with the language model Claude writing ninety percent of the code.

The Original Problem Sounded Mundane The initial task was straightforward: find tickets to Bali for five people with flexible departure dates and a fixed trip duration. Anyone who has attempted something similar knows the feeling: aggregators like Aviasales or Skyscanner work beautifully when you're traveling alone and know exact dates. But add variables—a group of travelers, a floating date range, a duration requirement—and the interface starts to choke. You end up manually sifting through dozens of combinations, opening tab after tab. That's when the author's switch flipped: instead of spending hours on manual searches, he decided to automate the process.

The result is a Telegram bot capable of checking over a thousand route combinations per hour and finding options with savings of up to fifty-two percent relative to standard search. One key insight uncovered in the process: round-trip tickets can be forty percent cheaper than the sum of two one-way tickets. It seems obvious, but aggregators rarely show this difference clearly, especially with complex routes involving connections.

The Technical Side The technical side of the project deserves special attention. The author deliberately chose an "AI writes all code" approach and entrusted the bulk of development to Claude. By his assessment, the model handled ninety percent of tasks—from backend logic to DevOps configuration. This isn't just boilerplate generation: it's a complex architecture including reverse-engineering of airline and aggregator closed APIs, bypassing anti-bot systems, and building analytics infrastructure with CTR, retention, and conversion funnel metrics. Three weeks from zero to a working product with real users—a pace that just a couple of years ago would have required a small team and months of work.

The Legal Gray Area That said, the case raises uncomfortable questions. Reverse-engineering third-party APIs and bypassing protective mechanisms is a practice that balances on the edge of legality. Most aviation aggregators explicitly forbid automated data collection in their terms of service. This doesn't mean such projects shouldn't exist, but scaling such a service will inevitably face legal and technical barriers. Companies regularly update their defenses, and legal precedent on scraping remains contradictory.

The More Interesting Aspect Much more interesting here is another aspect—the speed at which language models allow a solo developer to create products previously accessible only to teams. When Claude takes on the routine of code-writing, the developer can focus on product thinking: what exactly to build, for whom, and how to measure success. The author emphasizes that he simultaneously thought about backend, DevOps, UX, and business metrics—and it's precisely this ability to keep the full picture in mind that distinguishes a successful project from a technical demo.

The One-Person SaaS Trend This case fits into the gathering momentum of "one-person SaaS," where AI tools become a multiplier of possibilities for individual developers. We're seeing more and more stories where a single person with a clear understanding of the problem and access to modern language models releases a product faster than a corporate team completes an approval cycle. This doesn't eliminate the need for teams on large-scale projects, but it radically lowers the barrier to entry for testing hypotheses.

Three weeks, one developer, a language model as co-author, and a live service as output. A formula that seemed exotic a year ago is becoming the new normal today. The question is no longer whether AI can help write code, but whether the developer has the product intuition to channel that power in the right direction.