Abacate Pay
How we helped Abacate Pay shape the product before the first deploy
Abacate Pay arrived with a validated thesis, funding raised, and a deadline to show product. The team had two developers and no designer. Without defined flows and without a visual system, every week of code was technical debt waiting to happen. We came in to give the product shape before it became irreversible. We set the first concepts, the main flows, and a design system built for the internal team to extend without onboarding. After launch, they kept coming back: every redesign passes through our judgment before shipping.
The starting point
The brief was specific, not ambitious. Abacate needed a PIX payments gateway that indie hackers and small teams could integrate in minutes. The company positioning was settled. The product was missing. The dashboard became the entry screen instead of a cards-heavy overview. Payment list first, available balance as the headline, completed transaction count as the secondary information, filters (Completed, Pending, Failed) next to the action buttons.
Shape before code
Before any high-fidelity Figma, we mapped with the team the minimum states a gateway needs to cover: charge created, charge paid, charge expired, processing failure, refund, chargeback. When the state exists in the product and not on screen, it becomes a support ticket. When it exists on screen but not in the product, it becomes silent frustration. The v1 of the app was designed with those states as the skeleton. Screens came later, anchored in state, not in the happy path.
A design system for a team with no designer
The DS was built for the internal team to use without a designer next to them. The inclusion criterion was a single one: every component had to be understandable in a few seconds. If it needed explanation, it stayed out of v1. Color, typography, spacing, and input states were documented as named tokens, not as visual reference. The developer consumes the token, not interprets the pixel.
The platform seen by the Abacate client
Abacate's client is the developer who integrates. For them, the platform has to look made by an engineer: no ornament, clear hierarchy, no celebrating small wins with animation. Every screen passed through that ruler. When decoration took space from information, it left.
They came back
The app shipped, and the Abacate team kept designing the rest. At some point, instead of sending a redesign straight to deploy, they started running it past us first. "We redid this flow. What would you change?" From then on, it became routine. They design, send it over for review, adjust what makes sense, ship. The team decides what is worth reviewing, not us.
Your product could be next.
We help founders and small teams who need UX, a design system, and product judgment before every code decision turns into technical debt.