Requirements
Requirements
- Role-based access across six organisational roles.
- A defined maintenance workflow with priority-based approval categories.
- Relational modelling for organisations, users, jobs, quotes and approvals.
- Audit logging, soft deletion and restoration.
- Responsive dashboards and reporting per role.
- Strong accessibility across every role-specific view.
Research
Research & planning
- Modelled the job lifecycle as an explicit workflow before writing any endpoints, including the three priority-based approval categories the workflow actually needed.
- Iteratively tested and remediated the interface against Lighthouse accessibility scoring across role-specific accounts.
Solution
The solution
OpFix models organisations, users, maintenance jobs, quotes, approvals, attachments and audit history as first-class relational entities. Six organisational roles, including regional manager, store manager, engineer, accounts and system admin, are enforced through role-based access control and access-level administration.
Maintenance requests are categorised by urgency into immediate (three-hour), 48-hour and one-week approval-based workflows, each with its own dashboard and reporting view per role. That's a tradeoff choosing explicit named tiers over a generic priority field, so the workflow logic matches how urgency is actually communicated in a maintenance operation.
Every significant action (creation, approval, deletion, restoration) writes to an audit log. Soft deletion with restoration means nothing is destroyed by mistake, even by an admin.
I evaluated the platform across every role-specific account and iteratively remediated accessibility issues, reaching a self-assessed Lighthouse accessibility score of approximately 97–99.
Architecture
System architecture
A FastAPI backend over PostgreSQL (hosted on Supabase), consumed by a React + Vite single-page application. Role-based access control is enforced server-side on every protected route, resolving each of the six organisational roles to its permitted actions.
As this project is being prepared for commercialisation, internal implementation details (data models, business rules, authentication internals) are intentionally not published here. The diagram below reflects the shape of the system, not the proprietary implementation.
Data
Database design
Because commercialisation is planned, the schema below is deliberately high-level. It shows the entity relationships already described above (organisations, users, roles, jobs, approvals, audit history), not the actual field-level design, permission rules or migration history.
Every entity carries a soft-delete flag rather than being hard-deletable, and role is a first-class relation rather than a string on the user record, which is what makes the six-role access model centrally enforceable instead of scattered across route handlers.
Features
Key features
Six organisational roles
Including regional manager, store manager, engineer, accounts and system admin, each with distinct permissions.
Priority-based approval workflow
Immediate (three-hour), 48-hour and one-week maintenance categories, each with its own approval path.
Relational job lifecycle
Organisations, users, jobs, quotes, approvals, attachments and audit history modelled as first-class entities.
Audit logging & soft delete
Every significant action is logged; deletions are soft and restorable.
Role-specific dashboards & reporting
Responsive dashboards tailored to what each of the six roles needs to see.
Accessibility-driven development
Iteratively tested and remediated across role accounts to a self-assessed ~97–99 Lighthouse accessibility score.
Engineering
Engineering decisions
Explicit approval categories
Three named urgency tiers (3-hour / 48-hour / 1-week) rather than a single generic priority field, matching how urgency is actually triaged.
Access-level administration
Permissions are administered per role rather than hard-coded per page, keeping access control centralised and auditable.
Soft delete as a first-class pattern
Deletion and restoration are both explicit, logged operations. Nothing disappears silently.
Solo scope management
Built independently within a fixed final-year timeline: a deliberate tradeoff scoping six roles and a full workflow deeply, rather than more roles shallowly.
Managed backend over self-hosted
Supabase-managed PostgreSQL over a self-hosted database: a tradeoff trading some infrastructure control for the deployment and backup velocity a solo developer needs under a deadline.
Interface
Screenshots
Reflection
Lessons learned
Designing the approval workflow around real urgency tiers, rather than a generic status field, made the whole system easier to reason about.
Accessibility work compounds: testing role-by-role surfaced issues a single-account pass would have missed entirely.
Scoping deeply on fewer things beats spreading thin when building solo under a deadline.
What's next
Future roadmap
- Commercial development is planned; further roadmap details will follow as that work progresses.