DEV Community: Alessandro Binda

How to Stop an AI Assistant From Inventing Numbers in Business Reports

Alessandro Binda — Wed, 28 Oct 2026 20:32:12 +0000

A method, not a guarantee: no setup removes errors completely. We give no accuracy percentages because we have not published a measurement.

Why does an AI assistant invent numbers?

A language model writes text that sounds right. If you ask for a figure that is not in front of it, it can produce a plausible one. The risk is highest when the model is asked to remember, estimate or sum figures from a long document. The fix is not a better prompt alone; it is a different division of labour.

What is the basic rule?

Numbers come from the data, calculations come from code, and the model writes the explanation. The assistant should never be the source of a figure. If you keep that rule, most invented numbers disappear because the model has nothing to invent: it is handed the figures it may quote.

Control 1: how do I show where each number comes from?

Attach to every figure its origin: the table, the cell or the query, and the date. In a report this can be a footnote or a hover. A number without an origin is treated as unverified and should not be published. This also lets a reader check a figure in seconds.

Control 2: why should totals be calculated outside the model?

Sums, averages, percentages and year-on-year changes are deterministic. A spreadsheet formula or a database query gets them right every time; a language model sometimes does not. Compute them first, then pass the results to the model as given facts.

Control 3: what should the assistant do when a figure is missing?

Write "data not available" and say which source was empty. Tell the assistant explicitly that this is the correct answer when data is absent. Without that instruction, models tend to fill the gap.

Control 4: how do I catch figures that look wrong?

Compare each figure to the previous period and to a plausible range. A cost line that moves by an order of magnitude, or a margin above 100%, is flagged automatically. These checks are cheap and catch both data errors and model errors.

Control 5: who reviews, and what do they review?

A person reviews only the figures that were flagged or that changed the conclusion, not the whole report. Keep the reviewer's name and date on the report. If no figure is flagged, say so in the report.

What can I measure to know the setup works?

Count the errors found by the controls and by readers over a period, compared with the number of figures checked. Publish the method with the number, or do not publish the number. We do not publish an accuracy figure for S.C.A.L.A. today.

What should I ask any AI vendor, including S.C.A.L.A.?

Ask to see the origin of any number you plan to use, and ask what the assistant does when data is missing. If the answer to either is "the model estimates it", do not use the figure in a report.

Originally published at https://get-scala.com/en/blog/how-to-stop-ai-inventing-numbers-in-business-reports.

SPF, DKIM and DMARC: A Setup Checklist for Business Email Senders

Alessandro Binda — Wed, 28 Oct 2026 20:32:11 +0000

Google requirements read on 28 October 2026. Your email provider's own instructions are the reference for the exact DNS records.

What are SPF, DKIM and DMARC?

SPF lists the servers allowed to send email for your domain. DKIM adds a cryptographic signature that receivers can check. DMARC tells receivers what to do when SPF or DKIM checks fail and sends you reports. Together they let a receiving server see that a message really comes from your domain.

Do I need all three?

For senders of more than 5,000 messages per day to Gmail, Google requires SPF and DKIM and a DMARC policy (the policy can be "none"), plus valid forward and reverse DNS records and TLS (Google). Below that volume it is still the baseline expected by most receivers.

In what order should I set them up?

Make an inventory of every service that sends mail as your domain (company mail, newsletter tool, CRM, support desk, outreach tool).
Publish one SPF record that includes all of them.
Enable DKIM signing in each service and publish the keys it gives you.
Publish a DMARC record with policy "none" and an address for reports.
Read the reports for a few weeks, fix the senders that fail, then consider a stricter policy.

What is the most common SPF mistake?

Publishing two SPF records for the same domain, or listing so many services that the record exceeds the lookup limit. Keep one record, and remove services you no longer use.

What does "alignment" mean?

For DMARC to pass, the domain in the From header must match the domain checked by SPF or DKIM. Google lists this as a requirement for direct email. A tool that sends "from your domain" using its own signing domain can fail DMARC even when SPF and DKIM pass individually.

What else does Google require?

Keep the spam rate in Postmaster Tools below 0.30% (Google recommends below 0.10%), format messages according to RFC 5322, do not impersonate Gmail From headers, and support one-click unsubscribe with a clearly visible link in marketing messages.

How do I test the setup?

Send a test message to a mailbox that shows the original headers and read the SPF, DKIM and DMARC results. Repeat for each sending service. Check again after any DNS or tool change.

Where does this fit in cold outreach?

Authentication is necessary but not sufficient: list quality, volumes and legal basis matter just as much. See B2B Cold Email in Europe Without Landing in Spam.

Originally published at https://get-scala.com/en/blog/spf-dkim-dmarc-setup-checklist.

What 100 fast-growing UK SMEs have in common (data from Companies House)

Alessandro Binda — Sat, 24 Oct 2026 23:06:43 +0000

The UK has about five million active companies, but "fast-growing" lists usually mean venture-backed start-ups. We looked at the other end: independent private companies that grew turnover quickly using only the accounts they filed.

The result is the SCALA Growth 100 UK (2022-2024): the 100 independent UK SMEs with the fastest turnover growth between FY2022 and FY2024. It is computed from Companies House filings, it is not an official Companies House list, and no company paid or applied to be on it. (How we parsed 7.35 million filings is in the technical write-up.)

What the 100 look like

All figures below come from the published CSV (turnover as filed, in pounds):

Growth: the median company grew turnover by 31.4% a year (range 22.5% to 93.8%), or 73% over the two years at the median.
Size: the median company went from £13.1M in 2022 to £24.8M in 2024. 63 of the 100 had at least £20M turnover in 2024; 12 started below £5M.
Leader: Travellanda Ltd (Borehamwood) grew from £8.8M to £33.0M (+275.6%).
Largest in 2024: MM Freight Ltd, Prestwick Aircraft Maintenance Ltd and New Century Foods Ltd, each around £41M.
Where: 11 are in London, 3 in Glasgow; the other 86 are spread across 78 other places.
What they do: business support services (6), online and mail-order retail (4), other manufacturing (3), motor vehicle repair (3), property development (3), food services (3). No single sector dominates.

So these are not tiny start-ups: most are established companies in ordinary sectors that doubled their turnover in two years.

How the list was built (short version)

Only accounts filed at Companies House, FY2022 to FY2024.
Independent companies only: no foreign or group parent, no company controlled by another company.
Holding, property, finance and investment vehicles excluded.
Each company reviewed individually (group membership, mergers, insolvency, consistency with public sources). When in doubt, it is left out.

Use the data

Ranking, method and badges: score.get-scala.com/rankings/uk/growth-100
CSV and JSON (open data): github.com/Alessandro114/uk-fastest-growing-companies
Look up any UK company's financials for free: S.C.A.L.A. Score

If your company is on the list, or you think a figure or a group link is wrong, tell us: corrections and removal requests are always honoured.

How we found the UK's 100 fastest-growing SMEs in 7 million Companies House filings (and why 4 in 10 candidates were wrong)

