The problem
Mail threads, files and production decisions live in separate places. A generic CRM can record a lead, but does not model the technical path from an attached model to a production-ready order.
Active product · 2026
CRM for 3D Printing
A workflow-focused system that turns fragmented inbound requests into manager-confirmed production orders.
Context
Software shaped around an operating process
A 3D-printing business receives requests through email, usually with attachments and incomplete technical details. A manager must inspect the request, clarify it, decide whether it can become an order, and keep its files and status understandable to the rest of the team.
The constraint
Parsing and analysis may assist a manager, but cannot silently make commercial or production decisions. The workflow needs visible states, audit events and explicit confirmation.
Role & approach
Product decisions and backend architecture in one loop
I mapped the request-to-order flow, defined roles and state transitions, designed the service boundaries, and implemented the Go backend and integration layer. The UI is a focused manager workspace rather than a broad general-purpose CRM.
Workflow before features
The order state machine is the source of truth. Integrations feed it; they do not define it.
Human confirmation
Inbound parsing produces a draft. Only an explicit manager action creates the order.
Replaceable adapters
Storage, mail and model providers sit behind boundaries so local development and external services use the same core.
Background jobs
File transfer and model analysis run asynchronously, with visible statuses and retries instead of blocking the request path.
Workflow
Automation prepares; a person commits
An incoming message becomes a reviewable draft. Parsed fields and attachments reduce manual entry, while the manager remains responsible for confirming the customer, scope and order.
- Receive a message and attachments through the inbound adapter.
- Create a review draft; an optional language model may suggest extracted fields.
- Let the manager correct data, reject the request or explicitly create an order.
- Track order status, files, storage jobs and technical analysis from one record.
Architecture
A small core with explicit integration boundaries
The Go API owns authentication, permissions, order transitions and audit events. PostgreSQL keeps workflow state. Workers handle slower or failure-prone operations, while the React UI consumes the same APIs used for operational checks.
Why two languages? Go keeps the transactional application and adapters cohesive; Python/trimesh provides a mature geometry toolkit behind a narrow analysis contract.
Delivery status
What exists today — and what does not
This is an active product, not a polished retrospective. The repository was reviewed against its iteration plan in August 2026; the distinctions below are deliberate.
Core operating flow
JWT/RBAC, users and customers; order creation and controlled states; files and pluggable storage; inbound drafts with explicit manager confirmation; jobs and audit events.
Technical file pipeline
Archive safety checks, STL metrics, watertight warnings, preview jobs and a Three.js viewer are in code and covered by tests, but the iteration still awaits acceptance in a pilot workflow.
Estimation workflow
Print types, tariffs, express and detailed estimation, readiness checks and technologist data have iteration designs but are not presented as delivered features.
Production operations
Tasks and Telegram reminders, production history, management dashboard, diagnostics, backup and production deployment remain future work.
Trade-offs
Decisions made for clarity and recoverability
- Draft instead of auto-order: slightly more interaction, much lower risk of turning an incorrect parse into a commitment.
- Asynchronous analysis: more job-state code, but uploads and API requests stay responsive and failures become retryable.
- Storage adapter: an extra abstraction, in exchange for local testing and the ability to switch external storage without rewriting order logic.
- Incremental delivery: the product can validate the core workflow before pricing and production modules increase scope.
Next
Validate before expanding
The next meaningful milestone is not more surface area. It is pilot acceptance of archives, STL analysis and the viewer using representative files, followed by decisions on estimation rules. Real conversion, time-saving and production metrics are intentionally marked TBD until the workflow is used in operation.
Not shown: customer data, credentials, repository access, real prices and unverified business metrics. The diagrams and cover are synthetic.