The problem and its origin
The idea for Spooki was not born in front of a whiteboard but in high school, during evenings with friends. Every time, the same dead time came back: we looked for something to watch, we opened three catalogs, we read synopses, and the urge faded before the opening credits even rolled. Above all, the question we were really asking was never the one the platforms answered. We did not just want to know which horror film to watch, but which one is truly scary, and what type of fear it triggers. That nuance changes everything. A rating out of ten does not tell you whether a film is scary, or how. That is what Spooki had to be able to say.
The intuition sharpened on the subway, then turned into a mental specification well before the first line of code. At that time, my technical background was thin: some JavaScript picked up on Discord bots and automation scripts, and some HTML. A complete mobile application, with a backend, a database and distribution on the stores, clearly seemed out of reach. I tackled it precisely because it was hard. It was neither a school project nor a commission, but a field I chose for its ability to make me progress.
There was no method. I learned the technical side as I went, whenever I needed it. The interface always mattered to me as much as scrolling smoothness or rendering quality.
The bet and the community
The initial vision went beyond the app alone. I imagined a pairing between a discovery tool and a Cine-Club, a community of horror fans who recommend films to each other. The community angle was not a late addition, it structured the project from the start: value did not come only from an algorithm, but also from people who share the same taste and trust each other to flag what is truly scary.
To fund both the development and the Cine-Club, I launched a Ulule campaign, closed on December 11, 2023. The result: 474 euros collected against a goal of 3,000 euros, for 23 contributions. So the campaign was not funded and no money was received. The screens shown to contributors matched the React Native MVP of the time, which made the promise concrete, without being enough to convince at the intended scale.
My response to that failure defined the rest of the project: build and ship Spooki anyway, alone and self-funded, all the way to publication on both stores. This resource constraint imposed sober choices and few paid dependencies, a discipline that lastingly shaped the architecture. The community angle did not disappear: it survived in the product in the form of recommendation through a fright score fed by the community.
The React Native to Flutter pivot
I started in React Native, a natural choice for a JavaScript profile, and quickly had a first working MVP. It served to validate the concept: the discovery flow held up, and the problem deserved a real app.
I am a perfectionist, and I want an app that feels as smooth as a native one. I notice micro-stutters, transitions that catch, lists that do not scroll perfectly, and those details are what make people keep an app or delete it. On Android, in real use, scrolling and animations were not up to that level. Between iOS and Android, it was night and day. I probably lacked the experience to optimize properly, but getting a smooth result on Android with React Native remained very hard.
So I made a decision that was costly in the short term and profitable in the long term: rewrite the entire frontend in Flutter, whose engine draws the interface itself, which offers pixel-level control and homogeneity between iOS and Android. The trade-off was explicit: accept a real learning curve and the loss of the existing MVP, in exchange for a much higher quality ceiling and a single codebase, maintainable by a single person. At the same period, I adopted TypeScript on the backend, to carry the same demand for rigor from the client all the way to the server.
The full-stack architecture
The entire chain is held by a single person, from the mobile client to the infrastructure. The frontend is written in Flutter and Dart. The backend relies on Node.js, TypeScript and Express, with Prisma as the ORM on top of a MySQL database.
On the infrastructure side, the service runs under Docker to guarantee reproducibility across environments, Nginx plays the role of reverse proxy, and Cloudflare sits in front. The application also integrates many external APIs, which required particular care over the resilience of the calls and the consistency of aggregated data. The whole thing deliberately stays classic and manageable by a single person, which is here an engineering goal and not an admission of simplicity.
Industrialization and continuous delivery
Delivery is automated, which is rarely the case on a personal project and is nonetheless a speed multiplier. GitHub Actions automatically publishes internal betas to TestFlight for iOS and to the Play Store for Android. Concretely, a validated change triggers a distribution to testers without manual intervention, which removes a classic source of errors and slowness, and allows testing a fix on a real device right away.
Beyond the deployment mechanics, I kept a professional Git organization, even working alone. I use GitHub issues to track the work and pull requests to integrate changes, whereas a simple push to the main branch would have been enough. This choice is deliberate: it imposes traceability, forces me to state the intent of each change and creates a readable history that I can reread, which is precious when picking up a project after a break.
This discipline deliberately reproduces the conditions of a team, so that moving to a collaborative context requires no change of habit. It is concrete proof of the way I work, more than of the product itself.
Product instrumentation and measurement
I instrumented Spooki end to end and built myself a homemade analytics dashboard, named SPOOKI Analytics V4, on Grafana. It is fed by my own backend metrics, exposed from Node.js and MySQL, with observability provided by Prometheus and Loki. The goal was not to collect curves, but to be able to answer precise questions about the product: who uses it, how, and whether the core feature really answers the original need. I thus measure acquisition (sign-ups per day and cumulative), engagement, retention, the breakdown by platform, by language and by app version, and above all fear intensity preferences.
As of September 2026, the dashboard shows 1,397 users, 107,075 swipes, 4,639 films watched, 3,026 ratings and 19,898 active films in the catalog. Sign-ups are accelerating: about thirty a month in late 2025, 123 in July 2026 and 130 in August. The audience is French-speaking and international, mostly in France, but also in Ivory Coast, Cameroon, Canada, Gabon, Congo, the United States and the United Kingdom.
The most interesting point closes the loop opened in high school: the distribution of preferences shows that about 57% of users seek the highest fear intensity. So the data validates the need that founded the project. I want to be honest about the scope of all this: the value I claim is not the size of the audience, still modest, but the ability to measure and the data-driven culture that flows from it. The product is young and run solo, I do not oversell the traction and I do not highlight fragile metrics.
The engineering challenges
The first challenge was learning Flutter. It took me several months to feel comfortable: the way you build an interface has nothing to do with what I knew from JavaScript.
Authentication was another significant piece. I had never implemented any, and it was a real backend learning experience, with its questions of security, session management and edge cases. In the same vein, designing a solid and scalable database schema required thinking beyond the immediate need, so as not to find myself blocked by my own choices a few months later. Robustness and stability were a permanent guiding thread: handling error cases everywhere, and at the same time thinking of users, administrators, future scalability and the various frontend states.
What makes the exercise sustainable is that I take as much pleasure in the backend as in the frontend. What motivates me is not a particular layer but the result: search, understand, then accomplish. This motivation is what lets you go the distance when you have to, alone, think of everything at once.
Result and proof
Spooki was designed and shipped solo, from prototype to publication on both stores. That is the point I hold onto first, because it sums up the nature of the project: seeing through, alone, a complete chain that goes from the idea to the installed mobile client. The app shows a rating of 5.0 on the App Store, over 10 reviews, and I deliberately state the volume so as not to suggest a representativeness it does not have.
As of September 2026, the backend counts 1,397 users, a figure read from my own dashboard. The trademark is registered with the INPI and the activity runs through a sole proprietorship. Spooki was also featured on Télématin, on France 2, in 2024.
What this project shows, more than its numbers, is that I can design, ship and maintain an app in production on my own, even without funding.