If you’ve read the About page, you know I’ve been working in WordPress for quite a while. A significant portion of that time was with Sandhills Development, the company ran by Pippin Williamson and previous owner of WordPress plugins like Easy Digital Downloads, AffiliateWP, WP Simple Pay, and several more.
I joined the company pretty early in its development. I was the first official employee, though I was not the first WordPress community member to embrace Pippin and his plugin projects. Many of the early orbiters, including myself, eventually became part of the company and helped it grow to around 28 people over 6-7 years.
I share this history as context to help understand my perspective on the changes we went through behind the scenes. Put succinctly, we went from typing “hey, I’ll be off-and-on tomorrow while my friend is in town” in a Slack direct message, to stating “everyone please read the new PTO policy and drop a thumbs up once you’ve seen it” linked to a Basecamp post with a Google Doc attached.
Neither of these eras, nor the eras in between, were bad. They were exactly what we needed at the time. Our troubles came in two particular flavors; when it came time to transition from one system to another, and when we had more than one system doing the same job.
I remember building detailed cards in Trello explaining how to format GitHub issues. I also remember switching from my personal Google account and my company Google account before accessing company SOP documents. Luckily I only had one Basecamp login to remember if needed a quick refresher product branding guidelines posted by the Marketing lead.
As a veteran in the company, I could navigate our organizational knowledge pretty well. Perhaps I took that for granted. Newer team members could easily miss information jumping from one system to another. Onboarding new team members never really caught stride, and our knowledge never had a fully centralized home.
As leaders of the company—Pippin and all of us Directors—that was our fault.
WordPress Knows Us Well
Interestingly, given that every team member had an account, we didn’t use our company WordPress website for anything other than outward marketing and information for the external masses.
Each team member had a WordPress user role, and user roles have capabilities assigned to them which determine access levels for each user. Both user roles and capabilities can be customized. What a foundation.
Unfortunately, we stopped there, as do many teams that run on WordPress. Team members already know how to do things like manage posts or even carry out special tasks made possible by a plugin. For an e-commerce WordPress site, you expect content management and store functionality to be done on-site. That is the natural home, and often the very reason why the site exists.
The moment you need to do something different like document internal operations or provide training material to a new hire, teams usually jump ship to a separate platform that has a purpose of its own. Why? The answer is pretty straightforward.
We use WordPress for its core functionality and its plugins that have proved their worthiness in the ecosystem. For all other functionality, we look elsewhere.
Google Drive, Trello, Notion, & Basecamp…
…just to name a few. We use these platforms to organization information. A scattered company footprint, multiple account logins, and onboarding chaos is the price we pay for services that do their jobs well. Perhaps it’s not a choice, but more of a sacrifice.
I don’t have a problem with each individual tool. What bothers me is the fragmentation and unnecessary complexity. SaaS platforms provide a robust toolset that teams sometimes adopt simply because they can, or to help justify the monthly costs (per-seat).
WordPress’s approach is a lot simpler—provide the core functionality and extend as needed.
The catch is that extending WordPress requires development skills. Plugin development has to be done well and with intent. Most teams using WordPress don’t have the skills to roll their own solutions. So, they either hire a developer at high upfront costs, or purchase a service for a smaller monthly fee.
I genuinely believe that teams and individual users would rather extend WordPress than subscribe to an external platform.
So I Built the Plugin
Keystone is a WordPress plugin that gives your WordPress site a proper internal knowledge base. It lives entirely inside the admin and uses the user accounts you already have to manage information and control access to it.
Managers organize knowledge into Sections, Modules, and Items. Items are the actual content like readings, checklists, quizzes, documents, and videos. You can assign modules to specific users or roles, track who’s completed or seen what, and verify that your team actually received the information rather than just assuming they saw it. Or you can skip all of that and use it as a simple, searchable reference library. It works either way.
It’s $99 a year for a single site, unlimited users, no per-seat pricing. The price is for updates and support. The plugin is yours forever, even if you cancel your subscription.
I built it because I spent years watching teams, including the one I helped lead, manage their WordPress operations from everywhere except WordPress. The foundation was already there. It just needed a room built on top of it.