I learn by doing so I have been busy building stuff with AI.
One project that started as a fun vibecoding experiment became a full month-end close production app (close checklist, streamlined recons, flux analysis, etc). I worked with some friends who are way smarter than me to move from “vibecoded” to production.
Check it out and let me know what you think…
There are a lot of things I learned as I built stuff with AI and also as I watched my teams “vibecode” stuff to help them in their functions. After about one year of building with AI in the finance function, here are my 1) five reasons not to vibecode internal apps and 2) two reasons why it may still be a good idea.
5 Reasons Not to Vibecode Internal Apps
1. It Always Takes Longer Than You Think
Everyone I have talked to on my teams has experienced the same thing. They get really excited after Claude farts out a pretty artifact that feels like it’s 90% of the way there. “We can cancel our forecasting tool! I just vibecoded something so we will save lots of money.”
The last 10% though takes 100,000% longer than the seemingly easy first 90% for any somewhat complicated app. This will get easier as AI and the tools continue to improve, but…it’s still really hard.
2. Cost Savings Aren’t What You Think
A lot of folks talk about cost savings as the reason they decided to build something in-house. And it sounds nice on a slide deck to the executive team or your board about how AI-pilled the company is becoming (have seen several of those).
But…it’s always more expensive than you think. It takes a lot longer to build (as mentioned above), but also sucks up a lot of time for everyone involved.
Also, any assumed cost savings will continue to shrink. We are seeing an explosion of AI-native, bootstrapped companies today thanks to AI and they are putting a ton of pricing pressure on the incumbents. Just go with a cheap tool from a startup…will probably be less expensive than you building it and it will very likely be better.
3. Vibecoded Apps Die With Vibecoder
Internal vibecoded apps usually have one primary owner. They designed it, QA’d it, they are behind the scenes trying to fix bugs, add features, etc when other people complain about it. It’s their baby.
So what happens when that person leaves the company?
Let me tell you from experience….nobody wants to adopt that person’s baby. Why would they? They don’t get the glory of building something that saves the company a bunch of money, but they now have to be customer support, customer success, and product development for it…
4. No One to Throw Under the Bus
Nobody ever got fired for buying IBM
IBM is obviously an outdated example and the vibecoding comparison is more extreme, but the idea is the same. By raising your hand and saying we can just vibecode this internally, you are taking on A LOT of responsibility.
It’s really nice to have someone external to throw under the bus when things go wrong. Compliance, security, user access, bugs, errors, etc. Otherwise that all falls on you…
5. How’s Your IT / Engineering Team Holding Up?
Here is another hidden cost…whoever is managing your teams’ hosted apps will get exponentially busier. When you have non-technical users vibecoding, eventually they will need IT to help “finish” it and then they need them every time something breaks (which will be a lot)
You are either going to have to hire more technical folks to maintain your internal apps or you are going to break your current folks and they rage quit.
When Vibecoding Internal Apps Makes Sense
Ok, I was pretty negative on vibecoding apps above but there are some good reasons to build internally.
1. Customization Matters
Sometimes you have a unique process or tech stack that isn’t fully supported by any existing vendors. And the lack of customization slows you down or makes things much more inefficient.
I believe this is the best reason for building internally.
If you can move faster and be more efficient because of the ability for endless customization (because you built it) then maybe it’s worth it.
2. The App Is Low Impact
Like I said above, saving money is rarely a good reason. But if the app is low impact and you don’t need a full enterprise app then building may make sense:
Your company is small
Doesn’t touch sensitive data
Limited number of users
Nothing blows up if the app is gone tomorrow
I think about the below a lot when I hear people on social media talking about the death of SaaS and all the cool stuff they are vibecoding:
Final Thoughts
There are a lot of internal AI slop apps. I have been asked to use many…
They can seriously slow down the business. Potentially saving a few thousand dollars per year means nothing for almost every VC-backed company. If you can’t grow, then you are dead anyway.
If building internally actually helps you move faster or more efficiently, then go for it. The point of this post is not to discourage it, but rather to think carefully about it. There will be lots of pride in these projects from the person leading the build, but sometimes/often the projects will need to be killed before they waste too much time.
Look up “sunk cost fallacy” and make sure your team understands it.