🧠 NeuraPRO: My MVP Worked. My Customers Didn't.

Product, adoption, marketing, and the hardest lesson after launching a SaaS MVP

About a year and a half ago I started building NeuraPRO.

The idea seemed fairly logical: create a platform that would help small businesses manage inventory, production, sales, and daily operations in a more organized way. For years I had seen businesses running on spreadsheets, notebooks, WhatsApp messages, and a lot of information stored only in people’s experience. I thought I could help solve part of that problem.

As an engineer and project manager, I approached the challenge in the way I knew best: by building. For months I worked on the architecture, prepared development, preproduction, and production environments, configured domains, integrated payments, improved the mobile experience, and redesigned the interface several times. I also built a user portal separate from the main application, simplified access to avoid multiple logins, and spent a lot of time on details that probably no user would consciously notice, but that were important to me.

Looking back, I realize that much of my energy was focused on making sure the product was ready to grow when the time came. And technically it was.

The application did not only work. It works. NeuraPRO is still alive, the platform is still operational, still evolving, and still has a clear path for agriculture and businesses that need to organize inventory, production, and sales. After more than a year of work, I felt I had built a solid foundation on which I could keep developing new features.

Then came the moment to launch it.

The launch

My initial strategy was relatively simple. I started with Meta Ads campaigns using small but consistent budgets. The idea was to validate whether there was real market interest: people saw the ads, clicked, and landed on the NeuraPRO website.

On top of that, I offered three free months of use. No credit card, no commitment, and no risk. My reasoning seemed logical: if the problem existed and the solution was useful, people would start using it.

At least that was the theory.

What the data showed

The clicks came. The visits came. People did indeed enter the site. But when I analyzed their behavior, the same pattern appeared again and again: they entered, explored a little, and left.

At first I thought it was a technical problem. Maybe the page was slow, maybe the registration process was too long, maybe the mobile experience could be improved, or maybe an important feature was missing. So I did what many engineers do when something does not work: analyze, measure, optimize, change, measure again, and repeat.

In parallel, I learned something that was not in my comfort zone: trying to sell the product. I created carousels for Meta Ads, tested different messages, adjusted copy, reviewed which images attracted more attention, and slowly started to understand how people’s behavior changes depending on a sentence, a promise, or a first impression.

I also requested videos and images from external collaborators, tested different formats, and learned that communicating a product is almost a product of its own. It is not enough to have an application that works. You have to explain in seconds why it should matter to someone.

I had to learn how to manage campaigns, how to look at landing page visits, how to interpret small signals, and how to improve the page so that the person arriving there could understand faster which problem NeuraPRO solves. I even built dashboards inside the portal to observe those data points more clearly: how many people arrived, where they came from, what they did, where they stopped, and what I could learn from that behavior.

That opened another world. Marketing, data, product, and human behavior started to mix. And although I am still far from having all the answers, today I understand much better that launching a product is not simply putting it online. It is building a complete system around attention, trust, message, timing, and continuous learning.

That is why I keep exploring this path. I keep thinking about new marketing strategies, keep adjusting the landing page, and keep observing what captures customer attention and what does not. At some point I will probably do a second launch, better prepared, with better materials, better data, and a clearer story.

Because the first time I did many things on the fly. And that was also part of the learning.

But the more I looked at the data, the more obvious an uncomfortable possibility became.

The problem was probably not in the software.

The lesson that was hardest to accept

I think I made a fairly common mistake among those of us who build technology products: I assumed that the main problem my potential customers had was the lack of a tool.

Today I think I was looking at the situation from the wrong perspective. Many people are not actively looking for new software. They do not spend time comparing SaaS platforms, evaluating features, or researching digital transformation processes. They are focused on keeping their business running, serving customers, solving operational problems, and making it to the end of the day.

And changing the way someone works is much harder than developing an application.

That was probably the most important lesson of this whole process. I saw an obvious opportunity for improvement. But for many potential users, the problem simply did not have the same level of urgency that it had for me.

And that difference changes everything.

The second attempt

As a second strategy, I decided to rely on something closer: my own network. I started talking with friends, acquaintances, and people connected to different industries. I thought maybe the problem was not the product, but trust. Perhaps a direct recommendation or a more personalized onboarding could lead to a different kind of adoption.

