Lessons learned from developing open source LLM platform

Knowing is different from experiencing. Throughout the development of the open source project, I encountered many familiar situations, yet experiencing them was quite different from what I had anticipated. I’ll share those experiences.

You’ve likely heard this. It’s been a guiding principle for me for as long as I can remember. I even told this to the co-founders in previous startups. I struggled to understand why they preferred adding more features instead of focusing on building a strong, singular use case. I insisted that we should start small, allowing users to focus on core functionality.

• Users are not using it? 🤔 We need to think of different solutions. Or maybe different application.
• Users like it? 🤩 Great! Let’s add more features.

Starting small is straightforward. It allows time savings, efficient resource allocation, rapid iteration based on user feedback, easier maintenance, and the list goes on. There are only benefits to beginning with less – nothing wrong with it.

Assumption and proof

However, my understanding of “Less is More” fundamentally changed when I became the decision maker on a project (BTW, I’m the only person in this project). Building a new product starts with a guess. The real challenge lies in validating this assumption. My focus on improving core functionality and my co-founders’ approach of adding features were just different paths aimed at the same goal – building a good product. Yet, the important thing in here is to verify if the product was actually needed.

I believe that’s the true meaning of ‘less is more’. It’s about filtering out all the unnecessary features and concentrating on validating the fundamental assumption – the application is desirable.

How do we prove this? By building less. We let the user engage with the core problem we’re trying to solve and monitor their responses. If the application proves to be desirable, it will naturally attract more traffic. However, high traffic or large MAU doesn’t necessarily confirm the application’s desirability. That’s why less is critical – to prove more.

Keep on track

Adopting a “Less is More” strategy isn’t just about minimalism for aesthetics or simplicity. It’s about focusing on what truly adds value and ensuring that every addition is justified. This approach helps keep the development process on track by ensuring that every feature directly contributes to validating the core assumptions.

You’ll get different results when you execute "1" + 1, depending on the programming language. There’s no correct behavior. It’s just how each programming language works.

This also happens it real life (engineer + PM = 🤯). There’s no single solution that works for every interaction. Different situations, companies, teams, or roles require suitable approaches.

Consensus

The key is to understand the context: What’s happening here? What resources do I have? What can I accomplish with them? What needs to be delivered? It’s not about providing the correct answer every time, but about building a consensus on how to respond in each situation. It’s not about who is right or wrong, but the kind of team we are trying to build.

Previously, I often focused on the trade-off between the development schedule and technical debt. My decisions were typically driven by urgency of the tasks, which sometimes worked, but couldn’t achieve the best performance for both myself and the team.

Grammar and syntax

Now, as I complete the tasks involving the design of the service, features, flow, and all the details by myself, along with the engineering tasks, I realize the varied requirements of different roles. Understanding the context of the work and the necessity for a working consensus has become clearly essential. It’s fundamental to creating both a sustainable project and a functional team.

Like the "1" + 1 depends on the programming language’s rules, the success of any team effort relies heavily on the underlying culture and the consensus among its members.

Just as programming requires a clear understanding of language-specific behaviors, successful teamwork relies on building consensus. This consensus isn’t just about agreement but about harmonizing diverse viewpoints. It will be one of the most important keys of the team’s success.

At first, I wanted to create a platform for the discussion of the books (books, not the authors 😏). The concept was for AI to interact based on the contents of the books. I thought this as a new way of reading, but I quickly realized the extensive resources required to enable AI to comprehensively cover even a few books.

Next, I developed a content creator capable of generating a variety of genres including fiction, non-fiction, articles, and so on. It also assisted in editing the writing. However, I hardly produced high-quality content using it.

Next, I created an AI community. I thought that watching their interactions would be fun. The AIs could enjoy each other’s posts, leave comments, reply, and develop personas step by step. However their interactions were quite similar and were not as fun as I expected.

Finally, I created a tool that generates API endpoint for the prompt. I imagined it’d be helpful to pre-define model, configuration, chat history and only ask the necessary question each time. So far, I like it.

I wanted to create an AI content maker, not the LLM tool. Things might go as expected or they might not. Regardless, I feel like I’m pushing the boundaries of my engineering skills. I’m in the process of developing a fine AI application and I’m not yet satisfied with the results, but I am improving. That’s what’s important. It all starts with a single step. One step at a time!

My latest work: github gpinterface.com