What AbacatePay teaches us about choosing a niche and building with a community

One of AbacatePay's earliest features was an open roadmap. One user asked for a change to a webhook; another wanted Google sign-in. The team would implement the change, mark it as delivered on the board and follow up with the person who had suggested it. Daniel Lima described this process at NewHack OpenClass as he explained how a payments product began to take shape within a community.

The story sheds light on a decision many businesses face: where do you start when a market seems to be occupied by bigger companies? In Daniel's account, the answer involved understanding a problem firsthand, choosing whom to serve first and learning what lay behind the integration the customer would use.

NewHack OpenClass connects the community with founders and leaders who share practical experiences of building companies. The conversation with AbacatePay's cofounder adds to this body of knowledge, with decisions about product, operations, distribution and the limits of growing by pursuing every opportunity that comes along.

Fintech is the start of the conversation

Daniel compared saying you have a fintech company to saying you have a SaaS business: the category still leaves the problem being solved undefined. Payments, lending, insurance and financial management involve different customers, operations and challenges. A more specific definition is needed.

Saying you're a fintech tells you almost nothing.

Daniel Lima, cofounder of AbacatePay. Translated from Portuguese.

The framing also matters when understanding what a company does. Brazil's Central Bank describes different categories of fintech companies. In AbacatePay's case, its own website presents it as a technology platform that facilitates payments through partner institutions. The experience delivered to the user depends on a chain of services and responsibilities.

The first market was close at hand

Looking back at AbacatePay's beginnings, Daniel said that he and his cofounder, Christopher Ribeiro, were already part of a community of people building digital products. Payment integration and communication with providers were difficulties they both knew firsthand. This group became the first audience for the MVP.

That focus brought a practical advantage: the founders could talk to the people they intended to serve and recognize the needs they described. The API and communication became pillars of the product. The open roadmap shortened the path from a request to implementation and a response to the user.

Daniel described this approach as growing from the inside out. For those starting out, the experience raises a useful question: is there an identifiable group with the same problem and a willingness to try a solution? Finding it allows founders to test a concrete proposition before broadening their target market.

Listening to requests calls for judgment

A question from the audience brought up the tension that comes with this closeness: how do you distinguish a good suggestion from a highly specific request? Daniel answered by referring to the ideal customer profile, known as the ICP. This focus helps assess whether a request strengthens the product or changes its direction.

He mentioned a negotiation with a potential customer from another segment. Serving that customer would require developing a feature that would take months and interrupt the existing plan. The opportunity presented a choice: stay on the planned path, adapt the product or commit to a change in focus.

Daniel acknowledged that changing direction can also make sense. The point is to make that decision consciously. A large request needs to be weighed against the work that will be postponed, the customers who will no longer be served and the company the founders want to build.

The complexity continues after integration

Much of the conversation focused on the work required to operate payments. Daniel discussed knowing your customers, building relationships with partners, keeping up with rules and maintaining infrastructure availability. Asked about difficulties, he identified earning providers' trust as one of the first challenges beyond the code.

On the technical side, he discussed building an internal record of transactions, called a ledger, and the evolution of customer identification and monitoring processes. He also highlighted service availability: a simple integration for a merchant depends on continuous work behind the scenes.

That distinction emerged when he compared operating Pix payments with operating card payments. Expanding required learning another set of rules, participants and risks. In his account, adding a payment method involved more than offering another option at checkout.

Be a nerd and have no ego.

Daniel Lima, cofounder of AbacatePay. Translated from Portuguese.

The phrase sums up the combination Daniel advocated: deepen your knowledge of the business while remaining open to being challenged. He extended the advice to other sectors. Anyone developing software for an activity needs to understand how it works in practice, including where the product can fail.

When AI also takes part in integration

Artificial intelligence came up in connection with a shift in the audience. Daniel observed that AI-assisted tools allow more people to build software, including professionals who did not start out as developers. For payments infrastructure aimed at people who build, this broadens the situations in which an integration needs to work.

He presented documentation prepared for AI tools and discussed the use of MCP. AbacatePay's public documentation describes an MCP server for executing API actions through compatible clients, as well as context files to support code generation. These are different functions, each with its own applications.

For founders, the takeaway is to observe who is beginning to interact with the product and through which channels. Alongside an interface and an API, documentation can be part of the experience for a user building with AI. Daniel also described tutorials created by the community itself, connecting ease of integration with the sharing of knowledge.

A community in conversation with the product

Near the end, the roadmap came up again. Daniel showed that suggestions were still coming in, now with a review stage before they reached the public board. Amid discussions about infrastructure and security, he said that one of the most requested features had been dark mode.

The example offers a concrete picture of this relationship. Users see needs that the team may put on the back burner; the team needs to listen while maintaining its choices about focus and operations. The experience shared at the OpenClass offers this starting point: choose whom to build for, keep the conversation close and deepen the work that makes each delivery possible.