DEV Community: Shiva Matangulu

Building and Hosting a Custom Proposal Generator MCP Server on AWS: From Local Development to Production

Shiva Matangulu — Thu, 27 Aug 2026 16:42:14 +0000

How we built an AI proposal engine using Next.js, Google Gemini, and Model Context Protocol (MCP) - and architected a production AWS deployment that is fast, resilient, and cost-efficient.
1. The Challenge: Why Writing Proposals Stalls Real Work
Creating a professional proposal is often slow and manual. Teams must review client requirements, find the correct rates, calculate costs, write content, format it in branded templates, and organize the final files.
This process can take days, causes calculation and formatting errors, and takes valuable time from senior employees.
To solve this, we developed an AI Proposal Generator using Gemini (other models) and MCP, which automates requirement analysis, rate lookup, calculations, document generation, branding, and file management.
WHAT IS MCP?: The Model Context Protocol (MCP) is an open standard that decouples AI reasoning from tool execution. Instead of locking our AI logic into custom wrappers, MCP allows any LLM agent to securely discover, call, and coordinate back-end tools.
2. What the System Actually Does
The system connects AI chat with automated proposal generation through three main layers:
Next.js Chatbot UI: Users enter client requirements and interact with the AI through a web interface.
Google Gemini API: Understands the requirements, extracts the project scope, and decides which actions are needed.
Custom MCP Server: Performs the actual tasks such as generating DOCX proposals, XLSX cost sheets, timeline charts, and managing files through Google Drive.

**3. The Cloud Architecture: Why I Chose AWS
**I chose AWS to make the AI Proposal Generator fast, reliable, scalable, and cost-effective.
The system has three main goals:
Low latency: I run the Next.js application and MCP server together in Docker so they can communicate quickly.
High availability: I use multiple EC2 instances with a Load Balancer and Auto Scaling Group so the application can continue working even if one instance fails.
Cost control: I use Auto Scaling to increase or decrease resources based on demand, which helps avoid unnecessary costs.

With this AWS architecture, I can keep the application reliable, secure, and easy to manage while supporting future growth.
*4. How the Traffic Flows
*

