Forem: Frédéric Geens

The Cold Start Pricing Trap

Frédéric Geens — Tue, 24 Mar 2026 16:12:53 +0000

I spent a full day building a clever pricing mechanism for my marketplace. Dynamic coefficients, maturity thresholds, progressive price increases tied to platform quality metrics. It was elegant.

Then I killed it.

Here's what I learned — and the framework that actually matters.

The gut check that started it

I'm building Callibrate, a B2B matching platform that connects businesses with AI/automation experts. The expert pays per qualified lead — a booked call with a prospect who has a confirmed budget and a scoped problem.

Our pricing grid ties lead cost to prospect budget:

Prospect budget   Lead price
────────────────  ──────────
Under 5k          €49
5k – 20k          €89
20k – 50k         €149
50k+              €229

I was reviewing this grid when a question hit me: Would I pay €89 for a single lead from a platform nobody's heard of?

Probably not.

And that's the problem. The grid was designed for steady state — a platform with proven lead quality and a 30% call-to-project conversion rate. But at launch? Zero track record. Zero conversion data. The matching engine hasn't been calibrated on real leads.

The price might be correct in theory. But would an expert trust it?

The math that should come first

Before touching the price, I needed to know: are these numbers actually defensible?

I modeled the expert's real cost to acquire one paying client at each tier under three conversion scenarios.

At 30% conversion (steady state hypothesis):

Budget tier   Price/lead   Leads to close 1   Cost per client   % of deal
───────────   ──────────   ────────────────   ───────────────   ─────────
Under 5k      €49          3.3                €163              5.4%
5k – 20k      €89          3.3                €297              2.4%
20k – 50k     €149         3.3                €497              1.4%
50k+          €229         3.3                €763              1.0%

All green. The cost-to-value ratios are excellent — well under the 5% industry threshold for B2B lead generation (standard SaaS benchmark — acquisition cost should stay below 5% of contract value at scale).

At 15% conversion (realistic launch — engine not calibrated):

Budget tier   Price/lead   Leads to close 1   Cost per client   % of deal
───────────   ──────────   ────────────────   ───────────────   ─────────
Under 5k      €49          6.7                €327              10.9% ⚠
5k – 20k      €89          6.7                €593              4.7%
20k – 50k     €149         6.7                €993              2.8%
50k+          €229         6.7                €1,527            2.0%

Still works for everything except the smallest tier. And at 8% conversion — worst case — the under-5k tier becomes painful (20% of deal value) but the larger tiers remain viable.

Then I benchmarked against how AI consultants actually acquire clients today:

Cold outbound: $200-500 per meeting (Belkins, SalesHive — B2B lead gen pricing reports 2025)
LinkedIn organic: $750-3,000 per meeting — opportunity cost at $150/h consultant rates, 5-10h/week for 2-4 meetings/month
Bark / Thumbtack: $14-100 per lead (Bark Help Center, Thumbtack Pro documentation), 1.3/5 quality rating from professionals (G2, Trustpilot 2025-2026)
B2B lead gen agencies: $100-250 per qualified lead (Sopro 2025 B2B cost-per-lead benchmarks)
Referrals: Free but completely unpredictable

A pre-qualified B2B lead with a booked call and confirmed budget, priced at €49-229? That's competitive. The math works.

So the price isn't the problem.

The clever solution I built (and killed)

Knowing the math was sound didn't resolve my gut feeling. An expert seeing "€89/lead" on an unknown platform will still hesitate. So I designed what I thought was an elegant solution.

The Platform Maturity Coefficient. Lead price would scale with the platform's proven quality:

0-50 accepted leads: price × 0.65 (35% discount)
51-200 leads: price × 0.80
201-500 leads: price × 0.90
500+ leads: full price

The idea: charge less while the platform is unproven, increase as quality is demonstrated. Transparent. Published. Tied to real metrics.

I liked it. It felt fair.

Then I stress-tested it against what the industry actually does. Five problems emerged.

1. No marketplace uses this. I checked Bark, Thumbtack, Angi, Upwork, Fiverr, Contra, Expert360. Zero use a "platform maturity" pricing mechanism. Dynamic pricing exists — based on supply/demand, job value, exclusivity. Never based on "how many leads we've successfully delivered." Novel pricing mechanisms are a risk, not an advantage.

2. It penalizes loyalty. The price goes UP as the platform improves. The more an expert uses the platform and helps it succeed, the more they pay. That's a loyalty penalty. Research is clear: customers churn when they discover others paid less for the same thing. My mechanism guaranteed it.

