Vibe coding is not a hobbyist trend anymore. Lovable, the platform we used to build our own resource planning tool and now partner with, has seen usage accelerate to more than one million new projects a week, and apps built on the platform now draw an average of 720 million visits a month.

Building your own internal tool used to be a six to twelve month decision. Now it can take six to twelve days to evaluate, build and deploy! That speed changes what's worth building. But, it doesn't change what makes a build the right call.

We’ve been through this a few times, most recently, making the decision to build our own resource planning tool. Here's the framework we used to evaluate the build, and some key considerations worth running through before you get started.

Start with these four key questions, not the price tag

We built a working prototype of our resource planning tool, Dialed, using Lovable for $127 in AI credits and 527 prompts. Less than 40 hours of effort total. This replaced a $35,000 annual cost for a SaaS tool we had become reliant on.

That's eye-popping, but it's also the wrong number to build a decision upon. A hundred dollars and a few prompts gets you a prototype. It does not get you a system your team relies on. Whether building makes sense comes down to four questions, and the price tag only answers one small part.

• How core is this workflow to operational success? A tool supporting a narrow internal task carries a different bar than one touching your primary revenue process, or one that's client-facing. The wider the footprint the more you have to consider the engineering and security cost that turns a prototype into something trustworthy and reliable. Data sensitivity, number of integrations, compliance requirements, and how many people depend on it all scale that cost up or down.

• How well does an off-the-shelf option actually fit? Workarounds and side spreadsheets are a signal, not a nuisance to tolerate. If your team has already half-built a shadow version of the tool you're paying for, that's a strong signal to consider a build option.

• Do you have someone who can own it, not just build it? More on this below, because it's the one most build stories skip entirely.

• What's your appetite for being the one responsible when it breaks? Trust us: at some point, it’s going to break. You need to consider your capacity to support the build before you get in too deep.

Dialed has kept paying off past launch. As our team uses it and gives feedback, we can ship fixes and new features in a few prompts, everything from a new integration to a UI update. That is a different kind of return than the $35,000 line item disappearing.

If the answers to your build vs buy question are "core workflow, decent fit, no clear owner, low risk tolerance," buying still wins. The math hasn't changed there. What's changed is the middle case: workflows that used to default to buy because building was too slow to justify are now worth a second look, because building got faster and, now, more reliable.

It's not really about speed. It's about who's allowed to build.

The old build-versus-buy calculus assumed building meant a six to twelve month project and a dedicated engineering team. That assumption is completely different now. However, with AI's ability to discover and exploit vulnerabilities at speeds and depths we haven't seen before, security matters even more than it used to. So does having someone who can maintain the thing after launch.

The bigger shift is who's doing the building. The person who understands the workflow best, who is the subject matter expert living inside the problem every day, can now prototype a solution around their own knowledge without waiting on an engineering team to translate it for them. That's real. It just moves more decisions into the "worth a second look" middle case above. It doesn't remove the four questions.

The ownership question is the one everyone skips

Most build-your-own-tool stories end at launch. That's the wrong ending, because launch is when question three, who owns it, actually gets tested.

Who owns this tool once it ships? Who gets the message when an integration breaks on a Friday at five o'clock? What happens when the person who built it takes a new role, or leaves?

Tools built this quickly can sprawl just as quickly. Without a clear owner (or, ownership team), what looks like innovation is closer to shadow IT with better production values. The same speed that makes a fast build appealing is what makes it easy to lose track of once nobody's explicitly accountable for it.

Building doesn't remove lock-in. It relocates it

This is where question four comes in, and it's worth naming directly: building internally doesn't eliminate lock-in, it moves it. There are two versions now. Builder lock-in: you depend on the one person who understands how the tool works, instead of a vendor's roadmap. Platform lock-in: the tool itself may be tied to whatever no-code or AI-build platform it was created in, which comes with its own switching costs down the road.

Good documentation and a handoff plan from day one address the first. This is easier than it used to be. Google recently introduced the Open Knowledge Format (OKF), an open, vendor-neutral way to package product requirements, system knowledge, and decision history in a form any AI agent or new team member can pick up, instead of leaving it in one person's head. If you instruct your AI tools to maintain an OKF package as the build evolves, handoff stops being a scramble.

It's also worth being honest that the cost curve doesn't flatten at launch. The upfront cost is genuinely lower than it used to be, but that cost shifts into ongoing maintenance and feature development instead of disappearing. Budget for that second, quieter cost, not just the price of the prototype.

Run the same four questions against your own renewals

Pull up your SaaS renewals for the next twelve months. For the ones your team complains about, run them through the same four questions above: how core is the workflow and who touches it, how well does the current tool actually fit, do you have someone who could own a replacement, and what's your risk tolerance if you're the one on the hook when it breaks.

None of that requires a technical background. It requires an honest look at how your team actually works, and a willingness to admit when a tool that seemed indispensable is really just familiar.

Vibe coding and the new tools for building fast aren't going anywhere, and they're only getting better. The organizations that benefit most won't be the ones who build the most. They'll be the ones who consider these four questions honestly, and know exactly which few things are worth building.

If you're working through that list right now and want a second set of eyes on where you land, that's a conversation we're glad to have.