DEV Community: Muhammad Abdullah

How I Built a Production Multi-Tenant SaaS on AWS for $94/month - And Almost Gave Up

Muhammad Abdullah — Sat, 11 Jul 2026 23:26:22 +0000

I Almost Quit This Project at 2am. I'm Glad I Didn't.

After OrderFlow I thought I understood AWS.

I understood enough to be dangerous.

StatusNest was supposed to be the next step up - a real multi-tenant SaaS platform. Not a learning project. Not a portfolio checkbox. Something that actually demonstrated architecture-level thinking. Production grade. Built from scratch.

One week later I was staring at a screen at 2am watching my third consecutive deployment fail, wondering if I should just stop.

This is that story.

Why StatusNest

OrderFlow taught me event-driven architecture. Three microservices, EventBridge, SQS, SNS, clean Terraform modules. I was proud of it.

But it had no users. No tenants. No authentication. No real-world complexity beyond the messaging patterns.

I wanted to build something where the hard problems weren't just infrastructure - where multi-tenancy, security, cost optimization, and real application logic all had to work together simultaneously.

A status page platform made sense. Every SaaS company needs one. It has natural multi-tenancy - each customer gets their own page, their own monitors, their own incident history. The monitoring pipeline is genuinely event-driven. The public status pages need CDN. The auth layer needs to be real.

It touched every AWS service I wanted to prove I could use properly.

I gave myself one week.

The Architecture I Was Aiming For

Three FastAPI microservices on ECS Fargate:

Auth Service (port 8000) - registration, login, JWT
Monitor Service (port 8001) - monitor CRUD, check scheduling
Status Service (port 8002) - public status page data

Behind an ALB with path-based routing. RDS PostgreSQL for persistent storage. ElastiCache Redis for caching and rate limiting. An EventBridge → Lambda → SQS monitoring pipeline. CloudFront with WAF in front of everything. GitHub Actions OIDC for CI/CD. Full Terraform IaC. CloudWatch and X-Ray for observability.

On paper it was clear. In practice it was the hardest thing I had built.

Day One: The Port Problem That Wasn't Simple

The first thing I hit was the ECS services showing Running=0.

Tasks were registering. Services were active. Nothing was actually running. ALB health checks failing across all three services.

I spent hours checking the Terraform - security groups, task definitions, ALB target groups. Everything looked right on paper.

The actual problem: port mismatch in the Dockerfiles. The containers were exposing different ports than what the ECS task definitions were mapping. The fix sounds simple written out like that. Finding it was not simple at all. CloudWatch logs showed the containers starting and immediately stopping. No useful error message. Just an exit code.

That was day one.

The Lambda Deployment Timeout

The monitoring pipeline uses Lambda to execute health checks. When I first deployed the Lambda functions the deployments kept timing out.

The function zip was too large - I was packaging all dependencies directly into the deployment package. AWS has a 50MB compressed zip limit for direct uploads and I was hitting it.

The fix was Lambda Layers - extract the heavy dependencies into a separate layer, keep the function code itself small. But figuring that out, restructuring the packaging, updating the Terraform Lambda resources, and redeploying took most of a day.

Every time I thought I had it the deployment would run for 16 minutes and then fail. Then I'd fix something and try again. 12 minutes. Fail. 12 minutes. Fail.

2am on July 2nd

Look at this GitHub Actions history:

Jul 2, 01:42 AM  — Deploy Auth Service #4      ❌  27m 51s
Jul 2, 02:16 AM  — fix: remove duplicate redis_url line in config
                 — Deploy Auth Service #5      ✅  17m 50s

That 27-minute failed deployment at 1:42am. I was trying to get the auth service running with Redis. The config had a duplicate redis_url line that was causing a startup crash. The container would start, hit the config parsing error, and die. The ALB would keep retrying health checks. The deployment would wait the full timeout period before marking as failed.

27 minutes of watching a progress bar, knowing something was wrong, not knowing what.

Fixed it at 2:16am with a one-line change.

July 3rd: The CI/CD Failures

