ERPRFC000 — Koder ERP Architecture Overview

• *tatus:*Draft
• *ate:*20260411
• *cope:*Architecture target for running Crescer, Vivver, and Koder itself on the Koder Stack as a first-class ERP consumer
• *elated RFCs:*kompass-RFC-001-identity-and-org-unification.md, erp-RFC-001-licitacao-vertical-engine.md

Summary

This RFC frames how the Koder Stack — the same monorepo we ship as product — becomes the ERP that runs Crescer, Vivver, and Koder internally. It is the index document for the ERP track of RFCs: it maps gaps, assigns them to existing modules or new engines, defines the phase order, and records the decisions that unlock the next RFC.

Two assertions shape everything downstream:

1. *oder is not buying or building "an ERP product."*Koder is consuming its own stack internally. Every ERP requirement either maps to an existing Koder module or reveals a real gap in the stack that must be filled, regardless of the ERP framing. The ERP is a forcing function, not a product.
2. *osaic is not the ERP.*Mosaic is the consumer face of Kompass (the universal tenant engine). The ERP is the union of Kompass + vertical engines + horizontal engines consumed through one or more apps. Mosaic participates in that union as the peopleorgunit/event app, not as the umbrella.

Motivation

Crescer and Vivver are Brazilian technology services companies with meaningful operational complexity:

• Three legal entities (Crescer, Vivver, Koder) sharing staff — one person can be a director of all three simultaneously, a developer on Crescer with a PJ contract, or a field technician paid by Vivver but operating under Crescer's support contract. The concept of "the same person across multiple orgs" is non-negotiable.
• Revenue depends on Brazilian public procurement (licitação pública). Editais published on the PNCP (Portal Nacional de Contratações Públicas) are the top of the funnel; losing PNCP visibility loses the business.
• Around 90 field technicians operate from ~60 municipalities across MG, RJ, SP, PB, BA, MA, PA. Travel, expense, and location-aware scheduling are daily operations.
• Teams include commercial, bidding, implantation, central support, local support, monitoring, infrastructure, administrative, financial, HR, marketing, prospection, plus the tech stack itself (dev, QA, data, architecture).
• Brazilian tax and labor compliance is not optional: NFe, NFSe, SPED, eSocial, CAGED, RAIS, LGPD, ICP-Brasil assinatura digital.

No offtheshelf ERP handles this stack well. TOTVS Protheus, Senior, Sankhya, and Fluig cover the financial/HR base but miss licitação, are weak on field operations, and are generally hostile to engineering-led customization. Running on the Koder Stack instead is a deliberate choice: it forces the stack to mature against real load, produces commercially viable modules as a byproduct, and avoids paying license fees for an ERP that would never be a great fit anyway.

The nine gaps, mapped to the stack

A Brazilian tech-services ERP has roughly these functional requirements. The table maps each one to the current Koder Stack, marks what is present vs missing, and names the owner.