From Separate Projects to One Ecosystem: What I Learned Building Developer Tools

For a long time, I treated every open-source project I built as a separate thing.

I would run into a problem, build something to solve it, publish it, document it, and eventually move on to the next problem.

TomatoPHP grew out of patterns I kept repeating while building Laravel and Filament applications. Laravilt came from a different need: building modern Laravel admin applications with Inertia and Vue or React without letting the project architecture become harder to control than the product itself.

Then I started spending more time with Go and AI-powered systems. That led to ToGO, then Orchestra MCP, then CaBrain, and eventually Mark It Down.

At first, I saw them as different tools.

Over time, I realized the bigger problem was not building the projects. It was that I was still thinking about them as isolated projects instead of parts of a system.

That shift changed how I think about open source today.

Good projects usually start with friction, not ideas

Most of the open-source tools I keep working on did not start in a brainstorming session or with me trying to come up with a startup idea.

They started with something annoying that kept happening.

A piece of code I had to rebuild in every project.

A workflow that took more steps than it should.

A good tool that still forced me into an architecture I did not want.

Or a gap between two useful tools that made using them together harder than necessary.

Those problems are valuable because when you build for friction you have personally experienced, you know the small details.

You know where the wasted minutes are.

You know which part feels unnecessarily complicated.

And you learn the difference between a solution that is technically correct and one that is actually pleasant to use.

Developers do not just need a library that works.

They need something they can understand quickly, trust, and add to a project without feeling like they have adopted an entire worldview they can never leave.

When separate problems start becoming adjacent problems

After enough time, I started noticing that the problems I was solving were not as separate as I thought.

In the Laravel world, TomatoPHP and Laravilt solve different problems, but they sit close to each other in a developer's journey.

One focuses on reusable plugins and packages. The other focuses on building modern admin applications and giving the application structure a clear shape.

Then I moved further into Go.

The goal with ToGO was never to make Go look like Laravel on the surface. What interested me was preserving some of the ideas I value as a Laravel developer: strong conventions, fast onboarding, clear structure, and a productive way to compose the pieces an application needs.

Then AI agents stopped being experiments for me and started becoming infrastructure.

That created a different set of questions.

How do I give an agent access to many tools without turning the system into a mess?

How should those tools be composed?

How can different IDEs expose the same capabilities?

How does an agent keep memory after the conversation ends?

How can the notes and knowledge I already write become useful to those agents?

That is where the relationship between Orchestra MCP, CaBrain, Mark It Down, and ToGO became much more obvious.

They were no longer just repositories.

They were different layers of the same broader problem.

An ecosystem matters more than a project count

One trap in open source is measuring progress by how many repositories you have.

Ten repositories look better than three.

One hundred packages sound more impressive than ten.

But the number itself does not tell you much.

You can have fifty projects where users of one have no idea the others exist.

Or you can have five projects where each one naturally leads to another when the developer reaches the next problem.

The second is much stronger.

So I started thinking about projects as relationships instead of a list.

If someone is using TomatoPHP, what else might genuinely help them?

If someone is building with ToGO, what happens when they start adding AI agents?

If they use Orchestra, what happens when those agents need long-term memory?

And if they already have Markdown notes, technical knowledge, and documentation, how does that knowledge become available to an agent?

When those answers are natural, connecting the projects helps the user instead of acting like cross-promotion.

That is the difference between a real ecosystem and a page full of logos.

Open source is not only the code

It is easy for developers to spend 90 percent of the effort on the code and then wonder why only a small number of people use the project.

But the product experience starts before anyone runs the first command.

It starts the first time someone sees the project's name.

Do they understand what it does?

Can they tell whether it is for them?

Can they see a real example?

Does the documentation explain the reason before it explains the API?

Can they get from the homepage to installation in less than a minute?

Can they tell whether the project is experimental, stable, or something you actually use in production?

These things are not marketing in the superficial sense.

They are part of the product.

That became especially obvious while I was reviewing my own project websites recently.

Some of the projects were much stronger technically than their websites suggested.

Orchestra MCP was a good example. If the project has a serious plugin architecture, MCP tooling, agent workflows, and developer infrastructure, but the website communicates almost none of that, then the project is hiding its own value.

That is not primarily an SEO problem.

It is a clarity problem.

Good SEO is often a side effect of clarity

While improving the sites, I tried not to think about SEO as a process of adding keywords.

Repeating “AI agents” fifty times does not make a page more useful.

The better question is:

If a developer lands on this page from search, will they find a real answer to the question that brought them here?

A name like ToGO is difficult in search by itself. The name does not tell a person or a search engine what the product is.

But pairing it with a useful description such as “Laravel-inspired Go framework” or “Go framework for AI-native applications” does more than add a keyword.

It explains the product.

The same applies to Mark It Down.

The name is broad, but describing it in terms of Markdown, MCP, knowledge workflows, and AI agents gives it a specific meaning.

The best SEO improvement I have found is often simply making the product easier to understand.

Not every project needs its own content machine

