We got 50 paid users, then learned that building the tool wasn’t enough

Good catch, that line was inconsistent, since existing buyers don't have a "willingness to pay" question at all if it's free for them. Let me fix it:

---

Finding the next buyers, clearly, not onboarding or support. The thing that actually broke was the search channel itself, the Google spam update hit right as things were working, and that's specifically a distribution failure, not a product or support one. Onboarding and support load were never the bottleneck, the tool is simple enough that neither became a real problem at any point.

On the "automate only what repeats" framing, that's closer to what's already happened than not, and more tested than I made it sound. ShardDesign and Guardrails didn't come from brainstorming features, they came from the same two requests repeating across customers, plus I actually went and tested the alternative explanation before building anything: pointed people toward Claude SEO, free, 17k stars on GitHub, and separately asked if they'd pay for an established paid tool instead. Both got rejected for the identical reason, not price, not missing features, just not wanting a recurring subscription. That's a specific, repeatable signal, not vague interest.

One correction to my own point there, existing customers don't actually have a willingness-to-pay question, everyone who already bought ShardStitch gets the full bundle free. The real test, per your actual point, is new customers, whether someone who's never bought ShardStitch would pay $49 for everything or $29 for just the design and guardrail piece on its own. That's the freeze-and-verify step I still owe, not the existing base.

Oops, pasted a messy draft in there by accident, the "Good catch..." bit and the "---" weren't meant to be public. The actual reply is everything after that.

Also, no sleep last night and replying to everyone here, turns out support load wasn't zero after all, it just moved from the product to this thread 😃

That's exactly it, and probably a sharper version of the point than mine. The sitemap lastmod thing was a small case of the same failure, the content changed but nothing downstream knew it had. A function four versions behind the repo, or a provider failing silently for two weeks, is the same shape at a much higher cost. Checking the deployed result instead of trusting the source is basically the whole argument for Guardrails in one sentence.

I checked the actual compliance report rather than going from memory. It was both, but weighted much more toward a cluster-wide pattern than a few isolated page pairs.

The bigger issue was shared text. About 96 of 190 pages had identical paragraphs, FAQ blocks and closing sections across /tools/, /guides/, /painpoints/, /compare/ and /features/, often with little more than the tool or competitor name changed.

So this wasn't just pages having vaguely similar titles or intent. We could measure the repeated content using sentence-shingle/Jaccard overlap.

Separately, there were three genuinely redundant page pairs. Two pages around the same Windsurf issue, two around the same Aider issue, and two around the same Copilot issue. In each case one was close to a copy of the other and they were effectively addressing the same query.

We fixed both types and re-verified the pages live. For those three pairs, we didn't simply merge them. We rewrote them so each page had a narrower, distinct claim and disclosed where they shared the same underlying source.

One interesting thing the report also caught was that, as of Sept 29, the sitemap lastmod values for the rewritten pages were still showing their old August dates. So even though the pages had changed, the sitemap wasn't communicating that freshness yet.

That last part is actually a good example of why I'm interested in Guardrails. Fixing the content is one thing. Verifying all the surrounding state after the change is another.

Thanks, appreciate it

Thanks, that part never gets easier

I think the trust problem is real.

Personally, I'd prefer the short report first with no call required.

If a free audit tells me "your SEO score is 62," I still don't really know what that means. If it shows me two actual pages, explains why they may overlap, points to the evidence, and tells me what is certain versus what is an interpretation, you've already given me something useful before asking for anything.

That's actually influencing how we're thinking about Guardrails too. I don't want another big score that pretends to know more than it does. I'd rather show the finding, evidence, uncertainty and possible action.

Then if the person wants help understanding or fixing it, the 15-minute walkthrough has a reason to exist.

The repeat problem became much clearer after people started using ShardStitch for website projects.

A surprisingly common thing was that they had already built something with AI that worked, then needed a tiny change: a font, footer, image, price, spacing or some copy.

Sometimes that tiny change took another 5 to 10 prompts, but the bigger issue wasn't the prompt count. It was: "I already have something that works. I don't want the AI to break it just to make this change."

That connected directly back to why I built ShardStitch in the first place. Missing context makes an AI fill in gaps with something plausible, and plausible isn't necessarily consistent with everything the project already learned.

ShardDesign came from giving the human direct control over those small changes instead.

Guardrails came from a related version of the same fear. Some customers had website/search-quality problems but didn't want to put a working site back through another agentic workflow just to diagnose or fix them. Our own search problems later reinforced that.

So the repeat signal I'm paying attention to isn't really "users want SEO" or "users want a visual editor."

It's that people are comfortable letting AI build a lot, but become much more cautious once they have something valuable that already works.

We kept marketing at zero on purpose for the first run, specifically to test whether someone with the problem could search their way to us and pay without any push from us. That worked, strangers found it and paid through search. What it didn't prove is whether that path is resilient or repeatable, which is the thing I'm actually still testing now.

