DEV Community: Limani Ndou

Building a receipt-scanning budget tracker with Amazon Bedrock, Lambda, and DynamoDB

Limani Ndou — Fri, 04 Sep 2026 16:16:26 +0000

---

The Problem I Kept Ignoring

Every week, the same small annoyance played out: I'd snap a photo of a receipt, tell myself I'd log it later, and then completely forget. By the time I got around to reviewing my spending usually at the end of the month I'd already blown past a budget category without knowing it. Even when I did log expenses manually, I'd misclassify them, which quietly made my "budget tracking" useless.

I didn't need another finance app with fifty features I'd never touch. I needed one thing done well: upload a receipt, get an instant answer on whether I'm still within budget.

That's what I built. It's called BudgetSnap.

What BudgetSnap Actually Does

BudgetSnap is intentionally narrow in scope, and that's the point. The entire flow is:

Upload a receipt image or PDF.
Automatically extract the merchant, date, subtotal, tax, total, and category.
Store the entry in a database.
Compare the new spend against that category's budget limit.
Return a clear, immediate status over budget or within budget with practical advice.

No end-of-month surprises. No manual spreadsheet updates. Just upload and know.

On the UI side, I kept things lightweight but functional:

A responsive single-page interface that works on desktop and mobile.
A budget period selector (week/month).
A category override selector for when the AI gets it wrong.
Editable budget limits per category.
Real-time result cards showing spend status the moment a receipt is processed.

How I Built It on AWS

I built this incrementally so I always had something working, even as I layered in more capability.

1. Frontend — plain HTML, CSS, and JavaScript

I skipped frameworks entirely to keep setup minimal and deployment fast. The frontend supports drag-and-drop uploads, a manual file picker, category budgeting controls, and a responsive layout.

2. AI extraction — Amazon Bedrock (Nova models)

This is the core intelligence of the app. I enabled model access in Amazon Bedrock and used a Nova model to read the receipt content and return structured fields merchant, date, totals, category that the rest of the pipeline can store and evaluate.

3. Data layer — Amazon DynamoDB

Two tables power the app:

expenses — processed receipt entries.
budgets — category limits.

4. Processing logic — a receipt processor AWS Lambda function

It:

Receives the upload context.
Extracts receipt data (via the Bedrock path, or a fallback path more on that below).
Looks up the relevant budget limit.
Computes spend-before, spend-after, and any over-budget amount.
Writes the final expense row to DynamoDB.
Returns normalized JSON back to the UI.

5. API layer — an upload Lambda behind Amazon API Gateway

It accepts multipart uploads from the browser, stores the file in Amazon S3, invokes the processor Lambda, and relays the processed result back to the frontend.

6. Event wiring — Amazon S3 triggers

Tested end-to-end from upload through to the final budget status response.

AWS Services Used

Service	Role
Amazon S3	Stores uploaded receipt files and triggers processing
AWS Lambda	Runs the upload handler and the receipt processor
Amazon API Gateway (HTTP API)	Exposes the upload endpoint to the frontend
Amazon DynamoDB	Stores budgets and processed expense entries
Amazon Bedrock (Nova models)	Performs receipt understanding and categorization
Amazon CloudWatch Logs	Debugging and operational visibility across the pipeline

Architecture Flow

User uploads an image or PDF from the web app.
API Gateway routes the request to the Upload Lambda.
Upload Lambda writes the file to S3.
The Processor Lambda runs using the S3 context.
The processor checks budget data in DynamoDB.
The processor writes the new expense entry to DynamoDB.
The API returns budget status and advice back to the frontend all in one response payload.

What I Learned

A focused scope beats a broad scope. By solving one annoying, recurring task really well, I ended up with a fully deployed, genuinely useful app instead of a half-finished feature list.

Technical takeaways

Apply least-privilege IAM policies and validate permissions early across Lambda, S3, API Gateway, and DynamoDB, this saved me from several silent failures later.
Amazon CloudWatch Logs is the backbone of debugging serverless workflows. Without it, tracing failures across a multi-Lambda pipeline would have been guesswork.
Standardizing request/response schemas across frontend and backend made integration, testing, and iteration dramatically simpler.
Keeping the architecture lightweight and modular made the app easy to deploy, maintain, and extend.

Product takeaways

