Frihet’s AI-Native ERP: Building a Production Accounting Platform on Firebase in Under 3 Months
Frihet’s AI-native ERP leverages Firebase, Google Gemini, Stripe, and a centralized financial engine to deliver a localized, high-performance accounting platform with integrated AI copilots.
FACTUAL ACCURACY
A focused tech stack for a production ERP
Frihet’s technical foundation is compact and opinionated: a React 18 and TypeScript frontend built with Vite 5, styled using Tailwind CSS plus shadcn/ui and Radix; a backend built on Firebase services (Auth, Firestore, Cloud Functions, Storage); AI via Google Gemini (2.5 Flash + Pro); payments through Stripe Billing and Connect; hosting split between Vercel for the frontend and Google Cloud Platform (europe-west1) for backend services; and mobile builds produced with Capacitor to target iOS and Android from the same codebase. These choices reflect a single-developer tradeoff: assemble managed services and modern frontend tooling to move from idea to production quickly.
Why Firebase was chosen over a traditional backend
The author framed Firebase as a pragmatic decision for a solo developer competing against well-funded teams. Firebase supplies turnkey components—authentication across email and OAuth providers, realtime-capable Firestore, server-side Cloud Functions that scale to zero, and declarative Security Rules that enforce tenant isolation at the database level—removing the operational burden of managing database clusters, migrations, and connection pooling. The cost of that convenience is vendor lock-in and the constraints of a NoSQL data model; for rapid shipping by one developer, that tradeoff was judged acceptable.
Adapting a NoSQL model to ERP needs
Because ERPs typically map well to relational schemas, shipping an ERP on Firestore required disciplined modeling and clear conventions. Frihet enforces workspace isolation at the database layer so tenants are partitioned by security rules, removing a large class of cross-tenant leakage risk. The data design favors denormalization for read paths—e.g., showing a client name in an invoice list without an extra query—while preserving canonical records for writes so mutations target the single source of truth. Complex aggregations and cross-entity operations that resemble SQL JOINs or GROUP BYs are delegated to Cloud Functions rather than pushed into client code. This approach handles roughly four out of five use cases smoothly; the remaining portion of complex reporting and cross-entity querying demands extra engineering compared with PostgreSQL-style tooling.
State management by leaning on the database
Instead of introducing a client-side state library, Frihet treats Firestore as the application’s state store. The data flow is intentionally simple: a user action triggers a hook that writes to Firestore; onSnapshot listeners observe the persisted state and React re-renders. Optimistic updates bridge the latency between the write and the snapshot confirmation. By making Firestore the single source of truth, the implementation removes categories of client bugs such as stale caches, synchronization conflicts, and cache invalidation edge cases—“the database is always right,” in the author’s formulation.
Centralized financial calculations to ensure correctness
Financial logic is consolidated into a single calculation engine rather than sprinkled across UI components. All tax calculations, totals, and rounding operations pass through the same code path so a fix to calculation logic applies everywhere—on invoices, quotes, expenses, and reports. The article cites Spanish fiscal examples to underline the need for rigor: multiple VAT rates (21/10/4%), Canary Islands IGIC bands (7/3/0%), and freelancer IRPF withholding (-15%) are handled centrally. The implementation example shows a shared calculateTotal function invoked with line items and fiscal parameters, guaranteeing uniform rounding and aggregation behavior across the product.
AI treated as a first-class platform capability
AI is integrated as an operational feature rather than a superficial chat overlay. The copilot operates by invoking typed, structured functions that act on real user data through the same APIs the frontend uses—function calling rather than retrieval-augmented generation (RAG). The design choices called out are:
- Function calling, not RAG: the AI executes explicit functions with typed parameters (for example, create_invoice({ clientId, items, taxRate })) instead of searching documents and guessing intent.
- Lazy loading: the AI module is loaded only when users first interact with the chat; preloading begins on hover to ensure readiness by the time of click.
- Context injection: the system prompt includes concrete business context—active clients, recent invoices, tax obligations—so AI operations are grounded in live data rather than speculation.
- Security boundaries: AI runs under the same permission model as the UI; it cannot access data beyond the user’s privileges, and function calls adhere to existing security rules.
These constraints keep AI behavior explicit, auditable, and aligned with application permissions.
Localization and translation at scale
Frihet supports full localization across 17 languages, including fiscal terminology rather than simple machine-translated labels. The translation workflow relies first on a 240,000-entry Translation Memory with a 97.8% match rate; AI is used only to fill remaining gaps. That hybrid pipeline reduced per-run translation costs from $3.36 to $0.30, a 91% cost reduction. To maintain parity, a continuous-integration check blocks commits that introduce missing translation keys, ensuring all languages remain synchronized.
Performance and build metrics
Performance targets and results are stated explicitly: Lighthouse desktop scores of 100/100/100/100, First Contentful Paint under one second, and build times under ten seconds for TypeScript type checking plus Vite bundling. Architectural choices such as route-level lazy loading and on-demand AI module loading contribute to those metrics.
Trade-offs and the pragmatic lesson
The author acknowledges that Firebase is not an objectively “right” choice for every ERP scenario: PostgreSQL and a traditional backend would make reporting and certain cross-entity queries easier, and would give the developer more granular control over the data layer. Still, Firebase enabled delivering a production ERP with 17 languages, 41 integrations, full accounting features, and AI as a solo developer in under three months. The central maxim is pragmatic: an architecture you can ship with is preferable to one you cannot finish.
How Frihet’s design answers practical user and developer questions
Frihet’s stated design choices clarify what the product does and how it operates. It functions as an AI-native ERP with accounting, invoicing, and multilingual support, handling tax calculations centrally and integrating payments through Stripe Billing and Connect. It works by combining a modern single-page application stack (React, TypeScript, Vite) with managed backend services (Firebase Auth, Firestore, Cloud Functions) and AI provided by Google Gemini. The AI copilot operates via function calls into the same application APIs and abides by the same security rules as the UI, reducing the risk of unauthorized data access. Developers and maintainers benefit from reduced operational overhead: authentication, realtime updates, and serverless compute are delegated to managed services so a small team—or in this case, a single developer—can focus on product logic. The article indicates that Frihet is available to try and links the app and documentation, implying the product can be accessed as a web application.
Developer implications and ecosystem context
Frihet’s architecture points to practical tradeoffs relevant to product teams and engineering organizations. Relying on managed services accelerates feature development and minimizes ops work, which is attractive for early-stage teams and solo founders. The choice to treat AI as a set of typed function calls rather than an open-ended retrieval layer emphasizes safety, audibility, and alignment with existing access controls—an integration pattern that will be familiar to teams building secure extensions on top of CRM platforms, accounting systems, or developer tooling. Teams prioritizing complex reporting, analytical flexibility, or tight control over SQL semantics should weigh those needs against the speed gains from a managed NoSQL stack; the author explicitly contrasts Firestore with PostgreSQL for reporting complexity.
Business use cases and integrations
The product surfaces core ERP use cases—multi-rate tax handling, invoicing, quoting, expense tracking, and payments—paired with integrations that include Stripe for billing and Connect. The localization and translation pipeline indicates target markets where fiscal terminology varies across jurisdictions, and the mobile strategy—one codebase exported via Capacitor—supports cross-platform access for users who need mobile invoicing or expense entry. These choices make the product applicable to small businesses, freelancers, and service providers who require accurate fiscal behavior and want to minimize admin overhead.
Operating, securing, and scaling an ERP on managed services
Frihet’s approach to security centers on database-level rules and Cloud Functions for server-side aggregation, which together limit the attack surface that application-layer bugs could exploit. Tenant isolation in security rules prevents cross-tenant data leakage even if application code contains mistakes. Delegating complex aggregations to Cloud Functions maintains correctness for operations that are awkward in NoSQL while preserving client performance through denormalized read patterns. The serverless footprint also reduces idle infrastructure costs because Cloud Functions can scale to zero between invocations, a capacity especially useful for a lean operational team.
Observations on user experience and product ergonomics
Making the database the canonical state store simplifies the mental model for users and developers alike: optimistic client updates provide immediate feedback while persistent snapshots reconcile eventual consistency. The AI copilot’s explicit function calls and use of real business context aim to reduce the kinds of hallucinations or guesswork associated with purely natural-language assistants. Lazy loading and hover-based prefetching for the AI module are small but deliberate UX investments that keep perceived latency low without inflating initial bundle size.
Broader implications for the software industry and teams
Frihet’s story illustrates a broader pattern in modern product development: managed cloud services and powerful consumer-grade AI models lower the barrier to building sophisticated, compliance-sensitive applications. For startups and solo founders, the calculus often favors rapid iteration over maximal control—shipping a usable product with robust UX, localization, and payroll- or tax-sensitive features can outweigh the long-term benefits of self-managed infrastructure. The described approach also highlights a practical template for integrating AI safely: use typed function APIs, inject precise context, and enforce existing permission models rather than exposing unrestricted natural-language agents to internal data.
As more teams experiment with AI copilots that act on live business data, the integration pattern Frihet describes—typed function calls, context injection, and permission parity with the UI—may become a recommended practice for developers who need traceability and least-privilege behavior in regulated domains.
Operational lessons for builders choosing a similar path
Teams considering the same route should prepare for the specific engineering demands Firestore imposes: rigorous data modeling, careful denormalization strategies, and server-side functions to emulate relational operations. Centralizing critical domain logic—tax math, rounding, and financial aggregation—pays dividends in correctness and auditability. Investing in a translation memory and CI checks for localization maintains product parity across languages and reduces per-run translation costs materially. Finally, treating AI as a platform component that loads on-demand and operates through the same security model as the rest of the application simplifies privacy and compliance reasoning.
Frihet’s implementation demonstrates that with clearly defined constraints, a lean toolchain, and disciplined modeling, a single developer can deliver a production-grade ERP experience that includes multilingual support, integrated payments, and an AI copilot—trading off relational flexibility for speed and reduced operational overhead.
Looking ahead, the choices documented here suggest incremental future work areas: easing complex reporting for NoSQL-hosted ERPs, expanding typed-AI function libraries to cover more business workflows, and evolving translation pipelines to maintain accuracy as product scope grows. Those trajectories reflect a practical balance between delivering immediate user value and investing in the platform capabilities that will sustain growth.