3. It signals weakness. An expert reads "35% discount because we haven't proven our quality yet" and hears: even they don't trust their own product. That's the opposite of the confidence signal you need at launch.

4. It creates a price cliff. Early adopters get welcome credits (part of our Founding Expert program). If those credits buy leads at one price and paid credits buy at another, one credit no longer equals one credit. Transparent pricing means stable units. My co-founder instinct caught this one: "I prefer transparency and no surprises. Credits must have the same value."

5. It's redundant. We already have a Founding Expert program that gives early adopters 300 free credits, a 20% permanent recharge bonus, and a 14-day satisfaction window where credits are restored on bad leads. The cold-start trust gap was already covered. I was adding complexity on top of a system that didn't need it.

I deleted the coefficient.

The actual insight

The pricing grid was never wrong. But I was asking the wrong question.

"Is €89 too expensive for an unproven lead?" is a pricing question. The real question is: "Does the expert trust the platform enough to find out?"

That's a trust question. And trust has different mechanisms than price.

Here's what I already had in place:

Trust gap                           Mechanism
──────────────────────────────────  ──────────────────────────────────
"What if the matching is bad?"      14-day window — credits restored
"What if I pay for nothing?"        300 free credits ($5 setup)
"Price too high for the quality?"   20% recharge bonus, for life
"How do I know this is legit?"      Published metrics + methodology
"Lead fine but doesn't convert?"    Normal pay-per-lead risk

The trust gap was already covered. Not by pricing tricks — by structural protections.

What I built instead

One thing was genuinely missing: a pre-defined plan for what to do if the data proves me wrong.

So instead of a clever pricing mechanism, I wrote a simple rule:

After 50 accepted leads: if conversion drops below 15% on any tier AND the flag rate is below 20% (meaning leads are technically fine but not converting), pause that tier, diagnose whether it's a matching problem or a pricing problem, and adjust accordingly.

That's it. No dynamic coefficients. No progressive discounts. Just: track the data, define the trigger, pre-commit to the response.

The lesson was clear. I was solving a trust problem with a pricing tool. The right tools for trust are: risk reduction (free trial leads), quality guarantees (flag window), and radical transparency (published metrics). Not discounts.

The framework, if you want to steal it

For any marketplace founder working through pricing:

Step 1: Model the expert's ROI at multiple conversion rates. Not just your optimistic hypothesis — model 30%, 15%, and 8%. If the math doesn't work at 15%, you have a real pricing problem.

Step 2: Benchmark against alternatives. Not against other marketplaces — against how your supply side currently acquires customers. If an AI consultant spends $500 and 3 weeks to land a client through cold outreach, a €89 pre-qualified lead is cheap. The anchor is their current cost, not Bark's credit price.

Step 3: Separate price from trust. If the price is defensible but adoption is uncertain, don't lower the price. Build trust mechanisms instead: free trial credits, satisfaction guarantees, transparent metrics, quality protection.

Step 4: Pre-commit your response. Write down, before launch, exactly what data would trigger a price adjustment. What conversion rate? How many leads? What diagnostic steps? You don't want to make this decision under stress.

I'm building Callibrate in public — a matching platform for AI/automation experts. If marketplace pricing and cold-start problems are your thing, I write about this stuff regularly.

Originally published on Substack.

My girlfriend banned my laptop for 6 weeks. I came back with GAAI — a governance framework for AI coding agents.

Frédéric Geens — Mon, 09 Mar 2026 01:35:41 +0000

My girlfriend banned my laptop for 6 weeks. I came back with GAAI — a governance framework that turns AI coding tools into reliable agentic systems.

39 stories. 79 decisions. 260 tests. 16,000 lines of code. 4 days.

That was day 4. Today: 32 epics, 176 stories, 177 decisions, 84,000 lines of code, no AI drifts. Same framework. Same governance. The compound interest is real.

The enforced pause is what made the results possible. Here's how.

Who I Am (Not a CV)

I'm Frédéric Geens. Belgian. Program & Operation manager by day, builder by obsession.

Ten-plus years of coding alone at night — hundreds of hours, most dropped early (fail fast, learn faster). A dozen projects started, a handful finished, almost none made it to production. Not failure. Training. The kind you don’t get from tutorials.

