Multi-vendor quoting system for a high-end furniture reseller

A Brasília furniture reseller was leaving R$ 200k deals on the table — not for lack of demand, but because every quote took the founder four hours at minimum, and for the larger projects, sometimes four full days. The bottleneck wasn’t sales. It was a spreadsheet, a calculator, and a roster of supplier catalogues that refused to speak the same language.

The challenge

Nexus Mobília Corporativa sells high-end corporate furniture in Brasília — to clinics, law firms, construction companies, executive offices. Tickets range from a few thousand reais to over R$ 500,000. The team is two people: Fernando, the founder, and Fernanda. They don’t compete on price. They compete on curation and project work, which means every quote is bespoke.

The trouble was the bespoke part. Every quote started from a blank Excel sheet. Fernando would open each supplier’s catalogue, find the product, calculate the markup on a calculator, paste the photo into Excel, and export a PDF. Four hours of work per quote was the floor. For the larger projects with mixed suppliers, it could stretch across four full days.

The deeper problem hid in the supplier catalogues themselves. Nexus resells from a roster of hundreds of suppliers, and they don’t agree on how to price anything. Some price by fabric group — seven price columns per product, depending on whether the customer picks basic leather or premium leather. Some price directly, one number per SKU. Some publish fabric grids in matrix form. Others use a triple matrix — product × base × fabric — with thousands of valid combinations. Every quote meant holding the right model for each supplier in his head, cross-referencing the catalogue, and running the math by hand — a process that was as fragile as it was slow.

And then there was the PDF. The furniture Nexus sells costs as much as a car. The quote was being sent in a Word document that looked like it had been built in 1995. Fernando was, in his own words, embarrassed to send it.

The compounding effect was the worst part: he was turning down larger projects because he knew he couldn’t quote them fast enough. The business wasn’t constrained by demand or by sales skill. It was constrained by the time it took to put a number on paper.

The approach

The instinct most consultants would have is a CRM. We considered HubSpot, Pipedrive, Conta Azul — and rejected all of them. None of them model a furniture catalogue with per-supplier markup chains, fabric groups, and product-base-fabric matrices. They’re built for tracking deals, not for pricing a 47-item office fit-out.

We considered SaaS tools built specifically for the furniture industry — Acetech, Promob, and others. They exist, but they’re built for manufacturers, not resellers. They lock you to a specific factory ecosystem, which is exactly the problem Nexus needed to not have. Their entire value proposition is being able to mix and match across suppliers.

We considered Excel with macros — a familiar path for a small business. Rejected too. Fernando isn’t an Excel power user; the macros would have become a permanent maintenance burden, and a single broken VLOOKUP six months in would have left him stranded.

What we landed on was unusual: Notion as the interface, with a custom Python backend doing the work invisibly behind it. Notion isn’t designed for this. But it had three things that mattered: zero learning curve for someone who’d never used a SaaS tool, native mobile support for quoting from a client’s office, and a structure rich enough to model a real domain if you push it hard. Fernando would never see the Python. To him, the system would simply be the Notion workspace.

The other constraint shaping everything was that this was a high-end deliverable. The PDF the client sees at the end isn’t just functional — it has to look like it belongs to the furniture it’s describing. Every decision tilted toward the polished side: PT-BR throughout, Brazilian R$ formatting, centimetre dimensions, corporate-grade typography. Nothing that read as “MVP”.

What we built

Eight Notion databases model the entire domain: factories, fabric groups, fabrics, products, SKUs, clients, quotes, and quote items. Fernando works in Notion the way anyone works in Notion — dragging products into a quote, picking a fabric group, adjusting quantities. Behind that interface, a Python service running on a private VPS handles everything Notion can’t do on its own.

