M.AMIIN

CASE STUDY · PROJECT 01 / AVIATION SOFTWARE

Airport Operations Management System.

A web platform for the control tower that replaces paper logbooks and movement registers with one accountable, real-time record of tower operations.

Development complete for current scope.

ROLE
Product design & full-stack development
STACK
Next.js · TypeScript · Supabase
Demo screenshot pending · Tower dashboard
Tower dashboard — today’s arrivals and departures, aircraft on ground, recent movements and predicted inbound traffic in one view. Demonstration environment, synthetic data.

Paper records, scattered context.

Manual registers

Tower workflows are traditionally handled through paper logbooks and disconnected records.

Scattered information

Traffic movements and operational updates are often spread across separate manual records.

Accountability

On a shared tower position, it must always be clear which controller made each entry and each correction.

One record of the tower’s day.

AOMS brings the records a tower keeps by hand — arrivals, departures, the logbook, aircraft on the ground — into a single authenticated web application, designed from the controller’s position: quick entry during busy traffic, clear attribution of every entry, and no record that can quietly disappear.

OPERATIONAL CONTEXTThe design draws on my own professional experience in tower operations, including my on-the-job tower training at Hargeisa (HCMH). This reflects my experience only; it is not a claim of official adoption or deployment by any airport.

01

Database-enforced rules

Strip numbers are allocated inside PostgreSQL, records are archived rather than deleted, and audit history cannot be rewritten.

02

Accountable by design

Controllers confirm their identity with their initials and a PIN, so every movement, correction and log entry is attributed to the controller who made it.

03

Live across screens

Registers, the logbook and operational boards update in real time, so every position works from the same picture.

Inside the interface.

  1. Demo screenshot pending
    01 / WORKFLOW

    Arrival register

    Each arrival is recorded with its callsign, registration, route and actual time of arrival in Zulu, and receives a strip reference from the database. The entry form also captures the active runway, remaining endurance and people on board.

  2. Demo screenshot pending
    02 / WORKFLOW

    Departure register

    A departure can be prefilled from an aircraft already on the ground, including night stops, or recorded manually. The register filters by status, flight rules, destination and date range, and searches by callsign, registration or strip number.

  3. Demo screenshot pending
    03 / WORKFLOW

    Traffic statistics

    Totals of movements, arrivals, departures and people on board for a chosen period, with daily movements split into arrivals and departures and a breakdown by operator.

All screenshots are taken from a demonstration environment containing only synthetic flight and movement data. They are not live airport records.

Controller-focused features.

01Movement registers

  • Arrival and departure registers with search and filters
  • Automatic, database-allocated traffic strip numbers
  • Time-limited editing with administrator override
  • Auditable corrections, recorded in the tower logbook
  • Departures created directly from aircraft on ground

02Tower logbook

  • Digital tower logbook with operational activity types
  • Movements logged automatically
  • Controller duty roster with initials and attestation
  • Operational-day rollover in the airport’s locked time zone

03Traffic picture

  • Live tower board
  • Aircraft-on-ground board with endurance tracking and night stops
  • Dashboard with expected arrivals predicted from recurring weekday traffic

04Runway & station

  • Active runway control with confirmation
  • Configurable runway and airport settings
  • Station opening time and secure tower station password rotation

05Reports & data

  • Reports and statistics, with arriving and departing POB
  • Operational reports linked to the tower logbook
  • Traffic import and developer-only historical movement import

06Access & security

  • Administrator, controller and restricted demo controller roles
  • Staff administration with database-wide account deactivation
  • Token-based guest presentation access
  • Row-level security, hardened privileges and operational notifications

Rules live in the database.

  1. CLIENT

    Browser interface

    Next.js App Router renders pages on the server; interactive workspaces run in the browser. Responsive, with dark and daylight themes.

    • Next.js
    • React 19
    • TypeScript
    • Tailwind CSS
    • shadcn/ui
  2. APPLICATION

    Server actions & session proxy

    Input validation, role capability checks and session-aware routing sit on the server boundary.

    • Server actions
    • Zod
    • React Hook Form
  3. DATA

    Supabase

    Authentication, PostgreSQL with row-level security, database functions for strip allocation and attribution, and realtime updates.

    • Auth
    • PostgreSQL
    • RLS
    • RPC functions
    • Realtime
  4. PLATFORM

    Vercel

    Separate development, UAT and production environments, plus a scheduled server job.

    • Vercel
    • Cron
80
versioned SQL migrations
92
automated test files
v1.0.0
tagged release, with a rehearsed upgrade and rollback runbook

Engineering record taken from the project repository, October 2026.

Hard problems, solved carefully.

  1. 01

    Strip numbers that never collide

    Numbers are allocated by a database function with monthly uniqueness, and historical imports share the same numbering, so two entries can never receive the same strip.

  2. 02

    Attribution on a shared position

    The tower station login is shared, so each controller verifies with initials and a PIN. Attribution was moved to verified sessions in stages, with each migration rehearsed first.

  3. 03

    The operational day

    A tower day does not follow the browser’s clock. The airport time zone is locked, and an operational-day rollover replaced an earlier automatic station closure.

  4. 04

    Changing a live database safely

    Ordered migrations across separate environments, verification scripts, and a release runbook with rehearsed rollback and re-entry paths.

Development complete for current scope.

Case study of the software as built — not a claim of airport deployment or adoption