Skip to content
Om Salunkhe
Three systems, three stacksFull-stack · Java · Python · Android

Full-Stack Management Systems

A banking REST API in Spring Boot, a gym operations platform in Flask, and a college app paired with an admin app on a shared Firebase backend.

Role
Sole developer
Year
2025
Stack
  • Java 21
  • Spring Boot
  • Spring Data JPA
  • MySQL
  • Lombok
  • Python
  • Flask
  • SQLAlchemy
  • Flask-Login
  • APScheduler
  • SQLite
  • Android
  • Firebase

01The problem

Each of these is an operations problem: keeping records consistent, enforcing rules on money and membership, and getting the right information to the right person — whether that's a bank teller, a gym administrator, or a student checking today's notices.

Banking API

Spring Boot · Java 21

  1. REST client

    /api/accounts

  2. AccountController

    create · get · list · deposit · withdraw · delete

  3. AccountService

    Business rules, e.g. reject overdrafts

  4. AccountRepository

    Spring Data JPA

  5. MySQL

    accounts table

Gym platform

Flask · SQLAlchemy

  1. Browser

    Server-rendered Jinja templates

  2. Flask routes

    @login_required, staff & admin users

  3. SQLAlchemy models

    Members, classes, payments, attendance, reminders

  4. SQLite

    gym.db

APScheduler · daily 09:00

Surfaces due fee reminders, rolls paid ones forward

College apps

Android · Firebase

  1. Admin app

    Publishes notices & categorised gallery images

  2. Firebase

    Realtime Database + Storage + Auth

  3. Student app

    Notices, faculty by department, e-books, gallery

fig.Three architectures: layered REST API, server-rendered app with scheduled jobs, and two mobile clients on a shared backend.

02What I built

  • Banking — a layered Spring Boot REST API (controller → service → repository) over MySQL with JPA, exposing create, read, list, deposit, withdraw, and delete for accounts.
  • Gym — a Flask application with login and staff/admin roles, members, fitness classes and registrations, payments, attendance devices and check-ins, and automated fee reminders.
  • College — two Android apps in Java: an admin app that publishes notices and categorised gallery images, and a student app that reads them alongside faculty by department, e-books (PDFs), and Firebase Authentication.

03Key decisions

  1. D1

    DTOs and a mapper at the API boundary (banking)

    The API exchanges AccountDto objects rather than JPA entities, keeping persistence details out of the contract. Withdrawals are rejected when the balance is insufficient.

  2. D2

    Business rules as data events (gym)

    An SQLAlchemy after_insert listener creates a member's first fee reminder 30 days after joining, priced by membership tier. A daily APScheduler job at 9 AM surfaces due reminders and rolls paid ones forward.

  3. D3

    One backend, two apps (college)

    Splitting publishing (admin app) from reading (student app) keeps write access out of the student client. Both use Firebase Realtime Database and Storage, so new notices appear without a custom server.

  4. D4

    Passwords are hashed, routes are guarded (gym)

    Werkzeug password hashing and Flask-Login's login_required protect every management route.

Want to talk through how this was built?

Next case studySolarPay