I got more signups, more conversations, and more initial interest. But the final result was quite similar. Some people tried the platform. Others even completed the onboarding process. However, after some time, they stopped using it.

The question remained the same: why?

The truth is that I still do not have a definitive answer. And I think part of the learning is accepting that some answers require more time than one would like.

NeuraPRO is still here

Something important I want to make clear is that NeuraPRO is not dead. It was not abandoned. It is not a forgotten project in a repository.

The platform is still running, the infrastructure is still operational, and the roadmap continues to move forward. The agricultural line is also still open, and it was an important part of NeuraPRO’s origin. I still see value there: producers, distributors, warehouses, stock, sales, and processes that often continue to run with scattered information.

What changed was my focus. Today I dedicate less energy to adding features and more energy to understanding problems. Less time building and more time observing. Less time programming and more time talking with people who truly live the problem I am trying to solve.

Because after this process I understood something important: adding features is relatively easy. Deeply understanding an industry is much harder.

From a multi-industry solution to understanding one industry

When I started NeuraPRO, I imagined a platform capable of adapting to multiple types of businesses. And technically, that is still true.

However, over the last few months I have started working with a friend who manages several bakeries in Chile, and that experience has been completely different. For the first time I feel I am spending more time understanding the business than building software.

Our conversations are no longer centered around screens, reports, or databases. We talk about raw material waste, production control, costs, margins, operational errors, daily processes, and real problems.

I have had many conversations trying to understand where he loses time, where he loses money, and what things truly cause pain in his daily operations. And the deeper we go, the more obvious something becomes that I probably should have understood from the beginning.

The best solutions are born when you deeply understand the problem before you start building.

The interesting part is that much of the difficult work is already done. The platform exists, the architecture exists, and the main backlog exists. Today, much of the effort is about adapting, simplifying, and adjusting what has already been built for a specific industry.

And that difference is enormous.

What AI changed along the way

There is another reason why I keep building. And it was probably never only about money.

Of course I would like to create something successful. Any entrepreneur would. But there is another motivation too: understanding how to work in a world where artificial intelligence is changing the way we create, learn, and solve problems.

During these years I discovered that my way of working adapts quite well to this new paradigm. I feel comfortable working with clear objectives, concrete actions, small tasks, and measurable results. AI did not replace that way of working. What it did was accelerate it.

That is why I have also started building tools for myself, tools designed to solve problems I face every day in my work. After all, who better than oneself to identify the frictions one experiences daily.

And perhaps that has been one of the most interesting lessons of this whole journey: today it is possible to build extremely personalized solutions for very specific problems, something that only a few years ago would have been much more difficult.

Something I did not expect

Interestingly, while I was working on NeuraPRO, many people began contacting me. Some were friends. Others were not. Most arrived with a similar idea:

“I have this problem in my business.”

“Do you think this could be automated?”

“Could a tool be built to solve this?”

It did not always turn into a project. But it did leave me with an interesting conclusion: the problems exist, the opportunities exist, and the ideas exist.

The hard part is not building.

The hard part is choosing correctly which problem is worth solving.

Final reflection

If someone asked me today what the main lesson of the last eighteen months was, I would probably answer something very different from what I would have said when I started.

It was not a technical lesson. It was not a lesson about architecture. It was not a lesson about artificial intelligence.

It was a lesson about people.

I learned that a good product does not guarantee adoption. I learned that good architecture does not guarantee customers. I learned that having more features does not necessarily create more value. And I learned that deeply understanding the problem is usually much more important than quickly developing the solution.

NeuraPRO is still here. The roadmap is still here. The ideas are still here. And I will probably keep building for a long time.

Only now I try to do it in a different order.

First understand the problem.

Then build the solution.


To follow the NeuraPRO story: the origin, the technical foundation and the road before the MVP.


✍️ Claudio from ViaMind

“Dare to imagine, create and transform.”


Comments
Comments are shared between English and Spanish versions.

Subscribe

Get a monthly email with the best posts on innovation, technology, and the future. No spam.

* required

Intuit Mailchimp