Bohea

A web form becomes a scored, routed lead, before you spend a credential

A small lead-capture pipeline: a form comes in, it gets enriched, scored, stored, and the team gets a clean summary in Slack. What makes it worth showing isn't the diagram. It's that the whole thing runs end to end on mock data, so the logic is proven before a single real API key, contact record, or CRM seat is touched.

n8nAutomationMock-firstLead OpsSlack / Airtable

The problem

Leads arrive from a form, and someone has to research each one, decide whether it's worth a fast reply, and get it in front of the right person before it goes cold. Done by hand it's slow and leaky: good leads wait, weak ones eat time, and nothing is logged consistently. The obvious fix is "automate it," but most buyers have been burned by automations that are a tangle of half-connected integrations nobody can trust or maintain.

The constraint: prove the logic without spending trust

Every real integration asks you to spend something up front (an API key, a paid enrichment credit, write access to a live CRM) just to find out whether the flow even works. That's exactly backwards. I build these mock-first: a stand-in enrichment server and fake data let the entire pipeline run and be watched, so you verify the behavior on evidence before wiring in anything real or billable.

How it works

Why this is my kind of problem

The value isn't the node graph. Anyone can wire boxes together. It's the engineering instinct around it: validate at the edge, make the scoring legible, keep a record that survives, and prove all of it on mock data so the client risks nothing to see it work. That "show it running before you trust it" discipline is how I de-risk every integration I take on.

Proof

A capability demo you can read and run, entirely on mock data. The sanitized pipeline is public on GitHub: the n8n workflow, the mock enrichment server, the scoring config, and a one-button demo panel that walks the three failure moments (duplicate lead, enrichment outage, unknown company) — so the logic is inspectable and runnable, not just described. This is a demonstrated capability rather than a specific client engagement; the point it proves is the method.  Code →

Where else this applies

Any "an event comes in, it needs to be enriched, judged, recorded, and someone notified" workflow: inbound leads, form intake, support triage, order or application processing, alerting. If you've been quoted a number of days for an integration you can't picture yet, I'd rather build the mock-first version first, so you watch it work before you commit.

If a machine you build needs an interface, a device connection, or data that has to land somewhere else, tell me what it's costing you now. You'll get an honest read on whether it's solvable, and usually something running to look at. Start here →

← All case studies