Jul 3, 01:59 AM  — chore: remove scratch files     ✅
Jul 3, 14:07 PM  — Add CI/CD workflows             ❌  16m 20s  (Monitor Service)
Jul 3, 14:07 PM  — Add CI/CD workflows             ❌  12m 01s  (Auth Service)
Jul 3, 14:07 PM  — Add CI/CD workflows             ❌  12m 57s  (Status Service)
Jul 3, 14:08 PM  — Remove sensitive files           ✅  11m 52s

Three services. Three simultaneous CI/CD workflow failures. Same commit. 14:07pm.

I had pushed the GitHub Actions workflows for all three services at once. All three failed. The OIDC configuration, the ECR push permissions, the ECS deploy step - all of it needed to be debugged across three separate workflows simultaneously.

And before that - 1:59am again the night before. Still going past midnight.

The Free Tier Problem

I had planned to use Aurora Serverless v2 for the database. Scales to zero when idle. Perfect for a dev environment.

Not on free tier. The minimum Aurora Serverless v2 capacity costs more than a standard RDS instance running 24/7 at t3.micro.

So I switched to standard RDS PostgreSQL. Changed the Terraform, updated connection strings across three services, redeployed everything. Half a day gone.

This is the kind of decision that doesn't show up in architecture diagrams but defines what you actually ship. Real cloud engineering is full of these tradeoffs.

The Moment I Almost Stopped

It was somewhere in the middle of that week.

Deployments were failing. The Lambda timeouts weren't resolved yet. The API was returning errors I didn't fully understand. I had been debugging for hours and the list of open issues wasn't getting shorter.

I remember thinking: this is too much. I could just leave it at OrderFlow. That's already a solid portfolio project. Nobody is forcing me to finish this.

I sat there for a while.

Then I thought about why I started. I wanted to prove I could build something at architecture level - not just follow patterns but make real decisions under real constraints. Quitting with a half-built system proved nothing except that I quit when it got hard.

So I made chai, opened CloudWatch logs, and kept going.

When It Finally Worked

The moment the StatusNest dashboard loaded for the first time - auth working, monitors creating, status page serving data through CloudFront - was one of the best feelings I've had building anything.

Not because it was perfect. It wasn't. There were still bugs. There are always still bugs.

But the architecture was running. Every component I had designed on paper was live on AWS. The EventBridge rules were firing. Lambda was executing health checks. SQS was buffering. Redis was caching. CloudFront was serving. X-Ray was tracing the full request path.

$94/month. Built from scratch. Zero manual console interaction after the initial setup.

What StatusNest Actually Is

A production-grade multi-tenant SaaS status page platform:

3 FastAPI microservices on ECS Fargate
RDS PostgreSQL - primary data store
ElastiCache Redis - caching and rate limiting
EventBridge → Lambda → SQS - monitoring pipeline
CloudFront + WAF - CDN and DDoS protection
GitHub Actions OIDC - zero stored credentials
Terraform - every resource as code
CloudWatch + X-Ray - full observability

Full architecture documented in an 8-ADR Solution Architecture Document in the repo.

What This Taught Me

Errors are information. Every failed deployment told me something specific if I read the logs carefully enough. The ones that cost me the most time were the ones where I guessed the fix instead of reading the actual error.

2am debugging is a skill. Not a fun one. But learning to stay methodical when you're tired and frustrated and nothing is working - that's what separates someone who ships from someone who has half-finished projects.

Architecture decisions have real costs. Aurora vs RDS. Lambda Layers vs direct packaging. Every choice has a tradeoff that tutorial projects never show you because tutorial projects never have real constraints.

Finishing matters more than perfect. The bugs I didn't fix before shipping taught me more than the ones I did, because I had to understand the system well enough to know which ones were safe to leave for later.

GitHub: github.com/aboodi679

The architecture diagram, full Terraform modules, and 8-ADR Solution Architecture Document are all in the repo.

If you're hitting any of these same issues - ECS Running=0, Lambda deployment timeouts, OIDC failures, Windows clock drift breaking AWS signatures - drop a comment.

From FYP to Production AWS: How I Built My First Real Cloud Project (And How Many Times It Broke)

Muhammad Abdullah — Sat, 11 Jul 2026 23:09:18 +0000

My final year project was done.

