Leobit
Multi-product enterprise ERP platform
Software architecture design and custom software development that unifies seven enterprise products under a single Google sign-in with per-service data isolation and one governed data pipeline
ABOUT the project
- Client:
- Leobit (Internal project)
- Location:
-
USA
- Company Size:
- 200+ Employees
- Industry:
-
Software development
- Solution:
- Custom software development
Services:
Technologies:
Leobit developed a multi-product ERP platform to support its internal business operations. The platform brings together seven interconnected applications into a single ecosystem with a single sign-in experience. While each product operates independently with its own database, users authenticate only once and can seamlessly switch between applications, accessing only the data permitted by their roles.
The platform streamlines the day-to-day operations of a software company by centralizing key business functions, including invoicing and payments, payroll, compensation management, access control, human capital management, client account management, and finance and business intelligence, all within a unified, user-friendly interface.
We treated our own operations as a client project. The platform now runs the company day to day, and the process behind it — specifications first, AI agents inside guardrails, humans owning every decision — is the same one we bring to customer work.
Customer
It was Leobit’s internal project aimed at supporting internal operations.
Business Challenge
As Leobit expanded, its internal operations relied on multiple disconnected systems for finance, HR, client management, and analytics. Separate logins, inconsistent access controls, and fragmented data made daily work less efficient, and reporting meant pulling exports by hand, which increased administrative overhead. The company needed a unified platform that would provide a seamless user experience, centralize identity and access management, securely isolate each product’s data, and establish a governed data integration layer for reporting and analytics without impacting operational systems.
Project
in detail
Leobit owns the platform’s full design, from the identity model to the data pipeline. The project reflects the kind of enterprise architecture work Leobit delivers for clients: a federated suite of products that remain independent, a security model that fails closed, and a data layer that supports fast analytics without becoming a back door into production systems.
Our team built the shell as the Next.js front end for the entire platform. It serves the landing page, the app tile launcher, and the admin console, while also providing the authentication and back-end-for-front-end routes that broker sign-on into each product. Once a user authenticates, the shell carries that identity into any product they open, removing the need for a second login. We deliberately kept the shell thin. It routes, launches, and administers, while the business logic stays within individual products and the foundation services that support them.
Our team built a set of business-capability APIs, including File, Email, Doc-to-HTML, and Data-Integration, on top of an internal operation broker. The architecture allows a single consent at sign-in to enable access to Gmail, Sheets, Docs, Drive, and BigQuery on the user’s behalf, with the broker holding that access centrally. A product requests an outcome from the capability layer, such as sending an email or converting a document to HTML, and the layer performs the operation. No product holds a Google token directly. Every Google call goes through a single governance layer where our team manages access, auditing, and rate limiting, rather than spreading those responsibilities across seven applications.
Our developers adopted RabbitMQ and built a shared event bus to carry cross-app facts between products, such as an invoice being paid or an employee changing roles. Products publish what happened and subscribe only to the events they need, which keeps them decoupled. We designed the bus as an accelerator. If a message is delayed or missed, the authoritative data remains in the product that owns it. Consumers can rebuild their view through a synchronous read instead of depending entirely on event delivery. We designed the event bus as an accelerator rather than a correctness dependency. If a message is delayed, missed, or the broker becomes unavailable, the authoritative data remains in the product that owns it. Consumers can always rebuild their view through a synchronous read, so an outage affects latency rather than data consistency. We adopted this architecture only after determining that the platform’s scale and integration requirements justified an event-driven approach.
Our team defined the APIs and events exchanged between products as shared contracts in TypeScript and Python. A contract defines the agreed shape of a request, response, or event. Every product imports the same definitions, so changes made in one place propagate to all consumers. This removes guesswork at product boundaries. A product cannot quietly send or expect the wrong structure because mismatches surface against the shared definition before they reach production.
Our team built a vendored library of UI primitives and design tokens to give every product the same foundation. Buttons, forms, spacing, and colors are sourced from a shared set, so they behave consistently across the suite. As a result, users experience seven separate applications as one cohesive product, even though each is built and deployed independently.
Every request must include a verified, signed token, and unverified requests are rejected by default. Our developers configured the nginx mesh to present all services from the same origin at the edge while keeping service-to-service communication on a private network. Products that handle especially sensitive data run on their own isolated origins. This creates a single public surface with private connectivity behind it, and a failure mode that denies access rather than allowing it.
Our team gave each product its own PostgreSQL database. Products reference each other by key instead of reaching into each other’s tables, so a schema change in one product cannot break another. Our developers also connected the operational products to the finance and data intelligence hub. This hub acts as the universal sink, consuming facts from across the suite and pairing a BigQuery warehouse with Power BI for reporting.
Our team built the platform as a polyrepo, with a separate repository for each product and shared service. Three environments run in parallel: DEV builds from the dev branch, STAGE from stage, and PROD from main. Our developers configured CI/CD automation for each environment, allowing each branch to promote cleanly to its corresponding stage. Promotion to production happens only on explicit human approval.
We designed a central backup service that treats backup as a platform guarantee. Every product registers itself with the backup service at startup, so a new product cannot be forgotten and enrollment is automatic. Product databases are backed up on schedule, and a backup only counts after an automated restore round-trip proves it can actually be recovered; point-in-time recovery is defined for the platform’s databases. Failed events wait in dead-letter queues for replay instead of being lost.
A read-only monitoring service watches the health of every container in the platform through an isolated proxy and feeds a live status page in the admin console. Containers opt in with a simple label, so monitoring coverage grows automatically as the platform grows. The monitor is deliberately powerless: it can observe everything and control nothing. We applied the least privilege principle even to observability.
None of this is free, and the architecture documentation says so explicitly. Database isolation means products call APIs and keep local projections instead of writing one SQL join. Shared contracts require coordinated versioning when they change. Centralizing credentials concentrates risk in the identity service, which is exactly why it is the smallest, most reviewed, most audited component in the platform. The team accepted these costs deliberately, because independent deployment, bounded data access, and auditable governance mattered more for an enterprise platform than raw convenience.
Adversarial, multi-model design review
Leobit implemented a multi-stage design review process before development began. Every architecture decision was reviewed by two independent AI models, one from Anthropic and one from OpenAI, and then validated by a human architect. Using multiple models helped identify different types of issues, while human review ensured every decision was technically sound.
The platform architecture underwent 13 documented revisions, including four formal review rounds. The first review alone identified 16 findings, ranging from a missing deny-by-default row-level security contract to migration-ordering dependencies. Every finding was documented and mapped to the architectural section where it was addressed, creating a transparent record of design decisions and their evolution.
Leobit also maintained a complete revision history rather than silently updating the design. For example, an early version described part of the row-level security mechanism as “unforgeable.” A later review demonstrated that this guarantee was not possible in PostgreSQL, so the team explicitly retracted the claim, updated the threat model, and documented the change. This disciplined review process helped strengthen the platform architecture while maintaining a clear audit trail of every significant design decision.
Identity and SSO development
Our team built a single identity service to own Google sign-in, user sessions, and the signed JSON Web Tokens that represent logged-in users. This service is the only platform component that ever holds Google credentials.
For sign-in, our developers implemented Google OAuth with OIDC and PKCE. The service completes the Google handshake, establishes the session, and gives each product a signed identity instead of the underlying keys.
Every product trusts a request by verifying the token signature, which identifies the user. Products never see, store, or refresh Google credentials themselves. By consolidating credentials in one service, our team gave the platform a single place to rotate secrets, end sessions, and revoke access. As a result, a compromise of one product does not expose the keys.
Access Control
Leobit experts built Access Control as the security source of record for the entire platform. Identity proves who a user is, while Access Control decides what they may do and see.
The team modeled roles and product entitlements in the Users and Access view for role-based access, then built three independent row-level visibility domains. Account RLS maps managers to the client accounts they may see, automatically derived from the accounts, delivery owner, and employee tables. Employee RLS maps managers to their reporting line, with a strict position-level cap, a block list, and functional offices such as SDO, QMO, and PMO as read-only groups. Information RLS maps managers to manually assigned information tags.
Each domain follows the same pattern: automatic rules create the first pass, admins refine it, and the service publishes a manager-to-record mapping table that downstream products use for their own row-level security. Every table is advertised to the Data-Integration Service, and a broker event fires after each change, so access updates propagate as soon as an admin grants or blocks them.
Data-Integration Service: the data pipeline
Leobit experts built the Data-Integration Service (DIS) to manage all data in motion, including all imports and exports between the platform’s apps and external systems.
The team made one rule absolute: apps never connect to Google Sheets or BigQuery directly. Instead, each app advertises a bridge or emits an event, and DIS moves the data through a single pipeline: source, dataset, DIS table, one or more bridges, and target.
Every external call goes through connectors that use short-lived, scope-limited tokens minted by Identity, so raw service account keys never leave the identity layer. The engineers also assigned every job a single code path, whether it starts from an event, an API call, or a cron job. Each path includes per-connector rate limits, retry and backoff logic, and a full audit trail.
The team also defined clear authority rules. In export mode, the app database is authoritative, and the dataset is a projection. On import, the external system is the source, and the dataset is staging. Every dataset has one owner and a versioned contract, so apps never couple to each other through the warehouse. A Dataflows board maps every connection and provides a live view of pipeline health.
Technology Solutions
- Established a secure, enterprise-grade reference architecture that serves as a foundation for future product development and demonstrates Leobit’s expertise in designing federated software ecosystems
- Used Google OAuth with OIDC and PKCE to manage authentication through one identity service that issues access tokens across the platform.
- Applied PostgreSQL as a dedicated database for each product, keeping application data isolated and reducing cross-product dependencies.
- Adopted RabbitMQ to support asynchronous cross-product events without creating hard dependencies between applications.
- Integrated nginx as a same-origin mesh, presenting services publicly from one origin while keeping internal traffic private.
- Used BigQuery as the analytics warehouse for the finance and data intelligence hub.
- Integrated Power BI to deliver reporting on top of the analytics warehouse.
Value Delivered
- Delivered a unified authentication experience with single sign-on across seven products, simplifying access and improving user productivity.
- Centralized identity and access management with role-based and row-level permissions.
- Built a scalable multi-service architecture with isolated databases, enabling independent product development while minimizing operational risk.
- Streamlined enterprise reporting through a centralized data integration layer, accelerating analytics while protecting the integrity of source systems.
