01Brief
A multi-tenant property management platform built by a US startup. Homeowners keep a living record of their home: documents, warranties, a printable guidebook and a maintenance planner that tells them what needs care and when. Partners get co-branded referral links, and the operations team runs it all from internal admin dashboards.
My part covered both ends of the product. On the backend, I designed and owned the event-driven workflows that make it feel effortless: an ETL-style enrichment flow that pulls raw property records from an external data API, normalizes them into one consistent shape and loads them into PostgreSQL; rendering large PDF guidebooks in headless Chromium; scheduling warranty and maintenance alerts; and the short links that tie it together. On the frontend, I designed many of the screens myself and built them in React, together with the NestJS endpoints behind them, so the same person who shaped the data also shaped how homeowners and partners see it.
02Constraints
Infrastructure
Fully serverless on AWS, every resource defined in Terraform.
Load shape
PDF reports and data enrichment are slow, uneven jobs. They had to absorb spikes without ever holding an API request open.
Team
Three engineers shipping product features and infrastructure together, so anything we built had to be cheap to run and easy to hand over.
03Architecture
Guidebooks
Warranty alerts
Enrichment
Short links
Large downloads
04Decisions
D-01
Render guidebooks behind a queue
Why
Rendering a PDF in headless Chromium is slow and bursty. The API acknowledges right away and workers scale on their own.
Trade-off
Delivery becomes asynchronous, so the guidebook arrives by email instead of as an instant download.
D-02
Schedule warranty alerts with EventBridge
Why
Alerts are driven by schedules and events instead of a cron job scanning every warranty.
Trade-off
Schedules live outside the application code, so they are harder to test locally and to trace when an alert does not fire.
D-03
Short links on DynamoDB and Lambda
Why
Every lookup is a single key read. Pay per request, nothing to keep running.
Trade-off
Cold starts on rarely visited links.
D-04
Zip bulk downloads in the browser, with a worker for big archives
Why
Below a size threshold, files stream straight from S3 into a zip built client-side, with no server job to run or pay for. Above it, a worker builds the zip, stores it in S3 and emails a download link, so a big archive never depends on the user’s browser or memory.
Trade-off
Two code paths for one feature and a threshold to tune. Big downloads also stop being instant, since the link arrives by email.
05What I'd change
I would add end-to-end tracing across the queues from day one. With work split between API, EventBridge, SQS and several Lambdas, following a single guidebook from request to inbox meant stitching logs together by hand.