Edge Tier (Route 53 & CloudFront): Users hit Route 53 DNS and CloudFront CDN, which caches my static Next.js assets at the edge to slash TTFB and reduce compute load.
Ingress & Routing (ALB): An Application Load Balancer terminates SSL/TLS and evenly distributes dynamic traffic across multiple Availability Zones while running active health checks.
Compute Tier (Multi-AZ EC2 ASG): I run my workload on t3.medium EC2 instances across us-east-1a and us-east-1b, ensuring the Auto Scaling Group can self-heal and scale on demand.
The 0ms Docker Network: By co-locating the Next.js UI and FastMCP server in a shared Docker bridge network (ai-network), I achieve 0ms local loopback latency (http://proposal-mcp:8000) for internal tool calls.
External Service Integration: The app streams chat tokens from the Google Gemini 2.5 API via SSE, while the MCP server interacts with the Google Drive API v3 to fetch rate-cards and upload final proposals.

**4. Key Takeaways & What's Next
**Building an AI application is not only about using an AI model. It is also about connecting the AI with the right tools and running them on reliable cloud infrastructure.
**1. Use MCP
**I use MCP to connect the AI with different tools. This makes the system flexible because I can use a different AI model or framework in the future without changing the whole system.
**2. Keep Services Close for Better Speed
**I run the Next.js application and MCP server together in Docker. They can communicate through an internal network, which helps reduce delays when handling large documents and files.
**3. Build for Reliability
**I use AWS services such as Auto Scaling, Load Balancer, multiple Availability Zones, and CloudFront to make the application more reliable and available.
**What's Next?
**The goal is to continue improving the system by making it more scalable, reliable, and automated as the number of users and proposal requests grows.
JOIN THE CONVERSATION: Are you building MCP servers or AI applications on AWS? How are you hosting your AI workloads? Let's discuss in the comments.

AWS Amplify: What I Learned Building Cloud-Connected Applications Without Managing Everything Manually

Shiva Matangulu — Fri, 21 Aug 2026 06:13:51 +0000

**How a higher-level developer workflow changed the way I think about building on AWS and what I’d do differently next time.
**Introduction: AWS Is Powerful, But Sometimes That’s the Problem
One thing I’ve noticed while working with AWS is that the platform gives you almost everything you could possibly need.

That is also the problem.

You can build an application using services such as Amazon Cognito for authentication, Amazon S3 for storage, Amazon DynamoDB for data, AWS AppSync or API Gateway for APIs, Lambda for backend logic, CloudFront for content delivery, and several other services depending on what you’re building.

That flexibility is great.

But for a developer who simply wants to build an application, connecting all of those pieces together can become a project of its own.

This is where AWS Amplify becomes interesting.

Instead of manually configuring every AWS service and wiring the frontend to each one, Amplify provides a developer-focused layer for building and deploying cloud-connected web and mobile applications.

AWS describes Amplify as a toolkit for building full-stack applications, providing backend capabilities, frontend libraries, UI components, and hosting.

But I don’t think Amplify is best understood as “AWS made easy.”

It is better understood as:

A developer workflow that makes common AWS application architectures easier to build, connect, and deploy.

And that distinction matters. Because Amplify can make some things surprisingly simple — while other parts can still require you to understand what AWS is actually doing underneath.

Why I Started Looking at Amplify
I came across Amplify while I was already working inside the AWS ecosystem and getting tired of how much time went into wiring services together before I could even start on the actual product. I’d set up Cognito user pools, then spend an afternoon on IAM policies just so my frontend could talk to a DynamoDB table through API Gateway — and that was before I’d written a single line of application logic.
What interested me wasn’t simply the idea of “deploying a website.” I was more interested in the possibility of connecting a frontend application to cloud services without spending most of the development time configuring infrastructure. I wanted to spend my time on the product, not the plumbing.

That made Amplify worth exploring. And this is one of the things I think developers should understand about it:

Amplify is particularly interesting when your application needs more than just hosting.

If all you need is to host a static HTML/CSS/JavaScript website, there are many ways to do that. Amplify becomes more interesting when your application starts needing:

User authentication
Authorization
APIs
Database-backed data
File uploads
Serverless functions
Hosting
Continuous deployment
That’s where the pieces begin to fit together.

Big Takeaway
Amplify makes common patterns easier — but understanding the AWS services underneath (Cognito, S3, DynamoDB, Lambda, AppSync) is what makes Amplify easy to use well.

From Code to Cloud: What I Taught at the AWS User Group Nepal Meetup

Shiva Matangulu — Mon, 10 Aug 2026 07:55:16 +0000

Last Friday, I had the opportunity to lead a hands-on AWS workshop at the AWS User Group Nepal Meetup, hosted at Banepa College of Management & Technology in Kavrepalanchok. The session, "From Code to Cloud: Build, Deploy & Showcase with AWS," was designed for beginners — students and early developers who understood how to write code but had never deployed anything to a live server. My goal was to take them on a full journey: from understanding how a website works at a fundamental level, all the way to deploying a real, working site on AWS.
Starting With the Fundamentals
Before touching the AWS Console, we broke down how a website actually works — the DNS lookup, the request traveling across the internet, and the server responding with HTML, CSS, and JavaScript. I find that skipping this step is where most beginner cloud content goes wrong; you can't appreciate what AWS automates for you until you've seen the manual version.
From there, we compared traditional hosting models — shared hosting, VPS, and dedicated servers — against cloud computing, covering the core challenges of owning physical infrastructure: fixed capacity, hardware maintenance, downtime, and high upfront costs. This set up the "why" before the "how."
Cloud Service Models: IaaS, PaaS, SaaS
Using real-world analogies (renting an empty house vs. eating at a restaurant vs. using Netflix), I walked through the three service models and mapped each to concrete AWS examples:
● IaaS — Amazon EC2 (raw compute, storage, and networking)
● PaaS — AWS Elastic Beanstalk (managed application platform)
● SaaS — fully managed end-user software
Core AWS Services Covered
The heart of the workshop was a tour of AWS's building blocks — with 200+ services in the AWS ecosystem spanning compute, storage, networking, databases, AI, analytics, security, and developer tools. We focused on the services most relevant to a first deployment:
● Amazon EC2 — virtual servers for compute
● Amazon S3 — object storage, and static website hosting
● AWS IAM — identity and access management
● Amazon VPC — private virtual networking
● Amazon RDS — managed relational databases
● Amazon DynamoDB — managed NoSQL database
● AWS Lambda — serverless compute functions
● Amazon CloudFront — content delivery network (CDN)
● Amazon Route 53 — DNS and domain routing
● Amazon CloudWatch — monitoring and metrics
● AWS CloudTrail — API activity auditing and logs
Hands-On: Deploying a Static Site on Amazon S3
We got hands-on early with the simplest, most cost-effective deployment path — static website hosting on S3. Step by step, attendees:
● Created an S3 bucket
● Uploaded HTML, CSS, JS, and image files
● Enabled Static Website Hosting on the bucket
● Configured a bucket policy for public read access
● Accessed their live site via the generated S3 website endpoint
We then contrasted this with hosting a dynamic site on EC2 — launching an instance, configuring security groups, connecting via SSH, installing a web server (Apache/Nginx), and serving files from the instance's public IP — to make the trade-offs between S3 and EC2 concrete rather than theoretical.
Planning for Cost and Good Architecture
No AWS workshop is complete without talking about cost. We used the AWS Pricing Calculator to show how to estimate infrastructure costs before deploying anything, and closed the session with the six pillars of the AWS Well-Architected Framework: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability — the same principles that guide real production architecture decisions.
Why This Matters to Me
As an AWS Certified Solutions Architect – Associate, sessions like this are exactly why I'm passionate about community-driven cloud education. Watching beginners go from "I don't understand what a server is" to "I just deployed my own site on S3" in a single afternoon is the kind of tangible impact that keeps me investing in the AWS community in Nepal.
Huge thanks to AWS User Group Nepal and Banepa College of Management & Technology for organizing this, and to our supporters — Genèse, IMS Software, and Women in Big Data Nepal — for making it possible. Looking forward to more sessions like this.

📅 From Code to Cloud: Build, Deploy & Showcase with AWS
📍 Banepa College of Management & Technology, Kavrepalanchok
🗓️ Friday, 7th August 2026