This brief covers one question only: the ask to build the solution for Troquer — what it entails and whether it matches what AdapttoAI is today (per master-assets/MASTER-CONTEXT.md). Training / LearnAdapttoAI is a separate obvious option and is deliberately out of scope here.
| What Troquer is | Omnichannel preloved luxury fashion marketplace (Mexico). Web (Magento) + physical stores (Alquímedes, Liverpool Insurgentes) + assisted personal shopper (WhatsApp/phone). |
| Two-sided | Buyer side (acquisition via social, Google Ads, email, WhatsApp) and seller side — where the hard problems live. |
| Contact | Ytzia — operator, industrial-engineering background ("esto es 100% de procesos"). Decision-maker on this. |
| Scale | Up to ~23,000 unique live items. Every item is unique — no prior data, onboarded daily. "Empresa de muchos pasos para pocos ítems." |
| Current systems | Magento (a hated bottleneck being actively dismantled) + a growing home-grown back office. In-house visual-recognition tool already exists. A pricing engine is in development in-house. |
| Commercial goal | Reach profitability. Compress internal ops → free up people → redeploy to sourcing (their #1 bottleneck). |
Ytzia walked Raffaello through Troquer's three strategic challenges — sourcing (#1, hardest, least solved), product processing (#2, the operational machine), and rotation / selling (#3, buyer–item matching). She then screen-shared the full 9-step item-processing pipeline and the architecture of a pricing engine her team is building.
Her framing: processing is the "lowest hanging fruit" — optimize it, free up headcount, push those people to sourcing. She sees AI helping in four places: (1) internal workflows, (2) sourcing intelligence, (3) buyer–item matching/personalization, (4) projective BI (anticipate demand, e.g. Buen Fin).
The conversation converged on a concrete near-term ask: help her compress and automate the processing pipeline inside her own back office, and connect the in-progress pricing engine via API. She closed by raising — repeatedly and clearly — that she wants the work to be proprietary code that lives in / is owned-with Troquer, not an off-the-shelf SaaS. Follow-up booked Mon Jun 22, 5:30 PM; Raffaello committed to consulting Giuseppe on the code-ownership question.
Her ideal: compress steps 2→7, run them in parallel by ~2 people instead of serially by many. Today ~15 people sit across this phase (2 leads, 3 reception→pricing, 1 BI/pricing on OPEX). She'd like that to be ~10 and move the freed 4–5 to sourcing.
Known sub-pains: editorial description sometimes contradicts the grading decision · visual-recognition tool fills basic fields but not the qualitative copy · Magento is a "megastopper" degrading photos · everything serial because of approval gates.
Built by one strong internal person (fashion → data). Architecture: Troquer catalog (brand, model, price, days-listed) enriched by three scraping agents — VTC (vtc.mx, local Polanco), Irene Buffa (MXN/EUR, Thursday drops), Vestiaire (EUR→MXN). A moderator agent averages the three (weighted MX local 60% / Vestiaire 40%, FX-adjusted) → per-piece decision: raise · hold · discount (cara + parada >30 days) → daily WhatsApp/email report.
The integration ask: she's comfortable the engine will ship, but not that it'll be integrated into her platform — today it's copy-paste, off back-office. She wants it API-connected so it actually serves the workflow. Conceptually this is competitor-SKU price matching — our Module 05 shape — but it's their build, which makes it a dependency, not a clean greenfield module.
Three things, in priority order:
"Se entrega como un producto integrable a mi back office… el desarrollo del código se comparte entre los dos." / "lo puedo meter a mi sistema, que opere tal como es… podríamos pensar en un refresh del código cada seis meses, pagas un fee."
Her stated reason: Troquer is too particular for any off-the-shelf SaaS; she wants control over changes and the ability to make small changes herself; and she values Raffaello's operator experience over the code itself. She's open on commercial shape and floated a higher implementation fee as the trade.
Measured against MASTER-CONTEXT.md — the authoritative "what we do today." Two clean reads: the problem shape fits, the brand & business model don't.
| Problem shape Receive → Parse → Match → Propose → Order |
FITS | Their item intake is our intelligence layer with a physical input: Receive (prenda) → Parse (visual recognition) → Match (authenticate + price vs market) → Propose (editorial + price to seller) → Publish. Same backbone. |
| Module overlap | PARTIAL | Editorial gen ≈ 02 Unstructured parsing + Propose. Pricing scraper ≈ 05 Competitor matching. Real but conceptual, and the "+ Custom" path is the honest one. |
| Autonomy / "you stay in control" | FITS | Curaduría + seller-facing pricing need a human gate. Maps directly onto our autonomy dial. |
| Sector / brand "Industrial businesses. Only." |
BREAKS | B2C preloved-fashion marketplace + circular economy. Not off-ICP — off-brand for the product we're telling the market we are. |
| Connector reuse "One ERP connector, built once" |
BREAKS | No Odoo/NetSuite/SAP. The connector target is their evolving home-grown back office — a custom integration, not a reused one. |
| Business model "Usage not implementation · systems not projects" |
BREAKS | Owned/embedded code + high impl fee + refresh fee is the inverse of our three core value props (charge for usage · no handover · we own the improving system). |
| Replicability | ~ZERO | Seller-side / circular-economy logic carries to no other pipeline client. Breaks the amortize-across-clients economics. |
| Relationship / trust | STRONG | Raffaello ran GAIA ($100M e-commerce) — lived this exact operation. Warm, high-trust, she's asking us in. |
The crux — and a reframe: most of what she asked for, we already offer. On-prem deployment is in our FAQ ("the system runs on your own servers"). Staying current as new models ship is value prop #4. Custom modules on her connector is the "+ Custom" path. The only genuine thesis break is literal code-IP ownership — and she softened even that herself: "los dos podemos ser dueños… ¿en dónde se alberga y dónde se puede utilizar?"
So the pre-agreement question is narrow and answerable now: does control + continuity satisfy her, or does she need IP transfer — and if so, at what price? Sourcing and replicability don't change; the deal structure is the whole decision.
No deferral. We decide the model now and pre-agree it with Ytzia on Monday. The three structures differ on one axis — how much of "ownership" we concede — and that axis drives both pricing and whether we keep reuse rights.
Troquer gets a dedicated system integrated into / hosted on their back office, an editable config layer so she can make her own small changes, always-current models, and a source-escrow + continuity clause ("if we disappear, the code passes to you" — already in our playbook). AdapttoAI retains the IP and the right to genericize modules. Commercial: our standard 3-phase (implementation fee + monthly subscription), sized up for the custom build.
Co-developed. Troquer owns its instance + its data; AdapttoAI owns the generalizable framework/modules and retains reuse rights (genericized, no Troquer data). This is almost verbatim what Ytzia proposed ("el desarrollo del código se comparte entre los dos… tu sistema con eso aprende"). Commercial: higher implementation fee (lost-reuse premium) + a recurring refresh fee (her "cada seis meses" idea).
Troquer owns everything; we're a premium custom build for this engagement, optional maintenance retainer. Commercial: large implementation fee priced as zero reuse — i.e. priced like we'd rather not.