Why I Stopped Duct-Taping My Business Together

And Started Building What I Actually Need

Created by Author with Nano Banana

There’s a moment every entrepreneur hits, usually around the third or fourth tool they’re paying for that only does 60% of what they need, where you start doing math that doesn’t add up. Not to mention the frustration with having to duct-tape solutions together to “almost” get what you need.

$49/month for this. $97/month for that. $299/month for the platform that was supposed to handle everything, but somehow requires two other tools just to function, along with the joy of having the tool that connected the other tools sends error messages that your automation/connection/workflow broke or isn’t working (which somehow always seems to show up on the day you don’t have the time to deal with it).

And you’re still manually copying things between systems.

I’ve been building businesses on the internet for nearly 18 years. I started as “The WordPress Chick” (I fell in love with WordPress and thought it was a fun name, even though I knew as little as I did at the time. Ignorance was bliss). I embraced it fully, even though that wasn’t my intention when I started my business. I ran an agency, built an outsourcing company, and grew a content business that generated real revenue. I know the tool stack spiral intimately. I have lived it and paid for it many times over.

Created by Author with Nano Banana

Let Me Paint You a Picture

WordPress was actually one of the better examples of the industry solving a real problem. Before it, getting a website meant hiring a developer or learning to code. WordPress democratized publishing. Beautiful.

And then... the plugin space blew up.

When I started in 2008, you needed a plugin for even the simplest of things (rearranging the order of the pages in the navigation). You needed a plugin for your forms, another for SEO, one more for e-commerce (and for the love of all that is good in the world, I hate WooCommerce, lol), and if you wanted to actually sell something simple or host a course, you were suddenly managing a small ecosystem of tools just to have a functional website.

Kajabi came along and said, “We’ll do it all.” And they did. Kind of. Sort of. Enough of it. For a price that makes you feel the sting every single month, even when the features don’t quite fit your actual workflow. Kajabi spent so much time teasing, talking, and pre-launching the product that people were sold on it before realizing it wasn’t all that great (at the time).

The truth is, these platforms aren’t built for you. They’re built for the median customer. The average of everyone who uses them. Which means the features are designed for a composite fictional person who doesn’t actually exist, and you’re left bending your business to fit the tool instead of the other way around. You’re also at the mercy of what the founders decided were important features, not necessarily users.

Then There’s Notion.

I’ll be fair: Notion is genuinely incredible. It’s powerful and flexible, with a clean design. And I know people who have built entire operating systems inside it.

My brain just does not work in databases.

No matter how many times I jumped back into Notion, I never really wanted to log in and use it. I had a great time setting things up, but that’s about it. I would open it, stare at it, feel vaguely guilty about not using it properly, and close it. I paid for it for longer than I should have because I was convinced that if I just found the right template, it would click. (Note: it did not click.)

This is not Notion’s fault. It’s actually a perfect illustration of the real problem: there’s no such thing as the right tool for everyone. There’s only the right tool for you, your brain, and how you actually work.

So What Changed?

About a year ago, I discovered vibe coding.

The first thing I actually built, a quiz, I did in Lovable. I was blown away that just talking through it the way you’d explain a problem to a developer, Lovable would actually build it. Functional, looked the way I wanted it to look, and I actually had fun building it.

I’m not a developer; I don’t write code in the traditional sense. But I can tell an AI what I need with enough clarity that it can build it for me. And that changed everything.

What I’ve built since then is what I call the Hub (Kim’s Hub… who needs a catchy name when I’m the only one using it?), my own custom business operating system, built on Next.js and Supabase. It sounds more technical than it is to use. What it actually is: a dashboard that has everything I need in one place, in the way my brain works, with an AI assistant (I named her Metis, after the Greek goddess of wisdom and strategy) wired directly into it.

My content pipeline lives there; I track my client work, my Substack notes, drafts, and research live there. My research agents live there. I open it every morning, and it’s... mine. It works the way my brain thinks, looks great, and nothing is bent to fit someone else’s workflow.

Is it perfect? No. Am I still building it? Every week. But that’s kind of the point.

A Screenshot of the Hub.

Let Me Give You Two Examples Of What I Mean

One of my clients hired me to build her version of the Hub for her business, and the result looks completely different from mine. Same foundation, completely different implementation, because her business model is different, her workflows are different, the problems she’s solving are different.