Alessandro Binda — Wed, 14 Oct 2026 14:00:28 +0000

Ask an AI assistant "which UK SMEs grew fastest in the last two years?" and you'll get either famous scale-ups from press releases or "I don't have reliable data on that".

The data exists. Every UK company files accounts at Companies House, and a large share of them are machine-readable iXBRL. So we built the answer from scratch: a ranking of the 100 independent UK SMEs whose turnover grew fastest from FY2022 to FY2024, published as a CSV, a zero-dependency CLI and a skill that AI agents can use.

This post is about how we built it, and about the part nobody tells you: most of the "fastest-growing" companies you find in raw filings aren't.

1. Reading 7.35 million filings without filling the disk

Companies House publishes a monthly zip of every electronically filed set of accounts. We processed 24 months (January 2024 to December 2025): 7,352,908 filings, between 2 and 4.4 GB per archive.

One archive at a time, read straight from the zip, deleted after parsing. Each file is an XHTML document with inline XBRL facts like this:

<ix:nonFraction name="core:TurnoverRevenue" contextRef="c2" unitRef="GBP"
                decimals="0" scale="0" format="ixt:num-dot-decimal">21,770,081</ix:nonFraction>

The parser looks for a short list of turnover tags (whatever the namespace prefix), honours scale, sign and the number format, keeps only GBP units, and skips any context with dimensions, which is how consolidated (group) figures are tagged:

TAGS = ["TurnoverRevenue", "Turnover", "TurnoverGrossOperatingRevenue",
        "TurnoverNetOperatingRevenue", "Revenue"]

def parse_num(txt, fmt, scale, sign):
    t = strip_tags(txt).replace(",", "")
    v = 0.0 if "zerodash" in fmt else float(t)
    if scale:
        v *= 10 ** int(scale)
    return -v if sign == "-" else v

Every set of accounts carries two periods: the current year and the prior year as comparative. Take the period with the latest end date as "current" and the one ending within 10 days of its start as "prior", and one filing gives you two years. Two years of archives give you three years of turnover.

Only 162,700 filings (2.2%) report turnover at all. Small and micro companies are allowed to file without a profit and loss account, so this is a ranking of medium-sized and larger SMEs by construction.

2. Three years per company, in one query

Facts go to Parquet, one file per month. DuckDB then builds one row per company and financial year, preferring a figure reported as "current" over the same period reported as a comparative a year later:

CREATE TABLE f AS
SELECT * FROM (
  SELECT *, row_number() OVER (PARTITION BY cn, pe ORDER BY pri, archive DESC) k
  FROM (SELECT company_number cn, period_start ps, period_end pe, turnover t, 0 pri, archive FROM cur
        UNION ALL
        SELECT company_number, prior_start, prior_end, prior_turnover, 1, archive FROM prior)
) WHERE k = 1;

Then the rules:

12-month financial years only (350 to 380 days), same year-end month in 2022 and 2024
turnover rising every year, FY2022 → FY2023 → FY2024
at least £1.7m in 2022 and between £4.3m and £43m in 2024 (SME range)
no single-year jump above 2.5×, which is almost always a merger or a hive-up rather than sales
if the 2025 accounts are already filed and turnover fell by more than 30%, the "growth" was a one-off peak: out

That left 888 candidates. That's where the real work started.

3. The false positives

We checked candidates by hand: the Companies House page of each one (persons with significant control, filing history, officers), plus the company's own website and press. 260 checked, 97 thrown out. In a parallel ranking for France built from INPI filings, 332 checked, 126 thrown out. Almost 4 in 10, in both countries.

What they were:

Part of a bigger group (42). A subsidiary of a foreign parent or a larger UK group, or owned by private equity, that looks exactly like an independent SME in its own accounts.
Doubts we couldn't resolve (36). We left them out.
Insolvency or strike-off (10). Growing turnover, then administration, liquidation or a proposal to strike off.
Something else (8). Including a cluster of companies recently renamed after a single person, with micro-entity accounts that didn't match the turnover they reported.
Growth bought, not earned (1). An acquisition explained the jump.

The useful lesson: most of this can be caught automatically once you know to look. Three rules from the free Companies House company data product (status exactly "Active", account category not micro, dormant or audit-exempt subsidiary, and no name change since 2023) caught all 10 of the insolvency cases we had found by hand, without losing a single company we had confirmed.

4. Independence, from the PSC register

The persons with significant control (PSC) snapshot is free too. We kept only corporate controllers (no personal data stored) and excluded a company when:

a corporate PSC is registered outside the UK, or
a UK corporate PSC is itself controlled by another company, or turns over more than £43m.

A founder's personal holding company passes. A group's trading subsidiary doesn't. The manual review then caught what the register can't see.

5. Making it usable by AI agents

A ranking on a web page answers humans. To answer agents, we shipped the data as a CLI that prints JSON:

npx -y github:Alessandro114/uk-fastest-growing-companies filter --region Scotland --table

#2   Diona Construction Ltd     Glasgow    £9.6m -> £28.1m   +71.3%/yr
#3   I3works Ltd                Glasgow    £9.8m -> £27.3m   +67.3%/yr
#14  Pacson Limited             Dundee     £6.3m -> £13.8m   +48.3%/yr

Why a CLI rather than an API: an agent calls it with one short line, gets compact JSON, and if a command fails it just tries another. No API key, no long request bodies, no wasted context. A SKILL.md tells Claude (or any agent with a shell) when to use it and how to quote the figures: in GBP, with the year, and with the Companies House link for each company.

In Claude Code:

/plugin marketplace add Alessandro114/uk-fastest-growing-companies
/plugin install uk-fastest-growing-companies@uk-fastest-growing-companies

Then ask "which construction firms in Scotland grew fastest?" and you get filed numbers instead of a guess.

What came out

The median company on the list grew 31% a year. Together, the 100 went from £1.3bn to £2.35bn in turnover. 81 of them are outside Greater London, and the largest group is construction (14 companies), not software.

Repo (data, CLI, skill): https://github.com/Alessandro114/uk-fastest-growing-companies
Full ranking and method: https://score.get-scala.com/rankings/uk/growth-100/

If this saves you a weekend of parsing iXBRL, a star on the repo helps others find it. And if you spot a company that shouldn't be there, open an issue: every correction makes the list better.

I Replaced whatsapp-web.js With a REST API and My Bot Stopped Crashing

Alessandro Binda — Sun, 30 Aug 2026 19:49:30 +0000

The Problem

If you've built a WhatsApp bot with whatsapp-web.js, you know the pain:

Random disconnects every 2-6 hours
QR re-authentication breaking at 3am
Memory leaks from the embedded Chromium instance
Multi-instance? Forget it — each instance eats 500MB+ RAM

I ran this stack in production for 8 months. It worked... until it didn't. The breaking point was when I needed multi-tenant support: one server handling WhatsApp sessions for multiple businesses.

The Migration

I moved from whatsapp-web.js (browser automation) to WAHA (a proper REST API that wraps WhatsApp Web internally). The difference:

	whatsapp-web.js	WAHA
