Source code (GitHub) → Download APK ↓
Starting point
A beauty salon needed a simple tool to keep a client database and remind people about their appointments. Until then, appointments were tracked by hand and reminders — if sent at all — went out manually. Easy to slip up, and easy to lose a client to a no-show who simply forgot.
Goal
A lightweight phone app that does one thing well:
- client database: name, phone, e-mail,
- appointment scheduling: client, date, time,
- automatic e-mail reminder one hour before the appointment.
Solution
I built a native Android app (Kotlin), deliberately minimal — so it's reliable and free to run.
1. Data stored locally in SQLite
Clients and appointments are kept locally in SQLite (a repository layer over
SQLiteOpenHelper). No cloud, no subscription — the data stays on the
device, which simplifies GDPR and zeroes out fixed costs.
2. Background reminders (WorkManager)
Each appointment schedules a WorkManager job that fires one hour before the time. Jobs survive a phone reboot and run even when the app is closed. I also added a "send now" action to demonstrate the mechanism without waiting an hour.
3. E-mail delivery over SMTP
Notifications go out by e-mail (SMTP, JavaMail) — a free, dependable channel for a
salon's client base. The sending account is entered on a settings screen,
with no credentials hard-coded. The message body is configurable,
with {imie}, {data}, {godzina}
placeholders.
4. SMS hook left in the code
I left a prepared spot in the code for future SMS delivery through a gateway (with instructions), so extending it is a matter of plugging in a paid account rather than rebuilding the app.
Result
The client received a ready-to-install APK, a short guide, and the source code. The app keeps a client database and sends reminders on its own, one hour before each appointment — no server, no subscription, on a single phone. Tested on a set of contacts, with reminder delivery confirmed.
Takeaways
For most salons an off-the-shelf booking system is the sensible choice — and that's usually what I'd recommend. This brief was different: a small, self-contained app doing one specific thing, with the full source in the client's hands. The value isn't scale — it's clean execution: local data, reliable background jobs, and no secrets in the code.