←back to projects
Jan 2026/Fullstack/professional

Lapor FSM!

Built as a 0-to-1 emergency operations system for FSM Diponegoro University, this project replaced fragmented manual reporting with one shared incident pipeline for reporters and administrators.

project links
RepositoryrepoReleaseother
Domain
Fullstack
Role
Lead Architect and Product Engineer
Output
Web App
Category
Emergency Response Platform
Project Framing

A source-backed case study built for recruiter review

This reading path makes the problem choice, evidence quality, user framing, execution decisions, and proof trail visible without overstating what the sources support.

Project Type
professional

A real-time emergency reporting platform with dual portals and geospatial coordination for campus incident handling.

Orientation
Hybrid

Improved reporting speed and situational visibility for campus operators and decision-makers during active incidents.

Core Stack
Next.js · ElysiaJS · Bun · PostgreSQL

Next.js frontend with an ElysiaJS backend on Bun runtime, PostgreSQL/PostGIS for geospatial data, and WebSocket channels for low-latency updates.

Why This Problem Mattered

Problem framing before execution

The case-study layer starts with why this problem was selected and how the context justified investment.

Problem Framing Map

Issue

Campus emergency escalation relied on fragmented manual reporting and weak shared visibility.

Context

The project was initiated as a 0-to-1 operational platform for FSM Diponegoro University, where reporters and administrators needed a single live incident pipeline instead of disconnected coordination steps.

Why Selected

The problem was worth solving because it combined clear operational urgency, stakeholder demand, and a concrete handoff gap that software could reduce.

Problem statement

Campus emergency escalation depended on fragmented manual reporting, slowing coordination and reducing response visibility.

Solution thesis

Delivered a dual-portal system (reporter/admin) with real-time incident streams, role-based workflows, and map-assisted coordination.

Research and Evidence

What supports the narrative

Evidence is surfaced with its source type and credibility note so the recruiter can quickly see what is directly backed versus intentionally constrained.

Operational pain point
hybrid

Existing reporting flow was fragmented and slowed coordination during incidents.

Credibility: Supported by the existing project problem statement and documented production narrative.
Delivery scope
local

The first milestone centered on a dual-portal launch for reporters and administrators.

Credibility: Corroborated by the project metrics and proof records in the documented project evidence.

Credibility Notes

  • ●Public wording stays limited to operational workflow and release facts already documented in documented sources.
  • ●No response-time reduction or adoption metric is claimed because the current sources do not quantify those outcomes.
Who The User Was

User framing stays explicit

When formal research artefacts are not available, the page still explains who the work served and why that user framing is justified by the existing sources.

Primary user
Campus reporters who need a fast and structured way to submit emergency incidents.

The solution includes a dedicated reporter portal, making this user role explicit in the source-backed release scope.

Operational stakeholder
Administrative operators who monitor incidents, coordinate follow-up, and maintain shared visibility.

The dual-portal architecture and role-based workflows directly indicate an administrator-facing operational user.

Decision Flow

How design thinking translated into decisions

The goal is to show the trace from research and insight to concrete product or system decisions, then to the outcomes those decisions supported.

Design Thinking Flow

Each step keeps the movement from evidence to action explicit before the rationale expands it.

  1. Step 1
    Problem framing

    Mapped the coordination bottleneck as a workflow problem, not only a form-submission problem.

    Signal: Fragmented manual reporting became the core issue to resolve.
  2. Step 2
    User and workflow definition

    Separated reporter and admin needs to keep submission and operational response flows distinct.

    Signal: Dual-portal release became the first product milestone.
  3. Step 3
    Execution focus

    Prioritized real-time updates, geospatial context, and role-based states over broader feature breadth.

    Signal: WebSocket and PostGIS decisions aligned with situational visibility needs.

Decision Rationale

Each decision keeps the path from insight to execution visible before ending on the outcome signal.

Realtime communication
Insight

Incident visibility loses value when updates lag behind active field conditions.

Decision

Used WebSockets instead of polling for low-latency status propagation.

Outcome

The delivery story emphasizes live incident streams as a core operational feature.

Location-aware operations
Insight

Emergency handling requires more than text reports when response context depends on place.

Decision

Used PostGIS to support geospatial incident handling.

Outcome

Mapping and location-aware coordination became part of the v1 system baseline.

Solution and System Execution

Execution choices and delivery details

This section preserves the technical and operational substance: architecture, responsibilities, trade-offs, and implementation quality signals.

System Design

Next.js frontend with an ElysiaJS backend on Bun runtime, PostgreSQL/PostGIS for geospatial data, and WebSocket channels for low-latency updates.

Source-backed Impact

Improved reporting speed and situational visibility for campus operators and decision-makers during active incidents.

Responsibilities

  • ●Owned architecture and product scope from planning to launch
  • ●Defined data model and geospatial query strategy
  • ●Coordinated implementation across frontend, backend, and stakeholder feedback

Stack Decisions

  • ●Chose Bun + ElysiaJS for runtime performance and fast iteration
  • ●Used PostGIS for location-aware incident handling
  • ●Used WebSockets instead of polling to reduce alert latency

Trade-offs

  • ●Accepted newer runtime ecosystem risk (Bun) for performance gains
  • ●Prioritized operational reliability over broad feature breadth in v1

Challenges

  • ●Designing stable real-time flows under quick delivery constraints
  • ●Aligning technical implementation with stakeholder process requirements
Outcomes and Proof

What was delivered and what can be verified

Outcome claims remain conservative and source-backed, while proof records and recruiter-safe links surface the strongest verification trail available.

Validation Signals

  • ●Dual-portal release completed as the first production milestone.
  • ●Architecture and scope stayed aligned with stakeholder process requirements during delivery.

Source-backed Outcomes

  • ●1-month end-to-end delivery cycle
  • ●Dual-portal release in first production milestone
  • ●Real-time incident updates with WebSocket channel architecture
Retrospective and Limits

What the project proves, and what it does not

Strong case studies show both what was learned and where the current evidence stops.

Retrospective

Next iteration should add SLA tracking and auditable incident trails for stronger service governance.

Evidence Limits

  • ●Current sources do not expose formal user-research artefacts, interview counts, or usability-test records.
  • ●Current sources do not quantify post-launch SLA improvement, adoption, or incident-resolution deltas.

Lessons

  • ●Realtime systems require strict event contracts early
  • ●Operational tools need explicit fallback states for incident workflows