Acculabs — Build Feasibility vs. Aronlight

Internal Analysis · Confidential · Do not share with Luca

Updated:Jul 10, 2026

Contact:Luca Pizzuto, CEO

Wedge:Custom price-book repricing (not quote generation)

Timing:Not fixed — depends on scope

A · How Similar Is This to Aronlight, Really

Verdict

Same 3-stage skeleton as Aronlight — Gather → Match → Decide — but only the bookend stages are structurally similar. The middle stage is the same type of step at a fraction of the complexity. The stage where the actual business value sits is genuinely net-new, with zero Aronlight precedent.

📥

Gather (email intake) — high similarity. ~89% of Acculabs' orders arrive by email, same mechanical shape as Aronlight's inbox polling. Aronlight's connector pattern is directly reusable.

🔗

Match (email → customer → product) — same type, lighter weight. Luca confirmed this step is real, not zero: linking an order email to a customer, then to products, is "not always straightforward, but manageable." Far lighter than Aronlight's problem because Acculabs has ~200 known, repeat customers and (likely) known product references — not open-ended catalog matching against ambiguous free text for new requesters.

⚖️

Decide (price adjustment) — low similarity, net-new. Aronlight decides which product; Acculabs decides when/how much to adjust price — a financial-timing judgment with no existing playbook. This is where essentially all new build effort concentrates.

✅

Write-back + human-loop discipline — transfers directly. The always-draft-never-auto-confirm principle, and the discipline of wiring every human override back as a correction signal, apply regardless of ERP or workflow shape. Pattern transfers; no code exists yet for Acculabs.

B · Stage-by-Stage Map — Aronlight (Built) vs. Acculabs (Needed)

Stage	Aronlight (built)	Acculabs (needed)	Similarity
Gather	Poll Outlook/Gmail + WhatsApp, dedup, attachment OCR	Poll email inbox (~89% of orders); phone (~11%) out of scope	High
Match	Heavy: attribute schema, RAG retrieval, LLM reranker across 4,300+ SKU catalog, handles ambiguous free text from potentially new requesters	Light: link sender → 1 of ~200 known customers, link order lines → known products (SKU-based repeat orders, likely — needs confirmation)	Medium
Decide / Calculate	Draft-quote generation: product-match confidence scoring	Deterministic formula (time-since-priced, raw-material Δ%, inflation%) + judgment on edge cases + timing/communication judgment	Low
Write-back	Draft push to Odoo, human confirms before ERP write	Presumably draft price update, human (Luca) confirms — contingent on ERP API access	High
Human-loop / correction capture	`MatchCorrection` / `SkuMatchRegister` — every override wired back as a training signal	Not built — exactly the mechanism needed to capture Luca's price-override judgment over time	High (pattern) Zero (code)

C · Questions to Verify With Luca — Trimmed to What's Needed to Price an Offer

Scope-defining

Are product references in order emails known SKU/reference codes, or does someone interpret free text?

Determines Match complexity/cost.

Does the ERP have API access, or any way to connect to it programmatically?

The real gate. Target state: email arrives → system links it to customer/product → runs the price check → writes back into the ERP, end to end. If API access exists, that's buildable as scoped. If not, fall back to a lighter version (e.g. a review queue still requiring manual ERP entry) — same core logic, smaller footprint, priced differently.

Pricing logic

What's the actual formula — how do time-since-priced, raw-material Δ%, inflation%, and margin combine into a price?

We have the input schema, not the arithmetic. Can't scope the core build without it.

Is "current price" the ERP list price or the last-order price?

Foundational — everything downstream depends on this anchor. Luca's own RFI answer flagged the ERP list as "not always up to date."

How do multi-raw-material formulas decompose — is there already a cost breakdown per product, or does that need to be built from scratch?

Biggest lever on build complexity for the calculation itself.

Data quality / risk

Is "date last priced" reliably populated across the 200 price books, or patchy?

If patchy, that's its own cleanup workstream before automation has anything reliable to work from.

Deferred — not needed to price an offer

Customer-identifiability-from-email (likely trivial either way)

Who exactly "l'ufficio" is

Whether price overrides get logged today

Systematic stale-price detection / trigger cadence (reactive vs. proactive)

Rounding / presentation rules

Approval authority beyond Luca

Exact order-count figure (only "few hundred/month" so far — fine as an approximation)

Exact acquisition structure/timeline, revenue, NASF/network memberships

Phone-order handling (~11% of volume — not automatable via email, dropped as a priority)

D · Is This Worth Building

Worth building — but it's a different bet than Aronlight, not an extension of it, and the ERP-API answer decides whether it's a good one.

For: the net-new surface area is genuinely small. Gather and the write-back discipline transfer straight from Aronlight; Match is lightweight (known customers, likely known SKUs); Luca himself says the calculation isn't hard. Real pain (3–5 hrs/week of CEO time), good ICP fit (9/12), a technically fluent engaged champion — sitting on top of a build that's mostly assembly, not invention.

Against: this isn't Aronlight's pattern proven again in a new vertical — it's a new value-chain area (financial/timing judgment) with zero playbook. Three of the open questions (formula, price anchor, multi-raw-material decomposition) are exactly the kind of thing that looks simple in a call and turns out messy in the data. Company is small (15–20 people); Luca's own hesitation about justifying spend on "half a person" suggests this could be a modest contract even if it works.

The real fork is the ERP API question. With API access, this is a tight, compelling, mostly-assembly build riding on real infrastructure. Without it, the automated version collapses into a manual calculator — a much less compelling thing to sell. Treat that one question as the actual go/no-go, not just another scoping input.

AdapttoAI · Internal Analysis · Confidential