The biggest lesson was about keeping context alive. Every time we jumped between AI tools (Antigravity, Codex, Claude), the project “memory” reset and we ended up revisiting problems we’d already solved – like Jurassic Park’s missing DNA being filled with guesswork. That insight directly inspired ShardStitch (which preserves that history) and later ShardDesign/Guardrails (which address the related fears users have). In short, each new feature we’ve planned came from real user pain points – not just an idea in isolation. We always ask: does this fix something our first users actually struggled with?

Good point, WhatsApp's not something we've tested yet

Appreciate that. Good luck with the habit problem too, sounds harder than mine.

That line might be the simplest version of what we're trying to build into Guardrails. A score can be wrong in a way that still sounds confident. A real person asking whether a page actually helps them is harder to fake.

Good point, and I don't have that number yet since we never tracked signups by channel this cleanly. Something to fix before trusting any one channel going forward.

Fair push back. Same answer as above, marketing was zero on purpose so search did the work, and it worked once. Asking the 50 what they'd pay for next is a good idea and I haven't done it yet. Going to do that before building more.

I guess I should have kept the title of this post as "50 users without marketing and pure product infrastructure that should have been appropriate :D

Strong point. I'd add: ask the 50 buyers what they searched or asked for before they found you. That tells you which pages deserve the repair work. I'm trying to answer this for my own product too, since we have traffic but no sign-ups. Would you tackle the offer first or the channel first?

Mainly a cluster, not every page. some pages had near identical paragraphs and FAQ blocks across several sections, just the tool or competitor name swapped. On top of that, three pairs of pages were built around the exact same bug citation. So it was concentrated, not sitewide. On merge versus rewrite, we went with rewrite and disclosure for those three pairs since they weren't full duplicates, just narrow enough to compete with each other.

Same shape here even though the story's different. The checklist before every release point matches what we landed on too. The thing that holds up is the boring repeatable check, not a one time audit.

Yes, most likely. We kept marketing at zero on purpose for the first run so search was effectively the only path in, and it worked well enough to prove strangers could find and pay. What I haven't proven yet is whether that channel holds up long term. That's the open question now, not whether it worked once.

The distinction that helped me was tagging every source and checking what happened 48 hours later, not just the launch-day spike. Small niche directories and founder communities beat broad boards for me — slower, but the questions had context. I now add one tiny channel check to the weekly launch review so I don’t drift back to vanity traffic.

The interesting part is that we deliberately kept marketing at zero for the first experiment.

We wanted to know whether someone who genuinely had the problem could search for a solution, eventually find ShardStitch, understand what it did and pay $49 without us pushing it through ads or campaigns.

Our hypothesis was that a casual searcher might stop at the first few results or an AI summary, while someone with a real unresolved problem may keep digging through page 2, 3, 4 and further until they find something that actually solves it.

That worked well enough to prove strangers could discover the product and pay.

What it didn't prove was whether that one discovery path was resilient or scalable.

So I don't really have a "this channel finally moved the needle after the first 50" answer yet. The bigger lesson for me was that we validated willingness to pay much better than we validated distribution resilience.

Now I'm treating "where do the next 50 come from?" as a separate experiment rather than assuming the first funnel will keep working.

No marketing, on purpose. The idea was to see if someone with the actual problem could search their way to the product and pay without us pushing it anywhere. That worked for the first 50, but I'm not sure yet it keeps working, so that's the thing I'm testing now.

A useful way to unpack the first 50 is to separate “who paid” from “where they came from”: tag each buyer by channel, trigger, and first successful use. The channel that produced the first handful may not be repeatable, and that distinction seems central to the distribution lesson here.

We realized some issues can be tested or fixed automatically, while others can’t. For example, a missing canonical tag or a broken internal link is a straightforward bug , our tool can highlight or even fix it outright. But things like “two pages have the same intent” or repeated wording are judgment calls. For those, we plan to flag them with a warning and the evidence, not outright block. In practice, we’d show a PASS/WARN result: “Here’s the text overlap we detected – take a look and adjust if needed.” This way we avoid false alarms and keep trust with the user.