Instant feedback is what users actually value in a budgeting tool not more data, faster answers.
Over-budget nudges land better when they're short and practical, not verbose.
Reducing user effort upload once, get an automatic budget check is what drives real adoption.

Try It Yourself

GitHub repo: github.com/limanindou/BudgetSnap

Building BudgetSnap reminded me why serverless architectures are such a good fit for small, high-leverage tools like this: I could focus almost entirely on the problem — accurate extraction, meaningful budget feedback instead of managing infrastructure. That's exactly the kind of building I want to keep doing.

If you've built something similar with Bedrock or a serverless receipt/document pipeline, I'd love to hear how you approached extraction and fallback handling drop a comment below!

🤖 Building an AI Compliance Assistant with Hugging Face, RAG & Observability on AWS

Limani Ndou — Sun, 23 Aug 2026 18:40:21 +0000

I Built an AI Compliance Assistant That Runs Entirely on My Own GPU — Here's What I Learned

Combining RAG, local LLM inference, Terraform-provisioned AWS infrastructure, and full-stack observability to make South African financial regulation searchable

If you've ever worked anywhere near banking compliance, you know the feeling: somewhere in a 200-page guidance note is the exact clause you need, and you have no idea which page it's on 📄🔍. South African financial institutions operate under a dense stack of regulation — AML, CTF, CPF, the FIC Act, cross-border EFT reporting, Prudential Authority requirements — and most of it lives in long, technical PDFs that don't search well.

So I decided to build something that could actually answer compliance questions, grounded in real regulatory text, running on infrastructure I control end to end 🛠️. No black-box SaaS API calls to a third-party model — the LLM inference happens locally, on my own GPU, provisioned entirely with Terraform ⚙️, and I can watch every request move through the system in real time.

This is the story of building Compliance RAG 🤖: a Retrieval-Augmented Generation platform for South African regulatory intelligence, with local GPU inference, a vector database, infrastructure-as-code, and a full observability stack behind it.

🧩 The Problem

South African banks have to navigate obligations spanning:

Anti-Money Laundering (AML) and Counter-Terrorist Financing (CTF/CPF)
Customer Due Diligence and risk-based approaches
Cross-border electronic funds transfers and international reporting
FIC Act implementation requirements
Rules for representative offices of foreign banking institutions

A compliance officer might ask something like "What information must a bank obtain when conducting customer due diligence?" — a completely reasonable question with an answer buried somewhere in a Guidance Note. Traditional keyword search either misses the context entirely or returns ten tangentially related pages 😩. What's actually needed is a system that understands the question, retrieves the relevant passages, and answers using only what's actually in the source documents — no hallucinated legislation, no invented penalties.

💡 The Solution: Retrieval-Augmented Generation, Self-Hosted

The core idea behind RAG is simple: instead of asking a language model to answer from memory (where it might confidently make things up), you retrieve the most relevant chunks of real source documents first, and then ask the model to answer using only that retrieved context.

Here's the pipeline I built:

PDF → Document Loader → Text Splitting → Embeddings → ChromaDB
    → Similarity Search → Relevant Regulatory Context → Gemma → Answer

Regulatory PDFs — the ML/TF/PF Sector Risk Assessment, Guidance Note 7B on the FIC Act, Guidance Note 8 on EFTs, and documentation on representative offices of foreign banks — are stored in an S3 "compliance document vault" 🪣, ingested, chunked, embedded, and stored in ChromaDB for similarity search.

The regulatory document vault in S3 — each PDF is a primary source, ingested and re-embedded whenever it's updated.

When a question comes in, the system retrieves the most relevant chunks and passes them, along with the question, to a locally-hosted Google Gemma 2 2B IT model for generation. I picked Gemma 2 2B specifically because it's small enough to run comfortably on a single GPU without breaking the bank, while still being capable enough to follow strict grounding instructions — exactly the tradeoff a self-hosted compliance tool needs 🎯. Running the model locally rather than calling an external API meant provisioning real GPU infrastructure.

🏗️ Provisioning It All With Terraform

I didn't want to click around the AWS console to spin this up — I wanted it reproducible, versioned, and destroyable in one command. So every piece of AWS infrastructure — the GPU-enabled EC2 instance, the VPC, security groups, IAM roles, and the S3 bucket — is defined and deployed with Terraform 🧱.

