Katalogo: building a product for businesses selling on WhatsApp

My watch supplier sent me 130 photos on WhatsApp.

That is where it started. In March, with a fairly concrete problem: I wanted to see which watches he had, and I ended up working my way through a conversation full of images. For him, it was a way to show his products. From my side of the conversation, finding and asking about the watches I liked could clearly be easier.

I offered to build him an online store. That was my first response as a developer, but he could not afford that investment. His answer stayed with me. The problem was still there, even if the solution I had proposed was out of reach.

That is where what is now Katalogo came from.

I wanted to put this story somewhere. In case someone reads this and wonders where the project started, or in case I need to remind myself later. Looking at the website today, with its plans, demos, and features, it is easy to miss that part: before any of it, there were 130 photos of watches and a conversation with my supplier.

Before the product, there were experiments with Excel

I did not go straight from that conversation to the Katalogo that exists today. I tried Excel and worked through different iterations before arriving at what I have now.

I was looking for a way to organize products that made sense for this problem and was more affordable than the online store I had offered. I did not have the entire product structure figured out from the beginning. I worked through it.

That part matters to me because it is easy to show only the version that is ready for people to see. Earlier experiments are work too, even when you change them or leave them behind. In my case, they helped me understand what I wanted to build and what I still needed to learn.

I have been putting time into that since March. Katalogo has changed as I have found better ways to solve things. There is no perfect first version hidden somewhere. There is a process of trying things, reviewing them, and working on them again.

My first proposal was not right for him

I keep coming back to that conversation with my supplier. I could build a store, but that did not solve the fact that he could not afford one.

I had to think beyond what I knew how to develop. What did he need to show his watches? Which parts of the sale did he already handle through WhatsApp? What could I make easier without asking him to change his whole way of working?

The catalog took that direction: products organized behind a link, information buyers can browse, and a conversation that continues on WhatsApp. Depending on the plan, the mini cart collects products, variations, and quantities into one message. The business confirms availability and arranges payment with its customer.

This connects with something I discussed at WordCamp Nicaragua: before choosing an architecture, understand what the business needs to sell and how it sells it. With Katalogo, that question came from someone I know and a proposal of mine that did not work for him at the time.

I have learned much more than code

This whole process has involved a lot of learning. UX, UI, product design, and decisions that seem small at first but change how someone uses a tool.

Knowing where an option is because I programmed it is one thing. A business owner finding it and understanding what will happen when they tap it on their phone is another. Keeping that in mind makes me look at the dashboard differently.

In Katalogo, I have worked on quick price and stock editing, product ordering, and catalog settings. Behind those features are questions I find myself thinking about more often: how many steps does this task need? Is it clear whether the change was saved? What happens if someone makes a mistake?

For example, quick editing compares the data version before saving. If the product has changed since editing began, silently overwriting it would cause a problem. Pro’s CSV import includes validation and rollback for a similar reason: when an action affects many products, its recovery path needs attention too.

These are details people may never notice while they work well. They still take time. For me, that work is part of offering something of quality.

The technical work serves that idea

The catalogs run on WordPress with a custom PHP and JavaScript theme, Advanced Custom Fields, and the REST API. The marketing website is a separate application built with Next.js, React, and TypeScript.

The Katalogo case study covers that in more detail. What I want to explain here is that choosing those tools also meant doing the custom work: modeling products, building the administration, defining permissions, and deciding which features belong to each plan.

I also have to set limits on what the product can claim. The analytics shows visits and inquiries; a WhatsApp click does not tell me whether a sale happened. The catalog does not process payments. Those are decisions about how Katalogo works and how I want to explain it to the people using it.

I have been recording published improvements in the Katalogo release history. I like having that record because it shows the work happening between versions.

Another experience along the way

Something new to me happened during this process too. I told someone I considered a friend how Katalogo had started, how it worked, and that I already had four clients at that point. Later, he told me he wanted to make money too, and he ended up copying my idea.

I had not experienced that before. Sometimes these things happen, and that is part of the story too. I am still putting time into Katalogo and what I want to build with it.

I want to make something good for my country

Katalogo has a personal history behind it. It includes the Excel experiments, the different versions, and the time I have put into it since March. It includes decisions I am still reviewing and things I am still learning to do better.

I want it to be a quality option for businesses in Nicaragua. Something that helps people organize and share their products without making an investment they cannot afford the only answer. I will not solve every business’s needs, but I want to do the work I offer well.

That is why it matters to me that Katalogo has its own judgment behind it. I do not want to copy something I see elsewhere and put a different logo on it. I want to understand why a feature is there and whether it helps the person using it. That takes time and effort, and I am willing to put both into it.

If you have read this far, that is the story. My supplier sent me 130 photos, I offered something he could not afford, and I kept looking for another way to solve it. Through experiments and learning, I built Katalogo.

I am still building it.