About
A solo-built plugin, built in the open.
AcceleratorWP is one developer, building a structural performance layer for WordPress out of Istanbul. It is in active beta — paying testers, real production sites, public feedback. This page is who I am, what I'm building, and where it's going.
Founder & developer
Sarp Efe
Building AcceleratorWP solo since 2025 · Istanbul
I started AcceleratorWP because I kept hitting the same WordPress ceiling on different projects: every active plugin loads on every single request, regardless of whether the URL needs it. Page caching helps when the cache hits. Cart, checkout, admin-ajax, REST endpoints, logged-in views — none of those hit the cache.
So instead of another cache plugin, I wrote a mu-plugin that boots before the normal plugin set and asks one question per request: which of these plugins does this URL actually use? The rest are skipped for that request.
That single mechanism is the spine. Around it I built a module registry, kill switches, self-tests, shadow mode, telemetry — so that nothing changes behavior without being measured, and nothing measured stays on if it makes the site worse.
Where
Istanbul, Türkiye
One developer, one inbox, GMT+3 hours.
Stage
Active beta — public roadmap
Real testers on real WooCommerce stores. Changelog is always honest about what just shipped.
Contact
hello@acceleratorwp.com
Every email lands in my inbox. Usually replied same day.
Timeline
How we got here
AcceleratorWP didn't start as a product. It started as a workaround. Each step below is the moment it stopped being one thing and started being the next.
Early 2025
First lines of code
Started as a personal mu-plugin to stop a single WooCommerce site loading every plugin on every wc-ajax call. The trick worked — what took two seconds dropped under one. The idea grew from there.
Mid 2025
Module architecture
Rewrote the prototype into a registry of independent modules — each with its own kill switch and self-test. The constraint that everything must degrade gracefully shaped every later decision.
Early 2026
Wizard + rule library
Pivoted away from the "power user only" framing. Added a setup wizard, a rule library covering 300+ plugins, and per-page scope so non-developers could get the benefit without writing rules by hand.
May 2026
Beta with paying testers
Opened to a small group of beta testers. Real production traffic, real WooCommerce stores, real bug reports. Public discussion happening on Reddit; the feedback loop is what's driving the roadmap right now.
What stays constant
Four rules I don't bend
Every product has constraints. These are the four I keep explicit, so a future feature request that violates one of them gets a clear "no, here's why" instead of a drift.
No core changes
WordPress core files are never touched. Everything runs as a mu-plugin layered above the WordPress request lifecycle.
Caching is not the answer
No module rewrites "compute the result once, serve it forever." We change the mechanism, not the cacheability. Page caching belongs at the edge, not inside the plugin.
Every module degrades safely
Each module has a kill switch on disk, a self-test that runs before it boots, and shadow mode for anything that changes behavior. A broken module never takes the site with it.
Honest baseline
We don't promise 10x. The realistic shape is 2–3x median TTFB on a typical mid-sized site, and 10–100x on specific paths (cart, admin-ajax, REST). The plugin tells you what it actually measured.
Roadmap
What's shipping, what's next
Public roadmap so the people running this on production sites can plan ahead. "Shipping" means it's in the build that's either out or about to be.
- Shipping
Granular privacy controls + anonymous diagnostics
Operators decide exactly what (if anything) the plugin can phone home about. Diagnostics is opt-in, identifies sites by hashed UUID, and each shareable channel has its own toggle with an example of what shape of data leaves.
- Shipping
WooCommerce Cart & Checkout module
Detects which plugins each cart/checkout request actually uses, including translation extensions like WPML, and skips everything else. Picker UI on the Modules page replaces free-text rule editing.
- Up next
Fleet-level operator dashboard
For agencies and multi-site operators: a single view of which sites are silent, which versions are out in the wild, top error codes across the fleet. Built on the diagnostics endpoint shipped in 0.4.8.
- Up next
Plugin author API
A clean way for plugin authors to declare "my plugin is only needed on these route classes" so end users don't have to figure that out themselves. The wizard's rule library will keep working in parallel.
- Later
Self-hosted licensing for agencies
Agency tier with a self-hosted licensing server, so client sites talk to your infrastructure rather than ours. Useful for compliance-sensitive operators.
Want to be one of the next testers?
The beta runs on a small group of stores willing to try a fresh release, report what breaks, and tell me what's missing. If your stack matches, I'll send you a license.