Loading homepage
← All posts
Lessons from shipping MCP servers before the demand caught up
Six strategic lessons from two quarters of unpaid R&D on MCP — pricing, positioning, and refusing to retreat to retainer work.
·10 min read·By Damon Blais
Most of what I learned shipping Model Context Protocol servers in the first six months wasn't technical. The protocol is small and the SDK is honest about its sharp edges; once you've hit the same stdio framing bug twice, you stop hitting it. The lessons that actually shaped how I work are strategic — about building tooling for a buyer pool that doesn't exist yet, pricing into a market that hasn't formed a frame of reference, and resisting the gravitational pull back toward the delivery models that paid the bills last cycle.
Shipping ahead of demand is a posture, not a product decision. It changes what you build, who you sell to, and what you refuse to sell at all. The pressure on every choice is asymmetric: you can either invest now and let the market arrive on your terms, or wait for proof and then compete on price with everyone else who waited. Both options cost. Most of the writing about this stage of a market is by people who skipped the cost column entirely, so I want to put it back in.
This is the reflective companion to the gotchas post I shipped earlier in the week. That one is about the seams in the protocol. This one is about the seams in the business of working on it before there's a business there yet. I'll go through six lessons that mattered to me, each with a generic shipping receipt and an explicit cost line, and then I'll stop. None of it is a prescription — it's what shipping early actually felt like from the inside.
The obvious risk of shipping early is premature scope: you build for a use case no one validated and then spend a quarter re-shaping it. The underweighted risk is late entry. By the time the use case is validated publicly, three other people have a server, a guide, and a Stripe link, and you're the fourth voice with the fourth pricing page. Both costs are real; the question is which one you'd rather be wrong about.
I picked early. For roughly six months I built operator tooling on top of MCP — servers, scaffolds, deployment shims, the kind of thing you only know you need once you've shipped one and watched it crash on a teammate's machine. Nobody was asking for it in a buyer-shaped way. The shape of demand was developers nodding in Discord threads, not purchase orders. I kept building because the cost of being late looked worse to me than the cost of being unpaid for two quarters.
Cost. Two quarters of unpaid R&D, no proof of revenue to point at, and a slow corrosion of the "this is a real business" feeling. I had to budget that out of pocket and not let it leak into the work. I'd do it again — the alternative is showing up with the same Stripe link and zero distinctive material — but the cost was not nothing, and anyone telling you it was is editing themselves.
SDK READMEs are correct. They are also quiet about the operational edges, because that's not their job — they're reference, not field reports. Stdout pollution, retry semantics, FD leaks under hot-reload: none of that is in the README, because none of that is the SDK's problem to document. It's the operator's problem to discover.
That gap is where written material earns trust. Not by criticizing the docs — they're fine — but by writing the thing the docs aren't there to write. Every operational paragraph that costs you an afternoon to learn is worth fifty marketing paragraphs to the next person who hits it on hour two of their own afternoon. I noticed I was getting recognized in threads not for any single piece of code but for having written down the stdio framing fix in plain language with a working snippet. The snippet is twenty lines; the trust was disproportionate.
Shipping receipt. A generic internal data MCP I worked on broke on a teammate's machine because his database driver version printed a one-line connect warning to stdout. Same code, different node_modules. Writing that story up — with the shim that fixed it — got more reach than three weeks of feature posts on the same server.
Cost. Writing into the gap means you're permanently giving away the operational frame. Some buyers read the post, copy the snippet, and never come back. That's fine. The buyer I'm writing for is the one who reads the snippet, recognizes the shape of their own afternoon, and decides they'd rather pay for the full pattern set than rebuild it. The give-away is the qualification.
A $29 intro guide and a $199 list-price playbook recruit different people. The $29 buyer is curious, time-rich, and often pre-revenue themselves; they buy because the cost of being wrong is a coffee. The $199 buyer has already shipped one MCP, hit two of the gotchas, and is calculating in afternoons saved. The spread between the two prices is not a discount strategy — it's a sorting function for who walks in the door.
I priced both deliberately. The $29 floor isn't there to maximize volume; it's there to make the no-friction read possible for the person who isn't yet sure I write anything worth their time. The $199 anchor isn't there to maximize per-unit margin; it's there to communicate that there's real operational material behind the introduction. If I had only the $199 SKU, the $29 buyer never gets in; if I had only the $29 SKU, the $199 buyer assumes I'm a hobbyist.
Cost. The $29 buyer rarely upgrades. I knew that going in and I have to keep reminding myself of it when the upgrade rate looks flat. The $29 SKU pays for itself in attention and qualification, not in conversion to the $199. Treating it as a funnel-bottom feeder will make me change it in ways that ruin both prices. Holding the line means accepting that the intro SKU is its own thing, complete in itself, and that the upgrade rate is supposed to be slow.
I refuse calls. I refuse standing Slack channels. I refuse the "quick syncs" that quietly turn a $199 product into a $2,000/month obligation. Every buyer who has asked for any of that has been politely told no, and every one of them has either bought the async product anyway or walked. The walk rate is real and it's the cost of the moat.
The reason for the refusal is not preference, even though it is also that. It's that the delivery model I learned last cycle — retainers, embedded engineering, "trusted advisor" relationships — has an economic gravity that pulls every async product toward becoming a synchronous one. The first call is free. The second is a favor. By the third, you've quietly accepted that the buyer pays for access, not output, and the entire pricing logic of the async product is undermined because every buyer now suspects there's a hidden tier where the real value lives.
There isn't one. Everything is in the written material and in the pay-per-hour install option, which is itself bounded and async-coordinated. If I hold that line on every buyer, the next buyer trusts the price page. If I make one exception, the next buyer asks for the exception.
Cost. Smaller top-line per buyer than I'd get if I added a $5K/month retainer tier. The walk rate from buyers who wanted the retainer tier and didn't get it. Some of them were good buyers and the work would have been interesting. I let them walk because the moat is worth more than any single deal.
Writing for the person who already shipped one MCP server is a smaller audience than writing for the person curious about the protocol. It also converts better, because the operator-reader has already done the calibration — they know what they don't know, and they can tell within a paragraph whether you've shipped one yourself or you're explaining a quickstart back to them.
Course-grade content optimizes for completion: short paragraphs, lots of subheads, a 5-step ladder to a working hello-world. Operator-grade content optimizes for recognition: long enough paragraphs that the reader can locate themselves, specific enough receipts that the reader can map them to their own incident log, and zero "what is MCP" framing because the reader already knows. The cost of writing operator-grade is that the courseware-shaped traffic bounces. The payoff is that the people who don't bounce are the people who buy.
Receipt. The technical gotchas post — written for someone who has already shipped a server — got fewer clicks than a tutorial would have, and a higher percentage of the people who clicked stayed on the page long enough to reach the buy link at the bottom. I can see the depth-of-scroll difference in the analytics. The smaller audience pre-qualified itself by clicking through a title that promised production-edge material, not introduction.
Cost. Smaller addressable market by design. I will not show up in beginner roundups, because I'm not writing for beginners. I have to make peace with the SEO consequence and accept that the discovery path is "you already shipped one and someone you trust mentioned me", not "you searched for what is MCP."
The conventional advice is to launch with social proof. Three testimonials, two case studies, a logo strip. I launched with none of those, because the alternative was to fabricate them — to call a friend, ask for a quote, dress up an unpaid pilot as a paid engagement. I'd rather launch quietly than launch with manufactured proof. Manufactured proof reads as manufactured to the exact buyer I'm trying to reach, who has seen a hundred fake testimonials and developed an immune response.
The launch landed flat by quiet-room standards. A handful of clicks, a slower second day, one purchase by end of week. That was the right shape of result for the inputs. The buyers who arrived arrived because the writing was specific, not because someone they didn't know vouched for me. Week two and three will compound from there or they won't, and the answer to that question is in the work, not in the launch-day metrics.
Cost. A launch that did not crack any algorithmic threshold and a second week that has to do its own lifting without a viral assist. The opportunity cost of not having three friendly testimonials ready to go is real — that path would have gotten me a louder launch day. The trade is a quieter launch that doesn't have a credibility-laundering layer to defend in month three when someone asks who those testimonial people actually were.
None of this is a victory lap. Half of these lessons cost me revenue I could have had if I'd run the other play, and the other half are unfalsifiable until the market either arrives or doesn't. I am writing them down because the strategic side of shipping early gets less honest treatment than the technical side, and because the cost columns matter more than the payoff columns when you're deciding whether to do this yourself.
If you're at the stage of the gap I was at six months ago — working infra, no buyers yet — the operational instantiation of these lessons is the material at https://albinogeek.com/#offers. The intro guide is the cheapest way to read the rest of the pattern set; the pay-per-hour install is the bounded way to put one in your stack without the retainer creep this essay was partly written to resist.
