About EidoStack

Hi, I’m Timur Ludanov, the founder and developer behind EidoStack.

EidoStack is my first independent software product that I am seriously building as a business, but the journey that led to it started many years before AI became part of everyday software development.

From Student to Software Engineer

I studied software development at IT STEP Computer Academy.

During my studies, I worked with several programming languages, including C++, C#, Java, and JavaScript. We also studied web development, which at the time was largely centered around technologies such as PHP.

My professional career started while I was still a student.

During my final year at IT STEP, my C++ instructor offered me an opportunity to join a local engineering company in Kharkiv, Ukraine.

I accepted, and in 2009 I started my first professional job as a programmer.

The company developed railway automation systems, including microprocessor-based railway interlocking systems. I worked there from 2009 until 2016.

It was a very different world from modern web development.

I worked primarily with C++ and developed software for QNX and Linux. The systems we built involved multithreading, multiple processes, communication between different components, and software that had to operate reliably in a complex technical environment.

That experience gave me a strong engineering foundation. I learned to think not only about writing code, but about how complete systems behave, how their components communicate, and how software is deployed and maintained.

One of my favorite projects from that period was creating a custom Linux distribution based on Debian.

We needed a simple and reliable way to deploy our software onto new workstations and servers. Instead of manually configuring every computer, I created a distribution that could be installed from a USB drive.

You selected the disk and installation parameters, and the system installed an already configured environment with everything required for our software.

We maintained both desktop and server configurations.

Looking back, I think I already enjoyed building tools that removed repetitive work and made complicated technical processes easier.

Moving from C++ to the Web

Although my professional work was focused mainly on C++ and system software, web development had interested me for a long time.

I already had a foundation from IT STEP, where I had studied JavaScript and PHP alongside languages such as C++, C#, and Java.

While working professionally as a C++ developer, I returned to web development and started going much deeper into it.

I refreshed the technologies I had studied before and began learning new ones independently as the web ecosystem evolved.

That included technologies such as Node.js and TypeScript, which were not part of my original studies at IT STEP.

The goal was practical.

I wanted to move beyond academic exercises and learn how to build complete web applications that could be used in real projects.

I was particularly interested in applications with real interfaces, backend services, data, and business logic — not simply traditional websites.

So my transition from C++ to web development was not a complete change of direction from scratch.

It was a combination of returning to technologies I had already encountered during my education and independently learning the newer tools that were becoming important for modern web development.

And even at that stage, I was already thinking about building products of my own.

My First Attempt at Building a Product

While I was still working full-time at the railway automation company, I built my own RSS reader.

I called it Reader News.

It was one of my first serious attempts to create a product independently rather than simply work on software for my employer.

For the frontend, I used JavaScript and Polymer web component framework. For the backend, I used Node.js, which I had started learning independently while working at the railway automation company.

Reader News became one of the first real projects where I could apply the web technologies I had been studying outside my main C++ work.

I wanted to build something that people could actually use.

Technically, I was able to create it.

The problem was keeping it alive.

At the time, I simply did not have enough money to comfortably maintain the infrastructure and continue developing the service.

That experience taught me an early lesson about product development: building the software is only one part of the problem.

A product also needs enough financial support to survive and continue evolving.

Reader News became one of the reasons I started thinking more seriously about earning more and becoming financially independent.

My regular salary was becoming a limitation — both for me personally and for the products I wanted to build.

That eventually pushed me toward freelancing.

From C++ to Browser Extensions

I started working on Upwork while I still had my full-time job.

My freelance career gradually developed around browser extension development.

I initially worked with extensions for Google Chrome.

Later, that expanded into cross-browser development for Firefox, Safari, Edge, and other browser environments.

Interestingly, my previous C++ experience also became useful.

One of my freelance clients was an Estonian company developing its own browser based on Chromium.

This project was particularly interesting because it allowed me to combine two parts of my background.

On one side, I had years of C++ and systems development experience.

On the other, I was moving deeper into web technologies and browser development.

I worked with the browser itself at the source-code level, modifying its functionality for the company's requirements.

At the same time, this project gave me some of my first substantial practical experience with Chrome extensions.

The browser used a collection of internal extensions that provided different pieces of functionality.

These were not ordinary public extensions distributed through the Chrome Web Store. They were part of the company's own browser ecosystem and could be distributed and updated through its internal browser infrastructure.

That meant I was working on both levels of the platform.

I was modifying the browser itself while also developing extensions that ran on top of it.

That combination turned out to be extremely useful later in my career.

When Freelancing Became My Full-Time Career

At first, freelancing was something I was doing alongside my regular job.

Then something changed.

In 2016, I completed a freelance project in just a few days that earned me more than my monthly salary at my regular job.

By the end of that month, I realized that my freelance income was higher than the combined salaries of the team working in the same room with me.

At that point, the decision became fairly obvious.

I left my job and became a full-time independent developer.

Freelancing exposed me to completely different kinds of products and clients.

