For operations
Understand what needs attention, who owns the next action, and which site or asset the work belongs to.
Selected workCASE / GRIDLOCK
Gridlock · ERP & facilities management
One operation.
Connected
by design.
Gridlock brings sites, assets, work orders, documents, inventory, and commercial records into a connected platform for industrial operations. I lead the product definition and engineering, translating day-to-day operating requirements into software.
01 — The operating problem
A site is more than
a row in a register.
A single site can have assets, inspection records, planned maintenance, open work, quotations, contracts, and invoices. When those live in separate tools, someone has to reconstruct the relationship each time a decision is needed.
For commercial teams
Follow the quotation, contract, procurement, and financial records related to the work.
For administrators
Maintain access, shared configuration, approval rules, and document settings as the operation changes.
02 — Product walkthrough
Follow the work
through its records.
This representative workflow explains how the product is being organized. It connects the engineering scope to the task an employee needs to complete.
CONNECTED WORKFLOWRepresentative journey
Start with the site
Open the site and its assets. Review the related service, documents, and operational context.
Define the work
Create or review the work order, its scope, responsible team, checklists, and required materials.
Record the decision
Follow the configured approval or action path. Keep supporting documents and the record’s history close to the decision.
Trace the outcome
Review the resulting work status and its related inventory, commercial, or financial records where applicable.
Workflow illustration, not a production demonstration. Current work is focused on completing and validating connected user journeys for the pilot.
My contribution
I define the record structures and user journeys, develop the application and its integration boundaries, and review how the screens support actual operating tasks. Requirements come from working across projects, operations, maintenance, IT, and supporting business functions.
03 — Configuration
Operational choices.
Explicit configuration.
Configuration focuses on the policies that vary between operations. The aim is to give those choices a clear administrative home and a visible effect on the relevant workflow.
Approvals & workflow
Lifecycle definitions, approval steps, conditions, and the authorized actions available at each stage.
Numbering & documents
Record numbering, document templates, branding, and controlled outputs linked back to the originating record.
Access & visibility
Roles and permissions that determine which records a person can view and which operations they can perform.
Notifications
Rules for communicating changes and directing the next action to the people responsible.
Work planning
Maintenance schedules, assignment rules, and the information needed to coordinate recurring work.
History & relationships
Related-record navigation and a timeline that helps explain what happened to a record over time.
04 — Engineering approach
One platform.
Clear responsibilities.
The platform brings multiple business domains into a single application while keeping their responsibilities explicit. A shared application is practical for the operating environment; defined module boundaries help keep changes understandable.
REQUEST PATHModular application
- Blazor interfaceA task, form, record, or authorized action.
- Application handlerValidation, permissions, and the requested operation.
- Domain & persistenceBusiness records, rules, EF Core, and MySQL.
- Related workModule contracts and events connect the resulting changes.
Why this structure
Keep the page focused. An interface should express the user’s task while application logic handles the operation behind it.
Connect domains deliberately. Shared contracts make relationships explicit and reduce reliance on another module’s internals.
Make changes inspectable. Permissions, state changes, record history, and related documents belong in the review of a workflow.
05 — Product scope
The record families
behind the operation.
The development scope spans facilities, enterprise administration, and gas-utility work. Each family needs a usable register, record details, editing, related records, and the actions appropriate to its lifecycle.
| Area | Connected records and tasks |
|---|---|
| Facilities & work | Sites, buildings, assets, inspections, planned maintenance, work orders, and checklists. |
| Commercial & finance | Quotations, contracts, suppliers, procurement, invoices, receivables, and payments. |
| Utility operations | Metering, delivery planning, fleet activity, and the site context behind gas services. |
| Shared administration | People, access, workflow configuration, documents, notifications, reports, and support. |
| External access | Customer and supplier journeys with access appropriate to their authorized records and tasks. |
06 — Validation & next stage
Prepare the whole journey
for a pilot.
The review work focuses on discoverable registers, complete record forms, authorized actions, connected history, and clear loading and error behavior. Those are the details that make a broad platform usable.
Capability review
Map product requirements to application owners and visible user journeys. Distinguish existing capabilities from work that is still incomplete.
Workflow checks
Follow representative records through creation, changes, approvals, and related records, including permission and failure paths.
Pilot preparation
Review the installer, environment setup, sample data, and the first tasks that staff need to complete independently.
Status as of 2 October 2026: in development, with pilot preparation underway. This case study describes the product and engineering approach; it does not claim production adoption or measured business outcomes.