Building Your First GenAI Serverless Project to Enhance Your CV

A weekend project that shows you can ship AI on AWS and makes your resume impossible to ignore.

Hey, it’s Lefteris 👋 I’m the voice behind the weekly newsletter “The Cloud Engineers.”

Everyone tells you to “build projects” to stand out. But most portfolio projects are the same tired to-do app or a static site that says nothing about you as an engineer. In 2026, a fast way to make a hiring manager stop scrolling is to show you can ship a real-world project, like the serverless GenAI application we'll build in this article.

The good news: you don’t need a GPU cluster, an ML degree, or months of work. With AWS Lambda and Amazon Bedrock, you can build a genuinely useful GenAI app in an afternoon which is fully serverless, pay-per-request, and free-tier friendly.

So let’s design one. We’ll build a tool that enhances your CV. You give it a job description and your rough resume bullets, and the app rewrites them into sharp, tailored, results-oriented bullet points using a foundation model. It’s useful, it’s self-referential, and it demonstrates the full serverless-GenAI stack.

This article is about the thinking behind the project, the architecture, the decisions, and the career payoff. No code walls, just the blueprint you need to go build it.

The Idea: A Serverless AI CV Enhancer

The concept is simple. A user pastes in two things:

1. The job description they’re targeting.

2. Their current resume bullets rough, honest, unpolished.

The app sends both to a foundation model with a carefully written instruction: rewrite these bullets to be sharp, quantified, and tailored to this specific role. Seconds later, the user gets back stronger bullets they can drop straight into their CV.

Why this project works so well as a portfolio piece:

• It’s genuinely useful. You’ll actually use it. That authenticity comes through when you talk about it.

• It’s self-referential. “I built the tool that wrote the bullet point describing this tool” is a hook interviewers remember.

• It touches the whole modern stack. API, compute, a foundation model, and a database — the complete shape of a real GenAI application, in miniature.

The Architecture

We’re keeping this deliberately simple. Four managed building blocks, all serverless, nothing to patch or babysit:

Client  →  API Gateway  →  Lambda  →  Amazon Bedrock
                              │
                              └──────→  DynamoDB (history)

• Amazon API Gateway: the front door. It exposes a single endpoint your app (or a curl command) can call.

• AWS Lambda: the brain. It receives the request, assembles the instruction for the model, calls Bedrock, and stores the result. It runs only when called, and you pay only for those milliseconds.

• Amazon Bedrock: the intelligence. This is AWS’s managed gateway to foundation models (like Claude). You call an API; AWS handles the model hosting, scaling, and infrastructure entirely.

• Amazon DynamoDB: the memory. It stores each enhancement so users have a history and so you have a reason to talk about data modeling in interviews.

The beauty of this design is what’s absent: no servers, no containers, no idle cost, nothing to keep patched. When no one’s using it, you pay essentially nothing.

The Real Product Is the Prompt

Here’s the insight that separates a good GenAI project from a toy: most of the quality lives in how you instruct the model, not in the plumbing.

The plumbing like API, function, database is standard serverless work. What makes this app good is a well-structured instruction to the model: telling it to act as an expert resume writer, to use strong action verbs, to quantify impact where plausible, to tailor to the target role, and to return clean output. That instruction is your product. Iterating on it, testing it against real job descriptions, tightening the wording, is where you’ll spend your most valuable time.

This is worth internalizing, because it reframes what “AI engineering” often means in practice: it’s less about training models and more about integrating them well and instructing them precisely.

See It In Action

Once you build and deploy the application, using it is as simple as sending your target role and your rough bullets. Feed it something honest and unpolished like:

• Worked on the payments service

• Helped with the migration to Lambda

• Fixed bugs in the API

...and it returns something tailored and sharp:

• Architected and shipped a payments service processing millions of daily transactions on AWS

• Led migration of the core API to a serverless Lambda architecture, cutting infrastructure cost significantly

• Improved reliability by resolving critical API defects and adding integration test coverage

Same you but sharper story. A quick note on integrity: use this to articulate real work more effectively, not to invent it. The goal is to describe what you genuinely did in the strongest honest terms.

How to Level It Up (and Talk About It)

The base project is enough to ship. But each of these additions gives you another thing to discuss in an interview, pick based on what you want to signal:

1. Add a simple frontend. A one-page static site that calls your API turns this into a full-stack demo you can link to from your CV.

2. Add streaming responses. Have the enhanced bullets appear word by word instead of all at once. It signals you care about user experience, not just the happy path.

3. Add observability. Structured logging and request tracing across the whole flow. This is the difference between a demo and something production-minded.

4. Add richer history. Let users query their past enhancements by date. A clean excuse to demonstrate access-pattern-first data modeling in DynamoDB.

What This Project Actually Signals

When this lands on your CV as “Built a serverless GenAI application on AWS (Lambda, Bedrock, API Gateway, DynamoDB),” here’s what a hiring manager reads between the lines:

• You can integrate foundation models into real applications a high demand skill of the moment.

• You understand serverless architecture and event-driven design, not just in theory.

• You can ship end to end, from idea to API to persistence.

That’s a lot of signal from an afternoon of work.

Conclusion

The barrier to building with GenAI has never been lower. A managed function, a Bedrock call, and a simple database are enough to build something genuinely useful and genuinely impressive on a CV. The fundamentals still apply: keep it simple, scope your permissions tightly, watch your cost, and design around the real problem.

So this weekend, don’t build another to-do app. Design and ship the CV enhancer, then put it on the very CV it enhances. Then tell me how it goes.