SeekMake

Problem

Small and mid-sized manufacturers tend to run their business across spreadsheets, email, and whatever invoicing tool happens to be cheapest that year. The cost is not the tools — it is the seams between them: orders that never get invoiced, invoices that never get reconciled, customers that drop off the radar between quote and delivery. The platform had to compress that workflow into one place without becoming the kind of bloated ERP that nobody actually uses.

Approach

The system was split along clear domain seams — customers, products, orders, invoicing — each owned by a service with its own data store and a well-defined contract. The split kept the invoicing surface (the part with money in it) isolated from the rest, which meant changes to product timelines or customer records could not accidentally corrupt billing state. The frontend was built in Angular against a monorepo so shared types and validators could move between web and services without drift. Microservice contracts were versioned and tested at the boundary so a backwards-incompatible change in one service surfaced loudly in CI rather than at runtime.

Outcome

Manufacturers using SeekMake get a single workspace that covers the customer-to-cash loop without forcing them to learn a new operations vocabulary. The architecture leaves clean room to add adjacent capabilities (production planning, supplier management) as separate services without touching the existing surfaces.

Stack