Context
Arquivei, later renamed Qive, extracts and structures fiscal documents for companies. I worked in three contexts over four years: Custom Projects (2021–2022) on custom front-end solutions for enterprise customers, Professional Services (2023–2024) building custom integrations and features for the same kind of customer, and the Ingestion team (2024–2025) on the NFSe module.
Scale is the defining constraint: a front end that lists, filters and validates documents on top of a dataset measured in billions per year cannot treat a query as free.
Problem
- Enterprise customers need to find specific documents inside a dataset far too large to browse.
- The UI has to stay responsive and honest about what it is showing: the user makes fiscal decisions from it.
- Custom enterprise requirements tend to be client-specific, which pushes against a shared product and design system.
- Authentication and access control run through the platform's identity layer (Keycloak).
My responsibility
Front-end engineering on the NFSe module: interfaces and flows over the existing API, within the platform's established patterns, design system and state management. Earlier, I built and maintained custom integrations and custom front-end solutions for enterprise customers.
How I approached it
Consistency first: the module already had conventions for components, state and error handling, so new work followed them rather than introducing a parallel style. For lists over large datasets, the important question is what the client actually needs to receive: pagination and filtering belong on the server, and the client's job is to render predictably and debounce what the user types. Production issues were diagnosed through error tracking and dashboards instead of guesswork, and changes shipped through the platform's containerised CI/CD pipeline.
Challenges
- Building interfaces over a dataset of billions of documents per year without pretending the client can hold it.
- Serving enterprise-specific needs while keeping the product coherent for everyone else.
- Working inside a codebase with years of history and several teams: reading before writing is a survival skill.
Decisions and trade-offs
- Follow the design system and existing state patterns. Trade-off: some screens are less optimal than a bespoke solution would be; the codebase stays learnable across teams.
- Client-specific work kept separate from the product path. Trade-off: duplication in places, but the shared product never permanently carries one customer's exception.
- Server-side pagination and filtering over client-side convenience. Trade-off: more round trips and a UI that must handle loading states properly, but a client that does not collapse on volume.
Result
Four years of continuous delivery inside a product of that scale, and proficiency in a domain that punishes imprecision.
What I learned
- Scale changes interface design: what looks like a UI question is often a query-shape question.
- Domain literacy (a fiscal document is not a generic record) is what makes front-end decisions correct.
- Long-lived codebases reward convention over cleverness.