In 2015, I co-founded a transport company in Wallonia with a friend. I built the booking platform between rides, laptop on knees in the car. It was one of the first online booking systems for on-demand transport in the region. We ran it for five years. I handed it over in 2019. It survived COVID. It still runs today.

Somewhere in there I fell in love with SaaS. Read Rob Walling's The SaaS Playbook and something clicked: bootstrap everything, no VC, start small and stay small. Build something people need badly enough to pay for. Painkillers, not vitamins.

I'm an IT Program & Operation Manager now — 30 hours a week, remote. The rest of the time, I build. I describe myself as a Swiss Army knife: not the deepest expert in any single thing, but deeply curious, fast to learn, and obsessively focused on building things that actually solve problems.

I'm not someone who discovered "vibe coding" last month. The distinction matters for everything that follows.

The Vietnam Digital Detox (The Part That Started Everything)

My partner is my guardrail. She watches over my balance, pulls me out of the cave, forces me to live things that have nothing to do with screens. She's been watching me build project after project for years, most of them destined for the drawer. She knows when I need a break even when I don't.

So she imposed a rule before our trip to Vietnam: no laptop. Six weeks. (Jan-Feb 2026)

I agreed. I shouldn't have been surprised. I also shouldn't have been surprised at how much it bothered me, because the AI ecosystem was exploding in exactly those six weeks.

January–February 2026 was chaos. New agent frameworks going viral overnight — some shipped entire products, others wasted nine hours and got nothing. A bash one-liner that just looped AI prompts until tests passed was getting adopted by YC teams. Anthropic launched Claude Cowork with Skills; Fortune called it a threat to dozens of startups. New models every week — Opus 4.6, GPT-5.3-Codex, Sonnet 4.6, Gemini 3.1 Pro — each making last week's feel outdated. A major open-source skill registry got hit with 824 malicious packages. The creator joined OpenAI mid-crisis.

I was watching all of this from an iPhone 8 in Southeast Asia with no way to respond. Every new tool to try, every new model to test, every drama to follow — and no laptop to get pulled into any of it.

The itch was unbearable. But not having the laptop turned out to be the best thing that could have happened. Because while everyone else was chasing the shiny objects — trying B-Mad, looping Ralph Wiggum, panicking about Cowork, benchmarking whatever model dropped that week — I couldn't participate. I was forced to sit with a different question entirely. Not "how do I code faster with AI?" but "how do I make agentic coding reliable?" How do you control the beast? What happens when the agent makes a decision you didn't authorize? What happens when context is lost between sessions? What happens when you can't trace why something was built the way it was?

The hype was about speed. The question nobody was asking was about governance. And I had six weeks with nothing but a slow phone to think about it.

So instead of coding, I started thinking. From that painfully slow iPhone 8 — the kind where you watch the progress bar and go make coffee — I read scientific papers. Papers on separating reflection from execution, on context engineering, on persistent memory in agent systems, on isolation between cognitive and operational roles.

I used Google NotebookLM (Gemini 3) and ChatGPT deepsearch to condense the state of the art. NotebookLM is genuinely good at this — feed it 15 papers and a handful of forum threads and ask it to synthesize. It did the work my slow phone couldn't.

Then I used ChatGPT 5.2 to brutally challenge every idea I was forming. No complacency. I'd draft a concept, feed it to ChatGPT, and tell it to find every hole. It found plenty. That friction made the framework tighter.

Piece by piece, the architecture took shape — captured in Notion via MCP, challenged by ChatGPT, synthesized by NotebookLM, refined on a phone that could barely keep up.

There's an irony here I want to name explicitly: a governance framework for AI agents, born because a human imposed governance on the builder. The same person who gives me the energy to keep building is the one who forced the pause that made the breakthrough possible. She doesn't need a framework to keep me on track. But apparently AI agents do.

What I Built: GAAI in Four Concepts

GAAI stands for — Governed Agentic AI Infrastructure. It lives in a .gaai/ folder at the root of the project and governs every session.

4 layers:

→ Dual-Track Agentic: one agent thinks, produces epics, stories and logs the decisions trail. The other builds. Never mix.
→ Skills: execute only what the skill authorizes
→ Rules: govern them all
→ Persistent Memory: agents read yesterday's decisions before today's code

No improvisation. No drift.

Here's what each layer does:

1. Dual-Track (think ≠ do)

