Facix
An activity booking app for French associations, taken to a beta with pilot associations: Flutter, in-app payments and a serverless AWS backend.
Associations run sports and cultural activities but take bookings through forms, phone calls and cash at the door. Facix gave them one place to publish an activity, and gave the public one place to find it, pick a date, register every participant and pay, on mobile and on the web. That meant handling money on behalf of organisations that had never taken a payment online.
- Built alongside our studies, with a mobile team of two to three developers
- Card payments inside a Flutter app, where Stripe support was a community plugin rather than an official SDK
- Several participants per booking, each with their own details
- Running costs had to stay near zero before there was any revenue
Serverless on AWS from the start
Lambda, Cognito, DynamoDB and S3 meant no server to patch and a bill that followed usage, which for a startup with no revenue was close to nothing. DynamoDB also pushed us to design around how the data would be read, by activity, by user and by date, before writing the screens.
Keep payment in the app, even with a weak plugin
Sending people to a web checkout would have been easier to build and worse to use, at the one step where hesitation costs a booking. We kept payment native with flutter_stripe and worked around its gaps rather than leave the app.
Design every state before building it
The Figma file covers each flow in all its states: no account, no saved card, an existing card, success and error. Agreeing on them up front let a small team build screens in parallel without rediscovering the edge cases one by one.
The app worked; the market did not. Associations were not ready to pay for a service, and we spent our time polishing the product instead of testing that assumption. I would put a paid pilot in front of a handful of associations before writing a single payment screen.