Do What You Do Best, Vibe the Rest

"Do what you do best, outsource the rest," a famous business principle from management guru Peter Drucker, means focusing on your core strengths to achieve excellence while delegating non-essential tasks to specialists for greater efficiency, cost savings, and better overall results.

Early in my entrepreneurial career this was a key principle passed down to me from the tribal elders: keep your effort and time on your core business and strengths, do needle-moving things, and outsource everything else. Now I'm not saying this is completely untrue anymore, but I am saying the plates have been shifting and adaptations can and should be made.

For the past three years the world has been undergoing a truly fundamental change. AI has become interleaved with a significant chunk of our lives, both professionally and personally, from doing homework to doing your taxes. That being said, allow me to skip the trivial examples and use cases — I think at this point you've heard, seen, and actively utilized a whole lot, and the value of using ChatGPT, Claude, or any other AI-based tool is clear.

Code writing though, and I might be biased, has undergone a radical, fundamental change due to LLMs and their code-writing applications. A $100/month Claude Code subscription can, if properly set up, ramp up an engineer to be 2–3x more efficient while keeping proper standards and even maintainability given its done right. This is big. We are actively seeing tickets take nearly half the time from branch creation to merge (a real study we conducted over the past year, averaging month-over-month). The ability for engineers to take on more complex tasks, focus on architecture and structure, then have AI implement the majority of the code creates opportunities not just for product development acceleration but also for internal tooling and dev infrastructure. What used to be a hard dilemma of "should I take the time and effort to build it or should I just use something off-the-shelf" has in many cases shifted to a trivial "give it a vibe-coding go, see what you get, then reconsider."

---

For Us By Us

While the impact is tremendous for all development, production code should still be treated with due respect and processes, internal apps on the other hand, are the wild west. I'd argue that the concepts of good, clean & optimized code and architecture are irrelevant when it comes to internal apps, especially read-only ones providing monitoring and insights. It's a leap one needs to make and let go of the intrinsics of functions and classes to an abstract feature-based & driven approach — creating a development cycle of hours, not days.

---

Code Is King

Most dashboarding platforms today have evolved to be somewhat no-code/low-code, and while this was an enabler when code was a skill and craft left for the brave, it's become their Achilles heel in the vibe-coding era. We recently needed to set up a monitoring dashboard for LLM token usage and cost. The first go-to was Grafana, as the raw data was dumped into Postgres and most of us had touched and used Grafana at some point in life. After a couple of days of struggling with writing SQL queries in Claude and pasting them into Grafana, we had a reasonably nice dashboard that was annoying to maintain and covered the baseline metrics we needed. This is when we decided to give it a go as a dedicated internal app. We set up a simple repo with a README describing the task and structure, and after about half a day of iterations we had a full-blown app covering everything we had in Grafana, plus a full LLM tracing logger with capabilities we'd need to hack Grafana for weeks to come anywhere near. To me personally, this was a bit of an enlightenment. The time it took, the results, and the ease of maintaining it (for anyone on the team with VS Code) was a game changer.

---

It's Not About the Money

While this seems like a somewhat financial decision, that's actually not the main incentive as we see it. Even the best off-the-shelf tools require some onboarding, customization, and ramp-up — and that's assuming the features you need exist and are part of your tier. These tools were purposely built to be general-purpose and as such are packed with different features and customizations that you probably only need a mere subset of, yet setting them up is cumbersome and complex.

That's where a DIY tool shines: you focus on the few key features you need, adding more only if required and per specific team needs. You get your own tailored tool, integrated with your specific stack and matching your unique needs — you can even host it inside your own private network so it has easy access to your infrastructure.

---

The New Default

This isn't about replacing every SaaS tool you use — Slack, GitHub, and your core infrastructure tools aren't going anywhere. But for that long tail of internal needs — dashboards, admin panels, automation scripts, internal workflows — the calculus has fundamentally changed. The question is no longer "can we afford to build this?" but rather "can we afford not to own this?"

---

A Word of Caution

This approach works best when you embrace it fully. Don't try to architect a vibe-coded internal tool like you would a production system. Don't spend days on code review. Let it be a little messy. The goal isn't perfect code — it's a tool that solves your problem today and can be easily modified tomorrow. If you find yourself fighting the AI more than collaborating with it, you've probably overcomplicated the requirements.