RU

← All projects

The operating platform for a fashion brand

Collection, cost, production and sales on one data model, from specification to actual margin.

Preparing for a pilot

Built: showrooms and pricing, reservations, order confirmation, specifications, samples and tech packs, cutting and production, materials sourcing, order economics and margin. Next: an end-to-end check on a live environment, then a pilot with a first brand. Scope of work: section 10.

Summary

  1. A brand’s product and commerce live in separate systems. There is no single version of the data.
  2. The gap costs far more than an IT budget: dead stock, lost margin and missed sales in the season.
  3. Syntha puts both on one data model. The system calculates price and reservation, and both sides work on the same order.

Discuss involvement

01 — Diagnosis

Decisions are made before the data to support them exists

A fashion brand’s product and commerce have always lived in separate systems. The result is three gaps.

  1. Data gap

    Collection, cost, orders and stock sit in different systems. There is no shared version.

  2. Feedback lag

    Reconciliation is manual and happens after the period closes. The discrepancy surfaces when it is too late to act.

  3. Asymmetry between parties

    Brand and buyer hold different versions of the same order: confirmation, reservation and availability do not match.

The upshot: price, buying volume and assortment are decided on incomplete data.

02 — Design principle

I remove the cause of the gap, not its consequences

  1. One data model

    Industry systems cover either product or commerce and swap exports. Here a change to a specification flows through to cost and the permissible price, and both sides agree an order amendment in the same system.

  2. The system does the calculating

    The system calculates price, availability, reservation and confirmation, not a document sent by email. A document is out of date the moment it is sent.

  3. Symmetry between parties

    Brand and buyer work in a shared deal space and see one order. They do not exchange versions.

03 — System class

Syntha sits where two classes of system meet

Three classes of system serve the industry: PLM systems (for example Centric PLM, Bamboo Rose), wholesale platforms (JOOR, NuORDER, Brandboom) and accounting systems (1C, SAP, NetSuite). Each covers its own part of the cycle and hands the rest on through exports. Syntha joins the product and commercial classes on one versioned product core and carries the chain through to actual cost and margin.

Exhibit 1. Functional coverage by system class. The Syntha column shows the designed scope; current readiness by area is in section 10
Product core and style versions
yes
no
no
yes
Materials, specification, planned cost
yes
no
partial
yes
Samples, tech packs, measurement charts, quality
yes
no
no
yes
Materials sourcing and production
partial
no
partial
yes
Showroom, line sheets, price lists, assortments
no
yes
no
yes
Order, confirmation, reservation
no
yes
partial
yes
Actual delivery cost and margin close-out
no
no
partial
yes

Wholesale platforms (JOOR, NuORDER, Brandboom, Faire) cover collection presentation and order intake. PLM (Centric, WFX, Wave PLM and Russian equivalents) covers product development. Neither calculates the actual cost of a delivery, so the brand pieces it together by hand. I prepare a detailed comparison of features, timelines and risks myself and provide it on request.

04 — Scope

Management areas on one data model

The areas form a single chain. Each step takes the recorded result of the one before: nothing is re-keyed or moved by export.

  1. Style and version
  2. Specification and planned cost
  3. Sample and tech pack
  4. Production order
  5. Publication to showroom and price list
  6. Order and confirmation
  7. Delivery
  8. Actual cost
  9. Margin and period close-out
Exhibit 2. System areas and the decisions they support
Product and collection Season planning, collections, styles and colourways, SKUs with GTIN, materials and trims, measurement charts, samples, tech packs
What to make and how much, from the collection structure and last season’s results
The specification rebuilds when a style changes, so copies do not drift apart
Cost and economics Specification and cost, price calculation, margin by style, category and assortment
Target price and permissible cost, before the production order is placed
A factory quote is checked against the permissible price straight away
Sourcing and production Suppliers, requests for quotation and purchase orders for materials, quotes, production orders, production calendar, quality control to sampling plans (AQL)
Whom to order from and when; what to run first when capacity is short
A missed deadline is visible in advance
Commerce and deal Digital showroom, line sheets and assortments, buyer selections, order, confirmation, order amendments, deal space
Confirmed commitments and free stock, at any moment
Price lists, reservations and confirmations are not sent as documents
Data and metrics The shared data model under every area, metrics, management reporting
Where to put capital: categories, channels, seasons; where cash is tied up
The report is built from operational data, not by hand
Roles and partner access Organisations, roles, permissions at object and operation level
Who is responsible for what when brand, retailer, distributor and manufacturer work together
A partner sees their own slice of the data, not a copy of a file