There are two agents, and they never mix roles. The Discovery Agent thinks: it clarifies intent, asks questions, creates artefacts, help the human in-the-loop to define what to build. The Delivery Agent executes: it reads the backlog, picks a validated story, builds it, tests it, opens a PR. An agent that discovers is never also the one that codes — like separating the architect from the construction crew.

This isn't just conceptual cleanliness. It's what prevents scope creep, rogue decisions, and the particular failure mode where an agent decides to "improve" something while building something else entirely.

2. Persistent Memory

Every session starts with loaded context. The agent knows what was decided three days ago, what the billing model is, why Cal.com was replaced, what Reddit told us about expert pricing sensitivity. Pattern: memory-retrieve runs before any action. Result: no repeated mistakes, no re-litigating decisions.

3. Decision Trail

Every non-trivial choice gets a decision log entry in DEC-NNN format. The entry records: what was decided, why, what it replaces, what it impacts. 177 decisions logged at time of writing. Each one is a future mistake prevented.

When something breaks or needs to change, you (or your Discovery Agent) open the log and find the entry. When you pivot, you (as well as the agent) know exactly what you're replacing and why.

4. Skill-Based Execution

Agents do only what their skill authorizes. No improvisation. No scope creep. The backlog authorizes execution; the skill defines how to execute. The agent reads both before touching a file. This is the constraint that makes the whole system predictable.

Here's a concrete Dual-Track example from the project: while Delivery was building the matching engine (story E06S05), Discovery was simultaneously running listening sessions on Reddit — 27 posts across 20 subreddits, non-revealing engagement. The budget data that came back from Reddit directly changed the pricing model (DEC-67). Two tracks, running in parallel, from day 1.

Here's what the folder looks like:

.gaai/
├── core/
│   ├── agents/          # Discovery, Delivery — role definitions
│   ├── skills/          # What each agent is authorized to do
│   └── contexts/rules/  # Orchestration constraints
└── project/
    ├── contexts/
    │   ├── backlog/     # Stories: the only thing that authorizes code
    │   ├── memory/      # Persistent context, loaded per session
    │   └── artefacts/   # Decisions, strategies, research
    └── ...

No magic. No custom tooling. A folder, markdown files, and constraints that Claude Code reads before touching anything.

The Test: Callibrate

I flew home to Belgium. Opened the laptop. Started the first real implementation with Claude Code under GAAI governance. The results were well beyond what I'd expected.

Not just speed. Confidence. The kind where you push to production and actually sleep afterward, because you know the agent didn't make up decisions in the dark.

But I didn't want to write about an untested framework. I needed it to hold up on something real and complex — not a toy project, not a demo. So I ran it on Callibrate.

Callibrate is an AI expert matching marketplace. Businesses with automation needs — SMBs trying to implement n8n, companies building internal AI tools, startups who need someone who actually understands their business logic — get matched with vetted AI consultants. Not LinkedIn. Not Upwork. Specialized, curated, pre-qualified on both sides. The unit of value isn't a profile view or a message. It's a booked call.

Here's what GAAI governance shipped in 4 days:

39 stories delivered, 46 total stories planned
79 decisions documented (20 active, 59 archived)
260 vitest tests passing
16,246 lines of TypeScript across 97 files
4 Cloudflare Workers: Core API, Matching Engine, PostHog Proxy, Satellite frontend
7 epics spanning auth, billing, matching, AI extraction, Google Calendar, analytics, content
4 working days (2026-02-19 to 2026-02-24)
Total API cost: $198.29 for 458 million tokens — 96.9% cache reads

That was day 4. Two and a half weeks later, the same framework has shipped 176 stories across 32 epics, documented 177 decisions, and governs 84,000 lines of TypeScript across 7 Cloudflare Workers. The governance didn't slow down — it compounded.

That last number deserves a sentence: 96.9% of all tokens were cache reads. The persistent context system meant the agents weren't regenerating knowledge from scratch every session. They were re-reading what was already established and building forward.

How I Validated the Problem Before Writing a Line of Code

The matching engine existed before anyone asked for it. That's the usual failure mode of solo builders: we fall in love with solutions before confirming problems.

The Discovery Agent ran a parallel track while Delivery was building. 27 posts across 20 subreddits. Non-revealing — the product name never appeared in any of them. Just questions, observations, engagement. Community conversations about real pain.

The posts are still getting comments weeks later.

Here's what the community actually said:

On expert lead quality: "90% of inbound is just tire kickers looking for a $50 fix." — Littlecutsie, r/n8n_ai_agents