Architecture	Your code spawns Chromium	Standalone Docker container
Memory per session	~500MB	~80MB
Multi-session	Manual, fragile	Native REST endpoint
Session persistence	File-based, breaks	Built-in
Reconnection	You build it	Automatic
API style	Event-driven JS	REST + webhooks

What Changed in the Code

The biggest architectural shift: instead of your bot being the WhatsApp process, your bot becomes a webhook consumer.

Before (whatsapp-web.js):

const client = new Client();
client.on("message", async (msg) => {
  // Your bot IS the WhatsApp process
  // If this crashes, WhatsApp disconnects
  const response = await generateAIResponse(msg.body);
  await msg.reply(response);
});
client.initialize(); // Spawns Chromium

After (WAHA webhook):

// WAHA runs separately as a Docker container
// Your bot receives webhooks
app.post("/webhook/message", async (req, res) => {
  const { from, body, session } = req.body;
  const response = await generateAIResponse(body, session);

  // Send via REST API
  await fetch(`${WAHA_URL}/api/sendText`, {
    method: "POST",
    body: JSON.stringify({
      session,
      chatId: from,
      text: response
    })
  });

  res.sendStatus(200);
});

The separation means:

Bot crashes don't kill WhatsApp sessions
You can restart your bot without re-authenticating
Multiple bots can share the same WAHA instance
Scaling is just adding more webhook consumers

The AI Agent Layer

Once the WhatsApp connection was stable, I built the actual agent runtime on top: SARA (github.com/Alessandro114/sara).

SARA handles:

Tool-calling loop on Groq/Cerebras/Mistral (free tiers)
20 industry-specific knowledge packs (restaurants, clinics, retail...)
Session memory that persists across conversations
Multi-tenant isolation — each business gets its own agent persona

The entire stack runs self-hosted via Docker Compose:

services:
  waha:
    image: devlikeapro/waha
    ports:
      - "3000:3000"
  sara:
    build: .
    environment:
      - WAHA_URL=http://waha:3000
      - GROQ_API_KEY=${GROQ_API_KEY}

Results After Migration

Uptime: 99.7% over 3 months (vs ~92% with whatsapp-web.js)
Memory: 80MB per session (vs 500MB)
Deploy time: restart bot in 2s without losing sessions
Multi-tenant: 5 businesses on one $10/mo VPS

Try It

SARA is open source (Apache-2.0): github.com/Alessandro114/sara

If you're stuck on whatsapp-web.js and hitting the same problems, the WAHA migration is worth the effort. The codebase is ~3K lines of TypeScript.

I'm the author of SARA. Questions about the migration or architecture welcome in the comments or on GitHub.

We Built 41 AI Agents That Run an Entire Business — Here's What We Learned

Alessandro Binda — Sun, 16 Aug 2026 19:43:11 +0000

The Problem Nobody Talks About

Every business runs on 7+ disconnected tools. Zendesk for support. PagerDuty for monitoring. Monday.com for projects. BambooHR for people. QuickBooks for invoices. A WhatsApp group for everything else.

Total cost: $1,200-1,800/month. Total integration: zero.

We asked: what if one AI platform handled all of it?

What We Built

41 autonomous AI agents organized in 9 packs, all accessible via WhatsApp:

HR & People — An employee sends "How many vacation days do I have left?" on WhatsApp. SARA (our AI) checks the balance, finds 12 days, and submits the leave request to their manager. No app. No portal. No training.

Finance — "What's the status of invoice 1234?" SARA finds it, sees it's 15 days overdue, and asks if you want to send a payment reminder. One message: done.

IT Support — "I need to reset my password for the CRM." SARA creates the IT ticket, sets priority, and confirms: "New credentials will arrive within 15 minutes."

Infrastructure — At 2 AM, the database container crashes. Our guardian agent detects it in 60 seconds, recreates the container on the correct network, fixes the nginx proxy, and verifies health. You wake up to a "Recovered" notification. Total downtime: under 2 minutes.

The 9 Agent Packs

Pack	Agents	What It Does
Support	3	Ticketing, status, escalation via WhatsApp
HR & People	4	Leave, payslips, onboarding checklists
Finance & Admin	4	Invoicing, expenses, payment reminders
Compliance & Legal	3	GDPR requests, deadlines, contract renewals
Sales & Marketing	5	Lead scoring, pipeline, campaigns, follow-ups
Project Management	4	Tasks, assignments, progress, timelines
IT Support	4	Password resets, access provisioning, system status
Inventory	2	Stock levels, reorder alerts
Proactive Customer	3	Appointment reminders, feedback, churn detection

Plus 7 infrastructure ops agents that run 24/7: auto-healing, DB performance monitoring, security audits, backup verification, and log anomaly detection.

The Architecture

Every agent follows the same pattern:

SARA receives a message (WhatsApp, Telegram, or web)
Intent detection determines which agent to invoke
Tool dispatcher calls the right handler with context (tenant, phone, sector)
Handler queries the database, performs the action, returns structured data
SARA formats the response in natural language

The handlers degrade gracefully — if a table doesn't exist yet (customer hasn't set up that module), they return a helpful message instead of crashing.

registerHandler('check_leave_balance', async (args, ctx) => {
    try {
        const res = await pool.query(
            `SELECT leave_type, (total_days - used_days) AS remaining
             FROM hr_leave_balances WHERE user_id = $1 AND employee_phone = $2`,
            [ctx.tenantId, args.phone || ctx.phone]
        );
        if (res.rows.length === 0)
            return { success: true, data: { message: 'No leave data found.' } };
        return { success: true, data: { balances: res.rows } };
    } catch (err) {
        if (err.message?.includes('does not exist'))
            return { success: true, data: { message: 'HR module not configured yet.' } };
        throw err;
    }
});

Why WhatsApp?

Everyone has it. No app to install. No login to remember. No training needed.

A CEO can manage their entire business from the same app they use to text their family. That's not a feature — that's a paradigm shift.

The Numbers

41 AI agent tools across 9 business functions
20 industry verticals (restaurant, hotel, legal, healthcare, retail...)
< 60 seconds to auto-heal infrastructure failures
€2,000/month for the entire suite (vs $1,800+ for fragmented tools)
€0 to try — 14-day free trial, no credit card

Free Tool: AI Business Health Check

We also built a free tool that analyzes any business website and generates an AI-readiness score across 5 dimensions. Try it: get-scala.com/en/health-check

What's Next

We're adding Meeting Notes via WhatsApp — send a voice memo of your meeting, get a structured summary with action items in 30 seconds. Free. Because the best marketing is a product people can't stop talking about.

SCALA AI OS is an open platform. SARA, the core AI assistant, is open source on GitHub.

Try SARA on WhatsApp: +39 351 787 4003

Every WhatsApp chatbot framework is broken. Here's what I built instead.

Alessandro Binda — Sat, 15 Aug 2026 00:56:03 +0000

I've evaluated every open-source WhatsApp bot framework on GitHub. They all share the same fatal flaw.

