How I shipped a $5k/mo consulting funnel in one hour
Most personal sites end with a mailto: link and a sentence that says "available for select engagements." The buyer drafts an email, hesitates over the price they don't know, and closes the tab. Conversions: zero.
I replaced the mailto: with three productized offers at public prices.
Each one is bookable with a USDC deposit on Base via x402.
Buying the engagement now costs the same number of clicks as buying a coffee.
It took an hour. The whole thing is 550 lines of code.
The three offers
/services lists three:
Agent-Ready Audit — $1,500 flat. 48-hour async. Written report on MCP exposure, agent discoverability, x402 readiness, and bot policy. One pull request with the smallest change that moves the needle.
x402 Integration Sprint — $2,500 flat. One week. x402 middleware wired into your stack, one MCP tool wrapping your API, smoke tests, recorded walkthrough.
Senior Agent-Infra Retainer — $5,000/month. Two-month minimum. Three async consults per week, code review on any PR touching agent infra, one architecture note per month.
Deposits are $150, $250, and $500 — one tenth of the headline price. They're credited toward the first invoice and refundable if I decline the work.
Why deposits
A free intro call is a coin flip.
The deposit screens out tire-kickers.
Someone who pays $150 in USDC to audit their repo is going to take the call seriously.
Someone who won't part with $150 was never going to send the contract.
I learned this from the $50 consult filter pattern other indie consultants use to filter inbound, and from running a $0.
10 USDC paywall on the skills marketplace.
Same principle, two orders of magnitude up: the price moves the conversation from "you should pitch me" to "I've already paid, what's the scope."
The code is boring
The full funnel is four files:
src/pages/services.astro — the listing page (308 lines, mostly copy and CSS).
src/pages/services/sprint/book.ts — 34 lines.
src/pages/services/audit/book.ts — 33 lines.
src/pages/services/retainer/book.ts — 34 lines.
src/lib/service-booking.ts — 141 lines, shared by all three booking endpoints.
Each route file is a thin wrapper. Here's the entire sprint/book.ts:
That's the whole file. The shared helper does three things:
1.
Calls x402.
enforce() with the deposit price.
If the request doesn't have a payment header, the helper returns the 402 challenge and the agent's x402 client settles automatically.
Humans hit a payment page.
2.
On payment success, logs the purchase to D1 and writes a flagged row into contact_messages so the booking shows up in the admin inbox within seconds.
3.
Returns a confirmation HTML page with a booking token, the deposit amount, the credited total, and what happens next.
No account system.
No Stripe webhook.
No queue.
No email service.
The booking is one HTTP round-trip with a payment in the middle, and the side effect is a row in the inbox I already check every morning.
Why USDC on Base, not Stripe
Three reasons.
I'm an unbanked founder. Stripe wants a US bank account in good standing. USDC wants a wallet address. The wallet is faster to provision.
Settlement is instant. The deposit lands in my hardware wallet (0x0E4d...1028) before the buyer sees the confirmation page. There's no two-day hold, no chargeback window, no payout schedule.
It's the same payment rail I already accept on the skills marketplace.
One wallet, one network, one currency.
An agent that bought a $0.
10 skill from me yesterday can book a $5,000 retainer today with the same client.
For a buyer who wants a fiat invoice, I can arrange one through a partner. The default is USDC because the default is what most agent-shaped buyers will use.
The same rail for agents and humans
The booking endpoints are not bot-only.
An agent operating on behalf of a CTO can call GET /services/sprint/book with an x402 payment header, settle the deposit, and receive the confirmation HTML — same flow as a human clicking the link.
The booking token returned in the response is the receipt the agent hands back to its principal.
I haven't seen this happen yet. The market for agent-purchased professional services is roughly empty. But the surface is built, the price is public, and the protocol is the same one Claude Code already speaks.
What's at risk
Honest pricing signal: zero purchases at the time of writing.
The blog is eight days old.
The /services page launched yesterday.
The funnel is live and the booking flow is verified end-to-end on Base mainnet, but no one has paid for anything yet.
This post is the first time the URL has been linked outside the site itself.
Three things have to be true for this to convert:
1.
The traffic has to find the page.
I'm relying on inbound from posts, the footer, /hire, and direct shares.
No paid acquisition.
2.
A reader has to recognize the offers as a fit.
The audience is senior eng, CTOs, and founders at Seed–Series B AI startups who want x402/MCP/agent infra and don't have the in-house time.
That audience exists.
I haven't proven they read this blog.
3.
The crypto-native deposit has to not be a blocker.
If half the buyers I'd otherwise close on bounce off the wallet step, the funnel needs a fiat fallback.
I'll know in a month.
If none of the above turn out true, I rip out the productized offers and go back to a mailto:.
The cost of running this experiment is one hour of code and a half-day of writing.
The cost of being wrong is the same as the cost of being right and ignored: nothing.
What to do with this
If you're building agent infra and want a pair of senior eyes on it, /services has the three ways to hire me.
Pricing is public.
Deposits are USDC.
The deposit is credited if we proceed and refunded if I decline.
If you're not sure your site is ready for agents at all, the free agent-readiness check at /tools/agent-readiness gives you the same scoring rubric I use on the audit, run on your URL with no paywall.
If you want to copy the funnel, the source is at github.com/integrate-your-mind/mondello-dev. It's four files. Steal it.