cd infrastructure
terraform init
terraform plan
terraform apply

One terraform apply and I have a fully networked, GPU-ready EC2 instance with the right IAM permissions to talk to S3 — no manual setup, no configuration drift, and a clean terraform destroy when I don't want to pay for idle GPU time 💸.

A g5.xlarge EC2 instance with an NVIDIA A10G GPU — provisioned by Terraform, running 24/7, hosting the entire Dockerized stack.

🖥️ What It Looks Like in Practice

The frontend is a React/Vite chat interface I called the "Enterprise Regulatory Advisor." I wanted answers that weren't just fluent-sounding text — they needed to cite exactly where in the source documents they came from, so a compliance officer could go verify it themselves in seconds ✅.

Asking "What information must a bank obtain when conducting customer due diligence?" Notice the "AI Engine: Gemma-2 Active" status in the sidebar 🤖 — the model answers only from retrieved context, and — critically — flags when the source text doesn't specify something, rather than filling in the gap itself. Every answer comes with verified source references down to the page number.

That last detail mattered a lot to me. The system prompt explicitly instructs the model to avoid inventing legislation, requirements, penalties, or dates, and to say plainly when the answer isn't in the available documents. In a compliance context, a confident wrong answer is worse than no answer at all ⚠️.

📡 Watching the System Think: Observability

Running your own LLM infrastructure means you can't just trust that it's "working" — you need to actually see what's happening under the hood 🔬. I instrumented the entire FastAPI backend with OpenTelemetry, exporting traces and metrics through an OTEL Collector to Prometheus, Grafana, and Jaeger.

Prometheus querying metrics scraped from the OTEL Collector — request durations, active requests, histogram buckets, all labeled and queryable.

Prometheus gives me the raw metrics — request rates, latency histograms, active request counts 📊 — and Grafana turns those into dashboards I can actually read at a glance.

A live Grafana dashboard built on the Metrics Drilldown view — request duration buckets, throughput, and payload sizes updating in real time.

And when I need to understand why a specific request was slow — was it the embedding step, the ChromaDB similarity search, or the Gemma generation itself? — Jaeger gives me the full distributed trace 🔎.

Jaeger tracing individual API calls through the RAG pipeline, down to the microsecond.

This turned what could have been a black box into something genuinely observable — I can see request rate, latency percentiles, GPU health, and trace-level detail on any single query.

🧰 The Stack, End to End

🐍 Backend: Python, FastAPI, LangChain, ChromaDB, PyTorch, Hugging Face Transformers
🤖 AI/ML: Google Gemma 2 2B IT, local GPU inference on an NVIDIA A10G
⚛️ Frontend: React + Vite
📈 Observability: OpenTelemetry, Prometheus, Grafana, Jaeger
☁️ Infrastructure: AWS EC2 (GPU) + AWS S3, provisioned with Terraform, containerized with Docker Compose, with Kubernetes/Helm manifests for scaling out
🚀 CI/CD: GitHub Actions

Everything runs in Docker Compose for local/single-instance deployment, with a parallel Helm chart if I ever need to move this onto Kubernetes — and every underlying AWS resource traces back to a Terraform module, not a manual console click.

🎓 What I Learned

Grounding is everything. 🎯 The hardest part wasn't wiring up the pipeline — it was getting the prompt-level guardrails right so the model would refuse to speculate. A 2B parameter model is small enough to run affordably on a single GPU, but it also means you have to be deliberate about keeping it on a short leash: retrieved context in, grounded answer out, and an honest "not found" when the documents don't say.

Infrastructure-as-code pays for itself fast. 🏗️ Provisioning the GPU instance, networking, and S3 vault with Terraform meant I could tear the whole environment down between sessions and bring it back identically an hour later — a huge win for both cost control and sanity.

Observability isn't optional once you self-host. 🔭 The moment you're responsible for your own inference infrastructure, "is it working?" becomes a real question you need real tooling to answer. Watching a trace waterfall through embedding → retrieval → generation taught me more about where latency actually lives than any amount of guessing would have.

Compliance AI has a very specific bar. ⚖️ This project is explicitly not a replacement for a compliance officer or legal advisor — the disclaimer sits front and center in the docs. The goal was never "trust the AI's judgment." It was "make the source material searchable, and always show your work."