The Problem Nobody Talks About

Most WhatsApp bot frameworks are glorified API wrappers. They handle message transport — receiving a text, routing it somewhere, sending a reply — and that's it. The "intelligence" layer is left entirely to you. You get a pipe. You get a webhook. You get some session management. And then you're on your own.

The frameworks that do add AI make a different mistake: they duct-tape GPT onto the messaging pipe and call it "AI-powered." The pattern is always the same: receive message → append to conversation history → call openai.chat.completions.create() → send reply. It's generic. It's stateless in any meaningful business sense. It doesn't know what industry it's serving, what data it has access to, or what actions it's actually allowed to take.

Here's the part that breaks me: none of these frameworks understand that a restaurant needs different tools than a law firm. A restaurant needs to check table availability, query allergens, create reservations, and handle cancellations. A law firm needs to schedule consultations, check document status, route inquiries by practice area. These are not the same problem. Treating them as "just chat" is the core architectural failure of every framework I've seen.

And then there's the "enterprise" tier: Twilio Flex, Intercom, Freshchat. These charge $500–$2,000/month for what is fundamentally a prompt and a webhook wrapped in a dashboard. They're selling you infrastructure and calling it intelligence. The underlying model doesn't know your business. It can't execute actions in your systems. It's an expensive illusion.

What's Actually Needed

The shift that matters isn't from "no AI" to "has AI." It's from generic chat to domain-specific function calling. This is not a subtle distinction.

Here's what a properly architected tool dispatcher looks like versus what everyone else ships:

// Each vertical gets domain-specific tools
const DINEOS_TOOLS = [
  { name: 'check_availability', handler: checkTableAvailability },
  { name: 'check_allergens', handler: checkMenuAllergens },
  { name: 'book_table', handler: createReservation },
  { name: 'cancel_reservation', handler: cancelWithPolicy },
  { name: 'get_menu', handler: fetchLiveMenu },
];

const LEGALOS_TOOLS = [
  { name: 'schedule_consultation', handler: bookLawyerSlot },
  { name: 'check_case_status', handler: queryCaseDB },
  { name: 'route_inquiry', handler: classifyAndRoute },
];

// vs the generic approach everyone else uses:
const GENERIC_APPROACH = [
  { name: 'chat', handler: askGPT }, // useless
];

When the model has access to real, domain-specific tools, it stops being a chatbot and starts being an agent. It can actually do things: query live inventory, write to your reservations database, check against your allergen tables, trigger workflows in your backend. That's the difference between a wrapper and a platform.

Two other things that almost no framework handles correctly: PII protection and multi-provider failover. You are routing customer names, phone numbers, order histories, and medical information through third-party LLM APIs. That's a GDPR liability waiting to happen. And when OpenAI has an outage — which they do, routinely — your entire customer-facing AI goes dark. These aren't edge cases. They're production requirements.

What I Built

I got tired of the same conversation and built SARA — an open-source WhatsApp AI agent platform with 20 vertical-specific agent profiles, each with its own tool set, knowledge base, and autonomy configuration.

The provider chain runs Groq → Cerebras → SambaNova → Mistral in sequence. If Groq is down or rate-limited, the system fails over to Cerebras automatically. All four providers have generous free tiers, which means the inference cost for most deployments is literally zero. No OpenAI dependency. No single point of failure.

Each tenant gets their own RAG instance — a pgvector knowledge base populated with their menus, policies, product catalogs, or legal documents. The model isn't hallucinating from its training data; it's retrieving from the business's actual content. Every query is scoped to that tenant's data.

The piece I'm most proud of is the autonomy gate:

// Autonomy levels — not every action should be automatic
enum AutonomyLevel {
  OFF,        // AI suggests, human decides
  OBSERVE,    // AI drafts, human approves  
  SEMI_AUTO,  // AI acts on low-risk, asks on high-risk
  FULL_AUTO   // AI handles everything
}

// Risk classification before every action
const classifyRisk = (tool: string, args: ToolArgs): RiskLevel => {
  if (tool === 'book_table') return RiskLevel.LOW;       // reversible
  if (tool === 'process_refund') return RiskLevel.HIGH;  // money moved
  if (tool === 'cancel_reservation') return RiskLevel.MEDIUM;
  return RiskLevel.LOW;
};

// Gate checks: if action risk > autonomy level → ask human
const autonomyGate = (tool: string, args: ToolArgs, level: AutonomyLevel) => {
  const risk = classifyRisk(tool, args);
  if (risk === RiskLevel.HIGH && level < AutonomyLevel.FULL_AUTO) {
    return { blocked: true, reason: 'requires_approval' };
  }
  return { blocked: false };
};

Before every LLM call, PII is anonymized — names replaced with tokens, phone numbers stripped, emails masked. The model never sees raw customer data. After the response is generated, the PII is re-injected for the actual reply. This is not optional if you're handling real customer data at scale.

The result: 20 vertical agents (DineOS for restaurants, LegalOS for law firms, ClinicOS for healthcare, RetailOS for e-commerce, and 16 more), each with 3–6 domain-specific tools, running on a zero-cost inference stack, with PII protection baked in at the transport layer.

Stop Wrapping APIs and Calling It AI

The entire WhatsApp bot ecosystem has optimized for the wrong thing: ease of connection, not quality of intelligence. Getting a message in and a message out is a solved problem. The unsolved problem is making the agent actually useful for a specific business context.

Stop wrapping APIs and calling it AI. Build agents that actually understand the domain.

SARA is open source under AGPL-3.0. Code, architecture docs, and agent definitions are at github.com/Alessandro114/sara.

How I Built 20 AI Agents for WhatsApp — and Open-Sourced Everything

Alessandro Binda — Wed, 12 Aug 2026 20:59:00 +0000

Building a conversational AI platform that serves SMBs across 20 industries sounds straightforward until you hit the real constraints: latency, cost, privacy, and reliability — all at once. This is the story of how we architected SARA (our AI agent layer for WhatsApp), the decisions we made, and why we open-sourced the entire thing.

Repo: https://github.com/Alessandro114/sara

The core problem: 20 verticals, one conversation interface

SARA powers AI agents for restaurants, hotels, law firms, clinics, retail, logistics, and 14 other verticals — all through WhatsApp. Each vertical needs domain-specific tool access (a restaurant agent books tables; a clinic agent checks appointment slots). But the conversation interface is identical: a WhatsApp message in, a useful response out.

The naive approach is one giant prompt per vertical. That breaks fast: context windows fill up, prompts drift, and debugging is a nightmare.

Our approach: one core agent loop, 20 sets of tool definitions. Function calling is the vertical differentiation layer, not the prompt.

Architecture decision 1: Multi-provider LLM failover chain

We chain free-tier LLM providers in priority order: Groq → Cerebras → SambaNova → Mistral. Each is tried in sequence; on timeout or error, the next kicks in. The caller never knows which backend responded.

