SC-CRM
We built SC-CRM to close the gap between the systems a mid-sized Mexican company runs on: selling, invoicing, and accounting as one flow in one database. We modeled 13 entities in PostgreSQL under real multi-tenancy (every row carries its organizationId, the JWT transports it, and middleware injects it into each request), stood up a REST API with validated CRUD for the 7 business entities, and built a Kanban sales pipeline with probability-weighted value and drag-and-drop. On the fiscal side we didn't reinvent the wheel: the invoice model stores the CFDI 4.0 UUID, XML, and metadata, and SAT stamping is delegated to the Omnifiscal API, keeping compliance in one place. All of it on Next.js, React, and Prisma, with a consistent editorial design system, an installable PWA, and Docker deploys with branch-based CI/CD. The proof is in the code: 11 functional areas, 30+ pages, and 19 endpoints over a 13-model schema.
Category
CRM
Stack
Next.js, React, TypeScript
Status
In development
The problem
Mid-sized Mexican companies run their business across three worlds that don't talk to each other: the sales team's spreadsheet, the CFDI invoicing system, and the accounting in CONTPAQi or Aspel. The problem isn't any single system, it's the gaps between them: a won deal gets re-keyed as a customer, again as an invoice, again as a journal entry. Every hop loses data, compounds errors, and destroys the lead-to-cash trail. The ERPs that do integrate everything (SAP, Oracle) cost north of $200,000 MXN and were built for desktops, not for a country that runs on its phone.
What we built
- —Kanban-style sales pipeline with stages (lead, qualification, proposal, close), probability-weighted deal value, days-in-stage, and conversion rate; drag-and-drop via dnd-kit
- —Full sales CRM module: customers with RFC and CFDI usage, opportunities, pipeline, and quotes, all on the same company entity
- —Multi-tenant REST API with real CRUD for 7 business entities (customers, suppliers, products, invoices, payments, chart of accounts, journals), with Zod validation, pagination, and search
- —CFDI 4.0 invoicing: the invoice model stores the fiscal UUID, stamped XML, and metadata; SAT stamping is delegated to the Omnifiscal API rather than reimplemented
- —Double-entry accounting: hierarchical chart of accounts (5 types), journal entries with lines linked to customer/supplier/product, and financial reports (income statement, balance sheet, cash flow, AR aging)
- —True multi-tenancy: every business entity carries an organizationId, the JWT transports it, and middleware injects it into each request to isolate data per company
- —Custom authentication with secure sessions and roles (owner, admin, finance, viewer)
- —A consistent editorial design system across the app (zero radius, Geist Mono only, hierarchy by opacity, 3 themes including OLED) with shared PageHeader/StatCard/FilterBar components
- —Installable mobile-first PWA, containerized packaging, and a CI/CD pipeline (branch-based deploy: develop/staging/main)
Results
13 data models and 6 enums in the PostgreSQL schema
11 functional areas and 30+ implemented pages in the app
19 API endpoints (auth + CRUD for 7 business entities + healthcheck), with Zod validation, pagination, and per-company filtering
Pipeline with total and probability-weighted value computed over live opportunities