🔮 What's Next

On the roadmap: hybrid search (BM25 + vector) with cross-encoder reranking, RAGAS-based evaluation for faithfulness and retrieval precision, regulatory change detection so the vault flags when a source document gets superseded, and proper enterprise auth via Cognito/OIDC before this goes anywhere near production data.

If you're curious about the architecture or want to build something similar, the full project — Terraform configs, Helm charts, ingestion pipeline, and all — is open on GitHub. ⭐

CODE: https://github.com/limanindou/compliance-rag
YOUTUBE DEMO PC:https://youtu.be/MgLLihgKUuc?si=GoLwfbuwJBZNLQ9c
YOUTUBE DEMO MOBILE:https://youtube.com/shorts/mRaoCBRngaY?si=RFCkVGLzyi1ohKOh

Built as an AI, cloud, and compliance engineering project focused on South African regulatory intelligence 🇿🇦. Not legal advice ⚠️ — always verify against the latest official regulatory publications.

Agentic AI for VMware migrations with AWS Transform for VMware

Limani Ndou — Tue, 09 Jun 2026 11:41:16 +0000

I recently learned about Agentic AI for VMware migrations from AWS through a session on AWS Transform for VMware. The session explained how enterprise VMware migrations are often slow and complex because of legacy systems, manual processes, and coordination challenges across multiple teams.

What stood out to me was how AWS Transform uses Agentic AI to simplify migration workflows like discovery, assessment, planning, network conversion, and deployment. Instead of relying heavily on manual effort, the platform uses AI agents to automate and accelerate large-scale cloud transformations.

The session also highlighted benefits such as:

Faster VMware migrations
Reduced operational and licensing costs
Improved scalability and security
Better collaboration between customers, AWS teams, and partners

It was interesting to see how AWS is moving beyond traditional migration tools and using AI-driven systems to modernize enterprise infrastructure at scale.

You can learn more here:
• https://aws.amazon.com/transform/vmware/
• https://youtu.be/BHO_45PxguI?si=FWAlu0vvqHbLuHmB

🚀 How I Ran 11 Microservices with OpenChoreo

Limani Ndou — Wed, 25 Mar 2026 22:05:07 +0000

I used OpenChoreo to deploy and manage the Google Cloud microservices demo (11 services) on my local machine. The result was a cleaner developer workflow, better service visibility, and a production-like platform experience without building custom platform tooling from scratch.

1️⃣ What OpenChoreo?
OpenChoreo is a developer platform for Kubernetes offering development and architecture abstractions, a Backstage-powered developer portal, application CI/CD, GitOps, and observability. It composes CNCF and complementary projects into a modular, extensible framework that provides both strong governance for platform engineers and simplified abstractions for developers.

OpenChoreo was developed by WSO2 and is now part of the Cloud Native Computing Foundation (CNCF) ecosystem.

2️⃣ Why OpenChoreo?
OpenChoreo it provides all essential building blocks of an Internal Developer Platform (IDP) :

High-level APIs for modeling cloud-native applications
A Control Plane that understands and enforces these APIs with GitOps support
A built-in workflow engine for CI/CD pipelines and automation
An opinionated Data Plane with runtime enforcement of design-time semantics
Built-in security, networking, and observability integrations
This is the key reason I used it for this 11-microservice demo.

3️⃣ GCP Microservices Demo: What It Includes
Repository: https://github.com/GoogleCloudPlatform/microservices-demo

