We accidentally sold our beta, and that is what forced us to ship v1
We never meant to sell the beta. No launch, no ads, no community post, not even a tweet. The plan was to leave a rough version of our WordPress speed audit plugin in the plugin directory, see whether anyone found it on their own, then take our time finishing the real thing.
People found it. Then they upgraded to paid plans on a product that was visibly unfinished, and that accident is what put v1 on WordPress.org three weeks early, with a working feature deliberately removed from it.
Here is how the accident happened, what it cost, and the repositioning underneath it all. I run product marketing and GTM on BoltAudit, working directly with the founder, so most of the decisions I am about to criticize are mine.
Last updated: 3 September 2026.
What is BoltAudit?
BoltAudit is a free, read-only WordPress speed audit plugin that names the specific plugin, query, asset, or database table making your site slow, then gives you the measured evidence and ordered steps to fix each one.
It never writes to your site. Finding the work is the product. Doing the work stays your decision.
That sentence took months to arrive at, and the beta is what dragged us to it.
How do you sell a beta by accident?
You attach the commercial machinery to a draft and then forget that you did.
We did not run a launch. What we did do, without ever calling it selling, was ship the beta with a pricing page live, an upgrade path wired up, and paid tiers visible inside the plugin. Then we published a glimpse of the redesigned UI and the roadmap. That was meant as a progress note. It functioned as a sales page.
Installs climbed past 100 with zero spend. People landed on the site, saw the screenshots, tried the free version, and a healthy share of them upgraded. I am not putting a conversion number on it this early, but it was high enough that we stopped treating the paid tier as a future problem.
If you leave a price on a draft, you have shipped. Not metaphorically. Someone's card was charged, and what they received was our unfinished work.
What happens when people pay for an unfinished product?
Paying customers on a beta feel like validation for about a day, and then the arithmetic changes on you.
Every week we sat on the finished build, the people who had already paid kept using the rough one. Waiting stopped being caution and turned into a disservice. The gap between what existed and what they needed was evidently already small enough to charge for, which means it was small enough to close.
So we pushed. Late nights, cut scope where we could, held the line where it mattered.
Why did we remove a working feature from v1?
Because it could write to a stranger's production database and could not reliably undo it.
Earlier versions applied fixes for you. One click and the cache cleared, revisions purged, transients gone. People used it. It was the most demo-friendly thing we had. We took it out anyway.
The apply actions worked, but they had no preview, no automatic backup, and no one-click revert on every change. A tool that changes a live site without those three things is a liability wearing a feature's clothes. We removed the routes on the server rather than hiding the buttons, because hiding a button leaves the endpoint behind it live.
Two rules came out of that:
Rule 1: Do not strand the people who already used it. Rollback for anything applied under an earlier version still runs. Every fix applied under an old version was promised a way back, and withdrawing the feature is not a reason to break that promise.
Rule 2: Ship the honest smaller product. v1 finds, ranks, and explains the work. That is a complete sentence. "Finds the work and half-does it, with no undo" is not.
Who actually buys a WordPress audit plugin?
Not the developer. Site owners, marketers, and agency leads make the purchase decision most of the time, and that single fact reshaped the entire product.
Before I joined, a designer had already delivered the full product and website design. The craft was genuinely good. But everything was built for developers: dense technical terminology, no visuals, a story only an engineer could follow. So I asked the question the design had skipped, and the answer was that the product was speaking fluently to an audience that would never buy it.
That is also the real reason a draft sold at all. By then, the perspective had changed everywhere except the feature set: the positioning, the content, and eventually the product's design. I built a sample UI from the end customer's point of view for the founder to brief his designer with. He handed me the whole product and website design instead.
Positioning, product UI, website, and content, all from one buyer's perspective. Some subscribers say outright that they bought because of how it looks and how it works.
5 design rules for selling a technical tool to a non-technical buyer
1. Name the thing, do not score it. Most speed plugins hand you a number and a checklist. Ours says: a plugin not updated since 2019, 41 images above the fold totaling 4.2 MB, 12,438 post revisions in your database. A score is a feeling. A named object is a task.
2. Rank by what the user recovers, not by technical severity. Findings are ordered by estimated visitors recovered. A developer sorts by severity. A site owner sorts by money.
3. Show the evidence under every claim. Each finding carries its measurement in copyable rows. Trust in an audit tool is built by being auditable yourself.
4. Label estimates as estimates, everywhere. Every visitor-loss figure comes from published abandonment research mapped against measured load times, and it says so each time it appears. When the engine cannot produce a defensible number, it says estimate unavailable instead of inventing one. The full method is public at boltaudit.com/methodology.
5. Make the safety property structural, not a promise in the copy. The free audit makes no outbound request, and the plugin enforces that with a request filter rather than a sentence on a landing page.
How do you run a free WordPress speed audit?
Install the plugin, open Tools, and run a Local Audit. It takes about three minutes and needs no account.
- In wp-admin, go to Plugins > Add New and search for BoltAudit. Activate it.
- Open Tools > BoltAudit and hit Run. That is the Local Audit: no account, no credit card, no trial clock, unlimited sites. It runs in PHP on your own server, and nothing leaves your site.
- Read the report. Findings are ranked by estimated visitors recovered, with evidence and steps for each.
- Optional: connect a free account for the AI Audit, which reloads credits weekly on every plan, including the free one.
Plugin: wordpress.org/plugins/boltaudit
The pre-promotion numbers
- 100+ active installs, from the directory alone
- 4.6 stars across 9 reviews
- $0 spent on ads or promotion, not even a community post
- Paying subscribers arriving through referrals plus organic and AI search only, with no paid acquisition at any point
Small numbers. I am posting them because pre-promotion numbers are the only honest kind, and every launch report I have learned anything from was written before the graph got interesting.
The SEO and AEO visibility engine is the second engine, still in development and deliberately not in this release. The apply engine returns when preview, backup, and revert are done properly. Both are on the public roadmap.
What I would tell another founder
A price on a beta is a launch, whether you call it one or not. We got a real launch without meaning to, which means we also skipped the preparation that normally goes with one.
Paying users on a beta are a deadline, not a compliment. They are telling you the remaining gap is already small enough to charge for.
Find out who signs off on the purchase before you write a line of copy. We built for the person who evaluates the tool, not the person who buys it, and that six-inch miss cost us months.
Removing a feature is a positioning decision. Cutting the apply engine forced us to say what BoltAudit actually is. The product got clearer the moment it got smaller.
FAQ
Should you charge for a beta?
Only if you are prepared to treat every purchase as a shipping deadline. Charging converts interest into obligation. That is useful when the remaining gap is weeks, and damaging when it is quarters.
Is it bad to remove a feature before launch?
Not if the feature carries risk it cannot undo. Removing an apply-fixes engine that lacked preview, backup, and revert made v1 smaller and much easier to explain. Users forgave it because rollback for anything already applied kept working.
How do you find what is slowing down a WordPress site?
Run an audit that names specific objects rather than returning a score. BoltAudit scans plugins, database, assets, and server environment in one pass and reports the individual items responsible, with the measurement behind each one.
Does a WordPress speed audit plugin need an account?
Not for a local scan. BoltAudit's Local Audit runs entirely on your own server with no account, no credit card, and no outbound requests. Only the cloud-based AI Audit requires a free account.
How do you market a developer tool to non-developers?
Identify who signs the purchase, then carry that person's perspective through every surface: positioning, product UI, website, and content. Messaging alone will not fix a product that is designed for a different reader.
The ask
I would rather have real feedback than upvotes. If you install it, tell me what is broken, what is confusing, what is missing. I want to build the product you need, not the product we are selling.
And a question for the room: Have you ever taken money on something you considered unfinished? Did it speed you up, or did it lock in decisions you were not ready to make?
Written by AKM Aminul Islam, product marketing and GTM for SaaS and WordPress. I am on LinkedIn if you want to argue with any of this.
We recently learned a similar lesson in stream setup. We used to force creators to choose a destination before they could even create a stream. Removing that requirement looked like a tiny product change. In practice it separated planning a broadcast from connecting channels, which are two different jobs. Your apply feature is obviously much riskier, but the effect is similar. The product gets easier to explain once it stops pretending those two jobs belong together.
That is a cleaner version of the same idea than mine, because yours had no risk
attached to it. You removed a requirement and the product still got easier to
explain, which means the clarity came from separating the two jobs, not from
avoiding danger.
Mine had the safety argument doing half the work, so I never had to test whether
the cut was right on its own. Yours did.
Picking a destination before you have planned the broadcast is a good example.
The order was wrong, not the feature.
I think the most useful thing in your post is not that the beta sold. It’s that you now have several different signals with very different evidentiary strength.
An install says the problem is interesting.
Keeping the plugin installed says the user trusts it enough to stay in the workflow.
Coming back says the job repeats.
Paying says the remaining gap is small enough to tolerate.
I’d separate those signals before the next roadmap decision.
For every paid account, I’d track:
first audit → specific finding acted on → return for another audit → continued install → renewal or continued payment.
Then compare that against free users.
That would tell you whether people are paying because the positioning is strong, because the audit produces a repeated operational job, or because the current paid tier simply looked worth trying once.
I also think removing the apply engine was the right kind of cut. A feature that changes production state without reliable preview, backup and revert creates a different product risk than a read-only diagnostic. I wouldn’t put it back just because users liked the demo.
The two numbers I’d want before deciding what deserves the next build cycle: how many paying users have run more than one audit, and how many have actually acted on a finding and then returned for another one?
This is the most useful comment on the thread. You are right that I collapsed
four different signals into one story, and the four say very different things.
The two numbers you named are the ones I do not have yet: how many paying users
ran more than one audit, and how many acted on a finding and came back for
another. Right now I can see installs, upgrades and reviews, which tells me the
first audit landed and nothing about whether the job repeats.
That distinction matters more for us than for most tools, because a speed audit
could easily be a once-a-quarter job rather than a workflow. If it turns out
people pay once and never return, the answer is not more findings. It is
monitoring, so the product has a reason to exist between audits.
I am setting up the funnel you described before the next roadmap decision. And
agreed on the apply engine. Liking the demo is not evidence that the risk is
acceptable.
The money signal part hits hard. We collected months of polite "looks promising" feedback and it changed nothing, because polite feedback has no cost attached. What actually moved our roadmap was one early user coming back three times in a week — repeat behavior is the closest thing to payment before you have payments. And respect for pulling a working feature over liability concerns. Most teams ship the liability and call it momentum.
That line about repeat behavior is better than anything in my post. Saving it.
I think polite feedback goes nowhere because saying "looks promising" costs the person nothing. Coming back a second time costs them attention. Keeping the plugin installed costs them trust. Paying costs them money. Those are the only three signals I look at now.
On cutting the feature, I would like to say it was principle. It was really one thought I could not get rid of: someone's checkout breaks overnight, there is no undo button, and I find out from a one-star review the next morning. That settled it faster than any of my own arguments.
How did you spot the user who came back three times? Were you watching for that, or did you just notice it?