Writing
September 26, 2025 · 8 min read

The Joy of Building: A PM's Journey from 'Why Not?' to Production

How a casual browse led to an 8GB container, semantic chunking experiments, and eventually a ~250MB production container—and why the journey was worth every iteration

The Spark: One Less PM Without a Portfolio

I was doom-scrolling through my usual LinkedIn feeds when Aakash Gupta’s post hit me like a well-timed notification. His thesis was simple but brutal: most PMs don’t have portfolios, so building one creates unusual ROI. The math was compelling—differentiate through demonstration, not just resume bullets.

But what caught me wasn’t just the business case. It was this line: “Very few PMs maintain one.”

I paused mid-scroll. Why was that true? Was it because we’re busy managing other people’s products? Because we think our work is too abstract to showcase? Or because we’ve convinced ourselves that shipping is someone else’s job?

Sitting there as a Senior PM at LexisNexis, surrounded by legal documents and AI systems I help shape but don’t actually build, a different question emerged: Why not me? And more importantly, why can’t I?

The “Why Can’t I?” Moment

That question—why can’t I?—turned out to be more dangerous than I expected.

As someone who spends days discussing semantic search improvements, chunking strategies, and retrieval accuracy for Lexis+ AI, I realised I could implement the techniques I was advocating—but I’d never built a production AI system that I could iterate on freely, measure rigorously, and optimise without enterprise constraints. Could I validate these chunking approaches on my own terms, with my own evaluation methods?

The PM in me knew this was both an opportunity and a validation test rolled into one.

If I were going to build a portfolio that demonstrated real technical depth—not just glossy case studies—it needed to showcase something genuinely sophisticated. Something that would make a hiring manager stop and say, “Wait, a PM built this?”

Down the Semantic Chunking Rabbit Hole

This is where my day job collided beautifully with my side quest.

At LexisNexis, we’d been wrestling with chunking strategies for our legal corpus. The standard approach—fixed 1000-word chunks—was causing what I call “context bleed”: issues, holdings, and facts cohabitating in large blobs where pronouns like “the accused” or “this doctrine” pointed to missing antecedents.

I’d been reading Wilson Lin’s write-up on building a search engine, where he advocated for sentence-level chunking with semantic context packing. The approach was elegant: make sentences the atomic unit, attach semantic context, and use a light model for statement chaining so each retrieved sentence brings the right antecedents.

Perfect. I’d validate this chunking approach on my own documents, then test it at work if the results looked promising.

The First Build: Go Big or Go Home (8GB Edition)

My initial architecture was... ambitious. ChromaDB for vector storage, sentence-transformers for embeddings, advanced semantic chunking with boundary detection, and the full local AI stack. I was going to prove that sentence-level intelligence could deliver the 35-49% improvement in retrieval quality that my testing suggested.

The results were genuinely impressive, validated through an LLM-as-a-Judge evaluation framework:

But there was a problem. Actually, several problems:

Container size: 8GB+ with all the ML dependencies. Build time: 10+ minutes Resource requirements: 4GB+ RAM just to run embeddings Deployment: Transferring 8GB containers is... not fun

I had built something technically impressive that was practically unusable. Classic engineer trap, even for someone who was only acting like one.

The Work Validation: Advocating Through Evidence

Before abandoning the approach entirely, I decided to validate the semantic chunking concepts through a more formal analysis. The research showed promise for legal documents specifically, since law is fundamentally sentence-quoted and pinpointed—lawyers cite specific sentences, not large text blocks.

I authored a whitepaper advocating for sentence-level intelligence approaches, which should help inform our AI strategy discussions.

This validation gave me confidence that the underlying approach was sound, even if my implementation was overkill.

The Reality Check: Portfolio vs. Enterprise

Here’s where PM instincts kicked in: I was building a Ferrari to drive to the corner store.

My portfolio site would have:

Meanwhile, I’d built a system designed for:

The technical sophistication was impressive, but the cost-benefit analysis was terrible. I was paying enterprise complexity costs for personal use case benefits.

Classic product mistake: building for imagined scale instead of actual usage.

The Pivot: Voyage AI and the Art of Letting Go

Sometimes the best product decision is knowing what not to build.

I stripped out the entire local AI stack and pivoted to external APIs:

The results were dramatic:

I kept the intelligent document processing and semantic context packing—the parts that actually improved user experience—while eliminating the infrastructure complexity that added no value for my use case.

Better product through subtraction.

Shipping to Production: Cloudflare and Beyond

The final system deployed beautifully:

But here’s what I learned: the technical architecture was only half the story.

What I Actually Built (Hint: It Wasn’t Just Code)

Looking back, this project delivered value across multiple dimensions:

For Me (The PM)

For My Work

For The Industry

As Aakash pointed out, differentiation matters. In a world where most PM portfolios look identical—the same case study templates, the same metrics, the same “I collaborated with engineering” language—technical innovation becomes competitive advantage.

This project proves that PMs can go deeper than requirements gathering. We can validate our hypotheses through code, understand implementation constraints viscerally, and build things that actually work.

The Learning - I cherish

The biggest learning wasn’t technical—it was emotional.

Building things from scratch is pure joy.

As PMs, we’re often several layers removed from the actual creation. We empathise with users, write specs, manage backlogs, analyse metrics, and coordinate launches. We enable building, but we don’t always build.

This project reminded me why I became fascinated with technology in the first place. There’s something magical about having an idea, writing code, seeing it work, breaking it, fixing it, shipping it, and watching real users interact with what you’ve created.

Every PM should experience this joy regularly.

Not because we need to become engineers, but because building things yourself changes how you think about product decisions. You understand tradeoffs differently when you’ve felt the pain of 8GB containers. You appreciate elegant solutions more when you’ve written terrible code. You communicate with engineering teams differently when you’ve debugged your own deployment failures.

Don’t give it a hug of death and be gentle on the tokens:

https://www.sundaradnus.ca

What’s Next: The Compound Interest of Building

This portfolio project has already compounded in unexpected ways:

But mostly, it broke the “why can’t I?” barrier. Now, when I see interesting technical problems, my first instinct isn’t “we should build this” but “I wonder if I could build this?”

That shift from spectator to creator changes everything.

For the PMs Reading This

Aakash was right about portfolio ROI, but he undersold the real benefit. Building a portfolio isn’t just about career outcomes—it’s about rediscovering the joy that brought you to technology in the first place.

Your portfolio doesn’t need to solve AI chunking or deploy to Cloudflare. It just needs to be something you built, something that makes you proud, something that demonstrates your ability to go from idea to working system.

The tools have never been better. The learning resources have never been more accessible. The barrier to building has never been lower.

So here’s my question for you: What’s stopping you from building something?

And more importantly: Why can’t you?

Technical Deep-Dive: What Actually Worked

For the builders who want the implementation details, here are the key architectural decisions that created value - well, you already know it. I don’t want to be embarrassed by my small contribution. :-)

Special thanks to Aakash Gupta for the portfolio inspiration and ROI framework, and Wilson Lin for the semantic chunking insights that made this technical journey possible.

Now go build something. The industry needs more PMs who know the joy of shipping code.

← All writing Home