The question I get most from mentees: "what portfolio project should I build?"

Everyone wants a list of ten. Here is the one build I would actually pick if I was starting from zero on AWS today.

Nothing clever, nothing new. Just the one hiring managers already know how to grade.

A portfolio's job is to give whoever's asking something concrete to dig into. Ten shallow projects get ten shallow questions. One deep one gets a long conversation, and long conversations are where offers actually happen.

Deep enough means the build makes anyone technical want to ask "why did you pick that?" instead of "what is this?" It has a clear user, one live URL you can put on the CV, and enough architectural decisions that you sound senior when you walk through it.

Simple to describe. Rich enough to talk about for thirty minutes.

A user types a long URL into a small web page. The system returns a short URL. When someone clicks it, they get redirected to the original, and the click lands in storage as an event. Then, once a week, the system reads its own click data and emails the owner a short plain-English summary. Top links, busiest day, where the traffic came from, what changed since last week.

That last part is the 2026 upgrade. Two years ago a URL shortener with a dashboard was a solid portfolio piece. Today anyone looking at a serverless portfolio piece wants to know one more thing. Have you shipped something with an AI service inside it, or have you only read about them? A weekly summariser running on Amazon Bedrock answers that before they ask.

And it is the right kind of AI. There is no chatbot bolted on the side. The model does one job. It turns a week of click data into three sentences a human wants to read. Small prompt, tiny cost, real output. That is what most production AI looks like, and almost no junior portfolio shows it.

Under the hood the build has three paths. A hot path that redirects clicks in milliseconds. An analytics path that streams click events into S3 without slowing the redirect down. And a weekly path where a scheduled Lambda aggregates the data, asks Claude Haiku on Bedrock to write the summary, and emails it to you.

One design rule holds the whole thing together: the model never sees raw click events. Your code does the counting. The model only narrates the totals. That single decision caps your AI cost forever, keeps the numbers honest, and hands you a senior-sounding answer to two hard questions at once.

The whole thing runs for under $2 a month, and AWS bills in dollars, so that is the number to say out loud. Most of it is logs and DNS. The AI part costs about 3 cents.

1. API Gateway + Lambda for the create-short-URL endpoint. One POST route, one function, one DynamoDB write. Where you show you understand handler shape, cold starts, and IAM roles per function.

2. DynamoDB single-table design. Short code as partition key, original URL as an attribute, click count as an atomic counter. Simple, and it explains why you did not reach for RDS.

3. Second Lambda for the redirect. Reads DynamoDB, bumps the counter, drops a click event onto Amazon Data Firehose, returns a 302. The event write takes single-digit milliseconds, so the redirect stays fast. Where you show you separate the hot path from the analytics path.

4. Firehose delivers to S3, partitioned by date. Firehose buffers your click events and writes them to S3 under a date prefix like clicks/dt=2026-08-04. You configure buffering, you write no batching code. Where you show you know why one S3 object per click would be an anti-pattern.

5. CloudFront + S3 static site for the front end. The tiny page that takes a long URL and shows the short one. Where you show you understand caching, HTTPS, and origin access control.

6. The AI leg: EventBridge Scheduler + Lambda + Bedrock + SNS. A weekly cron fires a Lambda. It reads the week's click files from S3, aggregates them in code, and sends the totals to Claude Haiku 4.5 on Bedrock with a short prompt. The summary goes out as an email through SNS. One catch worth knowing: Haiku is not hosted in the London region, so you call it through Bedrock's EU cross-region inference profile. Your request stays inside EU regions, and your IAM policy has to name both the profile and the model. That one paragraph of setup is the best Bedrock story material in the entire build.

Bonus if you have time: Route 53 for a custom short domain, CloudWatch dashboards for the ops story. And if you want the bill at zero instead of a few cents, swap Claude Haiku for Amazon Nova Micro. It runs in London directly and costs a rounding error. Knowing when the cheaper model is good enough is a model-choice conversation any senior engineer will engage with.

Portfolio is not production. Kill it once you are done with it, or pay every month for cloud services you are not using. Half the horror stories about surprise AWS bills start with a demo project someone forgot.

If you deployed with SAM, one command tears the whole stack down:

sam delete --stack-name url-shortener