// ai-providers.ts — simplified provider failover chain
const PROVIDER_CHAIN: AIProvider[] = [
  {
    name: 'groq',
    client: new Groq({ apiKey: process.env.GROQ_API_KEY }),
    model: 'llama-3.1-70b-versatile',
    maxTokens: 8192,
  },
  {
    name: 'cerebras',
    client: new Cerebras({ apiKey: process.env.CEREBRAS_API_KEY }),
    model: 'llama3.1-70b',
    maxTokens: 8192,
  },
  {
    name: 'sambanova',
    client: new SambaNova({ apiKey: process.env.SAMBANOVA_API_KEY }),
    model: 'Meta-Llama-3.1-70B-Instruct',
    maxTokens: 4096,
  },
  {
    name: 'mistral',
    client: new MistralClient(process.env.MISTRAL_API_KEY),
    model: 'mistral-large-latest',
    maxTokens: 8192,
  },
];

async function getAIResponse(
  messages: ChatMessage[],
  tools?: ToolDefinition[]
): Promise<AIResponse> {
  for (const provider of PROVIDER_CHAIN) {
    try {
      const response = await provider.client.chat.completions.create({
        model: provider.model,
        messages,
        tools,
        tool_choice: tools?.length ? 'auto' : undefined,
        max_tokens: provider.maxTokens,
      });
      return { provider: provider.name, response };
    } catch (err) {
      console.warn(`[AI] Provider ${provider.name} failed, trying next...`, err);
    }
  }
  throw new Error('All AI providers exhausted');
}

Key insight: the tool definitions are passed identically to every provider. OpenAI-compatible function calling is now a de-facto standard — Groq, Cerebras, SambaNova, and Mistral all support it, so the failover is truly transparent.

Architecture decision 2: Tool dispatcher pattern

Function calling gives you the LLM's intent ({ name: 'book_table', arguments: {...} }). You still need something to actually execute it. We built a centralized dispatcher with 30+ handlers — one per tool — all registered in a single map.

The key design principle: tool handlers are pure functions. They take validated arguments, hit the DB or an external API, and return a structured result. The agent loop feeds results back as role: 'tool' messages until the LLM stops requesting tool calls.

// tool-dispatcher.ts — dispatcher core + agent loop
type ToolHandler = (
  args: Record<string, unknown>,
  context: AgentContext
) => Promise<ToolResult>;

const TOOL_REGISTRY: Record<string, ToolHandler> = {
  book_table:         handlers.bookTable,
  check_availability: handlers.checkAvailability,
  get_menu:           handlers.getMenu,
  create_ticket:      handlers.createTicket,
  get_appointment:    handlers.getAppointment,
  // ... 25+ more across 20 verticals
};

async function dispatchTool(
  toolCall: ToolCall,
  context: AgentContext
): Promise<ToolResult> {
  const handler = TOOL_REGISTRY[toolCall.function.name];
  if (!handler) return { error: `Unknown tool: ${toolCall.function.name}` };

  const args = JSON.parse(toolCall.function.arguments);
  const validated = validateToolArgs(toolCall.function.name, args);
  if (!validated.ok) return { error: validated.error };

  return handler(validated.args, context);
}

// Agent loop: keep calling tools until the LLM stops asking for them
async function chatChainWithTools(
  messages: ChatMessage[],
  tools: ToolDefinition[],
  context: AgentContext
): Promise<string> {
  let response = await getAIResponse(messages, tools);

  while (response.tool_calls?.length) {
    const toolResults = await Promise.all(
      response.tool_calls.map(tc => dispatchTool(tc, context))
    );
    messages.push(
      { role: 'assistant', content: null, tool_calls: response.tool_calls },
      ...toolResults.map((r, i) => ({
        role: 'tool' as const,
        tool_call_id: response.tool_calls![i].id,
        content: JSON.stringify(r),
      }))
    );
    response = await getAIResponse(messages, tools);
  }

  return response.choices[0].message.content ?? '';
}

Why function calling over prompt-only approaches?

Structured output by default — no regex parsing of free-text responses.
Composable — the LLM can chain multiple tools in a single turn.
Auditable — every tool invocation is logged with exact arguments, giving a full per-conversation audit trail.

Architecture decision 3: PII anonymization before the LLM sees anything

WhatsApp conversations contain real names, phone numbers, fiscal codes, addresses. Sending that raw to third-party LLM APIs is a GDPR problem and a trust problem.

We anonymize PII before the message reaches any LLM, then deanonymize in the dispatcher layer — only when a tool actually needs the real value to write to the DB.

// pii-anonymizer.ts
interface PIIMap {
  [placeholder: string]: string; // '[PHONE_1]' -> '+39 333 1234567'
}

function anonymizeMessage(text: string): { anonymized: string; map: PIIMap } {
  const map: PIIMap = {};
  const counter = { PERSON: 0, PHONE: 0, EMAIL: 0, ID: 0 };

  const anonymized = text
    .replace(FISCAL_CODE_REGEX, (match) => {
      const key = `[ID_${++counter.ID}]`;
      map[key] = match;
      return key;
    })
    .replace(PHONE_REGEX, (match) => {
      const key = `[PHONE_${++counter.PHONE}]`;
      map[key] = match;
      return key;
    })
    .replace(EMAIL_REGEX, (match) => {
      const key = `[EMAIL_${counter.EMAIL++}]`;
      map[key] = match;
      return key;
    });

  return { anonymized, map };
}

// Restore real values in tool args before execution
function deanonymizeToolArgs(
  args: Record<string, unknown>,
  map: PIIMap
): Record<string, unknown> {
  return JSON.parse(
    JSON.stringify(args).replace(
      /\[(?:PERSON|PHONE|EMAIL|ID)_\d+\]/g,
      (ph) => map[ph] ?? ph
    )
  );
}

The LLM sees [PHONE_1] and reasons about it correctly. The book_table handler gets the real phone number only at execution time. The LLM API provider never sees actual PII.

Architecture decision 4: Autonomy gate — risk-tiered execution

Not all tool actions are equal. Reading a menu is safe. Cancelling a reservation or triggering a refund is not. An autonomy gate sits between the dispatcher and execution, classifying each tool call by risk level.

// autonomy-gate.ts
const TOOL_RISK: Record<string, 'low' | 'medium' | 'high'> = {
  get_menu:           'low',
  check_availability: 'low',
  book_table:         'medium',
  cancel_reservation: 'high',
  process_refund:     'high',
  send_notification:  'medium',
};

async function gateToolExecution(
  toolName: string,
  context: AgentContext
): Promise<{ allowed: boolean; reason?: string }> {
  const risk = TOOL_RISK[toolName] ?? 'medium';

  if (risk === 'low') return { allowed: true };

  if (risk === 'high' && !context.userConfirmed) {
    return {
      allowed: false,
      reason: `Action "${toolName}" requires explicit user confirmation.`,
    };
  }

  if (risk === 'medium' && context.autonomyLevel < 2) {
    return {
      allowed: false,
      reason: `Action "${toolName}" requires autonomy level >= 2.`,
    };
  }

  return { allowed: true };
}