The first thing it does is keep the catalogue current. We started by onboarding four of Fernando’s most-used suppliers — chosen because together they cover the full range of pricing models he’d encounter elsewhere. Each one publishes its catalogue in a different format — PDFs of varying quality, Excel workbooks, structured spreadsheets — so we wrote one idempotent parser per supplier. They normalize 9,569 SKUs into a single shape that Notion understands, regardless of whether the source priced by fabric group, by direct price, or by matrix combination. Re-running a parser produces the same result every time, so the catalogue can be refreshed without breaking existing quotes. The architecture is built to add suppliers incrementally — every new factory is one more parser, not a redesign.

The pricing logic is its own subsystem. Each quote item resolves its price through a three-level markup chain — factory default, then quote default, then item-level override — and picks whichever is most specific. This sounds simple stated this way; the work was in making sure it composed correctly across the different pricing models without the user ever needing to think about it.

When Fernando clicks “Gerar PDF” on a quote, a Notion button fires a webhook to the Python service. The service pulls the quote data, applies the pricing chain, lays it out through a Jinja2 template, renders it with WeasyPrint, and writes the PDF back as an attachment on the quote — along with the final totals on the corresponding Notion number properties. End to end: about forty seconds for a fifteen-item quote across five rooms totalling R$ 247,984.80.

One of the non-obvious decisions was anti-supplier safeguarding. Every photo and description in the client-facing PDF is scrubbed of supplier identity — no factory logos, no internal SKU codes, no QR codes pointing back to the supplier’s public Drive. The reason is direct commercial risk: if a Nexus client can identify the supplier, they can call the factory and reverse-engineer the markup. We tried to automate photo segmentation with vision models (rembg, U2Net, BiRefNet, Claude vision) and after three days abandoned the effort — none of them could reliably remove supplier branding without damaging the product image itself. We replaced the automation with a documented manual workflow: Fernando swaps photos as they appear in real quotes, and the initial 314 auto-cropped images stay as placeholders until then. The decision and its reasoning are written down in an architecture decision record, so the next person to look at this won’t repeat the experiment.

We also deliberately didn’t build a few things. No internal CRM — Fernando’s deal flow wasn’t the bottleneck. No mobile app — Notion’s native mobile is already good enough for quoting on-site. No complete coverage of every supplier in the roster yet — the architecture is ready to absorb them one parser at a time as Fernando’s usage tells us which ones matter most.

The outcome

Quote generation went from four hours at minimum — and, for the larger mixed-supplier projects, four full days — down to roughly five minutes of selection in Notion plus forty seconds for the PDF to render. The system has been live in production since May 19, 2026, with 9,569 SKUs from the first four onboarded suppliers already catalogued and the architecture ready to absorb the rest of Fernando’s roster one parser at a time.

The qualitative shift matters as much as the numbers. Fernando now has the confidence to pursue R$ 200,000+ projects he previously turned away. The PDF that lands in a client’s inbox is corporate-grade — the typography, the layout, the way totals are formatted in proper Brazilian R$ — and finally matches the price tag of the furniture it’s describing. The system operates entirely in PT-BR, with centimetre dimensions and Brazilian date formats, so nothing about it reads as a translated foreign tool.

Engagement is ongoing. The PDF generation system is phase three of a longer roadmap; phases A through D continue, including a conversational quoting agent that will let Fernando describe a project in natural language and have the system propose the items from the catalogue.

Lessons learned

The hardest engineering problems on this project weren’t the ones you’d guess from the outside. Anyone can describe “a quoting system” in a sentence. The actual complexity was in the supplier models — a roster of hundreds of factories, no two pricing the same way — and in the small, invisible gotchas: that Notion’s webhook serializes its payload in a deeply nested shape, that it has a sub-ten-second timeout and requires an HTTP 200 response (not 202), that it will report “Button failed to execute” even when the backend has succeeded if the response is late. Each of those took hours to debug the first time and are now reusable patterns for any future Notion-fronted system.

The other lesson was about knowing when to stop. Three days into automating photo segmentation, the right call was to abandon the experiment and document why. The temptation to keep pushing was real — vision models are almost there for this use case — but “almost” wasn’t going to ship the project. Replacing it with a manual workflow and a written record of the decision was less satisfying than a clever automation, and exactly the right call.