Why I'm building Tamarind

When a factory upgrades a machine, workers get a month of training. When a software team upgrades a framework, engineers get a deadline.

Let me start with an example.

Imagine being an engineer working for a paper company. You have been there for four years, and during that time some of the industrial processes and tools have changed. A new, more advanced machine is introduced into the production stage you oversee. You are worried about using it incorrectly and causing an accident. Your company knows this. In fact, they knew it before they even purchased the machine. So they prepare a training course for you and your peers. For an entire month, you study the machinery, practice using it, and get up to speed with the latest standards and procedures. Eventually, you finish the training. You are confident using the machine. You have the required certificate in your hands. You are ready.

Now let's jump into the world of software engineering.

You work for an ecommerce company that sells funny-looking rubber ducks. Your department decides to replace a third-party framework that you use on a daily basis for your work. The new framework is more powerful, supports more features, and works in a completely different way. The license for the old one expires at the end of the year, and the migration could potentially affect the user experience, or even sales. Suddenly, you need to learn the new tool, plan the migration, assess the risks, design a testing strategy, inform and enable other teams that will use the framework in different ways, and of course document everything.

All while keeping up with your usual work. No training. No dedicated time. No alignment sessions. No feedback loop. This is happening, and the company expects you to transition to the new tool—and become proficient with it—before the deadline.

Somehow, you and your team survive another migration. You take some self-taught knowledge with you and put it on your CV. No certificate, though. Nobody really cares anyway.

A year later, the company changes providers, and another migration is upon you. The cycle starts again.

We see this pattern across the industry many times. And while every migration teaches you something, the knowledge you obtain rarely matches what you'd gain from actually being trained properly.

That's one of the reasons why I started this project, along with these:

1. I wanted, for once, to be the architect. To create a new product where there was nothing but an idea. A true 0→1.
2. I wanted to get comfortable with state-of-the-art technology. To understand its strengths and limitations, apply it to a real use case, and document the journey.

Unfortunately, I knew my current job simply wouldn't give me the opportunity to get deeply involved with the kind of technologies, frameworks, and working disciplines I wanted to explore. Not directly, and certainly not within such a short period of time.

What could you achieve when there is a will to create, and the means for it?

Building my own SaaS gave me exactly that — a chance to learn new skills while shipping a real product, at almost no cost. I was able to experiment with:

• modern AI-powered coding tools such as Cursor, Claude, and Lovable
• hybrid RAG systems for information retrieval
• text embeddings through OpenAI model APIs and heuristic scoring
• vector normalization and information chunking
• modern frontend frameworks such as React and TanStack
• full-stack frameworks such as Next.js
• Supabase for backend and database infrastructure

And none of this required a new job, a large team, or someone giving me permission to do it. In the end, it's not so much about what you can bring to the table on a daily basis, but rather what you can achieve when there is a will to learn and build.

Times are changing, pretty fast, actually. Information is everywhere. AI assistants can give us superpowers, when put in the right hands. The old resource barriers are disappearing and the cost of acquiring this kind of knowledge has collapsed. You don't need a big budget, a dedicated team, or years of organizational support to create a software product and launch it.

Individual engineers can now create their own opportunities to learn things their jobs may never expose them to.

You just need an idea, the willingness to learn, and the time and effort to see it through.

That's why I'm building Tamarind.