Context
Vexa began with a real distribution business whose operation depended on paper records, scattered files, Excel quotations and manually managed email. Routine knowledge lived in a single computer and in the memory of the people doing the work.
The opportunity was larger than replacing a spreadsheet. The system had to preserve the way the business actually operated while making every transition explicit enough to validate, automate and improve.
The operational problem
Customer information, quotations, orders, inventory, delivery, billing and follow-up were separated. That fragmentation made work difficult to trace and forced the team to repeat information across tools.
The hardest questions were operational: when does a quotation become an order, who can change it, what must be validated first, and which downstream records should update as a result?
Actors and workflow
Vexa serves administrators and operational users with permission-aware dashboards. Customers, suppliers, products and inventory are shared context; quotations, orders, logistics and billing form the main operational chain.
The system follows the operation from the first customer interaction through fulfillment and reporting, keeping roles and permissions visible at each transition.
Solution
I helped model that complete flow as a modular platform for customers, quotations, orders, products, inventory, suppliers, billing, email, financial reporting, point of sale, logistics, users, roles and permissions. The current system includes an implemented integration with SAT-related processes.
The current foundation is tenant-aware so the validated implementation can evolve into a configurable SaaS product without treating every future business as an identical copy.
Product flow
- Find or register a customer.
- Create a quotation using product and pricing information.
- Convert the accepted quotation into an order.
- Coordinate inventory and logistics.
- Continue into billing, reporting and follow-up.
- Show each role only the actions and information it is allowed to use.
Architecture
The platform uses Next.js and TypeScript across the product interface and server capabilities, with PostgreSQL, Supabase and Prisma for relational data and access patterns. Cloudflare R2 stores files, while Vitest supports automated verification.
The architecture favors business modules and explicit workflows. Tenant awareness, role-based access and file ownership are system concerns rather than decorations added at the interface layer.
Key technical decisions
- Represent operational transitions as validated system states instead of loose form submissions.
- Keep permissions close to the workflows they protect and adapt the dashboard to the current role.
- Use relational modeling for the dependencies between commercial, inventory and financial records.
- Prepare tenant boundaries before turning the validated system into a broader SaaS offering.
- Audit database requests and client consumption after the first complete version exposed performance patterns.
My contribution
I led the technical development and implemented approximately 70% of the system. I translated the client's real processes into software workflows, designed the architecture, coordinated development tasks and worked across backend, frontend and database layers.
The work was completed with one collaborator. I did not build the system alone, and the client’s private operational information is not included in this case study.
Main challenge
The hardest problem was not a framework or API. It was turning an informal operation into explicit states, permissions, validations and interactions without losing the practical knowledge that made the business run.
Outcome and current state
Vexa is a validated operational system used as the foundation for a configurable product. It centralizes the operation the first version set out to model; the source remains private because the work is commercial.
No unverified efficiency metric is presented here. The strongest evidence is the existence of a complete, traceable workflow validated against a real operation.
What I learned
Vexa was my first independently led system intended directly for production. It clarified how different client work is from academic work, why discovery matters, and how database and API consumption must be reviewed before patterns become performance problems.
What I would change
I would define query patterns, internal service boundaries and performance budgets earlier. The post-build audit improved requests, APIs and client-side consumption; that discipline should begin with the architecture.
Roadmap
The next stage is a configurable SaaS foundation for distributors and commercial businesses that still depend on fragmented manual processes.
Interface gallery
The final gallery requires sanitized captures of the dashboard, customer record, quotation, order, inventory, reports, logistics and permission views. The layout below reserves those final proportions without presenting fabricated screens as product evidence.
Demo walkthrough
The recorded demo presents the working product and complements this case study with direct evidence of its operational experience. Before final publication, every visible record must be confirmed as sanitized and client approval must be in place.
Source and privacy
The source code is private because the project is being developed as a commercial product. Future media must use demo data and requires the client’s permission before any interface is published.