05 — Impact

What changes in day-to-day work

Exhibit 3. Today and in the system
Style specification
The file is rebuilt by hand, copies drift apart
Recalculated on every change, one version
Cost
A separate spreadsheet, recalculated after every quote
Each quote is checked against the permissible price
Availability to sell
Stock as at the last export
Calculated by the system, as at now
Reservation
A verbal agreement and an email
Atomic reservation: one unit cannot be sold twice
Order confirmation
Each side keeps its own version
One status for both sides
Management report
Compiled by hand, takes days
Generated from operational data

A comparison with JOOR, NuORDER, Brandboom, Faire and others: each platform’s features, Syntha’s coverage, the development plan. It is a working document and not published; I share it on request when we discuss a pilot or partnership.

06 — Parties

What each party in the chain gets

Brand, retailer and distributor work in the system. The investor looks in from outside. Each gains something different, from one source: shared data instead of swapped documents.

Brand

Sees the season’s economics while there is still time to change them.

  • Price and permissible cost are known before the production order.
  • One version of the data for factory, commercial team and buyer: specifications, measurement charts and tech packs stay aligned.
  • Confirmed commitments and free stock are visible at any moment, with no reconciliation.
  • Margin closes on actual cost, so the season’s result is a figure, not an estimate.

Retailer and retail chain

Orders what it will actually receive, and knows it immediately.

  • Assortment and availability are calculated on every request; a file sent by email is out of date the moment it is sent.
  • Confirmation is two-sided: brand and retailer share one order and one delivery date.
  • Its own account with its own slice of data, instead of a spreadsheet with columns cut out.
  • The retailer hears about a change to delivery date or contents in advance, before goods arrive.

What the retailer needs to do. The brand connects them: an invitation arrives by email and work happens in the browser, with nothing to install. No training is needed, because the order is built from the brand’s catalogue. The brand sets the terms of access.

Distributor

Runs both ends of the chain in one place, with different permissions.

  • Several brands and several retailers in one system, each with its own role and its own access.
  • Individual prices and terms per partner, without copies of price lists or manual substitution.
  • Commitments are traceable in both directions: what has been confirmed to the brand and what has been promised to the retailer.
  • Reservation is atomic, so the same stock cannot be promised twice.

Investor

Enters a niche where demand arrived before supply.

  • The product occupies ground that two classes of system share today, and competes head-on with neither.
  • The niche is protected by how the product is built, not by speed of development: section 11.
  • Engineering discipline can be checked: over 1,700 automated tests and more than 170 dated entries in the change log.
  • The industry reference is managed data, so new categories are added without rewriting the core.

07 — Scenario

How a season runs in the system

Four phases, six roles. Each takes the result of the one before, so data is never keyed twice.

Exhibit 4. Season phases, participants and the outcome of each
PreparationBefore production starts
Product manager, buyer
Collection structure, styles and colourways, materials and trims, specification and planned cost. Output: the economics of each style, calculated before the first spend.
Samples and launchConfirming feasibility
Product manager, production manager
Measurement charts, samples, tech packs, requests for quotation and quotes, placing production orders. Output: confirmed lead times and cost.
Sales openingWorking with the buyer
Brand sales lead, retailer buyer
Publication to the showroom, price lists and assortments, buyer selections, order and two-sided confirmation. Output: the volume of commitments and free stock.
Delivery and close-outActuals instead of plan
Production manager, finance function
Shipping and receiving, actual delivery cost, cost allocation, margin and period close-out. Output: the season’s actual result instead of an estimate.

08 — Local context

The system is built for the Russian market, not adapted to it

The market is built into the core: Russian brands that work with Russian and overseas factories and suppliers of materials and finished goods.

  1. Multi-currency calculation

    Buying abroad and selling in roubles is the normal mode for a Russian brand. The rate is applied line by line at the required precision, because rounding at total level skews the result systematically. Bank of Russia rates are loaded into the reference, and the brand fixes the season’s rate with a date.

  2. Import readiness

    Registries of certificates (OEKO-TEX, GOTS) and conformity documents (UPD transfer documents, EAEU declarations and certificates) are kept alongside product data; documents are linked to the order and the shipment.

  3. Industry reference

    The categories, product types and size systems of Russian fashion retail are already in the reference, so the brand does not have to build it from scratch.

  4. Integration with accounting

    Connecting to the accounting systems that Russian brands use is delivered as a separate project.

