Skip to content
zechim
Back to blog
4 min readagentsvertical-saaswhatsappbrazil

The vertical-agent playbook: from Zeobra to Manufa

We just launched a second vertical SaaS with an AI agent baked in. Same pattern as Zeobra, different vertical. What travels between verticals, and what doesn't.

by Zechim

This week I launched Manufa, a SaaS for boilermaking shops in Brazil. It's the second vertical where I apply the same architectural pattern: proprietary domain data + conversational WhatsApp agent + the business owner as the human reviewer. The first was Zeobra, for construction-site management.

Two verticals, two products, same architecture underneath. This post is about what travels between verticals and what has to be rebuilt every time.

What Zeobra does, in three lines

Architects and property owners send via WhatsApp:

  • a photo of the invoice
  • a voice note: "paid R$ 1,250 by Pix to Carlos the plumber"
  • a photo of the construction site

The agent reads, categorizes, files it to the project log. The owner confirms when the entry is ambiguous. Done. No app, no login, no spreadsheet.

Live for months. Works because architects don't open dashboards, but they're on WhatsApp 80 times a day.

The pattern extracted

After running Zeobra in production, I identified four layers that repeat.

1. Vertical-specific data model

The DB schema is industry-specific. In Zeobra: projects, entries, vendors, daily log. In Manufa: fabrication jobs, work orders, welders, materials, deadlines.

This does NOT travel. Each vertical demands its own schema, modeled in conversation with 2 to 3 pilot customers. Going generic here kills the product.

2. WhatsApp as the front door

WhatsApp Business API direct from Meta, with my own webhook. The user installs nothing. In Brazil, that's the difference between adoption and failure.

This piece travels almost 100%. Ingress code, media processing (photo, audio, PDF), intent classification, session management: all reused between Zeobra and Manufa.

3. Multimodal agent with a human reviewer

Claude reads the incoming content, extracts entities, proposes an entry or action. When confidence is high and impact is low, it executes alone. When ambiguous or expensive, it messages the owner asking for confirmation.

That human-loop pattern (not autonomous, not 100% manual, risk-calibrated review) travels directly. Prompts change per vertical, but the skeleton is the same.

4. Dashboard secondary, agent primary

There's a web panel for the office (finance, reports, config). But the end user almost never opens it. The main interaction is WhatsApp.

This UX hierarchy travels. It's counterintuitive if you come from classic B2B SaaS where the dashboard IS the product. Here, the agent is the product.

Applied to Manufa

Manufa serves caldeirarias: shops that fabricate tanks, pressure vessels, ducts, welded structures. Fragmented Brazilian market, tens of thousands of shops, largely manual processes.

The first agents shipping:

Quote from drawing or PDF. Customer sends a technical drawing or photo. Agent extracts material (SA-516 plate, thickness, weld type), estimates hours, calculates cost. Returns a draft quote the owner reviews in 15 minutes instead of 2 hours.

WhatsApp customer service. "Hey, is it ready?" "How much for a 5000L stainless silo?" Same pain an architect has with their supplier. The agent answers status automatically and drafts pricing for the owner to approve before sending.

NR-13 traceability. For pressure vessels, Brazilian regulation requires a logged welder + procedure + electrode batch per weld. Almost nobody does this properly. Agent takes a photo of the weld plus a voice note from the welder, files it to the job. When inspection comes, it exports the dossier as PDF.

Each of these has specific prompts, specific data, specific integrations. But the skeleton (WhatsApp ingress, multimodal Claude, human reviewer, secondary dashboard) is literally the same code.

What I learned along the way

Things I'd do differently if starting Zeobra today:

  1. Own database from day 1. I tried sharing Supabase between tests and production for a month. Expensive in time. Each vertical deserves its own DB with its own schema.

  2. Haiku + Sonnet routing from the start. I used Sonnet 4.5 for everything in the early days. Inference cost per conversation was 4 times what it needed to be. Today Haiku 4.5 handles 85% of volume, Sonnet enters only when the task demands reasoning.

  3. Model the data with 3 customers, not 1. I pivoted the Zeobra schema twice because I modeled with a single pilot. Manufa started with 3 customer interviews before the first migration.

  4. WhatsApp Business API directly, no middleman. You need the low latency and the good price. Use Meta direct, no 360dialog or similar.

Next verticals

The pattern is repeatable. Caldeiraria was the second. Third, fourth, and fifth probably:

  • Auto repair shops
  • Stone fabrication (marmoraria)
  • Real-estate vertical (commission settlement, which is what repasse.co does)

Each one has the same structure: small-to-medium Brazilian business, owner-operated, manual processes already happening on WhatsApp, real pain in time lost to repetitive communication.

If you're thinking about building a vertical SaaS with an AI agent for the Brazilian market, the playbook above is what works for me. The 80% that travels (WhatsApp, multimodal, human reviewer, agent-primary) you can literally copy. The 20% that doesn't (data model, prompts, integrations) is where your differentiation lives.

Want to talk about applying this to your vertical? Book a 30-min call.