We’re not configuring a SaaS product to fit her needs. We’re building her actual needs from scratch. The ability to create custom solutions are what makes this approach fundamentally different from anything that came before it.

The second example comes from the world of Substack scheduling. Substack recently released scheduling, but it’s basic — pick a date, pick a time, publish. No batching, no calendar view, no drafts queue. And because Substack doesn’t offer a public API, third-party tools can’t officially integrate with it. So a handful of developers found another way, reverse-engineering the scheduling through authentication cookies. The tools they built are beautiful, polished products that are growing real businesses because they solve one very specific problem for an audience that needed it solved and wasn’t getting it from the main platform.

And here’s the part I want you to hold on to: big platforms won’t solve your niche problem because it’s not their priority. Their roadmaps are shaped by what serves the most users and delivers the highest return on investment for their investors. Not for you. Users are second. That’s not cynical, it’s just how the economics work. So, the gap between what the platform does and what you actually need? That’s yours to fill now.

What This Actually Requires

Here’s the honest version: a year ago, if you’d told me I’d be building in Cursor and VS Code with Claude Code, self-hosting everything, I’m not sure I would have believed you. I started with Lovable and Mocha, proper vibe coding tools with guardrails, and within a handful of months, I’d migrated off the platforms entirely for more control. I didn’t see that coming.

The best part about that move was that things don’t break the way they used to on those platforms (and I know they’ve improved since then, also, just like my skills have). I also have way more context (usage) than I did on those platforms, and my monthly cost is less.

There’s something almost liberating about not knowing enough to anticipate all the ways something could go wrong. You just build, and when something does break, you figure it out.

Early on, Jenny Ouyang (who many of you know from this community) helped me shift how I was working last year when I became an early paid subscriber, and we hopped on a call. She shared her Master Coding Constraints, and all of a sudden, I saw building in an entirely new light.

One thing I want to be clear about is that I’m not learning to code. I’m learning processes, workflows, how pieces of the puzzle fit together, when to use the command line, and what the terminology actually means (seriously, last year I had no idea what terminal was). None of that was required before I started. I figured it out as I went.

I’ve also built close to 15 apps/tools over the last year and shipped exactly six of them. Two of which are my website and my hub. I’m not worried about it. Each build taught me something the last one didn’t, and they’re coming. That’s how this works.

What I think gets overlooked in most conversations about building with AI is this: women are already really good at figuring things out. Managing careers and families and businesses and about seventeen other things simultaneously. That’s not a small skill set; that’s a superpower.

Whether you’re technical or not, whether you’re 28 or 58, you bring a lifetime of solving problems that weren’t designed with you in mind. And that experience, knowing exactly where the gaps are, exactly what’s missing, exactly what a tool should do but doesn’t, is precisely what makes building something of your own so compelling. The technology didn’t create that instinct. It just finally gave us somewhere to put it.

The 16 years I spent in the WordPress world, watching plugins stack up, and platforms charge more for features that still didn’t solve the actual problem, weren’t wasted. It was research. I knew what I wanted to build because I’d spent years being annoyed at what didn’t exist.

One more thing, to be clear: this isn’t an argument against paying for tools. If something already exists that solves the problem well, and building it yourself would take longer than the value you’d get back, pay for it. That math is real.

Just because you can build something doesn’t mean it’s the best use of your time. The question worth asking is whether the tool genuinely solves the problem or whether you’re just tolerating the 60% it does well and working around the rest. That’s the version worth replacing.

And not everyone wants to be a builder, and that’s completely fine.

The point isn’t that everyone should go build custom software.
The point is that for the first time, if you want to, you can.

---

If This Resonated With You

We’re so grateful to Kim Doyal for allowing us to share her story here on Code Like a Girl. If this resonated, don’t just read it. Follow her work. Writers like this deserve readers who show up.

This Is What We Do

What you just read? That’s what we do.

Since 2016, Code Like a Girl has been finding writers like Kim, women and non-binary technologists doing serious, thoughtful work that deserves a much wider audience.

The women we feature are building products, leading teams, shaping AI, questioning systems, and redefining what leadership in tech looks like.

Three times a week, we publish their work.
Through Substack Notes and social media, we extend its reach.

The future of technology is being built by women like this.

If you want more voices like hers in your feed, you’re in the right place.