Vibe coding #1: the idea is born

Why I'm building a Luxembourg tax tool, letting go of corporate PM ego, and doing it all in public

I was scrolling through my phone when the headline appeared: "Tax deduction cap increases from €3,200 to €4,500."

I have decent tax knowledge from my professional and personal experience. Throughout the year, when planning expenses, I match expense types to tax deduction capabilities. My process typically starts one of two ways: either an expense occurs, or news pops up on my phone that catches my attention.

Then I go deep. I read the law to confirm I have the latest information. If needed, I contact the tax authorities to verify my understanding. Then I engage with service providers to ensure that the expense I’m planning will qualify for the deduction.

This process is worth it. Last year alone, I received a €50K tax refund.

But it’s also entirely manual.

That's when the idea hit me: "What if I make this process automatic with AI?"

Not just for me. For anyone paying taxes in Luxembourg who wants to make informed financial decisions without spending hours decoding regulations in languages they don’t literally speak (French or German), or navigating the professional jargon of understanding tax code.

I’m going to build it.

What Corporate PM Taught Me (And What It Didn't)

In 2025, I started my newsletter. I began engaging with other writers and creators outside the corporate world. And I noticed something striking.

Many creators have much stronger hands-on PM skills than corporate PMs.

They build. They ship. They iterate based on real feedback. No stakeholder alignment meetings. No three-month roadmap planning cycles. No resource allocation negotiations. They just make something, put it in front of users, and see what happens.

I spent 15 years in corporate environments. I’ve led programs worth hundreds of millions. I know how to manage stakeholders. I know how to prioritize competing demands. I know how to get buy-in from executives who all think their priorities should come first.

Corporate PM work is sophisticated. There’s real value in knowing how to navigate complexity, align diverse stakeholders, and deliver programs at scale.

But here's what I never learned: how to actually build something myself.

That gap matters more now because AI is reshaping the entire dynamic. Tools that once required specialized technical skills are now accessible to anyone willing to learn.

Recent post from CEO of Maven talks about how many experienced professionals (senior engineers, product managers, designers) learned valuable skills 15-20 years ago and have been relying on that same skillset ever since, assuming their seniority would protect them.

He’s right. And I'm intrigued by what I might discover when I build with my own hands.

Here's my approach: solve a problem that actually bothers me.

If I can build something that saves me hours every year, that’s time I get back. If it helps 10 other people in Luxembourg, even better. If it never scales beyond that, I still win.

My metric for success isn’t how many users I get. It’s whether I eliminate this manual process from my own life.

Letting Go of the Expert Identity

The first thing I had to release was ego.

For 15 years and my time at Amazon, I’ve been the person who reviews products. Who evaluates feasibility. Who asks the hard questions: “Have you thought about this edge case? What happens if this scales? How will you maintain this?”

Now I’m the person building something that will inevitably have edge cases I didn’t anticipate, scaling challenges I can’t foresee, and maintenance issues I’ll have to figure out as I go.

That requires a different posture. One that’s less about expertise and more about curiosity.

Here’s what I’m letting go:

• Being the expert. In this project, I’m starting with questions. Lots of them. Most are basic to people who’ve been coding for years.

• Having a team. I’m used to delegating. Now, if I want something researched, built, or designed, I do it myself. Or I ask AI tools to help me. But there’s no team to shield me from my own skill gaps.

• Producing polished work. Corporate environments reward polish. Clean presentations. Refined decks. Buttoned-up deliverables. But learning in public means showing messy progress. Half-working prototypes. Ugly interfaces. Questions that reveal I don’t understand something obvious. That’s uncomfortable for someone trained to present only finished work.

Here’s what I’m embracing:

• The beginner mind. There’s freedom in being new at something. No reputation to protect. No expectations to meet. Just pure learning for its own sake.

• Joining a community to grow together. I first joined Substack to follow famous VPs from FAANG companies and top founders and CEOs. Later, through Sam Illingworth I discovered Code Like A Girl and found Karen Spinner's newsletter. I'm looking forward to learning through her recent paid offering.

• Building for myself first. I'm not trying to create something perfect for millions of users. I'm solving my own problem. If it works for me, it's a success. If it helps others too, that's a bonus.

This shift isn’t just about learning to code. It’s about reclaiming a version of myself that got buried under years of corporate conditioning. The part that’s curious, experimental, willing to look foolish in pursuit of understanding.

Why I’m Doing This in Public

I’m documenting the journey publicly. Here’s why.

• Accountability. If I announce I'm doing this, I can't quietly give up when it gets hard. If I abandon this halfway through, I'll have to own that choice. Public commitment creates momentum that private learning doesn't.

• Mentorship. By sharing my progress and questions, I'm inviting people with domain expertise to guide me. I'm looking for developers who've built similar tools, designers who understand how to make financial tools approachable, and tax experts who can validate my assumptions about Luxembourg regulations.

• Community. Learning alone is possible. Learning with others is more interesting, especially since I spend most of my time alone with a computer. I'm building this in public because I want to invite people into the process, not as passive observers, but as active participants.

What Happens Next

You’ll see a series of posts from me documenting this journey: to develop a skill I don’t currently have. To understand what it’s like to create something from nothing. To bridge the gap between reviewing products and building them.

---

Want to join this journey?

Comment below if you:

1. Have domain expertise (coding, design, tax regulations) and you're interested in mentoring someone who's learning in public.

2. Want to join the beta test crew (must be paying taxes in Luxembourg) I'm opening this to 10 beta testers only. First come, first served.

---

If you're also learning something new in 2026, something that requires you to be a beginner again, I'd love to hear about it. What are you building? What are you figuring out? What's making you uncomfortable in the best possible way?