Terraform users run terraform destroy. CDK users run cdk destroy. Same idea, use whichever matches how you deployed.

Three things a stack delete will miss, so check them by hand:

1. Your S3 bucket. CloudFormation refuses to delete a bucket that still has objects in it. Empty it first, then delete it.

2. CloudWatch log groups. Lambda creates them on first run, outside your template. They sit there quietly accumulating storage charges.

3. Bedrock model access. Costs nothing while idle, and switching it off in the console keeps your account tidy.

Ten minutes of cleanup is also a talking point. Knowing what a stack delete misses is exactly the operational detail that separates "I followed a tutorial" from "I ran this thing."

1. Skip authentication in v1. No Cognito, no user login. It matters that you knew when to punt on complexity. Shipping a whole SaaS is a different assignment.

2. Leave out CDK Constructs Library patterns you copied from the docs. Write the CDK yourself, or use Terraform, or use SAM. The point is that you can explain the deployment. Anyone can copy a snippet that runs.

3. No CI/CD pipeline you did not build. GitHub Actions with a single deploy step is enough. A three-stage pipeline you cloned from a tutorial is a red flag. Anyone experienced can spot tutorial code in ten seconds.

4. Do not chase "production-grade" perfection. Real production has 200 things you cut for v1. Your job is to name three of them out loud when someone asks and explain what you would add next.

The core build fits in a weekend. When it is running, three upgrades take it further, in this order.

Put Athena over your S3 data. At portfolio scale your Lambda can aggregate a week of clicks in code. At real scale it cannot. Adding Athena with date-partitioned tables lets you run SQL over months of history for a few cents, and gives you the "here is when I would stop aggregating in code" answer ready to go.

Build a tiny eval harness for the summariser. Save each week's aggregate numbers next to the summary the model wrote. Once a month, check the model's claims against the stored numbers. This is the 2026 question behind every AI feature: how do you know the output is good? Having any answer at all puts you ahead of most candidates.

Add a real-time anomaly alert. If a link suddenly gets ten times its normal traffic, you want a ping that day, and this is the honest reason to introduce EventBridge: the moment you have a second consumer for click events, a bus earns its place. Great follow-up story for "how would you extend it?"

Three ways to walk anyone through it, whether it comes up on your CV, in a code review, or over coffee:

"Walk me through your architecture." Start at the user click. End at the Monday morning email the system wrote about itself. Mention the three paths (hot for redirects, analytics into S3, weekly AI summary) as deliberate decisions.

"What would you change if it had ten thousand users?" DynamoDB throughput mode from on-demand to provisioned with autoscaling. CloudFront in front for edge termination, TLS, and DDoS protection (POST endpoints do not idiomatically cache). API Gateway usage plans or a WAF rate-based rule for rate limiting. This is where any senior engineer will see the difference between "I built the tutorial" and "I understand the shape."

"What tradeoffs did you make?" Chose DynamoDB over RDS for latency and cost at low scale. Chose Firehose over writing S3 objects directly from Lambda, because one object per click is an anti-pattern. Chose to aggregate in code and skip Athena, because a few megabytes a week does not need a query engine yet.

The mentee who lands the offer is the one who can say "I built this, here is what I would do differently, here is why I did not do it that way in the first place." That is a conversation. Ten shallow projects is a slideshow.

If you are stuck between ten scattered ideas and one focused build, pick the focused build. Every time.

The version I use with every mentee, covering what actually separates candidates who get hired, the skills matrix hiring managers use, a 90-day plan, and the five projects worth building, is a free 17-page playbook. Written for DevOps, but the hiring guidance and portfolio thinking apply to any tech role. Direct link, no signup:

📥 Download the DevOps Hiring Playbook (PDF)

💬 What is the last project you shipped? Or the one that has been sitting half-finished in your Notion for three months?

Reply with BUILD and one sentence. I will tell you if it is deep enough to become a real conversation or if it needs a small pivot to get there. I read every reply.

Know someone building the wrong portfolio? Share your referral link. 1 friend subscribes, you get a free LinkedIn Profile Optimisation Checklist.

{{rp_refer_url}}

Shola

P.S. Last five Tuesdays I said this newsletter is weekly again. This is week six of the promise. Feel free to keep counting.