I do not want to put a blog on every project and start generating dozens of articles just because “content is good for SEO.”

That usually creates a large amount of repetitive material with very little value.

A better approach is to let each project own a clear technical area.

TomatoPHP can talk about Filament, Laravel plugin architecture, and maintaining reusable packages.

Laravilt can focus on Laravel admin panels, Inertia, Vue, React, and application structure.

ToGO can explore Go architecture, developer experience, plugins, and AI-native application design.

Orchestra can go deeper into MCP, agent tooling, orchestration, and developer environments.

CaBrain can focus on agent memory, RAG, retrieval, and entity graphs.

Mark It Down can focus on Markdown, knowledge workflows, and making human knowledge useful to AI systems.

Then the content exists because there is real experience inside the project worth sharing.

Search traffic becomes a consequence rather than the reason the article exists.

Metrics without context do not build trust

Another lesson is simple: do not display metrics just because they look impressive.

Stars.

Downloads.

Users.

Tools.

Those numbers are only useful when they are correct, current, and understandable.

While reviewing some of my sites, I found cases where numbers differed between language versions or between a website and its repository.

Even if the reason is caching or stale content, the result for the visitor is the same: something feels inconsistent.

I would rather show a smaller number that I know is correct than a larger one that needs explaining.

And when a metric changes frequently, it is usually better to fetch it from the source than to copy it manually across several places.

Trust in an open-source project is built from small details like these.

Old documentation is more dangerous than it looks

Projects that live for years change.

Frameworks move on.

Versions change.

Architectures evolve.

But old documentation pages can remain in search results for years.

This creates a strange situation where the product improves but search engines continue sending users into an older version of it.

A developer may then judge the entire project from a page you wrote three years ago.

That is why I now see documentation maintenance as product maintenance.

You do not need to erase history.

Older version docs can be extremely useful.

But they should clearly say what version they belong to.

Users should know what they are reading.

And old and new pages should not compete for the same search intent as if they describe the same product state.

What makes a project part of an ecosystem?

I have started using a few simple rules.

First, every project should solve a real problem on its own.

I do not want one project to exist only to force you to install another one.

Second, the relationship between projects should make sense.

CaBrain does not need to appear in every product I own. But when someone is building an AI agent that needs memory, mentioning it becomes relevant.

Third, each project should keep its own identity.

I do not want TomatoPHP, ToGO, and Orchestra to become the same visual product just because they share a creator.

A project should have its own personality.

At the same time, it should be possible to see that the tools share a certain engineering philosophy.

Fourth, the ecosystem should reduce friction, not create more of it.

If a developer has to visit five websites just to figure out where to begin, then the ecosystem has failed.

The network I am trying to build

Today I roughly see the projects like this.

On the Laravel side, there are TomatoPHP and Laravilt.

On the Go side, there is ToGO.

At the AI-agent infrastructure layer, there is Orchestra MCP.

At the memory and retrieval layer, there is CaBrain.

And at the layer where human-written knowledge meets AI workflows, there is Mark It Down.

That does not mean this architecture existed from day one.

It did not.

That may be the most important point in this whole article.

The ecosystem did not come from a giant roadmap I drew years ago.

It emerged gradually from the problems I kept solving.

At some point, the main thing I needed to do was stop and look at the whole picture.

You do not need to build everything yourself

Building an ecosystem does not mean building an authentication library just because you can.

It does not mean writing a new database, queue, UI framework, or protocol so everything can be “in-house.”

In many cases, the opposite is better.

The more you build on strong standards and good existing tools, the more time you can spend on the part that actually makes your project different.

MCP is a good example.

Instead of inventing a private protocol for every tool that needs to communicate with AI agents, you can build on a standard that is already being adopted across the ecosystem.

The same principle applies to frameworks, databases, transport layers, and infrastructure.

The value of your ecosystem is not that you own every dependency.

It is that the pieces you chose to build work well together.

What I would do differently if I started again

If I could go back a few years, I would do a few things much earlier.

I would write a clear positioning statement for every project before it became large.

I would treat documentation as a product from day one.

I would use one source of truth for changing metrics.

I would connect related projects earlier.

I would pay more attention to the pages people actually land on from search, not only the homepage.

And I would try to explain fewer things at the same time.

When a developer reaches your site, they do not need your entire history.

They need an answer to one question:

Will this solve my problem?

If you can answer that quickly, you have already done half the work.

What comes next

The next phase for me is not to create more repositories just to make the list longer.

I want the current projects to become better.

Better documentation.

More real production examples.

Simpler integration between the tools where that integration makes sense.

Technical writing based on problems I have actually faced.

And most importantly, I want each project to remain useful even if the person using it knows nothing about the rest of the ecosystem.

If they eventually move to another project, it should be because they discovered something there that solves the next problem they have—not because a website pushed them into it.

That is the kind of open-source ecosystem I want to build.

Start with a problem.

Build a good solution.

Share it.

Listen to the people using it.

Then pay attention to the problems that appear next to it.

After enough time, you may discover that you were never building a collection of separate projects.

You were building an ecosystem all along.