Productionizing Localz, in three pieces
Portfolio infra sprint — three independent AWS builds. Split the target architecture from LocalzDocs/why-localz-vision-synthesis.md into three builds designed, deployed, recorded, and torn down independently — real AWS, real domain, dummy business logic, budget kept honest.
Source docs: LocalzDocs/why-localz-vision-synthesis.md, LocalzDocs/progress-so-far.md, LocalzDocs/docs-vs-released-gap-analysis.md.
Before the split — CDK ≠ Terraform
They aren't interchangeable: CDK is imperative code that synthesizes to CloudFormation and stays in AWS's own state model; Terraform is declarative HCL with its own state file and a multi-cloud provider ecosystem. Neither can read or manage the other's state. Building one project in each isn't using them interchangeably — it's building independent reps in both, which is exactly what a senior IaC interview wants to see evidence of.
1. Where each project sits in the diagram
The architecture groups cleanly into three independent slices. Each slice is deployable, recordable, and destroyable on its own — no project depends on another being up.
| Slice | Diagram components | Localz doc it proves |
|---|---|---|
| 1 · Core Platform | Route53, CloudFront, WAF, API Gateway, VPC/ALB, ECS Fargate, Lambda, RDS-class store, S3, Secrets Manager, KMS, CloudTrail | §2 — the "connective tissue" itself, live and browsable at a real URL |
| 2 · Trust & Event Engine | DynamoDB + DAX, Step Functions, EventBridge, SNS, SQS, X-Ray | §5 — booking lifecycle → OTP → derived trust tier, event-driven |
| 3 · Analytics Pipeline | Kinesis Data Streams, Glue, Redshift/Athena, SageMaker, CloudWatch | §9 / Extended-Feature-Data-Platform.md — analytics as a growth lever, not a new business |
2. The three builds
Project 1 — Localz Core Platform
AWS CDK · Python · ~18 hrs · Weeks 1–4
Stack: Next.js, boto3 (Lambda glue), ECS Fargate, ALB, API Gateway, RDS Postgres, S3, CloudFront + ACM, WAF, Route 53, Secrets Manager, KMS, CloudTrail.
What it actually does:
- Next.js frontend on CloudFront + S3, FastAPI-shaped backend on Fargate behind an ALB — dummy endpoints only:
GET /listings,POST /bookings,GET /health. - A Lambda behind API Gateway does the one real piece of logic worth showing: presigned S3 upload URLs for listing photos, using boto3 directly.
- WAF in front of API Gateway, Secrets Manager for the DB credential, KMS-encrypted RDS, CloudTrail on.
Budget lever:
- The NAT Gateway is the one line item that can quietly cost more than everything else combined (~$32/mo idle). Put Fargate in public subnets with a locked-down security group instead — note the tradeoff on camera; it's a legitimate senior-level cost call, not a shortcut.
cdk deploy→ record →cdk destroysame day. Nothing here needs to survive between sessions except the Route 53 record and the S3 bucket.
Proves: you can stand up a real internet-reachable production stack — DNS, TLS, containers, a managed database, secrets — end to end with CDK, not just a tutorial VPC.
Project 2 — Localz Trust & Event Engine
Terraform · ~14 hrs · Weeks 5–7
Stack: boto3 (Lambda logic), DynamoDB (on-demand), DAX, Step Functions, EventBridge, SNS, SQS, X-Ray, OpenRouter.
What it actually does:
- A Step Functions state machine models the real booking lifecycle from
progress-so-far.md: Requested → Accepted → In-progress → Completed → Review. - Each transition drops an event on EventBridge; Lambda consumers (Python, boto3-heavy) recompute the three-tier trust score from stored facts —
compute_trust_tier, ported as dummy logic, not the real service. - SNS/SQS fan the "booking completed" event out to a notification queue — stubbed, no real email/SMS sent.
- One small concierge Lambda calls OpenRouter (cheap, pay-per-token, model-agnostic) to draft the booking-confirmation message a real provider would send — a taste of "AI-native Localz" for a few dollars, not a Bedrock bill.
Budget lever:
- Everything here is pay-per-use except DAX, which bills hourly per node. Stand DAX up only for the recording window, then
terraform destroy -targetjust that module. - Remote state in S3 + a DynamoDB lock table — worth doing properly here since "state management done right" is the actual interview question this project answers.
Proves: Terraform module design, remote state, and an event-driven state machine mapped directly to your own product's trust-tier spec — not a generic tutorial resource group.
Project 3 — Localz Analytics Pipeline
Terraform · ~10 hrs · Weeks 8–9
Stack: boto3, Kinesis Firehose, S3 (data lake), Airflow (self-hosted), Glue Data Catalog, Athena, SageMaker Notebook.
What it actually does:
- Dummy booking events (from Project 2's stream, or a synthetic generator if run standalone) land in S3 via Kinesis Firehose — raw → curated zones.
- A self-hosted Airflow DAG (Docker, local or a free-tier box) does the raw→curated transform on a schedule — the open-source stand-in for a Glue ETL job, per
Tools/Airflow.md. Glue itself is kept only for its Data Catalog, which Athena needs regardless. - Athena queries the catalog for the same KPIs the real
/api/admin/statsalready computes (GMV, bookings by category) — proving the analytics path without duplicating live product logic. - Optional: a SageMaker Studio notebook, spun up only for the recording, running a toy "most-booked category" model over the curated data.
Budget lever:
- The diagram's Redshift is deliberately not built — Athena-over-Glue-Catalog is the honest choice at this data volume, and saying so on camera ("here's when I'd actually reach for Redshift Serverless instead") is a stronger signal than building an idle cluster.
- Airflow instead of Glue ETL jobs removes the per-run DPU-hour charge entirely — orchestration runs free on your own machine or a free-tier instance, and it's a more portable skill outside AWS shops.
- Kinesis in on-demand mode, not provisioned shards — no hourly shard cost sitting idle between sessions.
Proves: you know when not to over-build — a serverless data pipeline sized to the data, with the scale-up path narrated rather than pre-built. Directly mirrors Extended-Feature-Data-Platform.md's own discipline argument.
3. Cost ledger — build phase
While still writing IaC, this is a per-session cost, not a monthly one. The only real budget risk is anything billed hourly left running between sessions. The discipline is the same for all three: deploy, work the hour, destroy.
| Project | Always-on baseline | While deployed | Teardown |
|---|---|---|---|
| 1 · Core Platform | Route 53 record + S3 (~$0) | ~$0.30–0.50/hr | cdk destroy |
| 2 · Trust Engine | DynamoDB on-demand (~$0.50/mo) | + $0.017/hr (DAX only) | terraform destroy |
| 3 · Analytics | S3 storage (~$0.10/mo) | pennies per Glue/Athena run | terraform destroy |
Realistic total: under $5/month baseline across all three, plus a handful of dollars in short recording bursts over the whole sprint. Set a $20 AWS Budgets alarm on the account as a tripwire, not because it'll be needed.
4. Domain plan
fullstackfusions.com hosted zone already exists for the blog — this only adds records, no new zone cost:
| Record | Points to | Project |
|---|---|---|
app.localz.fullstackfusions.com |
CloudFront distribution | 1 |
api.localz.fullstackfusions.com |
API Gateway custom domain | 1 |
Projects 2 and 3 stay internal — triggered via CLI/Postman on camera rather than exposed publicly, since neither needs a public surface to prove what it proves.
5. Running all three together — the $100 plan
This is the part that actually costs money: leaving all three up simultaneously long enough to feel like a running company, not a demo SSH'd into for ten minutes. Three optimizations make that affordable — cut the NAT Gateway (Project 1 stays on public-subnet Fargate + a locked security group), run DAX as a single node, and treat SageMaker as an on-demand tool stopped after each session rather than a background service.
| Project | Optimized | Continuous, per month |
|---|---|---|
| 1 · Core Platform | No NAT Gateway; ALB + Fargate + RDS single-AZ stay up | ≈ $62/mo |
| 2 · Trust Engine | DAX single node; rest is on-demand/serverless | ≈ $16/mo |
| 3 · Analytics | Scheduled Glue runs, not continuous; SageMaker off between sessions | ≈ $4/mo |
| All three, together | ≈ $82/mo |
At ≈$82/mo (≈$2.75/day), a full calendar month of "always on" alone nearly spends the whole $100 with no room for mistakes. So the $100 isn't a monthly budget — it's spent across the whole arc: small per-session spend through the nine build weeks, then one deliberate continuous launch window once all three are wired together, actually living in it as Provider, Customer, and CTO.
| Line item | What it covers | Budget |
|---|---|---|
| Build-phase sessions | ~45 hrs of deploy → test → destroy across Weeks 1–9 | ≈ $20 |
| Launch window | All three continuous for 12–14 days straight (Weeks 11–12) | ≈ $38 |
| On-demand extras | SageMaker sessions, extra Glue/Athena runs, data transfer | ≈ $15 |
| Margin | A day forgetting to destroy, a WAF rule left on overnight | ≈ $20 |
| Total | ≈ $93 of $100 |
Set an AWS Budgets alarm at $80 (email + SNS) and a hard one at $95 — with a 30-day free-tier account some of Project 1's RDS cost may be $0, which buys back margin rather than being assumed up front.
6. Sequencing at one hour a weekday
Five hours a week, not five hours a day — sized to that, not compressed to fit a sprint that was never going to survive a day job.
| Weeks | Phase | What the daily hour buys |
|---|---|---|
| 1–4 | Build Project 1 | CDK stack, one resource group per session — VPC/subnets, then ALB/Fargate, then RDS/S3, then WAF/CloudFront/Route 53 |
| 5–7 | Build Project 2 | Terraform modules — DynamoDB + DAX, then Step Functions state machine, then EventBridge/SNS/SQS wiring |
| 8–9 | Build Project 3 | Firehose → S3 → Glue → Athena, then an on-demand SageMaker pass |
| 10 | Integration | Wire Project 1's API into Project 2's event bus, point Project 3 at Project 2's stream; rehearse the role-play script (§7) |
| 11–12 | Launch window | Everything runs continuously; the daily hour is spent using Localz, not building it — this is the $38 line above |
~12 weeks end to end. This runs past the 30-day contract-search sprint's original window (project_contract_job_search (unresolved)) — treat it as a background project that keeps compounding through interviews, not something that has to close before then.
7. Experiencing it as Provider, Customer, and CTO
The actual point of the launch window — not a longer uptime number, but living in the three seats Localz's own docs name in one breath (why-localz-vision-synthesis.md §1). Script each seat as its own short pass during Weeks 11–12, not one blurred walkthrough:
Provider / Seller seat
- Onboard a dummy provider, list a service, set availability.
- Accept an incoming booking — watch it move through Project 2's state machine in the Step Functions console.
- Complete the OTP handshake, see the trust tier compute.
Customer / Consumer seat
- Search and book against the live
app.localz.fullstackfusions.comfrontend. - Pay the dummy checkout path, receive the stubbed notification off SNS/SQS.
- Leave a review, see it ranked by tier, not raw stars.
CTO / maintainer seat
- Watch the same booking's events land in CloudWatch and X-Ray traces across Project 1 and 2.
- Query the day's GMV/bookings-by-category KPI in Athena — Project 3 reading what Projects 1–2 produced, live.
- Check the Billing dashboard against the $100 budget, on camera, as the actual CTO habit it's modeling.
- Run day-to-day work through a scoped IAM role, not the root account — a small, real governance move that happens to sit squarely in the Security domain the SAA-C03 review flagged as weak (project_saa_c03_certified (unresolved)).
8. Free & open-source swaps already folded in
Pulled from the vault's own Tools/ notes rather than reached for generically — each swap earns its place by either cutting a real cost line or adding a skill AWS-only shops won't teach.
| Swap | Replaces | Why |
|---|---|---|
| Airflow (self-hosted) | Glue ETL jobs (Project 3) | Removes the per-run DPU-hour charge; Glue Data Catalog stays since Athena needs it. Airflow is also the more transferable skill outside AWS-native shops. |
| OpenRouter | Bedrock model calls | Same "AI in the booking loop" flavor for the concierge Lambda in Project 2, at pay-per-token pricing instead of a Bedrock bill — a few dollars, not a line item. |
| Terraform | — | Already core to Projects 2 and 3; the one on the list that was never a substitution, it was the plan. |
9. Bedrock AgentCore — not now, and why
A genuinely good idea for Localz's roadmap, deliberately kept out of this plan.
| Axis | AgentCore | This plan |
|---|---|---|
| Learning target | AI-agent platform ops — a different track than cloud/infra generalist | Compute, storage, database, network, security, analytics — exactly the SAA-C03 surface |
| Cost to eval honestly | ~$15–25 in Bedrock invocations for a real trial | Already at ~$93 of $100 with no room to absorb a fourth track |
| Timeline | A fourth, unrelated project | Three projects already fill ~12 weeks at 1hr/weekday |
| Where it still fits | Phase 4, after the core three ship — the right moment to ask whether Localz's next feature should lean agentic. Until then, the OpenRouter concierge Lambda above gets the same "AI-native" taste for a fraction of the cost. |
10. Recording checklist, per project
- Architecture walkthrough against the diagram slice — narrate what's real vs. dummy up front.
- Live
deployfrom a clean state, not a pre-warmed stack. - Working demo hitting the actual dummy endpoints/flow.
- One deliberate tradeoff call narrated out loud (no NAT Gateway, no Redshift, DAX on-demand) — this is the senior signal, more than the resources themselves.
- For the Weeks 11–12 launch window: the Provider/Customer/CTO script above, plus a live
destroyand a glance at Billing to close the loop.