Ona: AI Product Built from Idea to Production in Two Weeks

Why this case matters

theona.ai, or Ona, is a complex, production-level feature built by a small team of three engineers working together. Many teams talk about AI, but few manage to turn it into products that work in the real world, at scale, and with business impact. Ona is proof that with the right expertise, this is achievable.

‍

Can you briefly explain what Ona is and how it improves business operations?

Ona is a tool for automating work with business tools and services. It’s designed for everyone, not just engineers. With a simple UX, even managers who usually use ChatGPT or Claude can build and deploy their own agents. It allows you to create agents by performing a task once, and then run these agents autonomously in the future. For example, Ona can turn a single completed action — such as updating tasks after a team meeting — into an automatic agent that performs it daily without human involvement. This helps solve the problem of automating routine processes, and such agents can be applied across various business areas.

‍

What industries or tasks do you think will especially benefit from Ona and similar agent-oriented products?

The biggest impact will be in areas where people spend time manually moving data from one service to another. This is very common for managers — project managers, product managers, and others — who often end up shuffling information between tools. The first wave of automation will target these routine, repetitive tasks, particularly in fields like management and HR. These roles won’t disappear, but they will evolve, as many of their functions are automated and people focus more on complex, product-oriented work that is much harder to replace.

‍

Can you quantify the impact of creating Ona? For example, saved work hours, growth in conversions, or economic effect?

We can estimate based on several use cases. For example, we conduct daily meetings with the team, after which we need to do some managerial work: go through all tickets, update them, create new tasks, and so on.

This work can easily take about 30 minutes of a person's time. If we say a person earns, let's say $20 per hour, then this work could cost about $10.

Ona does this automatically, and running such an agent costs on average 70 cents — about 15 times less than human work. These are very rough estimates, but there are also cases such as automating analytics reports, where the potential savings and efficiency gains are even higher.

‍

Sounds amazing. And what are your favorite use cases that Ona handles?

What I like most is how Ona can develop itself. For example, you can ask it to analyze user feedback, turn those insights into GitHub issues, and then have another AI assistant pick them up, execute the tasks, and create pull requests — essentially writing code. 

I also like how it works with product analytics for itself. For example, reports showing how much money was spent: it generates these itself. Before, you had to manually write database queries, process the data, build reports, and set up scheduled mailings.

Now, you can simply ask Ona to calculate specific metrics and send the report straight to your corporate messenger. Sometimes the difference here is much more than 15 times in terms of labor costs.

‍

From an engineering perspective, would you say this is a complex product?

We deliberately built Ona without unnecessary complexity, focusing on a clean and scalable architecture. The product stays simple for users while retaining the flexibility to evolve as it grows, without the burden of overengineering. Any project with legacy code that's more than a year old would be more complex than Ona 😀

‍

What technologies did you use? What was the main tech stack required to create this product?

We use TypeScript as our main programming language. This isn't a typical choice: it was driven by our desire to create a native desktop application and use a specific framework that required TypeScript.

We use Supabase as our database, mem0 as a framework for working with agent memory, and Railway for deploying our services. For development, I primarily use Claude Code, and use IDEs with normal interfaces like WebStorm, PyCharm, or Cursor for convenient code navigation.

‍

How long did it take you to develop the first working version from idea to implementation?

About two weeks.

‍

That's impressive 😯 What was the most challenging part of this process?

The most difficult thing in developing any product is understanding what we're doing and why. From a technical standpoint, the challenge is that we can't always use existing solutions because we have many edge cases that need to be handled in our own way. This means we have a layer of the product that we have to develop by hand without using ready-made solutions.

‍

What made Ona possible wasn’t luck — it was having the right expertise in the right hands. That same kind of expertise can be developed: our instructor-led training helps teams move beyond prototypes and build AI features that make a real impact on business metrics.
‍Get a free consultation call with us and make your team building meaningful AI features that make a visible impact on your business metrics.

‍

What skills did you develop while working on Ona?

Technical skills are always evolving because the technical component is always changing. I definitely improved some technical skills. For example, I hadn't actively used JavaScript or TypeScript for a long time, but here I had to. 

If we're looking at something more large-scale, it's not so much a skill as a new process. Besides development, I have to deal with various tasks, including finding clients and conducting user research. It’s no longer just engineering — I had to learn product skills: talking to users, understanding their needs, shaping direction, deciding which features to launch first and which to postpone. Working on this product develops the kind of product thinking that’s been as valuable as the technology itself.