Makley Software Engineer
SaaS Product 2025 Private code

AgroNota

Tax and financial platform that turned rural producers' accounting close into a matter of minutes.

My role
Front-end Developer
Context
SBSistemas · Smarten Venture Builder
Category
SaaS Product
AgroNota home screen showing the tax-filing platform for rural producers.

Web and mobile system for issuing NFP-e, generating the Livro Caixa (cash book) and LCDPR filings for rural producers, accounting offices, unions and cooperatives. I worked on the product's front-end for four years, from the issuance flow to the reconciliation and reporting screens.

Results

7,100+
active customers Producers, accounting offices, unions and cooperatives
95%
of the cash book automated Cash book and tax ledger generated by rules, with no manual entry
735h
saved per month Reduction reported by a single client accounting office

The problem

Rural tax closing in Brazil is one of the most bureaucratic processes there is: NFP-e documents issued through different state government portals, Funrural, forward-delivery sales, activity-based cost allocation, and the mandatory LCDPR filing. Accounting offices spent the entire month entering documents manually, one producer at a time, with a high risk of error and rework when it came time to file with the Federal Revenue Service.

The solution

We built a product that fetches documents directly from SEFAZ in real time and applies a rule set that automatically classifies each entry — reaching 95% of the cash book and LCDPR filings generated with no human intervention. On the front-end, that meant extremely dense data screens (tables with thousands of rows, batch editing, OFX reconciliation) that still had to stay responsive, plus a field-issuance app built for a connection that doesn't always cooperate.

Key challenges

  1. Rendering fiscal tables with thousands of entries without freezing the interface — solved with virtualization, server-side pagination and careful memoization of derived state.

  2. Modeling tax forms with dozens of interdependent fields and conditional validation, while keeping them testable and readable with React Hook Form and Zod.

  3. Keeping visual and behavioral consistency between AgroNota and the company's other products, consuming the same design system without forcing it to fit the specific needs of the tax domain.

  4. Sustaining legacy code while new features kept shipping, without freezing the roadmap or quietly piling up technical debt.

Technologies used

  • React
  • TypeScript
  • Next.js
  • Vite
  • Zustand
  • Redux
  • TanStack Query
  • React Hook Form
  • Zod
  • Material UI
  • Styled Components
  • Cypress
  • Sentry
  • GitLab CI/CD

The context

AgroNota was built for an audience software rarely prioritizes: the rural producer, and the accountant who serves dozens of them. It’s a domain where the tax rule changes by state, the user is out in the field with an unstable signal, and the cost of an entry mistake shows up months later, in a tax audit.

My role

I worked on the product’s front-end for four years, from the document-issuance flow to the bank-reconciliation and reporting screens. Beyond shipping features, I did code review, pair programming, helped set standards across developers, and organized the backlog.

One of the things that stuck with me most technically was learning to treat information density as a design problem, not just a performance one: cutting the number of clicks in the monthly close mattered just as much as cutting the table’s render time.

↑ ↓ navigate ↵ open esc close