Development: 2023–present In production: July 2025
CORE STACK
Flutter / Dart · Python Azure Functions · Cosmos DB
01 The problem
A great show takes more than what happens in the sky.
Behind every display is a network of people, schedules, locations, equipment, and time records. As a manager and licensed pyrotechnic operator, I worked inside that network. Manual scheduling and disconnected records took time away from coordinating the actual work.
The operational need
Give managers and crews a shared place to coordinate shows and assignments, capture attendance with location context, and review the information needed for reliable operations.
The product started with a workflow I understood firsthand. That made it possible to ask better questions, prioritize useful features, and build with the people who would use it.
02 System architecture
A connected platform. Clear responsibilities.
The system connects Flutter interfaces to Python REST APIs on Azure Functions, with Cosmos DB for operational records and Azure Blob Storage for files. Role-based workflows separate the needs of administrators, operators, and employees.
PyroPunch · system overviewSIMPLIFIED LOGICAL ARCHITECTURE
CLIENT EXPERIENCEFlutter / DartMobile app & internal web views Schedules · shows · time punches
DATA & FILESAzure data servicesCosmos DB · operational records Blob Storage · uploaded files
Delivery · GitHub Actions
Builds, tests, and code quality checks support controlled releases.
Operations · Application Insights
Logs and telemetry help investigate behavior and diagnose issues.
Clients communicate with the application layer over HTTP REST APIs. Backend services manage access and persistence. This is a logical view of the client, API, and data responsibilities.
Data that reflects the workflow
Users, invitations, shows, assignments, time punches, and activity records form the core of the operational model. API contracts connect those records to clear tasks in the app.
Access with context
Role-based access, email verification, input validation, and audit logging help protect sensitive operational information. Geofencing and device context add useful evidence to time records.
03 Engineering decisions
Build around the constraints. Make the tradeoffs explicit.
The engineering challenge is connecting a usable field experience with a system that can be maintained, tested, and operated.
01
One cross-platform client foundation
Flutter and Dart provide a shared foundation for mobile experiences and internal web views. The design still has to account for different screens, device permissions, and the ways a crew member and an administrator use the product.
02
Keep business rules behind the API
Python APIs on Azure Functions give the application a clear boundary for authentication, authorization, and operational rules. The interface helps users complete tasks; the backend remains responsible for deciding what an account is allowed to do.
03
Treat field connectivity as a real constraint
Retry-aware, idempotent punch APIs help handle interrupted requests without turning a reconnect into duplicate records. Location and device context improve reviewability, while validation handles missing or unexpected inputs.
04
Build visibility into the system
Audit records, structured logs, and telemetry make it easier to understand what happened when something goes wrong. A maintainable product needs evidence that supports debugging and clear operational follow-up.
05
Make quality part of delivery
GitHub Actions CI/CD brings builds, automated tests, and quality checks into the development workflow. Staging and incremental releases provide a place to validate changes before they reach the crews using the product.
04 Ownership & collaboration
The job continues after the code ships.
I owned the product lifecycle while staying close to the operational team. That meant translating needs into technical work, coordinating delivery, supporting adoption, and learning from real use.
Understand & prioritize
Turn owner and crew feedback into requirements, API contracts, data models, and a backlog tied to the business workflow.
Build & review
Develop the client and backend, work through implementation choices, and use reviews and automated checks to support maintainable changes.
Roll out & support
Demonstrate workflows, onboard staff, and help people use the platform in the context of their actual responsibilities.
Observe & improve
Investigate issues, incorporate user feedback, and refine the product through staging validation and iterative releases.
05 Operational results
Less administrative friction. More time for the work.
90%+of manual scheduling automated
4h → <25mweekly manager data entry
~80%fewer payroll corrections
Reported internal results from my work at Rogue Productions, as documented in my résumé and experience summary. Results reflect that operating context.
PyroPunch brought scheduling and attendance into a connected workflow, gave time records useful location context, and reduced repetitive administrative work. The experience strengthened my ability to move between business needs, system design, implementation, and the people relying on the result.
06 Continuous improvement
A product that keeps evolving.
Current development
Ongoing work includes payroll review, configurable pay settings, and work-type and driver-eligibility workflows. These changes are moving through staging and QA as the platform develops.
Exploring AI engineering
I’m developing my AI engineering knowledge through a proposed Pyro AI Copilot architecture: permission-aware retrieval, source citations, evaluations, and human oversight.
Want to go deeper?
I’d be glad to discuss the architecture, lessons learned, and the work ahead.