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.

1. In wp-admin, go to Plugins > Add New and search for BoltAudit. Activate it.
2. 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.
3. Read the report. Findings are ranked by estimated visitors recovered, with evidence and steps for each.
4. 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.