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
The dashboard is where the developer spends time. Payment list as the entry screen, not a dashboard with cards. Available balance as the headline, completed transaction count as the secondary information, filters (Completed, Pending, Failed) next to the action buttons. The read is direct: what came in, what failed, what is still pending.
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 internal team kept building the product. A few releases later, they came back with a question: "We have this redesign. What would you do differently?" The pattern stuck. For every major redesign, the team prototypes, sends it over, and uses our review as reference before shipping. On-demand consulting, not a fixed scope.
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.