90/100. Top 8 at the exhibition. Supervisor happy. Committee happy.

And I had absolutely no idea if I could actually get a job.

The FYP had AWS in it Lambda, DynamoDB, API Gateway. But let's be honest. Zappa does most of the heavy lifting. You're not really doing cloud engineering when a library handles your entire deployment. I knew how to follow a tutorial. I didn't know if I could build something real from scratch.

That gap bothered me.

So I opened an empty folder and decided to find out.

Why Event-Driven

I spent a week just researching what to build before writing a single line of code.

Every job description I read - cloud engineer, DevOps engineer, backend engineer - kept mentioning the same things. Microservices. Event-driven architecture. Decoupled systems. SQS. SNS. EventBridge.

Not because it's trendy. Because it's how real production systems are actually built. Direct service-to-service API calls don't scale. They create tight coupling. One service goes down and it takes everything with it.

Event-driven architecture solves that. Services don't talk to each other directly - they fire events and let the messaging layer handle delivery. The order service doesn't care whether inventory or notifications are running. It fires an event and moves on.

That was the pattern I wanted to learn properly. So I built around it.

What OrderFlow Does

OrderFlow is an order management platform with three microservices:

Order Service - accepts incoming orders, fires an order.created event
Inventory Service - consumes that event, updates stock
Notification Service - consumes that event, sends confirmation

Simple domain. Complex plumbing.

The entire event flow looks like this:

Client Request
      │
      ▼
Application Load Balancer
      │
      ▼
ECS Fargate Cluster
      │
order.created event fired
      │
      ▼
Amazon EventBridge
      │
      ├──► SQS inventory-queue (direct)
      │
      └──► SNS orders-topic
                  │
                  └──► SQS notification-queue (fan-out)

Order service fires one event. EventBridge routes it. SNS fans it out. Both downstream services get what they need without knowing anything about each other.

That's the theory. The reality was messier.

The Part Nobody Puts in Their README

I want to be honest about what building this actually looked like.

This was my first time building something at this level of complexity without a tutorial holding my hand. No template. No starter repo. Just AWS documentation, Stack Overflow, and a lot of CloudWatch logs telling me things were broken.

The Terraform errors came first.

I had used Terraform before on smaller projects but never with a modular structure across networking, ECS, messaging, and observability layers all wired together. The dependency graph alone took me two days to get right. Terraform would plan successfully and then fail mid-apply because a security group wasn't ready before the ECS task definition tried to reference it. I learned more about depends_on in those two days than in any course.

Then ECS refused to run anything.

Services registered as ACTIVE but tasks immediately stopped. No obvious error in the console. I dug into CloudWatch logs and found the container was crashing on startup - environment variables weren't being injected correctly into the task definition. The container was starting, hitting a missing config value, and dying before it could even serve a health check. The ALB kept marking targets unhealthy. The fix was straightforward once I found it, but finding it took hours.

Then EventBridge events were disappearing.

I'd fire an order.created event and nothing would show up in the SQS queue. No error. No DLQ message. Just silence. Turns out my EventBridge rule pattern wasn't matching the event structure I was sending - a JSON field name mismatch between what I was publishing and what the rule was filtering on. One character difference. Two hours of debugging.

Then GitHub Actions kept failing on ECR push.

OIDC setup between GitHub and AWS is genuinely fiddly. The trust policy on the IAM role has to exactly match the GitHub repository path and branch conditions. I had the role ARN right but the trust relationship was slightly wrong - it was accepting tokens from the right GitHub org but not scoping to the right repo. Every push was failing at the assume-role step with a cryptic access denied. Fixed it by reading the IAM trust policy documentation more carefully than I've ever read any documentation.

Each one of these felt like a wall when I hit it. In hindsight they were the whole point.

What the Final Architecture Looks Like

Three Flask microservices running on ECS Fargate behind an Application Load Balancer with path-based routing:

/orders/*     → order-service     (port 5000)
/inventory/*  → inventory-service (port 5001)
/notify/*     → notification-service (port 5002)

Every AWS resource - VPC, subnets, route tables, security groups, ECS cluster, task definitions, ECR repos, ALB, SQS queues, SNS topic, EventBridge rules, CloudWatch alarms, X-Ray group - provisioned through modular Terraform. Zero manual console clicks after the initial setup.

CI/CD via GitHub Actions with OIDC - no AWS access keys stored anywhere. On push, the pipeline assumes an IAM role via web identity token, builds the Docker image, pushes to ECR, and forces a rolling ECS redeployment.

Observability through CloudWatch dashboards tracking ECS CPU and memory across all three services, ALB request count and response time, and SQS queue depth. Alarms fire if CPU crosses 80% or queue depth crosses 100 messages. X-Ray distributed tracing wired across the full request path.

The whole thing runs for ~$22-25/month.

What Event-Driven Actually Taught Me

Before this project, event-driven architecture was a concept I understood intellectually.

After this project, I understand it in my hands.

The difference between calling inventory service directly from order service versus firing an EventBridge event is not just architectural elegance. It's operational resilience. During testing I deliberately stopped the inventory service container while firing order events. The orders kept processing. The events sat in SQS. When inventory came back up it consumed the backlog and caught up. Nothing was lost.

Try that with a direct REST call. The order fails. The user gets an error. You have a support ticket.

That moment - watching the system absorb a failure and recover without intervention - was when cloud engineering stopped feeling like infrastructure configuration and started feeling like system design.

What I Built Next

OrderFlow taught me the patterns. But it was missing something real - actual users, actual tenants, actual production concerns like multi-tenancy, authentication, rate limiting, and cost optimization under real traffic.

So I built StatusNest next. A production multi-tenant SaaS status page platform on AWS, with everything OrderFlow taught me plus the things OrderFlow couldn't teach me.

That story is in my next post.

The Code

Everything is open source - Terraform modules, GitHub Actions workflows, service code, test events.

GitHub: github.com/aboodi679/orderflow-aws

If you're building something similar and hitting the same walls I hit - ECS tasks stopping immediately, EventBridge rules not matching, OIDC trust policy rejections - drop a comment.

Two Friends, Two Different Domains, One FYP - And a Committee That Changed Everything

Muhammad Abdullah — Sat, 11 Jul 2026 22:17:07 +0000

Final year project selection is stressful enough on its own.

Now imagine two friends sitting in a class, one laptop between them, trying to pick a single project that would satisfy a supervisor, an examination committee, and two completely different career paths.

That was me and Hassan in early 2024.

I was deep into AWS - ECS, Lambda, Terraform, the whole cloud stack. Hassan was into Unity and game development. We needed something that genuinely needed both of us. A game with a cloud backend made sense - Hassan owns the game, I own the infrastructure, we both have something real to show.

We went to the committee feeling good about it.

Then they said four words that changed everything.

"You Need to Add AI."

Not a suggestion. A requirement.

We walked out of that room and looked at each other. Hassan said: "Let's just add some pathfinding and call it AI."

I wasn't satisfied with that. If we were going to add AI, I wanted it to actually mean something - something the committee hadn't seen before, something that justified the domain split between a cloud guy and a game dev.

Hassan had been reading about Reinforcement Learning. The idea was compelling - instead of scripting NPC behavior manually, let the agent learn through trial and error. Reward good behavior, penalize bad, and over time it develops its own strategy.

He pitched it. It sounded perfect on paper.

Then we actually tried to implement it.

Why Pure RL Was a Problem

RL has a dirty secret that papers don't emphasize enough: it needs thousands of training episodes before it does anything useful.

In a controlled grid environment with a simple reward function, that's manageable. In a real Unity game with a 3D environment, dynamic player behavior, and a demo deadline four months away - it's a disaster.

The problems we hit:

RL is unpredictable by nature. That's literally the point - it explores. But in a game, "exploration" means your NPC stands in a corner, walks into walls, or runs away from the player for no reason. Not exactly the threatening enemy we were going for.

Reward shaping is an art, not a science. If you reward the NPC for getting close to the player, it learns to get close - then just stands there. Every reward signal has to be carefully designed or the agent learns to game the reward function instead of actually playing.

Training time. We didn't have a GPU cluster. We had Hassan's laptop. Full RL training on a live Unity environment wasn't going to be ready for demo day.

Hassan was honest about it - the RL implementation was beyond what he could execute in the Unity codebase within the timeline. He built the FSM instead, which worked, but felt incomplete given what the committee was expecting.

That's when I stepped in.

The Research Rabbit Hole

I took ownership of the AI architecture problem. If RL alone was too unstable and FSM alone was too rigid, there had to be a middle ground.

I spent two weeks reading - research papers, game AI blogs, anything I could find. The pattern that kept appearing in serious game AI literature was a hybrid approach. Not RL or FSM. RL and FSM together.

The insight was simple once I found it:

FSM and RL have exactly opposite weaknesses.

FSM is stable but rigid - it does exactly what you tell it, nothing more. Players figure it out fast. The NPC becomes a puzzle instead of a threat.

RL is adaptive but unpredictable - it can surprise you, but early in training it's chaotic and unreliable. You can't ship a game where the enemy randomly walks into walls.

What if FSM handled the high-level structure and RL handled the low-level execution?

The Architecture We Landed On

The FSM controls the overall zombie behavior. High-level states - Patrol, Stalk, Engage, Retreat - with deterministic rule-based transitions. This is what Hassan had already built. It was stable, it worked, it demoed reliably.

But within the Engage state, instead of scripted attack patterns, the NPC uses an RL policy to control its movement.

The zombie knows it's in Engage mode because of FSM rules. But how it moves during engagement - how it positions itself, how it adjusts to the player dodging, how it cuts off escape routes - that comes from the RL model.

The FSM gives the RL agent guardrails. The RL agent never has to explore the entire state space from scratch - it only makes decisions within a constrained, well-defined context. That solved the unpredictability problem.

The RL agent gives the FSM emergent behavior. The high-level states are still deterministic, but the execution inside each state adapts to the specific player. That solved the rigidity problem.

Each one covered the other's weakness. That was the breakthrough.

Where the Cloud Came In

This is where my domain actually mattered.

The RL model needed to be trained on player session data and updated over time. Running that inside Unity wasn't feasible. We needed a backend.

I built a serverless Flask API deployed to AWS Lambda via Zappa, with:

DynamoDB storing NPC behavior profiles and session data per player
S3 storing trained model artifacts
API Gateway exposing endpoints to the Unity client

The split finally made complete sense. Hassan owned the game engine and FSM implementation in Unity. I owned the AI architecture design, the RL research, and the entire AWS backend.

Neither of us could have built the other's half.

The Result

90/100 at the university's Project Exhibition.

Top 8 Runner-Up out of the Final Project Exhibition.

The viva ran long - not because anything went wrong, but because the committee kept asking questions. The hybrid architecture was something they hadn't seen in a student project before. They pushed hard on why we combined FSM and RL, how we handled the training instability, and why Lambda over EC2 for the backend.

We had answers for all of it.

What We'd Do Differently

On the RL side: Train in a headless simulation environment instead of the live game. A simulation running 100x faster than real-time would have produced a significantly better policy by demo day. We were constrained by training in real Unity time which slowed everything down.

On the cloud side: API Gateway WebSockets instead of REST for Unity-to-backend communication. The polling approach added latency that hurt the real-time feel. With my current AWS knowledge I'd redesign that from day one.

On the project itself: Don't wait for the committee to push you. We almost shipped a safe, forgettable project. The "add AI" requirement felt like a burden in that moment. It turned out to be the best thing that happened to us.

The Actual Lesson

The hybrid FSM+RL pattern we built isn't just a game AI trick. The same principle - deterministic rules for structure, learned policies for adaptation - shows up in production systems everywhere. Recommendation engines. Fraud detection. Adaptive difficulty in AAA games.

We didn't invent it. But we found it, understood it deeply enough to implement it under a deadline, and shipped something that surprised the people evaluating it.

That last part - surprising people who've seen hundreds of student projects - is harder than it sounds.

And it started with two friends from completely different domains who had no choice but to figure it out together.

Hassan Saleh Hayat handled Unity, game systems, and FSM implementation. I handled AI architecture research, RL integration design, and the AWS backend.

Source

GitHub:github.com/aboodi679/ai-hitman-backend