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
CRM for 3D Printing
A system that takes email requests through manager review to 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
Implemented, in pilot and planned
The core request-to-order flow works. File processing is ready for pilot acceptance; estimation and production operations come later.
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 implemented and covered by tests. The next step is a pilot with representative files.
Estimation workflow
Print types, tariffs, express and detailed estimation, readiness checks and technologist data are designed but not yet implemented.
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
Run the file pipeline in a pilot
The next step is to test archive handling, STL analysis and the viewer on representative files, then settle the estimation rules. Usage metrics will only make sense after the workflow is used in day-to-day work.
Not shown: customer data, credentials, repository access or real prices. The diagrams and cover use synthetic data.