Naiz Fit: configurable testing campaigns
A clothing brand fights against a cruel statistic: every sizing mistake is a return, a discount, or a garment that goes unsold. Naiz Fit sold those companies sizing campaigns with test users: real people trying on the clothes before they were produced at scale.
The vision was that testing could be done even at home, without supervision. The testing logic was highly refined —and not simple—, so a system was needed that could gather information from testers without friction. That system was the Survey App.
The constraints
Two factors shaped every decision:
- Truly offline: some testing sessions took place in locations without internet. The app had to work locally and sync later.
- A single developer: me. No team to maintain two native applications.
Kotlin Multiplatform
With those two cards on the table, the choice made itself: Kotlin Multiplatform with Compose Multiplatform. A single codebase —logic and UI— delivering iOS and Android.
The survey engine
The heart of the app is a survey engine defined with the Kotlin type system:
- Typed questions: text, number, date, photos, options.
- Per-question validations and custom error messages.
- Branching: the navigation graph is serializable data. If you pick one thing, the survey goes down one path; if another, down a different one.
Each campaign is provisioned as a single JSON: the tester scans a QR code, the app downloads the survey and the builder rebuilds questions, flow, and validations. Answers are stored on the device and synced when the network returns —Firebase Realtime Database with local persistence for the data and Storage for the photos, with its upload queue—.
Continuous delivery
I set up automatic delivery to testers with GitHub Actions: each release built the Android app and distributed it to testers via Firebase App Distribution; the iOS one went out through Xcode Cloud to TestFlight. With a single person on the project, automatic delivery was not a luxury: it was the only way to iterate fast.
The challenge
About eight months to learn Kotlin and Kotlin Multiplatform and deliver a working prototype. I wasn't starting from zero with dynamic surveys —I had already built similar systems at LIN3S and in my application Formidable—, but this was the most advanced implementation I have done for a use case like this.
Conclusions
Some software systems depend on the delivery of structured information. Naiz Fit used it for sizing testing, but the same pattern —define a schema, provision it, collect answers, and sync them— works for voluntary reporting of information by users or employees, for gathering data to train AI models, for advanced logistics systems, or for complex governance systems.
More real-world cases
Flowgraph: a flow engine built spec-driven
CERNphone: telephony for more than 5,000 users
Classifying documents into 77 categories without training a model
From standard to graph to project
Setting up a homelab from scratch: backups and restore - Homelab (06/06)
