3DPCC – ERP System & Calculator for 3D Print Farms

Project and Challenge

3DPCC is a B2B SaaS platform for companies and 3D print farms that need a central system for managing quotes, orders, inventory, and production fulfillment operations. The platform supports organizations with multiple users, subscription plans, and a separate data context for each client.

The project was previously developed as a quoting calculator using direct frontend queries to Supabase and distributed Edge Functions. That architecture was sufficient for the initial version of the product, but began to limit its evolution toward a full ERP system. Business logic was scattered between the frontend and serverless functions, and operations spanning multiple areas of the system became increasingly difficult to execute in a consistent and predictable manner.

The goal of the rebuild was to create a foundation for the continued development of 3DPCC as a central operational system for 3D printing companies, with support for multiple warehouses, organizations, customers, orders, and a rigorous stock reservation lifecycle.

Scope of the Rebuild

The work involved designing and implementing a dedicated Node.js backend from scratch, which took over the application's business and transactional logic. The frontend was simultaneously migrated from Next.js SSR to a React SPA.

The system was extended with additional areas typical of ERP and B2B SaaS applications, including warehouse and reservation management, order lifecycle handling, customer duplicate detection and merging, and an entitlements system tied to subscription plans.

Key System Areas

Warehouse and Reservations

The system supports multiple warehouses within a single organization. Reservation, consumption, release, and expiration of stock are executed as controlled transactional operations, ensuring that a change to one part of the process never leaves data in a partially updated state.

Warehouse operations are idempotent. Retrying the same request after a dropped connection or timeout does not create a duplicate reservation or deduct available stock a second time.

Orders

The order lifecycle is controlled by a defined state machine, progressing from draft through confirmation and fulfillment to completion or cancellation.

Status changes are coupled with the corresponding warehouse operations. Confirmation, fulfillment, or cancellation can automatically consume or release prior reservations, maintaining consistency within a single transaction.

Financial amounts are stored in the smallest currency units, which avoids the rounding errors characteristic of floating-point arithmetic.

Customers

The system detects potential customer duplicates based on contact and address data.

Records can then be merged in a controlled and auditable process, without losing the history of associated orders. The merge process itself is idempotent, so retrying the operation does not lead to unpredictable changes in the data.

Organizations and Entitlements

The platform operates in a multi-tenant model. Organization data is isolated at both the application logic level and the database level.

Roles, feature access, and limits are resolved based on the active Stripe subscription plan and assigned entitlements. The frontend receives a single, consistent set of information from the API about available features and limits, which it uses to adapt the interface to the organization's current plan.

Architecture and Security

The backend was designed as a modular monolith. At the current scale of the product, microservices would increase the complexity of infrastructure, deployment, and inter-service communication without proportional business benefits.

The modular monolith allows a simple operational architecture and consistent transactions to be maintained, while dividing the system into clear domains such as orders, warehouse, customers, and billing. Dependencies between them are controlled, which limits the leakage of business logic across module boundaries.

Organization isolation operates on two levels. The application layer restricts queries to the active organization context, and Row Level Security policies in PostgreSQL provide an additional layer of control directly at the database level. This reduces the risk of unauthorized cross-tenant access even in the event of a bug in the application logic.

Critical events such as role changes, organization ownership transfers, and invitation acceptances are recorded in an immutable audit log. Each entry is created in the same transaction as the business operation and can include the state of the data both before and after the change. Application code can add new audit records but cannot modify or delete existing ones.

Frontend

3DPCC is an application that operates almost entirely behind a login, so SSR offered no meaningful SEO benefits. Migrating from Next.js to a React SPA simplified the frontend architecture, authorization handling, and the deployment process.

The frontend can be distributed as a static application via CDN, with no need to maintain a separate server-side rendering layer.

Routing and internationalization have been decoupled from application components, reducing their dependency on specific libraries. The platform supports 16 languages, and additional translation bundles are loaded only when needed by the user.

Quality and Reliability

The CI pipeline automatically verifies code, business logic, database integration, and the readiness of the production image to run.

Unit tests cover domain logic, while integration tests run against a real PostgreSQL instance. They verify, among other things, operation idempotency, RLS policies, and system behavior under concurrent requests.

A separate stage also verifies the build and startup of the production Docker container, so environment configuration errors can be caught before deployment.

The API is documented according to the OpenAPI 3.1 specification and has stable versioning, providing a predictable contract for future integrations and other clients consuming the backend.

Business Results

The architectural rebuild allowed 3DPCC to grow from a quoting calculator into a system handling a broader range of operational processes, including orders, warehouse, organizations, customers, and entitlements.

Centralizing business logic in a dedicated API simplified the development of subsequent modules and made it possible to introduce mechanisms requiring transactional consistency, idempotency, and a controlled operation lifecycle.

The modular monolith allows the system to run on relatively simple infrastructure without the operational costs of maintaining multiple independent services. At the same time, the domain-based structure leaves room for further expansion without mixing the logic of warehouse, orders, customers, and billing.

A stable, versioned API and OpenAPI documentation prepare the platform for integrations with external sales systems and additional access channels, including mobile applications. The current architecture provides a foundation for developing further ERP modules without requiring a rebuild of the core system layers.

Click to zoom