JobTrek Pro
Field-service management SaaS for service teams

- Role
- Technical Architect
- Timeline
- Aug 2025 – Apr 2026
- Context
- Tech Emulsion · team of 5 engineers
Tech & skills
- Node.js
- React
- PostgreSQL
- Redis
- BullMQ
- Zod
- Docker
- AWS ECS
- AWS RDS
- CloudFront
About
A field-service-management platform for companies that dispatch technicians — scheduling, job tracking, customer records and invoicing in one system.
The team had strong AWS operational depth but no one owning application architecture, so I stepped into that seat and drove the major technical decisions across both the codebase and the deployment.
What I built
- Brought framework-grade structure to a Node.js codebase: modular service, controller and serializer layers with enforced conventions the whole team built against.
- Built a mailer abstraction with swappable drivers (Nodemailer, SES, Resend) and a storage abstraction over local and S3, so integrations became configuration rather than rewrites.
- Added a global request validator — a req.validate() helper taking a Zod schema and raising a typed validation exception — paired with a custom exception handler for structured errors and logging.
- Introduced Redis-backed rate limiting, BullMQ queue processing, an event-dispatch system, and application health checks covering database and cache reachability.
- Migrated the datastore from MongoDB to PostgreSQL on RDS with a backup and replication strategy.
- Redesigned the deployment: Dockerised the services onto ECR and ECS, moved the React dashboard off an EC2 box to S3 with SPA routing behind CloudFront, and wired DNS through Route 53 with ElastiCache for Redis.
Outcome
Shipped and deployed. The platform was later rebranded and handed to another engineer for ongoing feature work, and I was retained as architecture and deployment lead across the company’s projects.
I also drafted a multi-cloud cost proposal for the next phase: self-hosting on Hetzner behind a Kubernetes cluster with a custom autoscaler driving the Hetzner API, Cloudflare R2 for object storage, while deliberately keeping the database on managed RDS — point-in-time recovery is the one thing not worth self-hosting.
What I took away
- Structure is a team multiplier, not a personal preference. The abstractions that paid off were the ones that removed decisions from every future pull request.
- Knowing where not to optimise matters as much as knowing where to. The cost proposal self-hosted everything except the database, because the failure mode there is unrecoverable.
- Architecture ownership is a role someone has to take, even when it is not on the org chart.