Creating an open source app for everyone: it takes more than code

December 3, 2025

My ambition with FairScan is not just to build an open-source app: it's to make an app that everyone can use, including all the people who don't know what GitHub is. That's definitely not easy and it takes more than writing good code. Before starting FairScan, I already knew there was a big difference between good software and a good product. Now, I experience it very concretely. This is my daily reality.

It takes a good UI so that it's usable by everyone

Open source apps are started and built by developers like me, but what users see is the user interface (UI), not code. The UI of an app should enable people to use it without reading documentation, and that's not trivial. I'm not a user experience (UX) designer. No UX designer worked on FairScan, and I believe that's the case for most open source apps.

So I designed FairScan's UI myself and I make it evolve. Being aware of my limits, I tried to learn. I read Steve Krug's book, Don't Make Me Think, and it helped a lot when non-technical testers started using FairScan. Google required me to have 12 testers try the app before I could publish it on the Play Store. They were not next to me and had to figure out the app on their own. That was a revealing moment: several of them did not understand the basic workflow of the app. I had to rethink the UI and change significant parts of it. Once I did that, it became much easier for testers to understand how they could use the app. Now that some users tell me they appreciate "how easy it is to use", I'm convinced it was worth the effort.

Making the UI usable for everyone is a big step, but it still leaves open a deeper question: what should the app actually do?

It takes a product strategy to define where the app should go

The UI is crucial to expose the app's features, but which features? And among those features, which ones actually matter? Among all the things that could be improved in the app, what should development focus on? Those are exactly the questions that a product strategy tries to address. In a product development team, that's the job of product managers, who are maybe as rare in open source projects as UX designers. I knew almost nothing about product management before I joined a "product-first" company. There, the CEO had no problem saying "no" to customer requests. At first, that was a bit of a shock to me. Over time, I realized that a product is the result of choices, and avoiding choices makes the project lose direction. The product vision, and the strategy derived from it, help make conscious decisions, and that's what turns an app into an intentional system rather than a loose collection of features added whenever someone happened to request them.

All of that stayed with me, and it shaped how I approached FairScan from day one. What I wanted to achieve was already fairly clear early in the project: the "simple and respectful" approach that I described in my first blog post. And shortly after that came the first requests from users. It's open source, so they're not customers, but just like customers, users ask for specific new features. And as the developer, it's uncomfortable to push back: if I want to have users, shouldn't I say "yes"? The problem is that each new feature has a cost, not only technical (implementation and maintenance) but also functional because it becomes harder to keep the app consistent. More importantly, the requested features don't always align with the long-term vision.

The typical example for FairScan is that some users want to manually adjust the detected document edges. In my view, improving the precision of the automatic document detection is the alternative that's aligned with what I want FairScan to be. The product strategy helps make such decisions. It clarifies priorities based on long-term user value, not on what looks like the easy short-term path. It's what makes it possible to invest in hard but impactful improvements. It provides a direction, and without a direction, an open source project can drift very quickly.

A clear vision helps keep the app on track, but turning that vision into something that works in practice is another story.

It takes time and effort, a lot

I doubt it's possible to come up with an app that "just works" for everyone without putting a lot of effort into polishing every aspect of it. The UI is definitely part of that, but user experience goes far beyond the interface. For FairScan, I already spent a lot of time improving how the app behaves when multiple documents are in the frame, or when a document missing a corner seems to have 5 edges instead of 4. Because I want FairScan to rely on automation to make things easy for users, I know it's a neverending story, and I'm fine with it.

And beyond that, like any other app, there are countless details that don't show up immediately but still matter: how the app behaves in unexpected error cases, how it deals with different Android versions, how persistent state transitions when upgrading the app… Those are the things that make the difference between an app that works and an app that is truly reliable. All of that takes time and dedication. And it's not always fun. A developer who is paid to work on an app understands that it's part of the job. But it's not quite the same thing to work on similar tasks for an open source project in your free time. Users don't explicitely ask for any of it so there's no immediate reward. But attention to these details can bring more users over time, and that's a kind of long-term reward.

All these aspects add up. And building an open-source app for a broad audience is definitely challenging. It requires great care for user experience, a solid product vision and a lot of hidden work that nobody asks for directly. But that's also what makes it meaningful. I know FairScan won’t fit everyone’s tastes, but my hope is that anyone can use it. And maybe one day, through FairScan, some people will realize that open-source exists. And maybe they'll raise their expectations about how respectful the software they use daily should be. That would be my biggest success.