Why I'm Migrating My App to AWS, and How AI Is Helping Me Do It
Terrence Sibanda, engineering consultant. More about my work at www.terrylaws.com. In my last article I wrote about what cloud computing does for commissioning work, and where it falls short. This one is about a decision I've been circling for a while: moving my commissioning tracker, LC Tracker, fully onto AWS.
Why migrate at all
The front end currently sits on Cloudflare Pages as a progressive web app, which has been fine for an early version. But the tool is growing past what static hosting can carry. Here's what's pushing me:
- Real multi-user data. Issues, tasks, and checklists need to live in one database that many people update at once, with proper conflict handling. That means a real backend, and I'd rather build it once, properly.
- Access control. My work needs different permission levels for clients, contractors, and site teams, including time-limited and view-only access. Bolting that onto a static host gets ugly fast.
- Client requirements. Some clients ask where their data lives and who can touch it. Being able to answer "this Region, encrypted, logged" matters in my industry.
- Cost at small scale. Counterintuitive, but serverless pricing means I pay almost nothing while usage is low. A fixed VPS would cost more and do less.
Using AI to design and deploy
This is the part that would have been unrealistic for a one-person consultancy a few years ago. I'm using AI coding assistants, including Amazon Q Developer, in two ways.
First, as an architecture sounding board. I describe the problem (offline-first field app, syncs when connected, role-based access, cheap at low volume) and iterate on the design before writing anything. It won't make the decisions for me, and I push back on it plenty, but it compresses weeks of reading into hours.
Second, for infrastructure as code. I'm defining the whole stack in CDK rather than clicking through the console. AI drafts the skeleton, I review every line, and the result is a setup I can tear down and rebuild in minutes. Version-controlled infrastructure is also part of my IP discipline from my first article. If it's in code, it's documented, dated, and mine.
Scalable, but cheap
The design follows one rule: scale to zero, pay for use.
- Front end: S3 plus CloudFront. Static hosting with global delivery, for pennies.
- API: API Gateway and Lambda. No idle servers burning money between site visits.
- Database: DynamoDB for the hot paths, since its on-demand pricing matches bursty field usage. Aurora Serverless is the fallback if relational queries get heavy.
- Files: S3 for photos and test records, with lifecycle rules moving old data to cheaper storage automatically.
- Guardrails: Budget alerts and cost anomaly detection switched on from day one, because cloud bills creep.
The honest disclaimer from my last article still applies: the site often has no signal, so the app stays offline-first. AWS holds the system of record; the phone in a technician's hand has to work without it.
What's next
Migration is a project, not an afternoon. I'll write about how it actually went, including what broke, once it's done. Until then, the current version is at my engineering work www.terrylaws.com .
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article