Sinalio Began with a Recurring Task on WhatsApp

A recurring task in our partners’ customer conversations became Sinalio. Here is how our first productive month unfolded, from the MVP to finding people willing to try it.

Updated

Gouache illustration of a person seen from behind in a warmly lit workshop opening onto a navy evening street, with glowing connections leading to nearby windows.

Before there was a widget, a knowledge base or a public roadmap, there was a recurring task in the WhatsApp groups for our partners’ SaaS products: go back through the conversations, remember who had asked for each feature and tell them it was finally live. That work became the starting point for Sinalio.

At first, I was thinking about SaaS products run by a few business partners. Their customers were making requests, development was moving forward and changes were reaching production. After a release, someone still had to connect the dots: find the conversation, recover the request and write something like, “That feature you really wanted is available now.”

I didn’t want every delivery to require another manual round through those groups. Sometimes the contact felt forced, made only to convey information that could have been available inside the software. Some customers and situations absolutely benefit from a personal conversation. That kind of service still matters. But an individual message isn’t necessary for every update.

That was the starting point for our first productive month. We didn’t begin with every part of Sinalio as it exists today. The scope grew as one question led to another.

First, we needed to tell people what had shipped

We built Sinalio to help developers and users communicate. The initial need was straightforward: tell customers that something had changed in their software.

We included customer emails and created two ways to display updates. One sits inside the product through a widget. The other is a public Sinalio page that the application can direct people to.

This gave the information a home instead of leaving it dependent on someone finding the right conversation. A person could discover an improvement while using the product or visit its updates page. Personal contact remained available whenever a situation needed more context, an explanation or a real discussion.

Then came a question that an announcement alone couldn’t answer: “What now? Did people actually like it?”

Each addition left another question open

That is how feedback collection entered the product. We already had a way to communicate a change. We also needed a way to hear from the people who had used it.

Documentation followed. An update can tell someone that a feature exists without explaining exactly how it works. We thought that, if we were delivering features, there should also be a way to document their use properly. That led to the knowledge base.

The public roadmap came from another recurring question. Some users of our customers’ SaaS products wanted to know what would happen to requests that hadn’t been delivered: “What about that other feature I asked for? Is it coming, or isn’t it?”

Explaining what was ready and giving people visibility into what was still being considered were different jobs. That question led us to the roadmap.

Looking back, I can describe the product’s development through the conversations behind it: we need to announce the delivery; we need to hear the response; we need to explain how it works; we need to make the next steps visible. That is how we arrived at the MVP of these features during this month of work.

We also had to think about how to present them without overwhelming a team just getting started. Today, the features are available across all plans, and each team chooses which ones to use. Navigation for features they haven’t enabled stays out of the way. A team starting with updates doesn’t have to introduce every other area at the same time.

I thought getting people to the site would be easier

After delivering that MVP, we started exploring ways to make Sinalio known. We created the blog, began working with Instagram, X and LinkedIn, and added the product to TrustMRR and ListaMRR.

We’re working on SEO so founders in different countries can find us. That work is still taking shape, and my initial expectation was too optimistic: I thought attracting people to the website would be much easier.

It has been a daily challenge, with gradual progress. The most direct work has happened when I approach companies and introduce the tool myself: “I have a product that does these things. Would you like to test it and see whether it helps you communicate with your customers?”

That approach means explaining Sinalio to a particular business in its own context. It is a different kind of work from preparing a page or publishing an article. We’re still doing both: trying to be found and actively looking for people who could benefit from what we’ve built.

I want to bring this part of the experience into the blog, too. So far, we’ve written a lot about feedback, product updates and how to use these tools. Now I want to share what it is like to build Sinalio itself, including the work that doesn’t produce a new feature to show.

Agents became part of the writing process

Another thing that made a difference during this first month was MCP, through which we connected Sinalio to ChatGPT and Claude. In our workflow, being able to delegate the writing and then review the result was essential.

We can provide agents with the context of code changes from tools such as Azure DevOps, GitHub, GitLab or Bitbucket. With that material, they can help turn development work into an explanation for the people using the software. Sinalio becomes the channel for delivering that communication.

We’ve had a very good experience preparing copy from that context. I review the result to check that it accurately describes what shipped and makes sense to the reader. It is a combination that works for us: the agent helps with the writing, and we decide what is ready to reach users.

A beginning I want to share

I want to build Sinalio in public. This article is a starting point: where the idea came from, how the scope grew and what we’re encountering as we try to bring the product to more people.

I’ve created @mllrdev on X, and Sinalio is listed on TrustMRR and ListaMRR. I want to use those spaces and this blog to share the decisions and work behind the product.

Our ambition is to make Sinalio an increasingly complete connection between development and customer communication. By the end of 2026, our goal is to complete integrations with the main code repository and work-management tools, along with communication channels such as Teams, Discord and Slack. That is the target we are working toward for the product’s next stage.

We want to combine that connection with two choices already built into Sinalio: features available across all plans, and the freedom to enable only what a team needs now. We have a big vision for the product without requiring every customer to adopt everything at once.

I’m still approaching companies, introducing Sinalio and inviting people to try it. At the same time, we’re building toward what we want it to become. I want to share that journey up close: the releases, the decisions and the work of turning that ambition into a product.

Written by

João Müller