Building Marine Schedule — Issue Tracking and Real-Time Approvals
Defining the Core Flow
Before writing code, I spent time with domain experts mapping the actual workflow.
The biggest bottleneck in ship repair projects: issue report → review → approval. Something gets discovered on-site, a report is filed, the relevant parties review it, and someone signs off before work continues. When this happens over email and phone calls, it's slow and leaves no clear trail.
Three features to solve this:
- Issue reports with photo and video attachments
- Real-time push notifications on issue creation and status changes
- Structured approval workflow, configurable per project
Issue Report Implementation
Reports are written on-site. Mobile-first wasn't a preference — it was a requirement.
The workflow needed to be: open app → take photo → attach → submit, with as few taps as possible. It also needed to work when network connectivity was poor — ship repair happens on vessels in dry dock, not always near reliable WiFi.
I implemented offline support: reports drafted without a connection are stored locally and uploaded automatically when connectivity returns. Partial writes are safe — an interrupted upload doesn't lose data.
For photo uploads, sending full-resolution images through the server was too slow. I used presigned S3 URLs: the server generates a short-lived upload URL, the client uploads directly to S3, and the server only processes the metadata. Fast and cost-efficient.
Configurable Approval Workflows
Approval steps vary by project. Some need two sign-offs; others need four.
Hardcoding approval stages would make the app inflexible. I made the workflow configurable: project administrators define the stages and assign a responsible person to each. When one stage is approved, the next assignee is automatically notified.
Push notifications use Firebase Cloud Messaging (FCM). Speed matters — an approval request sitting unread for hours means the project is blocked for hours.
Multilingual Support
Ship repair is international.
It's not unusual for the shipowner to be Greek, the shipyard to be Korean, and the classification inspector to be Norwegian. At minimum, Korean and English needed to work.
The app UI is fully localized. Issue reports are stored in whatever language they were written in — no translation required, since the people reading them usually speak the same language as the person who wrote them. The interface adapts to each user's language preference independently.
Testing Challenges
B2B apps in specialized domains are hard to test realistically.
I couldn't simulate a real ship repair project in a staging environment. Meaningful testing required feedback from people who had actually done this work. I made regular check-ins with domain experts a core part of the process — "does this screen reflect how this actually works?" came up constantly, and the answer was often "not quite."
Developer logic and field logic diverge more than expected. The only way to close that gap is to keep asking.