The autonomy level is set per-tenant at onboarding. A conservative restaurant owner sets level 1 (read-only AI, all writes need confirmation). A high-trust logistics operator sets level 3 (full autonomous execution). Same agent code, different gate behaviour.

What ships in the open-source repo

github.com/Alessandro114/sara includes:

Multi-tenant WhatsApp session management (WAHA-based)
Full provider failover chain (Groq / Cerebras / SambaNova / Mistral)
Tool dispatcher with 30+ handlers across 20 verticals
PII anonymization + deanonymization pipeline
Autonomy gate with configurable per-tenant risk levels
RAG layer (pgvector + Jina embeddings v3) for per-tenant knowledge bases
Dream cycle: proactive agent behaviours that fire outside conversation threads
White-label support: each tenant gets their own agent identity and persona

Licensed AGPL-3.0 — free to self-host, cloud hosting available for teams that prefer managed infrastructure.

Why open-source this?

Most WhatsApp AI demos are either toy FAQ bots or closed-source commercial black boxes. We wanted to show what a production-grade, multi-vertical agent architecture actually looks like — the provider failover, the PII layer, the autonomy controls, the tool dispatch loop.

The growing platform already serves SMBs across 20 industries. Open-sourcing the core means the community can audit, extend, and build on what we learned.

If this architecture helps you ship faster or think differently about agent design, that is the win.

If this is useful, please star the repo: https://github.com/Alessandro114/sara

Open an issue to discuss architecture decisions, request a vertical definition, or contribute a new tool handler — PRs welcome.

Why Vertical AI Agents Beat Horizontal Ones (And How to Build Them)

Alessandro Binda — Sun, 09 Aug 2026 21:09:34 +0000

ChatGPT can write a poem. It cannot manage your restaurant's Friday night rush.

The gap between "general AI" and "AI that does a specific job" is where the real value lives. Here's why we bet everything on vertical AI agents — and the architecture behind 20 industry-specific agents running in production.

The Horizontal Trap

Horizontal AI tools (Zapier AI, generic chatbots, "AI for everything" platforms) share a fatal flaw: they know a little about everything and a lot about nothing.

When a hotel manager asks "optimize my pricing for next weekend", a horizontal AI will give you a generic answer about dynamic pricing. A vertical HotelOS agent will:

Pull your occupancy data from the last 3 weekends
Check local events (conference, festival, sports)
Compare competitor rates on Booking.com
Factor in your cost base and margin targets
Suggest specific prices per room category with reasoning

That's not prompt engineering. That's domain-encoded business logic exposed as tools.

Architecture: One Framework, 20 Brains

Shared Infrastructure:
├── AI Provider Chain (Groq/Cerebras/SambaNova/Mistral)
├── Tool Dispatcher (30+ handlers)
├── Autonomy Gate (risk classification)
├── OpenAPI Connector (universal SaaS integration)
└── Communication Layer (WhatsApp, Web, API)

Per-Vertical Agent Definition:
├── System prompt (industry-specific personality + knowledge)
├── Tool whitelist (which tools this agent can use)
├── Business rules (what requires human approval)
├── Data schema (tables, relationships, KPIs)
└── Proactive behaviors (when to reach out unprompted)

Agent Definition Example: DineOS (Restaurant)

{
  "id": "dineos",
  "name": "DineOS Agent",
  "vertical": "restaurant",
  "tools": [
    "create_reservation",
    "check_availability",
    "menu_analysis",
    "staff_schedule",
    "food_cost_calculator",
    "daily_revenue_report",
    "supplier_order"
  ],
  "proactive_behaviors": [
    {
      "trigger": "reservation_count > capacity * 0.9",
      "action": "alert_owner",
      "message": "Tonight is 90%+ booked. Consider opening the patio."
    },
    {
      "trigger": "ingredient_stock < reorder_point",
      "action": "draft_supplier_order",
      "requires_approval": true
    }
  ],
  "autonomy_rules": {
    "low_risk": ["check_availability", "menu_analysis", "daily_revenue_report"],
    "medium_risk": ["create_reservation", "staff_schedule"],
    "high_risk": ["supplier_order", "pricing_change"]
  }
}

Why This Beats Fine-Tuning

You don't need a fine-tuned model per vertical. You need:

The right tools — a restaurant agent with food_cost_calculator is more useful than a model that memorized 10,000 recipes
The right guardrails — different verticals have different risk profiles
The right data — inject business-specific context (menu, pricing, inventory) at runtime, not training time

This approach means we can launch a new vertical in days, not months:

Define the agent (system prompt + tool whitelist + rules) → 1 day
Create the data schema (tables + migrations) → 1 day
Wire up proactive behaviors → 1 day
Test with real scenarios → 2 days

Cross-Vertical Intelligence

The real magic: agents that talk to each other.

Event: Large group booking (20 pax) at DineOS restaurant
  → DineOS notifies TravelOS: "20 guests arriving Saturday"
  → TravelOS checks hotel availability nearby
  → TravelOS offers group rate to the booking contact
  → AgencyOS logs the cross-sell opportunity

This is implemented via an event bus:

eventBus.emit('large_booking', {
  vertical: 'dineos',
  guest_count: 20,
  date: '2026-08-15',
  contact: { name: '[REDACTED]', phone: '[REDACTED]' }
});

// TravelOS listener
eventBus.on('large_booking', async (event) => {
  if (event.guest_count >= 10) {
    const availability = await checkHotelAvailability(event.date);
    if (availability.rooms >= event.guest_count / 2) {
      await suggestGroupRate(event);
    }
  }
});

The 20 Verticals

We currently run agents for: Restaurant (DineOS), Hotel (HotelOS), Property (PropertyOS), Retail (RetailOS), Travel Agency (TravelOS), Facility Management (FacilityOS), Studio/Gym (StudioOS), Legal (LegalOS), Healthcare (HealthOS), Education (EduOS), Automotive (AutoOS), Real Estate (RealEstateOS), Construction (BuildOS), Logistics (LogisticsOS), Agriculture (AgroOS), Beauty/Spa (BeautyOS), Events (EventOS), Finance (FinanceOS), HR (HROS), and a General agent.

All 21 agent definitions are open source: scala-agent-definitions (Apache-2.0).

Metrics That Matter

For vertical AI agents, the metrics are different from chatbots:

Metric	Chatbot	Vertical Agent
Success	Response quality	Task completion rate
Value	Conversations	Revenue generated
Retention	DAU	Operational dependency
Pricing	Per-message	Per-seat (flat monthly)

When a restaurant can't run Friday night without your agent, churn is near zero. That's the moat.

Try It

Platform: get-scala.com (Growth $97/mo, Scale $197/mo)
WhatsApp Agent (open source): SARA on GitHub
Agent definitions (open source): scala-agent-definitions
RE feasibility agent (open source): LandIQ on GitHub

The future of AI isn't one model that does everything. It's specialized agents that do one thing exceptionally well. Follow for more on building vertical AI.

Building a Production WhatsApp AI Agent: Architecture That Actually Works

