Why We Published This Policy
At Pee-Aye Creative, we believe transparency is just as important as the software we build. That’s why we’ve chosen to publish this page. We want our customers to understand how we approach bug reports, support, feature development, and product quality, because these areas are just as important as the features themselves.
This isn’t a promise that our plugins will never have bugs. No honest software company could make that claim, especially in the WordPress ecosystem, where every website is unique. Instead, this page explains how we respond when problems are discovered, why we sometimes request access to your website, and what to expect when you work with us.
Over the years, this philosophy has become part of our company culture. It’s how we prioritize our work, how we support our customers, and ultimately how we’ve built products that continue to improve year after year.
Every Website Is Different
WordPress is one of the most flexible website platforms available today, but that flexibility comes with a challenge. Every website is built differently. Two sites may both use the same version of WordPress and the same plugin, yet still behave differently because of their hosting environment, PHP version, installed plugins, theme configuration, caching system, browser, custom code, or dozens of other variables.
Check Our Full Guide!
We made an entire post and video about why bugs happen in Divi and WordPress!
We spend a tremendous amount of time testing our products before every release, but it’s simply impossible to recreate every possible combination in the real world. That’s why some issues only appear on a handful of websites, and occasionally on just one.
Understanding that reality is important because it explains why software bugs aren’t always obvious and why reproducing them can sometimes be more difficult than expected.
What We Mean By “No Known Bugs”
When we say we have a “No Known Bugs” policy, we’re not claiming our plugins are bug-free. What we mean is that we don’t intentionally allow confirmed bugs to sit in a growing backlog while we continue building new features.
Once we’ve confirmed that a bug exists, it becomes part of our active development process. Depending on its severity and complexity, the fix may be included in the next update or scheduled for the following release if additional testing or development is required. Either way, confirmed issues don’t simply get acknowledged and forgotten.
Not every issue has the same priority. A bug affecting a critical feature naturally receives more immediate attention than an obscure edge case affecting only a very specific workflow. Even so, every confirmed issue is documented, prioritized, and worked into our development schedule rather than being left unresolved indefinitely.
Support Always Comes Before New Features
One of the principles we’ve followed since the beginning is that our existing customers always come before our next feature release.
If a developer is working on a new feature and a customer reports an issue that needs investigation, that support request becomes the priority. We’d much rather pause development for a few days than leave a customer struggling with a problem on a live website.
That doesn’t necessarily mean every issue is solved immediately. Some bugs require extensive testing or collaboration with third-party developers before they can be resolved safely. What it does mean is that customer issues become active development work rather than sitting behind a long list of future ideas.
We believe that’s the right way to support the people who have already trusted our products.
If You’ve Found A Bug, There’s A Good Chance We Haven’t Seen It Before
Because we actively fix confirmed issues, most new bug reports we receive are exactly that—new. Maybe that surprises you, but it’s true.Â
Sometimes they’re caused by an unusual hosting environment. Sometimes they’re the result of an unexpected interaction with another plugin or theme. Other times, they’re edge cases that occur only under very specific circumstances. In rare cases, they may even result from a change introduced by WordPress, Divi, or another product our plugin integrates with.
That’s why we appreciate detailed bug reports. Screenshots, screen recordings, error messages, and clear steps to reproduce the issue often make the difference between solving a problem in a few hours versus several days.
The more context you can provide, the faster we can understand what’s happening.
Why We Sometimes Need Access To Your Website
If an issue occurs only on your website, there’s a good chance we won’t be able to reproduce it on one of our development sites, as the environments are completely different. Rather than spending hours trying to recreate something that may never happen on our test systems, we’d much rather investigate the website where the issue actually exists.
Working directly on the affected website often allows us to identify the cause much more quickly. Sometimes we discover a bug in our plugin. Sometimes we uncover a conflict with another plugin or theme. Sometimes we find a server configuration or custom code that’s contributing to the problem. Whatever the cause, seeing the issue firsthand almost always leads to a faster and more accurate solution.
To make this process easier, many of our plugins include temporary support access tools that let customers securely grant access without creating permanent administrator accounts.
Every Bug Report Helps Improve Our Products
Although nobody enjoys finding a bug, we genuinely appreciate every report we receive because each one helps us improve our products.
A confirmed bug doesn’t just get fixed for the customer who reported it. That improvement becomes part of the plugin, so every customer benefits from the solution. Over time, those improvements make our plugins more reliable, more compatible, and better prepared for the wide variety of real-world websites they’re used on every day.
Some of our best improvements began with a single support ticket. That’s one of the reasons we encourage customers to report issues rather than assume someone else has already done so.
Our Commitment
We’re never going to claim that our software is perfect because perfection isn’t realistic. What we can promise is that we’ll continue approaching development the same way we always have.
When customers report problems, we’ll investigate them carefully. If we confirm a bug, we’ll prioritize it, fix it responsibly, and include that improvement in a future update. We’ll continue listening to customer feedback, improving our products with every release, and supporting the people who trust our plugins on their websites.
That’s what our No Known Bugs Policy really means. It’s not a claim that bugs never exist. It’s our commitment that when we discover one, we don’t ignore it. We fix it.