Treat it like a failing test. Write two or three checks that block a release (every page has a unique title, no two pages target the same query, each page answers something the previous one doesn't) and run them the way you run lint. Overlapping content and near-identical titles are exactly the kind of thing a cheap pre-publish check catches.

This distinction is important.

The 50 paying users validated ShardStitch and willingness to pay for the context problem. I don't think that automatically validates ShardDesign or Guardrails commercially.

Guardrails also didn't come purely from our own search repair.

Some customers were already running into website/search-quality problems. I initially pointed a few toward existing AI SEO workflows, but some didn't want to hand a working site back to another agentic tool because the thing they were worried about was breaking what already worked. They also weren't particularly interested in adding another monthly SEO subscription.

Then our own search problems happened and I got to experience another side of that problem firsthand.

So customer experience created the signal, and our own experience made the shape of the problem much clearer.

What still needs validating is whether people will actually pay for the solution. I'm trying to keep "we've seen this problem repeatedly" separate from "we have a commercially validated product."

This actually goes back further than the 50 users.

ShardStitch started from a hardware project. I was trying to keep an old APC UPS useful without spending $300 to $500 on a network card. My background is hardware with a lot of Python and HTML, so the part I primarily wanted AI help with was the UI/UX.

I started with Antigravity because I had Gemini credits, moved to Codex because I found it better for the UI, and later thought: can Claude just handle all of this? Maybe I wasted time moving between tools.

That experiment exposed the real problem.

Claude didn't know everything we'd already learned. Neither did the next AI when I switched tools. They kept confidently suggesting APCUPSD and NUT because those are perfectly reasonable solutions for an APC UPS, except we'd already tested them and they didn't work with our setup because the handshake wasn't happening.

I started thinking about it like Jurassic Park. When part of the DNA is missing, they fill the gaps with something that seems reasonable, but the result isn't necessarily what you intended.

AI does something similar when project history is missing. It fills the gap with the most plausible solution it knows, even when your project spent 20 iterations proving why that solution doesn't work.

That's what became ShardStitch and Bedrock. I wanted the project itself to remember the facts, failed approaches, decisions, constraints and why those decisions were made, regardless of which AI I used next.

Then customers showed us the same problem from another angle.

A lot were website builders. AI helped them build something they liked, but changing a font, footer, image or price could take another 5 to 10 prompts, and the bigger fear was the AI breaking something that already worked. That's where ShardDesign came from.

Some of those users also wanted basic website and search guardrails, but didn't want to hand the site back to another agentic workflow or pay another monthly SEO subscription. Our own search problems later reinforced what they were already telling us. That's where Guardrails came from.

So I don't really see it as context transfer + visual editing + SEO.

The common thread is control over AI-built work.

ShardStitch preserves the context. ShardDesign gives you direct control over the result. Guardrails is intended to verify and constrain what the AI changes.

The 50 buyers validated ShardStitch commercially. ShardDesign and Guardrails have customer-problem evidence, but they still have to earn their own commercial validation.

I like the "same PR" framing because one thing I learned from ShardStitch is that rules are much more useful when they travel with the work rather than depending on someone remembering to check them later.

The audit also changed how I'd implement this though.

Some checks are deterministic. Broken canonical, accidental noindex, duplicate title, broken internal link, sitemap problem. Those can behave much more like normal tests.

Others are judgment calls. Two pages may have similar intent without actually being duplicates. Repeated structure isn't automatically a problem either.

So I'm leaning toward something closer to PASS / WARN / BLOCK.

PASS for things we can verify. WARN when there's evidence of a possible conflict and show the pages and why. BLOCK only for a small number of high-impact changes where we really want human approval.

The thing I don't want is a tool confidently saying "SEO problem detected" when what it really has is evidence that deserves a human look.

That's probably the biggest lesson I took from doing the repair manually.

Same wall, almost exactly. The publish-checklist discipline you're describing, one clear page per job, unique titles, nothing new goes live unchecked, is close to what's shaping the guardrail side of this too. Slower shipping is the honest tradeoff, but it beats doing the audit twice.

The "log which edits get undone most" idea is a good one, genuinely better than guessing which guardrail matters first. I'd want to keep that logging local and visible to the person using it rather than something that phones home, since zero telemetry is a real commitment here, not just a pitch line, but tracking it locally as a signal is worth building in from the start.

On your actual question, non-technical founders and people newer to agentic coding, not daily prompters. That's who's actually been asking for this, mostly solo builders and small teams who got a site built with an AI tool and are now afraid to touch it themselves for a font or footer change. Someone who already prompts daily and is comfortable with it probably doesn't need this as much, they'd just prompt the change and move on.

Slight correction to my own framing there, it wasn't really a single-channel risk, it was a deliberate filter. In the AI-answer era, Google often satisfies a casual searcher with a snippet right on page one, so if someone's still digging into page two or three, that depth itself is a signal they're genuinely stuck, not just browsing. Every page on the site is tool-specific with its own buy function, so when someone buys from, say, the Codex or Roo page specifically, that tells us exactly which problem they had, not just that they bought something. Paid marketing would have worked against this, it pulls in people who buy because they can swipe a card, not because they need the thing, which would've corrupted the one signal I actually wanted clean.

On your actual question: existing customers won't have to answer it, we're giving ShardDesign and Guardrails free to everyone who already paid for ShardStitch, no matter which price they originally paid. What they've told us, in their own words, is they want the simplicity of ShardStitch applied to small edits, fixing a font, a header, a footer, without the whack-a-mole loop of fixing one thing with a prompt and breaking another, and a guardrail that checks their site against existing Google and Bing guidelines while also watching for the newest update, so they don't lose traffic they didn't see coming.

Worth being clear about what this actually is though: ShardStitch is the product that's already validated, it's getting real paying customers on its own. ShardDesign and Guardrails are an add-on meant to sharpen that product, not a pivot into something new. Same pricing philosophy as ShardStitch too, pay once and use forever, no subscription, so the real open question isn't whether the roadmap makes sense, it's narrower than that, whether a brand-new customer would pay $29 once for the add-on alone. That's the actual test, and I'd rather run it than guess the answer here

That's a good, specific warning, and it tracks with what happened on my side too. Batching a page-by-page fix feels efficient in the moment, but if you don't pace it, you end up re-touching pages you already fixed once something upstream changes. One page a day sounds slow until you compare it to doing the same page twice.