Alessandro Binda — Sun, 09 Aug 2026 21:09:19 +0000

Everyone demos a WhatsApp chatbot. Few run one in production with real customers sending real messages 24/7.

After 18 months of running SARA — an open-source WhatsApp AI agent serving businesses across 20 industries — here's what we learned about architecture that survives contact with reality.

Why WhatsApp?

The numbers are simple:

2B+ monthly active users
60% of SMB customers prefer messaging over calling
98% open rate (vs 20% for email)

But WhatsApp is NOT just another chat channel. It has unique constraints that break naive implementations.

Architecture Overview

WhatsApp (WAHA) → Bridge (:3008) → SARA API (:3006) → AI Provider Chain → Tool Dispatcher
                                                              ↓
                                                    Groq → Cerebras → SambaNova → Mistral

The Provider Fallback Chain

Single-provider AI is a production risk. We use a 4-provider chain:

Primary: Groq (fastest, free tier)
    ↓ fail
Fallback 1: Cerebras
    ↓ fail
Fallback 2: SambaNova
    ↓ fail
Fallback 3: Mistral (paid, always works)

Each provider gets 2 retries with exponential backoff before failover. Result: 99.7% uptime over 6 months with $0 inference cost (free tiers).

Tool Calling: Not Just Chat

SARA doesn't just answer questions. She executes actions:

create_reservation — books a table with date normalization ("domani alle 8" → 2026-08-10T20:00)
check_inventory — queries stock levels
generate_invoice — creates a PDF from database records
schedule_appointment — manages calendar slots

The dispatcher maps 30+ tools to handlers with an autonomy gate:

User message → Intent classification → Risk assessment → Tool execution
                                              ↓
                                    Low risk: execute immediately
                                    Medium: execute + notify owner
                                    High: ask for confirmation first

You do NOT want your AI agent booking a catering order for 500 people without human approval.

PII Handling

Messages contain names, phone numbers, addresses. Our pipeline:

Anonymize before sending to LLM (replace "Mario Rossi" → "[PERSON_1]")
Process with anonymized data
De-anonymize tool calls only (the reservation needs the real name)
Never log PII in plain text

Session Management

WhatsApp doesn't have "sessions" — it's just a stream of messages. We manage context with:

Sliding window: last 20 messages as context
Business context injection: CRM data, menu, pricing injected per-tenant
Cross-conversation memory: the agent remembers "last time you ordered the risotto"

Self-Hosting vs Cloud

SARA runs on a single VPS (4 vCPU, 8GB RAM):

Component	Resource
WAHA (WhatsApp Web)	~500MB RAM
Bridge service	~50MB
SARA API	~200MB
PostgreSQL + pgvector	~2GB
Total	~3GB

No GPU needed — inference is offloaded to cloud providers (Groq, etc.).

The Hardest Bugs

WhatsApp session contention — running two instances with the same number = instant logout for both. We learned this the hard way.
Date parsing across languages — "dopodomani" (Italian for "day after tomorrow") + timezone handling + business hours awareness. This alone took weeks.
Message ordering — WhatsApp doesn't guarantee delivery order. Our bridge queues and re-orders by timestamp.

Open Source

SARA is AGPL-3.0 on GitHub: github.com/Alessandro114/sara

Self-host it, extend it, build your own vertical agent on top. Cloud-only features (multi-tenant, white-label, analytics) stay in the commercial version.

The 20 industry-specific agent definitions are also open source: scala-agent-definitions (Apache-2.0).

What's Next

Proactive agents — don't wait for messages, reach out when something needs attention ("Your reservation for tonight has a conflict")
Cross-agent events — when DineOS agent sees a large booking, TravelOS agent checks nearby hotel availability
Voice — WhatsApp voice messages → STT → agent → TTS → voice reply

Running AI in production is 10% model quality and 90% engineering. Follow for more war stories.

How We Built a Universal SaaS Connector With OpenAPI + AI Agents

Alessandro Binda — Sun, 09 Aug 2026 21:09:19 +0000

Most SaaS integrations are built one at a time. Slack connector, Stripe connector, HubSpot connector — each one is weeks of custom code, OAuth flows, and webhook handling.

We took a different approach: a single OpenAPI connector that lets our AI agents talk to any SaaS with a spec file.

The Problem

Our platform (S.C.A.L.A.) serves 20 different industries — restaurants, hotels, property management, retail, and more. Each vertical needs different integrations:

Restaurants need POS + reservation systems
Hotels need PMS + channel managers
Retail needs inventory + e-commerce platforms

Building 50+ custom integrations was not an option for a bootstrapped team.

The Architecture

User prompt → AI Agent → Tool Dispatcher → OpenAPI Connector → External SaaS
                                    ↓
                            spec_url or spec_json
                            auth_type (api_key | bearer | basic | oauth2)
                            encrypted credentials (AES-256)

Step 1: Import any OpenAPI spec

Users paste a spec URL or upload JSON. We validate it, extract endpoints, and store the schema:

const createConnectorSchema = z.object({
  name: z.string().min(1).max(200),
  spec_url: z.string().url().max(2048).optional(),
  spec_json: z.record(z.string(), z.unknown()).optional(),
  auth_type: z.enum(['none', 'api_key', 'bearer', 'basic', 'oauth2']),
  auth_config: z.object({
    api_key: z.string().max(500).optional(),
    api_key_header: z.string().max(100).optional(),
    bearer_token: z.string().max(2000).optional(),
    // ... other auth types
  }).optional(),
});

Step 2: AI agent discovers available actions

When a user says "check my inventory levels", the agent:

Looks at all connected OpenAPI specs
Matches the intent to available endpoints (semantic search)
Builds the API call with correct parameters
Executes via SSRF-protected fetch

Step 3: Credentials never leave the vault

All secrets are encrypted at rest with AES-256. The connector decrypts only at call time, in-memory, never logged:

import { encryptSecret, decryptSecret } from '../lib/encryption.js';

// Store encrypted
const encrypted = encryptSecret(rawApiKey);

// Decrypt only when calling
const key = decryptSecret(encrypted);

Security: SSRF Protection

The biggest risk with a universal connector is SSRF — a malicious spec could point to internal services. We validate every URL before fetching:

import { validateUrlSSRF, safeFetch } from '../lib/ssrf.js';

// Blocks: localhost, 169.254.x.x, 10.x.x.x, internal DNS
const validated = validateUrlSSRF(targetUrl);
const response = await safeFetch(validated, { timeout: 15_000 });

Rate Limiting

Each connector gets its own rate limit bucket. We use per-key in-process limiting (1000 req/min) on top of the global IP-based limiter:

API Key → SHA-256 hash → lookup in api_keys table → scope check → rate limit bucket → execute

What This Enables

With this pattern, adding a new SaaS integration takes minutes, not weeks:

User pastes the OpenAPI spec URL
Sets auth type + credentials
The AI agent immediately knows how to use every endpoint

We've seen users connect everything from Shopify to custom ERPs — all through the same universal connector.

Lessons Learned

