Hello everyone, we are the Blar team.
Welcome to our latest updates!
Team
Companies aren’t built by a single person; they’re the result of collective effort. One of our key goals this month was to attract and hire top engineering talent, and I’m thrilled to announce that Emerson, Eliseo, and Juan have joined us in our mission to build the AI co-workers of the future—AI that helps developers worldwide maintain legacy code and reduce technical debt.
We’re incredibly grateful to have them on the team. From day one, they’ve brought energy, passion, and dedication. With their support, we can explore and experiment at a much faster pace, moving us closer to our goals.
One of our first tasks was to write down what Blar stands for—our values and our mission—laying the foundation for the culture we’re building. We firmly believe culture isn’t imposed; it’s created by people over time. We hope this is just the beginning, and that our culture evolves as our company grows. That said, some values are, and always will be, unwavering. Feel free to check out our manifesto.
Product
After receiving initial feedback on our product last month, two key areas emerged for improvement. First, platform recurrence—since production bugs don’t happen daily, this affected how frequently our platform was used. Second, we needed to provide greater context in our answers, making them feel less generic and more tailored to each business's specific needs.
That’s why during October we worked on two major projects.
Pull Request Agent
One of the most requested features was a pull request agent designed to detect bugs, optimize code, and identify vulnerabilities before they reach production. Since pull requests happen daily, this allows us to deliver value to our users more frequently. We launched the first iteration in a closed beta, and while the initial response was positive, there’s still plenty of work ahead to make this feature an essential tool for development teams.
Blar not only delivers a summary of recommendations, helping developers quickly address potential issues in their pull requests, but it also offers a chat interface where you can "chat with your pull request." This feature allows both developers and product managers to better understand the changes made and determine if the pull request truly meets its intended goals.
Graph Generation
We’ve begun updating our graph generation process, which lies at the core of our business. Our previous iteration was more of a proof of concept (POC) than a fully developed version, but it allowed us to validate key hypotheses:
Can we represent code as a graph?
Can an agent traverse and understand the graph?
Does the graph help us achieve better results?
Now that these have been validated, it’s time to move on to the second iteration to explore further hypotheses:
Can we contextualize nodes within the graph?
Can we store long-term context?
Can we generate a graph in every major programming language?
For our more technical readers, the updates include:
LSP Integration: We incorporated the Language Server Protocol (LSP) into our graph generation process. This allows us to support nearly all major programming languages, significantly expanding our potential serviceable market.
Graceful Graph Update: In our previous iteration, we regenerated the entire graph from scratch after each code update. This approach had significant drawbacks, particularly in terms of efficiency, and it prevented us from retaining long-term context within the graph.
With these changes, we can start contextualizing each node with multiple sources of information, including Blar, allowing our agent to gather deeper insights beyond just the code. This enables agents that not only understand how the code has evolved with the company but also learn and evolve alongside it.
Analytics
We’ve added an analytics tracking tool to our platform to measure user interactions and identify which features are delivering the most value and which ones may need to be rethought. With analytics, we’re able to make more data-driven decisions, ultimately helping us create a better product.
GTM Strategy
This month, we decided to take a step back and reassess our go-to-market (GTM) strategy. Initially, we followed a Product-Led Growth (PLG) approach, targeting individual developers to create a bottom-up dynamic. While this is common for developer tools, it didn’t quite fit our product for a few key reasons:
Integrations: Individual developers often don’t have the authority to grant the necessary permissions.
Collaboration: Our solution is designed to foster collaboration between developers.
Pain Point: The pain of technical debt is felt more acutely by managers, who have a broader view of the problem, than by individual contributors.
With these factors in mind, we shifted to a more sales-driven GTM strategy, focusing on managers and CTOs.
ICP
After speaking with our initial users and conducting additional interviews, we’ve refined our Ideal Customer Profile (ICP). We quickly realized that micro and small startups prioritize fast, cost-effective development. Our solution truly starts to add value for scaleups and beyond—companies that have been around for a few years and have a development team of at least 50 developers.
Scaleups are focused on growth, rolling out new features, and maintaining the ones they’ve already validated. But with rapid growth comes technical debt. In the rush to ship features and scale fast, shortcuts get made, and foundational work often gets overlooked. Over time, this debt builds up, and suddenly, maintaining these systems becomes a real pain.
This technical debt not only creates a drag on day-to-day operations but also significantly slows down the release of new features. What was once a nimble team able to iterate quickly now finds itself slowed down by legacy code, inefficient processes, and systems that are more fragile than they should be. The result is that innovation starts to slow, and the focus shifts from growth to firefighting.
Next steps
Our current goal is to secure 3-4 design partners to collaborate with us as we continue to develop our vision. We’re targeting companies that have been in the market for 3-4 years with dev teams of 50+ engineers. We’re already having promising conversations with a few and hope to reach agreements soon.
Over the next month, we’ll focus on:
Consolidating our graph generation process: We’re working to support multiple languages and maintain long-term context, which opens the door to exciting new possibilities.
Further contextualizing our agent: We’re enhancing our agent with more context, starting with design patterns to improve the code review process.
Improving our pull request agent: The current version has a few limitations that we’re addressing based on user feedback before we release it to the general public.
How You Can Help
If you know any CTOs or decision-makers at companies that fit our profile, we’d love an introduction! Feel free to reach out.
Here’s a short description of Blar you can share:
“Blar is a platform that helps companies reduce technical debt and manage legacy systems using artificial intelligence. By centralizing data from development tools, Blar allows AI to understand both the code and its context. This empowers engineers to move forward confidently, without the fear of breaking something, and focus on creating value. With Blar, teams can identify issues, optimize code, and prevent errors, streamlining both software development and maintenance.”
Thanks for reading.
Feel free to reach us at: jose@blar.io or benjamin@blar.io
Follow us on X and LinkedIn for more!
The Blar Team.