WorkOrder Systems

Overview

WorkOrder Systems is an offline-first CMMS designed for maintenance teams that can't rely on stable internet connections.

Technicians can create, update, and complete work orders entirely offline. All data is stored locally, queued, and automatically synchronized once connectivity returns. The system is designed to keep maintenance moving — even on large sites with poor coverage, such as resorts and industrial locations on Curaçao.

The problem

Most CMMS software assumes ideal conditions: stable Wi-Fi, desktop usage, and continuous connectivity.

In reality, maintenance teams deal with:

• unreliable or non-existent internet
• time pressure and physical locations
• fragmented workflows (paper first, software later)
• delayed or inconsistent data entry

This leads to lost information, broken coordination, and higher operational overhead.

Design goals

From the start, WorkOrder Systems was built around a few non-negotiable requirements:

Work must continue offline

Offline is not an edge case — it's the default.

Fast execution under pressure

Logging work, photos, and time must be frictionless.

Security and tenant isolation by design

Multiple organizations must safely share one platform.

Low operational overhead

The system must be realistic to build and maintain as a solo founder.

Every architectural decision traces back to these goals.

Solution

WorkOrder Systems is built as a Progressive Web App backed by PostgreSQL via Supabase.

Offline-first architecture

• All server state is cached and persisted in IndexedDB
• Mutations are queued locally when offline
• A service worker handles caching and background sync
• The UI is optimistic by default — users don't wait on the network
• Conflicts are handled via timestamp-based last-write-wins

The application behaves as if it's always online, even when it isn't.

Key architectural decisions

Supabase as backend

Chosen to reduce infrastructure complexity while retaining strong control over data and security.

• PostgreSQL with Row Level Security
• JWT-based authentication with org context
• Realtime updates scoped per tenant
• Edge Functions for backend logic without server management
• Storage policies tied to tenant ownership

All authorization happens in the database — never in the client.

Multi-tenancy & security

• Strict RLS on every table
• Role-based access control at database level
• Storage buckets isolated per organization
• Frontend bugs cannot cause data leaks

Security is enforced where it belongs: in the data layer.

Performance & scalability

• Indexed queries on core fields (org, status, assignments)
• GIN indexes for JSONB metadata
• Realtime broadcasts limited per organization
• Code-splitting and aggressive caching in the PWA

The system remains responsive even with growing datasets.

Flexible data modeling

Work orders combine:

• structured columns for critical fields
• JSONB metadata for tenant-specific extensions

This keeps queries fast while allowing the product to evolve without constant schema migrations.

Who it's built for

Technicians

• Mobile, field-based work
• Poor connectivity
• Need clarity and speed
• Offline is mandatory

Maintenance managers

• Planning and coordination
• Real-time progress visibility
• SLA and workload monitoring

Facility admins

• Asset management
• Preventive maintenance templates
• Clean historical data per organization

Market context

Curaçao

Maintenance work often happens on large sites with unreliable Wi-Fi. Many teams still rely on paper workflows and delayed data entry.

WorkOrder Systems matches how technicians already work: mobile, fast, offline — without friction.

International

Globally, the shift is toward:

• web-based tools
• BYOD environments
• faster iteration without app stores

PWAs and offline-first architectures are becoming requirements, not experiments.

What this project demonstrates

Although developed during a semester and internship, WorkOrder Systems was built under real constraints:

• unreliable networks
• multi-tenant data isolation
• production-grade security
• long-term maintainability

It shows how I approach system design as a founding engineer:

• start from real-world constraints
• make deliberate trade-offs
• optimize for reliability over novelty