Viert Atelier
Viert System — The atelier's production and sales in one place
After the website, the system behind Viert Atelier's operation: a schedule that plans and replans the production of each dress, an app where the team handles inquiries, sales and contracts, and WhatsApp wired into all of it. It sits behind a login. It is a working tool, not a showcase.

- 4 + 1
- 30 min
- 2
Problem.
A bridal and occasion-wear atelier works made-to-measure: each piece goes through more than ten steps, with seamstresses, embroidery, fittings and outside suppliers, and a delivery date that doesn't move. Any delay throws off the rest, and replanning by hand is the kind of job that eats the coordinator's day. At the same time, inquiries, sales and production ran on separate tools.
Solution.
A monorepo with the production schedule, the team app, the scheduling engine both share, and the atelier's websites. The schedule works out who does what and when, prioritizing the project with the least slack. The team app covers pre-sales (chat, CRM, catalog), sales (orders, contracts, integrations) and the workshop floor. Both use a single login and talk to each other over an API.
Result.
The production schedule has been live since September 14, 2026, with automatic deploys, daily backups and an off-site copy. The team app, the sales module and the integrations joined the same repository and keep evolving from requests by management and the production coordinator.
The hard part.
Every project has a point where the obvious solution doesn't cut it. Here, it was these.
An engine that is a function, not a service
Scheduling is a pure function: it takes the full state (projects, resources, calendar, unavailability) and returns the proposed schedule, the project order and the reason behind each choice. It reads neither the database nor the clock, so the same scenario always gives the same result and runs in tests with no infrastructure. The preview runs the engine over a snapshot of the state and writes nothing until the coordinator confirms. The schedule works in wall-clock time, in whole minutes on a 30-minute grid, with no time zone in the core.
Replanning without undoing what a person decided
Each project is prioritized by slack (available time minus the work remaining), and every event triggers a full recalculation. The catch is that the coordinators also edit by hand: they lock a time slot, lock a person's whole day, move a fitting. Those decisions must survive the recalculation, pull predecessors in ahead of them, and show when delivery misses its deadline, pointing at the step that drives the delay. A circular dependency is rejected on the spot instead of becoming an error screen.
Outside suppliers don't have an hourly schedule
Finishing work goes out to outside suppliers, who work by lead time: each has a drop-off day, a pick-up day, a cap on pieces at once and a weekly ceiling. Without those limits the engine sent as many tasks as it liked to the same supplier. They became a registry rule and enter the allocation just as internal resources' hours do.
Tests that carry the client's rules
The examples in the requirements document itself became scenario tests, with the text report approved as the reference: if behavior changes, the change has to be deliberate. Property-based tests with random scenarios check invariants, and a performance test caps the time for 100 projects, 14 steps and 15 resources. The app runs its integration suite against an embedded Postgres, without Docker.
AI that reads the photo but doesn't decide alone
The catalog came from a spreadsheet, with many records flagged for review. The AI reads each model's photos and flags mismatches with the record, separating what is visible, what is absent, what the photo can't tell, and what is merely likely. Code, not the AI, translates the reading into the catalog's official criteria. Every applied correction keeps the previous value and the author, and can be undone, one by one or in bulk.
Two WhatsApp numbers with Meta's rules in between
The customer talks to pre-sales on one number and moves to sales on another. On the pre-sales number the 24-hour window is open and the notice goes out as free text. On the sales number the customer has never written, and Meta only accepts an approved message template. The template text is editable: changing it creates a new version, which goes back through approval, and until then the last approved version is sent. The handoff stays off until management switches it on.
What I did.
- Gathering the production rules with the atelier, recorded in a requirements document and in a list of business questions answered over time
- A scheduling engine in plain TypeScript, with unit, scenario, property-based and performance tests
- Production schedule: projects, steps, resources, recalculation preview, locked tasks, fittings and outside suppliers
- Team app: pre-sales with CRM and catalog, sales with orders and contracts signed through ZapSign, integrations with Bling (OAuth) and Google Drive
- WhatsApp with two numbers and automatic handoff from pre-sales to sales
- Consolidating scattered repositories into one monorepo, with automatic deploys, daily backups and an off-site copy
Stack.
Have a similar project?
Tell me the problem — I answer personally.