On finding good experts as a buyer: "Took me about 3 months to find someone who actually got our specific business logic." — Present-Access-2260, r/AiForSmallBusiness

On the scarcity of real expertise: "Real workflow architects who understand business logic are maybe 10-15% of that pool." — PathStoneAnalytics, r/AiForSmallBusiness

On expert billing sophistication: "Money upfront. Card on file. Auto billing enabled." — MachadoEsq, r/gohighlevel

Zero competitors named across all 27 posts.

One anti-signal worth sharing: someone asked "Do you use AI to write all your posts or are you a bot?" — mycall, r/digitalnomad. The format was too polished. Reddit needs rougher writing. Lesson noted, applied.

The signals directly changed the architecture. Budget was the #1 filter in every expert conversation — they didn't want leads who couldn't pay. That became DEC-67: a dynamic pricing model based on declared prospect budget (€49 for sub-5k prospects, €263 for 50k+ projects). Expert time waste became the case for making the matching engine the critical path, not a nice-to-have. Expert sophistication signals — "card on file", "modular or nothing", "if they want me to build the brain inside GHL, it's a hard no" — became admissibility controls in expert profiles (DEC-80).

One quote changed the entire positioning framing: "We stopped selling 'n8n workflows' and started selling 'found time'." — Littlecutsie, r/n8n_ai_agents. Outcome-based positioning. Not what you build. What you save.

The Dual-Track proof: Discovery (Reddit) was running in parallel with Delivery (code) from day 1. By the time the matching engine was done, the pricing model and admissibility logic it runs on had already been validated by real people with real opinions.

Why Agents Need Governance

The problem isn't capability. Today's coding agents can write, test, refactor, and ship. The problem is what they do when you're not watching. They make architectural decisions you didn't authorize. They "improve" code that wasn't in scope. They forget what was decided yesterday and re-invent it differently today. They accumulate technical debt that only surfaces when you try to merge.

MCP solves tool access. It doesn't solve behavior. Governance is what fills that gap — not at the ecosystem level, but at the session level, where the actual damage happens.

Here are three concrete examples from this project:

The 19-PR disaster (DEC-71). Nineteen story branches accumulated unmerged over multiple delivery cycles. When they were finally batch-merged, cascading conflicts required three rounds of resolution — 60 conflict files, more than two hours of remediation work. The root cause: the delivery process had no mandatory merge step. Fix: one rule added to conventions.md. Every PR gets merged immediately after QA passes. Never accumulate. One process change, problem gone.

The billing pivot (DEC-68). The original billing model had structural friction — per-lead checkout with non-refundable payment processor fees. The decision trail showed exactly what depended on it. Six stories and four decision log entries later: a completely different billing architecture. Without the trail, this problem would have surfaced in production.

The Cal.com pivot (DEC-41). Cal.com closed its Platform plan — the Managed Users API needed for multi-tenant booking — to new signups on 2025-12-15. Discovered in 30 seconds via the decision trail — the dependency was logged, the impact was clear, the pivot path was obvious. Google Calendar OAuth instead. Time lost: near zero.

The memory system completes the picture. Session 1 establishes that postgres.js replaces Supabase JS for all DB queries (DEC-66). Session 2 doesn't re-evaluate it. Session 3 doesn't re-implement a Supabase client because the agent "forgot." The decision exists in memory, the agent reads it, and builds forward. Without persistent memory, every session starts from scratch — reinventing decisions, repeating mistakes, rebuilding what was already built.

What's Next

GAAI is open-source on GitHub. The framework held up on a real, complex project — four days to first proof, two and a half weeks to 176 stories. It's ready to use.

Callibrate is launching. The matching marketplace — the product GAAI built — will be live for AI experts and businesses shortly. If you're an AI consultant tired of unqualified leads, or a company that's spent months trying to find someone who actually understands your business logic, it was built for you.

This post is the first public artefact. The build log already exists — 177 decisions, 176 stories, all documented. It just needs to be made public in pieces.

Follow on X (@frederic_geens) for build-in-public updates — threads on specific governance decisions, architecture choices, and what the data actually shows.

Subscribe on Substack for the monthly milestone posts — deeper dives, less frequent, built for reading not scrolling.

If you're using Claude Code and wrestling with unstructured sessions — agents making decisions you didn't authorize, context lost between sessions, no way to understand what happened or why — the framework might be exactly what you need.

The digital detox was my partner's idea. This post exists because of her.