OpenAPI specs are inconsistent — many have wrong types, missing required fields, or incomplete auth docs. Build defensive parsing.
AI needs curated endpoints — showing the agent ALL 200 endpoints of a large API is noise. Let users pin the 5-10 they actually need.
Timeout aggressively — external APIs are slow. 15-second hard timeout prevents one bad call from blocking the agent loop.
Log everything except secrets — when debugging "why didn't the agent call Shopify correctly?", you need the full request chain minus credentials.

Try It

S.C.A.L.A. is an agentic AI platform with 20 industry-specific agents. The OpenAPI connector is available on the Scale plan.

Website: get-scala.com
Open-source WhatsApp agent: SARA on GitHub
Open-source RE feasibility agent: LandIQ on GitHub

API docs and sandbox available at get-scala.com/api-docs.

Building AI agents for real businesses, not demos. Follow for more from the trenches.

How I Built 100 Industry-Specific Website Templates and Why I'm Giving Them Away (Next.js + TypeScript)

Alessandro Binda — Sat, 08 Aug 2026 00:28:42 +0000

Last week I open-sourced a project I've been building for several months: 100 website components across 12 industry verticals, organized as a pnpm monorepo, MIT licensed, free to deploy.

GitHub: https://github.com/Alessandro114/scala-sites
Live demo: https://scala-sites.vercel.app

This post covers three things: the technical architecture decisions, the business reasoning behind giving it away, and a cost analysis that motivated the whole thing.

The Problem with Generic Templates

Every website template marketplace sells you the same thing: a generic hero component, a features grid, a testimonials section, a contact form. The assumption is that good design transfers across industries.

It doesn't.

A restaurant's website needs to answer: what's on the menu today, can I book a table right now, what do real customers say. A law firm's website needs to answer: do you handle my specific type of case, how do I get a consultation, what's your track record. A gym's website needs to answer: what classes run when, can I sign up directly, what membership costs.

These are structurally different problems. A generic <Hero> component with a title and a button doesn't solve any of them particularly well.

So I built per-vertical hero components, per-vertical JSON-LD schemas, and per-vertical component sets.

The Theming System

Rather than a global design token system, I went with three base themes and a createCustomTheme() override function:

import { createCustomTheme, themeToStyleObject } from '@scala-sites/themes'

const restaurantTheme = createCustomTheme('classic', {
  primary: '#1e3a5f',
  accent: '#c9a84c',
  background: '#fafaf8',
})

// Use in your layout:
const style = themeToStyleObject(restaurantTheme)
// Returns: { '--color-primary': '#1e3a5f', '--color-accent': '#c9a84c', ... }

The three base themes:

Minimal — white background, Inter font, subtle borders. Works for luxury brands, professional services.
Bold — dark background, Bebas Neue headings, sharp edges. Works for gyms, nightlife, automotive.
Classic — warm tones, Playfair Display serif, soft radius. Works for traditional restaurants, heritage brands, legal.

No CSS-in-JS runtime. No Tailwind config rebuild when you change a color. Pure CSS variables injected at the root. This means theme switching is a single property change, and SSR works without hydration mismatches.

JSON-LD by Vertical

The @scala-sites/core SEO package handles structured data automatically based on which vertical you're in:

dineos (restaurant) emits FoodEstablishment schema with servesCuisine, hasMenu, priceRange
legalos (law firm) emits LegalService with areaServed, knowsAbout
clinicos (medical) emits MedicalBusiness with medicalSpecialty
gymos emits SportsActivityLocation

The FAQAccordion component — shared across all verticals — always emits FAQPage schema, which Google uses to populate rich results directly in search.

The goal is that a developer using these templates doesn't need to think about structured data. It's correct by default.

Hero Architecture Decision

The most debated decision in the repo was whether to have a single parameterized <Hero> component or per-vertical hero implementations.

I went per-vertical. Here's the argument:

A restaurant hero needs: full-bleed video or image, overlay gradient, reservation CTA as primary action, menu CTA as secondary, possibly an urgency element ("booking fast this weekend").

A gym hero needs: class schedule preview above the fold, membership CTA, possibly a live class counter or next-class timer.

A law firm hero needs: practice area selector, consultation CTA, social proof counter (cases handled, years experience) — but restrained, because aggressive sales tactics read wrong in legal contexts.

These aren't just different slot content. They're different interaction models. Forcing them into one component either makes the component so generic it adds no value, or makes it so complex with conditional logic that it becomes harder to maintain than separate components.

Separate components means more code. But each component is smaller, more readable, and can evolve independently. A restaurant owner updating their hero doesn't need to understand the gym hero's class-schedule logic.

The Cost Analysis

The second thing I built is https://analyze.get-scala.com — a tool that shows what a typical SMB pays for its digital stack.

I spent a week on pricing research across every major tool category. The result for a typical 3-location restaurant, using annual billing rates:

Category	Tool	Monthly
Website builder	WordPress.com Business	$40
Email (5 users)	Google Workspace	$35
CRM	HubSpot Starter	$40
Booking	Calendly (2 seats)	$20
Live chat + AI	Tidio + Lyro	$68
WhatsApp API	2K marketing msgs	$40
SEO	SEMrush Pro	$140
Reviews	Trustpilot Starter	$99
Email marketing	Mailchimp (2K contacts)	$27
Forms	Typeform Basic	$29
Social scheduling	Buffer (3 channels)	$15
Analytics	GA4	$0
Total	14 vendors	$555/mo

That's $6,660/year. And this is the conservative version — with Intercom instead of Tidio you hit $1,500/month.

Three things I found notable in the research:

Mailchimp's free tier went from 2,000 contacts (2022) to 500 (2023) to 250 (2026). They degrade it deliberately to force upgrades.
Ahrefs raised Lite from $99 to $129 in March 2026 with no feature changes.
SiteGround intro pricing is as low as $2.99/month; renewal rates hit $17.99/month — a 6x jump that small business owners routinely don't notice until it hits.

The full pricing data (with sources) is in COST-COMPARISON-DATA.md in the repo.

Why Give It Away

My company sells an AI operating system for SMBs — real-time booking, WhatsApp automations, multi-location CRM. The website is the entry point, not the product.

The templates are free because reaching business owners early — before they've committed to a fragmented stack — is worth more than charging for templates. Give them something genuinely useful. Be present before anyone asks to see a pitch deck.

It also creates a forcing function: MIT licensed code has to be good enough to fork. That pressure is useful.

Performance

The demo app (Next.js 14, App Router, SSG) scores 97-100 on Lighthouse across all vertical pages. Static generation means zero TTFB on cached routes. The CSS variable theming adds zero runtime overhead — it's compiled at build time.

No JavaScript is required to render any template above the fold. Booking widgets and interactive components lazy-load only when scrolled into view.

Try It

GitHub: https://github.com/Alessandro114/scala-sites
Cost analyzer: https://analyze.get-scala.com
Live demo: https://scala-sites.vercel.app

Star the repo if it's useful. Open an issue if you want a vertical that's not there yet. PRs welcome — especially for industries outside the current 12.