Swikko

In first year, class information ended up all over the place. A room change posted in a group chat, homework only one person had written down, an announcement buried under a pile of messages. On top of that, everyone was looking for an apprenticeship on their own.

We wanted something light that students would actually feel like opening in the morning.

The whole app rests on one idea: self-sufficiency (in French, “autosuffisance”). The community organizes itself and fills in the content itself, with no administrator going behind everyone.

In practice, students approved with a class code add and correct lessons and homework themselves. The class rep doesn’t check everything: they decide who joins the class and post the official announcements.

To make that hold, the API does the policing. Everyone only gets to see what they’re allowed to, and one class’s data never mixes with another’s.

Opening the app takes you straight to the home screen⁰⁸: the next class, homework due and the latest announcements. The first time, a five-page introduction⁰³ explains how it works and asks whether you already have a company, which adapts the app.

• a timetable by day¹¹ and by week¹², filled in and corrected by the class;
• an agenda¹³ that separates school from the company, handy when you’re an apprentice;
• study groups¹⁶ with live chat, shared tasks and time slots when everyone is free;
• an apprenticeship search¹⁵ with favourites and saved searches, available even without a class.

Exams, notifications and group work arrived over successive versions. Each update has its own “What’s new¹⁰” screen, so nobody misses what changed.

Apart from my apprenticeship, this is the project that taught me the most, especially on the Flutter side. The app has sixteen features, from sign-in to exams, and I had to work out how to keep them readable version after version.

• each feature has its own folder, with its screens, its state and its data access;
• data access comes in two versions: a real call to the API, and a demo version with made-up data. The app therefore runs without a server, which was used for the tests, the presentations and the screenshots on this page;
• one codebase for iPhone, Android and the web, with a side menu and a two-column week when the screen is wide;
• live group chats, and reminders scheduled on the phone;
• a dark⁰⁹ theme on top of the light one, reworked so each colour keeps its meaning.

109 Flutter tests replay the journeys with the demo data: sign-in, timetable, groups, introduction. They run on every change.

On the other side, an ASP.NET Core API with PostgreSQL behind it. It’s the same stack I use in my apprenticeship, and I wanted to build it end to end myself. The API is split into four layers (Api, Application, Domain, Infrastructure).

Sign-in uses JWTs with refresh tokens. There are two roles (student and class rep), plus an organizer role inside study groups. Sensitive data is encrypted, and the 106 API tests run against a real PostgreSQL database thanks to Testcontainers.

Being able to hand a working version of the app to anyone for the testing phase took more effort than expected. Luckily I wrote a script that automates installing the app, from my machine, onto any smartphone: that need is covered.

Then the API had to leave my Mac. It now runs on a personal server, in Docker, behind an HTTPS reverse proxy. For performance reasons, the image is built on my own machine before being sent over. And when the project went from StudyFlow to Swikko, everything had to be renamed without losing a single piece of data.

Swikko started as a year-long project at ESGI, with a classmate. On my side: the product, the Flutter app, the design, the timetable, the agenda, the apprenticeships, the Company space, then deployment. My partner took security, meaning sign-in, roles and data protection.

I’ve kept developing it since. It’s the project that taught me to ship without improvising: a version number, notes that say what changed, and tests that run on every change.