09 — Interface

What it looks like

The screens are captured from a working build, not mocked up.

Syntha — workspace Syntha — product catalogue Syntha — wholesale showroom

Click a screenshot to open it full screen and page through the others.

10 — Stage

The commercial core and production module are built; I am preparing a pilot

11 — Defensibility

Why the position is defensible

  1. Market timing

    Russian brands have grown in turnover, assortment and number of channels, while their tools have stayed the same. Demand for control arrived before supply.

  2. Engineering maturity

    The current build passes over 1,700 automated tests, some of which run on PostgreSQL in CI. A change is accepted only together with an update to the specification: the change log holds more than 170 dated entries, and the specification itself is the single source of truth. Knowledge of the product does not depend on one developer.

  3. Barrier to replication

    The chain from style to margin close-out is a property of how the data is structured, not a set of features. A wholesale platform would have to build a product module; a PLM would have to build commerce and the economics of actual delivery. This kind of connectedness cannot be added as a layer on top.

12 — Objections

What usually holds people back

  1. “We run everything in our accounting system”

    The accounting system stays where it is. Syntha covers what comes before it: collection, cost, price, order. I fix the integration boundaries before work starts.

  2. “We already pay for two systems”

    This is not a third subscription but a replacement for an industry system and the spreadsheets around it. The thing to count is not licences but the manual reconciliation between them, and the cost of decisions made too late.

  3. “We have no one to run it”

    A pilot needs just one person on the brand’s side. I migrate and structure the data myself.

  4. “What if the project stops?”

    The risk of an early-stage product is real. I address it through structure rather than promises: the specification is kept as a document that can be read without me, changes are recorded in a log, and we agree the terms of data access and export before work begins.

13 — Involvement

Four ways to get involved

Pilot

I provide work in the system across a full season cycle, priority in the development queue, and migration and structuring of the brand’s data.

I expect one live season and a dedicated member of the brand’s staff for the whole cycle.

Go to market
A partnership with someone who has channel access and implementation experience.
Investment
Participation at the pilot-preparation stage: the commercial core and production module are built.
Integration
Connection to the brand’s accounting system: a separate project with its own timeline and budget.

I show the architecture and the development plan in person, under a non-disclosure agreement.

14 — Due diligence

How a large client vets the system

Corporate procurement vets a supplier on nine points. The answer to each is below: some on this page, some in the contract, some in the scope of work.

Exhibit 5. Areas of review and where the answer sits
Functional scope
Sections 03–05: coverage by area, system areas and how processes change.
Roles and access control
Built: organisations, roles, partner access, permissions at object and operation level. Section 04.
Data traceability
An end-to-end chain from style to margin close-out: each step refers to the recorded result of the previous one. Section 04.
Hosting and backup
Fixed before work starts: the make-up of the environment, and the backup and recovery procedure.
Data protection and logging
Permission control works; requirements for encryption, authentication and the activity log are set in the contract.
Service level
Set out in the agreement: availability, maintenance window, response and resolution times, incident priorities, contact channels, support hours.
Pilot terms
Environment, client data and participants: section 13.
Timeline and launch stages
Depend on the set of areas and on which integrations are needed; agreed at the first meeting.
Product development
Scope of work by area: section 10. The plan has no dates; I do not promise timelines at this stage.

Frequently asked questions

Does the system replace accounting?
No. The accounting system stays. Syntha covers the decisions that come before accounting: collection, price, order, deal. Integration is a separate project.
How does it differ from a specific platform?
The fundamental differences are in section 02. I provide a feature-by-feature comparison on request.
What are the commercial terms?
Agreed case by case: pilot terms differ from those for full production use.
What is needed to get started?
No history is needed: work starts with the current season. Which data we need depends on the area we start with, and we decide that at the first meeting.
What does the system not do?
It does not keep accounting or tax records, manage warehouse logistics or serve retail at the point of sale. Other systems handle those tasks, and integration is built with them.
Who builds the system?
I do: Petr Fedin. I work where strategy, commerce, product, data and capital meet, from market and collection to stock and cash. The product grew out of my advisory practice. More about my practice.
Can I see a demo?
Yes, on the working system; by arrangement, on the client’s own data.

Contact

Tell me what interests you: a pilot, a partnership, investment or integration. I reply personally.

Write to me Other projects

Petr Fedin