Dynamox
role
period
domain
Full Stack Developer (mid-level)
2025-Present
Industrial inspection & condition monitoring
Industrial monitoring & inspection company where I grew from junior to mid-level full-stack developer, becoming the team's reference for cross-service data synchronization.
overview
Dynamox builds an industrial monitoring and inspection platform (predictive maintenance for industrial assets). I joined in February 2025 and work on the squad that owns the inspection domain: inspection routes, checklists, teams, compliance ("adherence") and reporting, building both the web front end and the backend services behind it.
business domain
Industrial predictive maintenance and asset inspection: field teams follow inspection routes, complete checklists against equipment, and the platform tracks coverage and compliance so plants can act before failures happen. The work spans data-heavy backends (large asset hierarchies, event-driven synchronization between services) and operator-facing web UIs.
responsibilities
- —Full-stack delivery of inspection-domain features (React front end; NestJS backends).
- —Cross-service data synchronization via an event-driven (Kafka) architecture, the domain I became the team's reference for.
- —Production reliability: incident response, debugging deadlocks/connection issues, safe production data corrections.
- —Platform work: security/CVE remediation, observability, CI/CD and test infrastructure, and infrastructure-as-code for the team.
achievements
- +I wrote the architecture decision to move heavy customer-reporting queries away from the database serving live application traffic. Another engineer and I established the service foundation; rollout is underway, and end-state latency has not been measured.
- +I led the work to keep edits to an organizational node consistent across seven tables and two services. That became the work teammates used when they needed help reasoning about cross-service data changes.
- +I contributed recursive backend traversal to asset-tree search, reducing the query pattern from N×3 sequential calls to three. The overall feature was shared; another engineer completed most of the final search issue.
- +I investigated route-adherence reports with production data and staging reproductions. When my first diagnostic rule proved too broad, I changed the measurement before the team chose targeted fixes. The post-release Data Quality trend is a team measure, not an isolated result of my work.
- +A role-cleanup change I wrote removed access across workspaces. I owned the incident response and architecture follow-through; the squad delivered the replacement consumer. Months later, I diagnosed a separate deadlock and contributed to its per-user locking and failure-recovery work. No post-deployment error-rate measure is available.
- +I also worked on production data corrections, container and dependency hardening, observability, and test infrastructure. The linked studies describe the scope and evidence for each.
- +I moved from junior to mid-level in about 11 months; the promotion dossier covered backend, frontend, architecture, security, quality, and continuous delivery.
technologies
15 case studies here
Moving customer reporting off the transactional database
Synchronizing a Cross-Service Data Edit Atomically
Designing a single computation path for a cross-service metric
Making asset-tree search faster across the API and interface
Choosing the right altitude to fix a bug found in review, not just the fastest patch
Changing where a new state is handled, instead of teaching eight read paths about it
Measuring route-adherence defects before changing production behavior
Trading a runtime join for a materialized column, then finding the 79% my own migration left behind
Making a flaky end-to-end suite deterministic without hiding failures
Bringing error observability to a team that had none
Making container and dependency hardening a standing practice, not an audit response
Correcting production data safely with reversible, auditable tooling
The role-binding incident—and the separate deadlock found later
Designing the safety guarantees for an AI-orchestrated cleanup, not just automating the grind
Accepting inspection answers instantly and processing them durably, with an outbox
lessons learned
Eventually-consistent derived data should have exactly one computation path. Multiple writers deriving the same value is the defect; consolidating the derivation is the fix.
Parallel AI agents need the same safety design as any other concurrent workers. Isolate their work by disjoint file ownership, or they will corrupt each other's changes exactly like any other race condition.
Put the promise where you can keep it. A synchronous boundary should confirm only what is already guaranteed. Here that was "validated and durably stored", not "processed".