I worked with startups, growing companies, and established products.

Instead of spending years inside one technical environment, I constantly had to learn new technologies, understand new products, and solve new problems.

Browser extensions eventually became one of my main areas of specialization.

And one of the most important long-term projects for me became PrintFriendly.

Building Software for Millions of Users

Working on PrintFriendly changed how I thought about product development.

This was no longer software built for a limited internal environment.

It was a product serving a very large audience.

A significant part of my work involved browser extensions.

I initially worked on improving the existing extension and later became deeply involved in rewriting and modernizing it.

My previous experience with browser internals and Chrome extensions became extremely useful here.

The extension had to work across multiple browsers, including Chrome, Firefox, Edge, and Safari.

Working on browser extensions across multiple platforms taught me another important lesson: software that appears simple from the outside can contain enormous complexity underneath.

Different browser APIs, compatibility issues, legacy code, performance constraints, deployment requirements, and millions of real-world usage scenarios all have to coexist.

Over time, my role became less about simply implementing individual tasks and more about understanding systems, architecture, product requirements, and how to make development faster and more reliable.

Then AI changed the development process again.

My First Experience with AI-Assisted Development

My first serious experience using AI for software development was GitHub Copilot.

I began using it in my everyday client work.

At first, it was mostly another tool that could help accelerate implementation.

But the capabilities quickly became more interesting.

Instead of only completing individual lines of code, AI could increasingly help with larger features, debugging, refactoring, understanding existing systems, and implementing meaningful parts of real client projects.

That was important because I was not experimenting with AI in isolation.

I was using it on actual software that had real users, real requirements, and real consequences if something did not work correctly.

And it performed well enough that I started thinking differently about the development process itself.

Instead of manually writing everything, I could increasingly focus on understanding the problem, designing the solution, defining requirements, reviewing the implementation, and testing the result.

Eventually, however, my heavy usage of GitHub Copilot became expensive.

Once the workflow started consuming additional credits, I was able to burn through the available budget in just a few days.

That pushed me to look for another development workflow.

I moved to Codex through ChatGPT.

Codex became a much more important part of the way I work, and it remains the primary AI development agent I use today.

From Freelancer to Indie Hacker

As AI became more important in the products I was building for clients, I started running into a new engineering problem.

Some projects required direct AI integrations. Others involved AI-powered features where the choice of model could significantly affect quality, cost, and even the architecture of the product.

I needed a practical way to evaluate models under real project conditions: compare providers such as OpenAI, Anthropic, and Google, run the same tasks across different models, experiment with system prompts, context strategies, conversation history, and model parameters, and track token usage and actual cost.

Doing all of this manually was possible, but it quickly became repetitive and time-consuming. Every new provider, model, or experiment meant writing more scripts and maintaining more testing infrastructure.

I wanted one workspace where I could do all of this quickly.

That need became EidoStack.

For me, model selection is increasingly an engineering decision. Different models can behave very differently on the same task, with different costs, context limits, capabilities, and failure modes. A model that works well for one application may be a poor choice for another.

So the core idea behind EidoStack is simple:

EidoStack is a Multi-Model AI Playground for Developers. Chat with models from different providers, experiment with prompts and context, compare responses, and track token usage and estimated costs using your own API keys.

Once I decided to build it, I faced another familiar problem: time.

I was still working on client projects, and building a large application manually would have taken a significant amount of it. By then, AI had already proven itself useful in my professional development work, so I decided to use the same approach for EidoStack.

The project was initially developed with GitHub Copilot. Later, I moved the development workflow to Codex, which remains my primary AI coding tool today.

This has changed the way I work.

Instead of spending most of my time writing code manually, I focus more on defining what should be built, understanding the problem, designing the architecture, preparing requirements, reviewing implementations, testing results, and deciding what should happen next.

AI does not remove the need for engineering. Architecture, product decisions, testing, security, infrastructure, UX, and understanding the user problem still matter.

What changes is how much one developer can realistically build.

That matters to me because, for many years, I have built products for other people.

Freelancing gave me independence, introduced me to interesting clients, and allowed me to work on software used by large audiences. But I have always wanted to build products of my own.

That idea goes back to Reader News, long before modern AI development tools existed.

Today, the economics are different. A solo developer can build and maintain much more than before, which makes the transition from freelancer to independent product builder far more realistic.

Or, in the language commonly used around this kind of work, to becoming an indie hacker.

For me, that means building useful products independently, learning from real users, improving them over time, and gradually creating a sustainable business around software of my own.

EidoStack is my first serious step in that direction.

The product has grown from that original need into a Multi-Model AI Playground. I want developers to have one place to chat with supported models, explore their capabilities, test prompts and context settings, compare responses, and understand token usage and estimated costs.

After many years of building products for clients, I want to see how far I can go building my own.

I built EidoStack because I needed it.

Now I hope it can be useful to other developers facing the same problem.

— Timur Ludanov
Founder of EidoStack
Ukraine