Thoughts on Vibe Coding, Build vs. Buy, and the future of SaaS
As you may have seen, about two weeks ago I finally decided to build a knowledge aggregation system. Having seen a steady stream of similar projects on my T̶w̶i̶t̶t̶e̶r̶ X timeline, I wanted to build something like a “second brain” that would sync all of our company’s data into a searchable, AI-powered knowledge base. Think Glean (which I’ve heard is great but unfortunately not available for smaller companies), but homemade.
13 days and ~43,800 lines of Python later, here’s an update.
What it does
Knowledge Hub (the not very creative working title) pulls data from the primary systems that we run on at Point Nine: Gmail, Google Drive, Slack, Zendesk, Attio, and Granola.
The system can also ingest data from ChatGPT. Given how many conversations we’ve all had with ChatGPT over the last few years, I thought this might make sense, but it’s still TBD how useful this will be in practice. So this is an experimental feature in an already experimental application. The Dropbox integration has been built but not yet enabled in production. Since we use Dropbox to store sensitive documents, I want to invest more time into security testing before enabling it.
All data gets processed into a vector database (Qdrant) with semantic search. It’s then connected to Claude via MCP servers (local for Claude Desktop, remote for Claude.ai in the browser). Using Claude, you can ask natural-language questions like:
- “How is Company X doing?”
- “Have we seen Company Y?”
- “What did we discuss with Company Z?”
…and get AI-powered answers with sources.
In addition, I’ve also created a Slack bot that allows you to get information from the vector database in a faster way. It uses regex-based question classification and only hits Claude for the final answer (with tighter constraints — shorter responses, no extended thinking). This makes it snappier for quick lookups (what you expect from a Slack bot) while Claude with MCP gives you Claude’s full reasoning power for a larger variety of questions.
Architecture
At a high level, the system is split into three main layers.
- At the top sits a simple web app that handles authentication, user management, and the dashboard. This is the part users interact with directly.
- Below that is a set of background services responsible for syncing data from external systems, running scheduled jobs, and exposing the knowledge base via MCP servers and a Slack bot.
- At the bottom are the data sources themselves and the vector database, where all content is ingested, embedded, and queried.
If you’re interested in more technical details, here is an (AI-generated) technical documentation.
Key Features
- Hybrid search — combines semantic (meaning-based) and keyword search
- Multi-user support — Google OAuth login; each user connects their own accounts
- Role-based access — admin vs. user permissions
- Claude integration — MCP servers let Claude Desktop and Claude.ai search the knowledge base directly
- Slack bot — team members can query the knowledge base from Slack
- Automated sync — scheduled background jobs keep data fresh
275 commits. 95 pull requests. Zero lines written by a human.
As you probably guessed, I didn’t write a single line of code myself. Every line was written by either Replit’s agents or Claude Code. I described what I wanted, tested the result, and told the AI what wasn’t working (many, many times).
Besides that, I occasionally asked the AI for a full code review and for suggestions for improvements, with a lot of rinse and repeat.
I did have to deal with pull requests, merges, version conflicts, etc., mostly because I messed up things when I tried to have several AIs working on it in parallel, and because it quickly went way out of my technical comfort zone. Because I don’t know how a system like this has to be built, the iteration went much slower than it would have if an experienced software developer had done it.
Things I’ve struggled with
- Process supervision. The MCP servers kept crashing. It took a lot of back and forth to implement health checks, auto-restart logic, and process monitoring. Neither I nor the AI anticipated this upfront.
- Parallelization. Initial sync was painfully slow. We were processing everything sequentially. (Am I starting to refer to the AI and me as “we,” a team?) Once we added parallel processing and batching, we saw a big speedup.
- Edge cases. All kinds of little things that created bugs that had to be fixed, in most cases without me even looking into what was going on.
I’m still battling with several issues: the MCP servers occasionally go down, the dashboard sometimes shows inconsistent numbers, sync jobs fail in non-obvious ways, and the Granola import is messy. I’m pretty confident that we (yes, we!) will be able to fix all of this though.
What’s less clear is how good the system will ultimately be at answering non-trivial real-life questions. Based on my tests so far, it provides pretty impressive answers on tasks like “Write a memo about company X” or ”How is company Y doing?”. But once we (I mean my human colleagues and I) start using it seriously — asking more sophisticated questions across more diverse topics — it’s well possible that it won’t be good enough to be genuinely useful.
My expectation is that my AI and I will be able to implement a few more relatively easy wins, but that pushing quality meaningfully beyond that will be hard. So my guess is that we’ll eventually end up using a product built by someone who knows what they’re doing. 🙂
Build vs. Buy
This is not an argument against vibe coding or against customization. Keep in mind that (i) I’m not an engineer and I did this part-time over two weeks, (ii) what I’ve tried to build here is a somewhat complex system, and iii) RAG across large, messy, heterogeneous datasets is not a solved problem. What I’ve built only scratches the surface of what’s needed to do this well. Finding needles in haystacks — reliably and verifiably — requires much more: better chunking strategies, reranking, evaluation frameworks, feedback loops, domain-specific tuning…
So in this particular case (small company, complex system, difficult problem), SaaS is still the better choice. In many other cases, the answer will be different, which leads us to the trillion-dollar question:
What kind of software will be replaced by custom-built solutions?
Given the speed at which AI coding models are improving, I’m careful with predictions, but my current thinking is:
1) For a small company like ours: If the solution exists, we should buy SaaS. It doesn’t make sense to reinvent the wheel (unless you do it for the fun and the learning, like me).
2) For a large enterprise: For a company paying millions of dollars for SaaS and with internal technical resources, the build-vs-buy calculus changes. I have strong conviction that if not now, then in the near future, a small team of engineers with AI assistance will in many cases be able to build and maintain a custom solution for a fraction of the cost of traditional SaaS. If I look at what I as an amateur have managed to build in less than two weeks, I can only imagine what a good developer, directing several AI coding agents in parallel, can get done in a few months.
I don’t think the replacement of SaaS by custom-built applications will happen fast. For most companies, reducing IT/software spend is not a top priority. If a piece of software works well, replacing it just to save money will usually not be a priority. It’s different when the existing software doesn’t do a great job and I think that’s where the “let’s just build it” conversations will start. But at some point, inevitably, the question will be asked more frequently: “Why are we spending $2 million on this and $500k on that?”
Now, software companies obviously have access to the same (or even better) tools as those enterprises. And arguably they should be able to leverage AI even more. What I mean by that is, if SaaS is under threat because software development becomes 10–100x cheaper, maybe the solution for SaaS companies is to produce 10–100x more software to keep the pendulum where it is.
Some more thoughts on vibe coding
When we talk about vibe coding, we’re actually talking about two developments:
- Non-developers building simple software. People using Lovable, Replit Agent, or Bolt to build simple applications that they wouldn’t have been able to build before. Landing pages, internal tools, basic automations.
- Engineers becoming hyper-productive. For complex systems, you’ll still need engineers. I built a 43,000+ LOC system without writing code, but I also spent 13 days debugging issues that an experienced engineer would have anticipated. I believe engineers paired with AI are becoming unbelievably productive. One person doing what used to take a team. Small teams doing what used to take hundreds of people.
If you’re a non-technical person thinking about building something with AI assistance and you’re overwhelmed or intimidated: just start. Start on Replit or Lovable. Just ask the AI what to build and iterate. If you get error messages, paste them into the AI chat. If you get stuck, ask Claude Opus 4.5 for help. If you don’t know how to give Claude access to the code, ask ChatGPT or Claude how to do it. You’ll get a good response, and in many cases, the AI will not only give you the answer but can do it for you straight away. You’ll be amazed by how far you can get. LFG!
Some Learnings from Vibe Coding a Knowledge Hub in 13 Days was originally published in Point Nine Land on Medium, where people are continuing the conversation by highlighting and responding to this story.