🌐 frontend (Go): Serves the website and auto-generates user session IDs.
🛒 cartservice (C#): Stores/retrieves cart items in Redis.
📚 productcatalogservice (Go): Product listing, search, and product details from JSON.
💱 currencyservice (Node.js): Converts money values using ECB exchange rates (highest QPS).
💳 paymentservice (Node.js): Mock credit card charge and transaction ID generation.
🚚 shippingservice (Go): Shipping cost estimates and mock shipping execution.
✉️ emailservice (Python): Mock order confirmation emails.
🎯 checkoutservice (Go): Orchestrates cart, payment, shipping, and email flow.
💡 recommendationservice (Python): Suggests products from cart context.
📢 adservice (Java): Returns text ads based on context words.
🔄 loadgenerator (Python/Locust): Simulates realistic shopping traffic.
4️⃣ What I Did (Step by Step)

⚙️ Prerequisites
Ensure the following before you begin:
-Docker (Engine 26.0+ recommended)
-Allocate at least 4 GB RAM and 2 CPUs.
-If you plan to install with WorkflowPlane, allocate 8 GB RAM and 4 CPUs for optimal performance.
-5-10 minutes of setup time

Step 1: Start OpenChoreo Quick Start

docker run --rm -it --name openchoreo-quick-start `
  --pull always `
  -v //var/run/docker.sock:/var/run/docker.sock `
  -p 8080:8080 -p 9443:9443 `
  ghcr.io/openchoreo/quick-start:v1.0.0

Step 2: Install OpenChoreo(two options):

./install.sh

With observability

./install.sh --with-build --with-observability

Step 3: Choose a Deployment Option
There are two ways to deploy the GCP Microservices Demo:

Option A: Use the built-in OpenChoreo deploy script for GCP Microservices Demo (11 services: frontend, cart, checkout, payment, and more)

./deploy-gcp-demo.sh

Option B: Clone and deploy manually

git clone --depth 1 --branch v0 https://github.com/GoogleCloudPlatform/microservices-demo.git
cd microservices-demo

kubectl apply -f ./release/kubernetes-manifests.yaml
I used Option B (clone and deploy).

Step 4: Verify in OpenChoreo UI
Access the UI at: http://openchoreo.localhost:8080/

Default login credentials:

Username: admin@openchoreo.dev
Password: Admin@123

Check:

Project and component catalog
Deployment pipeline view
Environment progression

Step 5: Validate End-to-End App Behavior
I opened the storefront and validated core user flow (browse, cart, checkout).

📚 References
Documentation: https://openchoreo.dev/docs/
Documentation: https://insights.linuxfoundation.org/project/openchore
OpenChoreo Quick Start Guide:
https://openchoreo.dev/docs/getting-started/quick-start-guide/
GCP Microservices Demo Repository:
https://github.com/GoogleCloudPlatform/microservices-demo

🚀 How I Built a Serverless Expense Tracker Using AWS Lambda and Amazon S3 - No Server Required

Limani Ndou — Fri, 20 Mar 2026 19:50:36 +0000

🚀I have built a fully serverless expense tracking pipeline on AWS no servers, no manual work, just pure cloud automation.

The problem: combining monthly expense CSVs every year is tedious and error-prone. So I automated the entire process.

🪣 Amazon S3 (Simple Storage Service)
Amazon S3 is a cloud-based object storage service that stores and retrieves any amount of data from anywhere in the world. It can also watch for new files and automatically notify other AWS services when something is uploaded.
💡 Think of it as a smart cloud hard drive the moment a CSV lands in S3, it wakes up Lambda automatically.

⚡ AWS Lambda
AWS Lambda is a serverless compute service that runs your code in response to events, without provisioning or managing any servers. You only pay for the milliseconds your code actually runs.
💡 Think of it as a worker who sleeps until you need them triggered, runs the task, goes back to sleep. No server running 24/7, no idle costs.

🔐 AWS IAM (Identity & Access Management)
AWS IAM is a service that controls access to AWS resources by defining who is authenticated and what actions they are authorised to perform.
💡 Think of it as the security guard of AWS without IAM, Lambda would not be allowed to touch a single file in S3.

📊 Amazon CloudWatch
Amazon CloudWatch is a monitoring and observability service that collects logs, metrics, and events from AWS services in real time.
💡 Think of it as the CCTV of your cloud application every log line, every error, every execution time recorded automatically.

⚙️ How The Pipeline Works:

Upload monthly CSV to S3
S3 fires an event → Lambda wakes up
Lambda reads the new file + existing master
Merges, sorts by date, removes duplicates
Recalculates category totals in South African Rand
Saves updated master file back to S3 instantly

📈 Real Results — 3 Months of SA Expense Data:
• ✅ 50 transactions merged automatically
• ✅ 0 manual steps required
• ✅ Categories: Groceries, Fuel, Utilities, Health & more
• 💰 Grand Total (YTD 2026): R41,859.97

🔗 Full source code, architecture diagram & sample data if you want to try:
👉 https://lnkd.in/dQNytjKD