Somewhere in the back of my mind, I’ve wanted to build an org chart tool for a while. Not because the world needs another org chart tool—there are plenty—but because over many years I saw the ones that exist don’t solve the problem we actually have. Struktr is a real now, thanks to 2 weeks of vibe coding with Claude Code.
The Problem
Org charts in tech companies are uniquely messy. The traditional hierarchy—CEO at the top, neat boxes cascading downward—doesn’t capture how modern product teams actually work. You have product managers, designers, and engineers who report to different people but collaborate on the same product areas. A designer might report to a Head of Design while spending most of their time embedded in a payments squad alongside engineers who report elsewhere entirely.
Existing tools fall into two camps. On one end, you have heavyweight HRIS systems—Workday, BambooHR, Rippling, etc.—that treat organizational structure as a byproduct of payroll and compliance. On the other, you have drawing tools that let you make pretty diagrams with no underlying data model. Neither helps you answer the question I kept asking: who is actually working on what, across Product, Design, and Engineering?
This frustration accumulated gradually. No single incident, just the slow recognition over more than 5 years that every company I worked with had some version of this problem. Spreadsheets passed around in Slack. Outdated Miro boards. The new VP asking for an org chart and someone spending half a day assembling one manually.
I knew what the solution should look like. A tool that understood cross-functional teams. That could show you both the reporting hierarchy and the domain structure. That was simple enough to maintain but complete enough to be useful. I could see it clearly. I just couldn’t build it.
The First Attempt
I tried once before. This was last summer. I had the architecture sketched out, the data models drafted, and ChatGPT open in a browser tab to help my (maybe rusty) coding skills work through the implementation.
It didn’t work—not because the AI wasn’t helpful, but because I was still doing the work manually. I’d describe a problem, get code suggestions, copy them over, run into errors, debug, iterate. Each feature took hours. A weekend would yield a login form and a database connection. The gap between what I envisioned and what I could actually ship felt insurmountable.
The abandoned codebase sat in a folder for months. I’d revisit it occasionally, convince myself I’d pick it up again, then let life get in the way. Time was the constraint. Not knowledge, not motivation—time. The economics of side projects simply didn’t work for someone with a full-time job and interests outside of coding.
This is, I suspect, a common story. Product people are full of ideas. Many of us can read code, understand systems, even fix bugs when needed. But building something from scratch, end to end, requires sustained effort over weeks or months. Most ideas die in that gap.
What Changed
My friend João—yes, two Joãos—showed me Claude Code over New Year’s Eve afternoon. I’d used ChatGPT for coding help before, so I wasn’t expecting a revelation. But Claude Code is different in ways that matter.
Instead of copying suggestions between a chat window and an IDE, Claude operates directly in the codebase. It reads files, creates branches, makes commits, runs tests. You have a conversation, but the conversation produces actual code in your actual project. The AI isn’t an assistant you consult—it’s a collaborator that ships.
This distinction sounds subtle but changes everything. When you’re copying code snippets, each context switch—read suggestion, paste, run, see error, go back to chat, explain error, get new suggestion—adds friction. The friction accumulates. A feature that should take an hour takes a day. A day’s work stretches to a week. Eventually you run out of weekends.
With Claude Code, the conversation and the codebase are unified. Claude reads the actual code, understands the actual structure, makes changes in actual files. When something breaks, it sees the real error and fixes it in place. The feedback loop tightens from hours to minutes.
After putting AI aside for some Moët and raisins, I spent that long weekend experimenting. Right after the first prompt in Plan Mode, I had a working React frontend with authentication, a Node.js backend connected to MongoDB, deployed on a free Render instance. By Sunday evening I had a refined product and Stripe integration for payments. Rough, certainly. Missing features, absolutely. But deployed. Live. With a proper domain name. Accepting signups.
The economics had shifted. Ideas that weren’t worth three months of evenings and weekends now cost a few focused days. The abandoned Struktr codebase finally had a path to completion.
How We Actually Built It
I started vibe coding on January 1st, 2026, with two separate repositories—one for the React frontend, one for the Express backend. Over the next few days and evenings, I made 157 commits across both repos. The core product took shape: org charts with three-department support, domain-based team structures, multi-tenant architecture, role-based permissions, and a complete subscription billing system.
The workflow that emerged was issue-driven development. I’d open a GitHub issue—”Add forgot password flow” or “Gate paid plans behind waitlist”—and work through it with Claude. Each issue became a focused conversation with a clear endpoint. Close the issue, ship the code, move on. Without this discipline, it’s easy to get lost in an endless stream of “one more thing.”
Claude Code has rate limits, and I hit them often during intense sessions. When that happened, I’d switch to ChatGPT for work that didn’t need codebase access—refining copy, thinking through user flows, drafting FAQ content. The vibe coding waited; the product thinking continued.
I deployed on day one. Broken styling, missing mobile navigation, edge cases I hadn’t considered—all of it live. This sounds reckless, but it’s the opposite. Shipping early surfaced problems I never would have found locally. Rate limiting issues appeared under real traffic. Dark mode contrast problems only showed up on actual screens. The feedback loop from production is irreplaceable.
On January 15th, I consolidated both repos into a monorepo. Managing two separate projects had become friction. With a single deployment, everything got simpler—one command to run the whole stack, one place to look for any file.
By January 17th, Struktr was launch-ready (maybe earlier, but that’s when I considered it ready for prime time). Two weeks from abandoned codebase to production SaaS launched on Product Hunt. (The PH launch was a dud, but that’s for another post!)
The Product Decisions
Here’s what I want to emphasise: Claude wrote the code, but I made the product decisions. Every pricing tier, every user flow, every “what should we build next” judgment was mine.
Pricing evolved through rapid iteration. The initial tiers didn’t feel right—too cheap at the low end, too steep a jump to the next level. I changed them three times in the first week until the structure made sense: a free tier for small teams, a startup tier at €29/month, and growth tiers scaling from there. Each change took minutes to implement. Testing pricing psychology used to require engineering resources; now it requires clear thinking about what you want to test.
Positioning required deliberate choices. Early on, I added an FAQ item: “Is Struktr an HRIS?” The answer is no—emphatically. Struktr doesn’t handle payroll, benefits, or compliance. It’s a visualisation tool for cross-functional teams. That single FAQ entry clarifies the product’s scope more than any feature list.
Feature prioritisation was constant. What matters for launch? What can wait? I chose to build CSV import early because bulk employee uploads are essential for testing with real data. I deferred advanced analytics because they’re nice-to-have, not must-have. These are product management judgments. Claude can implement anything—but deciding what to implement is still entirely human.
What I Actually Learned Vibe Coding
Vibe coding isn’t a shortcut around product thinking. Vibe coding is an accelerator for implementation that makes product thinking matter more. When you can build anything quickly, choosing what to build becomes the bottleneck.
Clarity of requirements is everything. Fuzzy descriptions produce fuzzy code. When I knew exactly what I wanted—the API contract, the user flow, the edge cases—Claude delivered it cleanly. When I was vague, the results were muddled. The AI amplifies whatever you bring to the conversation.
I learned more vibe coding in two weeks than I had in the years of occasional coding after I stopped coding full-time. Content Security Policy, Stripe webhooks, React rendering patterns—Claude explains as it builds. This isn’t replacing the craft. It’s making the craft accessible to people who understand systems but lacked the time to implement them.
One more observation: the tools complement each other. Claude Code has usage limits, and I hit them regularly during intense sessions. When that happened, I’d either get up and touch grass, or switch to ChatGPT for the work that didn’t require codebase access—drafting marketing copy, brainstorming positioning, thinking through pricing psychology. The vibe coding waited for Claude Code; the product thinking could happen anywhere. This forced separation turned out to be useful. It gave me time to think before building more.
Is vibe coding the future of building software? I don’t know. Struktr is one data point. But it’s a data point that suggests the economics of side projects have fundamentally changed. Ideas that used to die in the gap between vision and implementation now have a path to production.
That feels worth paying attention to.