INTRO: Welcome to Apply Filters, the podcast all about WordPress development. Now here’s your hosts, Pippin Williamson and Brad Touesnard.

BRAD: Welcome to Episode 78. This time Pippin and I will be digging into our mailbag and answering people’s questions. But first–

–This episode is sponsored by Pagely, undoubtedly the original gangsters of managed WordPress hosting. They’ve been around for a long time, but man have they evolved over the last few years. From humble beginnings to now hosting huge brands like Disney, Visa, Comcast, ebay. I could go on.

They’ve also figured out who their customers are. They realized that people come to them with complex scaling, deployment, and security challenges, challenges deemed unsolvable by other providers. And so they made that their niche. That’s what they do. They provide solutions to these challenges.

Over the years their technology has seen big improvements as well. One of the biggest changes they ever made was moving all of their hosting onto Amazon Web services, and it has paid off big time for them. In fact, there was an S3 outage just recently, and they were able to stay operational. There was even a tweet I remember from Scott Bollinger. I looked it up and it reads, “Impressed that while AWS is down, my @Pagely site with AWS infrastructure is still up. Redundancy ftw” (for the win).

So if you have a big scaling problem, a big hosting scaling problem, you should definitely get in touch with the great folks over at Pagely. They’d be more than happy to chat with you and find a solution to your scaling problem. Also, check out Pagely.com for more details about their services and contact details.

PIPPIN: All right, so we’ve got a number of questions today. We’re just going to go down the list. If we get through all of them, awesome. If we don’t then we will keep cataloging them for future episodes.

This first one comes from Bharat Mandava. And I’ll apologize ahead of time if I or Brad butcher anybody’s names. Sorry. This question is, what’s the best way to set up recurring payments: self-hosted versus third party affiliate solutions such as Affiliate WP or ShareASale?

I think there’s really two questions in here. First, he’s asking about, like, setting up recurring payments, I would assume how to actually collect those recurring payments, how to create subscription records, how to let your customers purchase subscription. And also then how to integrate those with an affiliate program.

Well, first, there’s a number of different ways that you can set up recurring payments. I mean for example all of the major e-commerce plugs and a lot of the membership plugins have recurring options: WooCommerce, Easy Digital Downloads, Restrict Content Pro, Member Press, Paid Memberships Pro, and a whole lot of others.

First of all, I would look at a plugin like that for setting up recurring payments. Then for an affiliate program, I think it’s Affiliate WP and WP Affiliate Platform from Tips and Tricks are the only two that I’m aware of that have built in support for recurring referrals. So like if you want to give an affiliate a referral on every payment that gets processed. Both of those do support a lot of the membership and e-commerce plugins.

There are other ways to do it too. You don’t have to use a plugin for it. I mean for example you could actually do a recurring payment directly through PayPal without ever using a plugin.

Brad, do you have anything you want to add to that?

BRAD: No, I think you pretty much covered it. I mean you’re the e-commerce expert, I think.

PIPPIN: Now I believe you guys have recurring subscriptions, don’t you?

BRAD: We do.

PIPPIN: Or you’re working on them?

BRAD: They’re fairly new. I think we launched four months ago or something. But yeah, we built our own subscriptions add-on for WooCommerce to do it. We’ve had our own subscriptions add-on since basically day one, but it just didn’t have the ability to automatically renew people’s subscription. They had to manually click, click a couple buttons to renew their subscription. Yeah, that’s what we did. I don’t recommend it.

PIPPIN: I think one of the most important things when you’re going about setting up recurring payments, and this applies to any kind of e-commerce stuff, is just figure out what your needs are and then figure out which solutions meet those needs. Don’t just assume that solution X or solution Y is going to work for everything. For example, EDD and its recurring payments plugin might work for some, but it won’t work for all situations. Figure out what you need and then start looking at the solutions that proposedly provide those.

BRAD: Yep. Good advice. All right, our next question is from Jonathan Perlman. He says, “When building custom routes in rest API for a mobile app what auth would you go with, cookies, oauth2?”

Hmm. Custom routes in the REST API for a mobile app.

PIPPIN: I’m not sure that the authentication method you use really matters too much depending on the custom routes. I mean your authentication is going to be the same whether you’re using the default routes or custom routes, typically. I mean unless you are — maybe if you are building custom routes that get access to information that uses different user capabilities than, say, your default routes. But typically the authentication would still be the same, wouldn’t it? Which, I mean, you could use the same authentication for either one.

BRAD: Yeah. I mean it really depends what he’s talking about here, right? If he’s talking about allowing your API to be accessed by a variety of different apps, that’s usually OAuth. It’s usually where the user goes to a screen and then says, “Yes, please allow AirBnB to use my Facebook account,” right? Like that kind of thing.

PIPPIN: Mm-hmm. I think OAuth is probably the best, if you can set it up. I’m not actually too familiar with the cookies authentication, so I honestly have not used that one. We did it a little bit differently in Affiliate WP recently. We extended the core REST API to add in our own routes and we also add our own authentication on top of it.

We struggled with the idea of using OAuth for a little while and then ended up deciding not to use OAuth. We implemented a variation of Basic Auth. Basic Auth is the simplest authentication, but it’s also one of the least secure because it requires putting in your user name and password basically into every single HTTP request.

What we ended up doing, we used Basic Auth, but we did it with API keys. So inside of Affiliate WP we created an API keys table called Consumers, and then any user that wants to interact with the API gets a set of user API keys created for them. Then those are the API keys that are provided as a user name and password inside of your HTTP request, which is then used to authenticate that request. But if those API keys get stolen or exploited in any way, you can revoke the API keys easily.

The other thing is that those API keys don’t provide any kind of other capabilities within WordPress. It is limited to the Affiliate WP data. Let’s say that you were able to get a hold of my API keys because I was sending them in HTTP request, it wouldn’t allow you to really do anything. I mean you could manipulate the affiliate data, but you couldn’t reset a password. You couldn’t change an email. You couldn’t create posts. You couldn’t update anything like that. It was kind of a nice middle ground for us.

BRAD: Yeah. I mean that’s a pretty typical authentication mechanism. I mean if you look at something like Amazon Web Services, that’s what they give you, right? When you create a user there and you want that user to use the API, then you get two keys, two separate keys. One is called the secret key and one is–I don’t know–the key/key or something.

PIPPIN: The public or the access key, I think.

BRAD: Yeah. Yeah, that’s right: access key. And so, yeah, I think that’s pretty typical setup. And to your point about Basic Auth not being that secure because of passing through the authentication details each time, I mean you kind of have to do that no matter what, right? You have to pass something back to authenticate, right? As long as you do it over HTTPS, I don’t think it’s that risky.

PIPPIN: Well, and especially if the credentials that you are passing are very limited in scope.

BRAD: Right. Yeah.

PIPPIN: Like for example when you’re using Amazon S3, you can create an IAM user. Then when creating that user, you can actually specify the exact capabilities that they have.

BRAD: Exactly.

PIPPIN: Which is then going to limit what those API keys can do, even if they get into the wrong hands.

BRAD: That’s right. That’s why they don’t recommend creating root keys that have global access to everything, which is kind of what everyone used to do until, you know, the horror stories came up where people ended up posting their root keys on their GitHub account by accident or something. Then some hackers got it and started filling up their S3 with tons of data and firing up EC2 instances and sending out spam email and all this stuff.

Now we don’t do that any more, right? We don’t use root keys any more. That’s bad practice.

PIPPIN: Yeah. We updated our Amazon S3 plugin for EDD. We didn’t actually update the plugin itself. We updated the documentation in the settings screens to indicate that you should create an IAM user because originally it was recommending the root user.

BRAD: It’s not as ideal for plugins in a way because if you need to get them to do something or if you need to do something with their AWS account, you may not have access to do it through the plugin. Then you have to tell them, oh, don’t actually have access to do this, so now you have to go back to AWS console, go in, edit your user, edit their permissions. It’s a lot of steps to get them to add permissions, but what’s the alternative?

One thing we thought about doing in our Offload S3 plugin is, on the first setup step, basically, get them to use their root keys, go them to go to their AWS account, get some root keys. But then as soon as they click next, we set up everything that needs to be set up in their AWS account, so create another IM user with restricted permissions. Then delete the root keys as kind of the final step to clean it up.

I don’t know if that’s possible. We haven’t actually even looked at if it’s possible for a root key to delete itself, but it’d be cool if it was because then you could do all those. You could do all the manual steps for people and then just clean up after yourself kind of a thing. That’s something we’re looking at doing in the future.

PIPPIN: This next one is actually pretty much the same question. I guess authentication with the REST API is a popular subject.

Morten Rand Hendriksen asked, for a standalone mobile app, OAuth2, which is tricky right now with lack of support?

And this is true. OAuth2 is not super well supported yet in the REST API. It’s also, at least the last time I checked, it seems to be lacking in documentation. So I would — for Morten, I would, well, go back to the last ten minutes.

BRAD: Yeah, right. The next question is from our friend Brian Krogsgard. He asks, “What’s your process for prepping for taxes?”

Wah-wah-wah. I added that last part. That wasn’t part of Brian’s question.

PIPPIN: It’s not really a development question, but Tom McFarland extended it and makes a good point. He says, “I think it would be neat for a lot of us self-employed in the WordPress world to answer as well.”

Basically, look, everybody has got to do taxes. Whether you’re a developer, a business owner, a designer, or whoever you are, everybody has got to do taxes. I guess our answers are going to be a little bit different. For one, you’re in Canada. I’m in the United States. And then listeners around the world. So I guess take it with a grain of salt. What’s your process?

BRAD: Well, I have a bookkeeper and an accountant, separate. Usually what happens is the accounting firm emails a checklist. Then I get my bookkeeper involved. Then if there’s anything else they need from me that they’re missing, then I get it for them, whatever it is. Like a missing invoice of some kind of statement or something.

My bookkeeper really has access to pretty much everything, though. It’s usually just something that gets sent to my private mail. She doesn’t have access to that. Yeah, it’s just a little bit of odds and ends from me. But usually it’s just my bookkeeper and the accountant that work together and sort everything out. Then I just have to sign some documents and I’m done, kind of thing.

PIPPIN: That’s pretty much the exact same process for us. I have an accountant that does bookkeeping work for us every single month. Keeps everything up to date. Then at the end of the year she sends everything off to the tax people, and they double check it. They send us back a checklist of everything they need, everything they have. Then they end up doing all the filing for us.

I think maybe the best piece of advice I can give you for prepping for taxes is if you run a business or you are self-employed, don’t do your own taxes.

BRAD: Yes. Agreed. Definitely have an account.

PIPPIN: Do not do your own taxes.

BRAD: And if you can afford one, get a bookkeeper.

PIPPIN: Yes. Even if it’s for a couple days out of the year. I can tell you personally that the last time that I did my own taxes was the year that it almost cost me $20,000 in a mistake. Then I had a bookkeeper redo them for me, and I was about to pay $20,000 more than I thought I was supposed to, more than I was actually supposed to. Worth it. Worth every single penny.

BRAD: Could you–? Here if you overpaid and there was a correction to be made, you could get that money back later. Is that the same?

PIPPIN: That’s true in the U.S. as well. But that’s assuming that the correction is made.

BRAD: Right. Assuming you discover it at all. Yeah.

PIPPIN: Right.

BRAD: Mm-hmm.

PIPPIN: If you are not self-employed or you don’t run a business, let’s say you’re employed by somebody, I don’t see there’s any reason to. Then I think doing your own taxes is perfectly fine because it’s actually — I mean depending on where you live. At least in the U.S. it’s still complicated, but it’s reasonably simple. It just really gets messy when you have a business involved.

BRAD: Yeah. I would recommend also setting up a system so that your bookkeeper or at least you have everything in one place, and you try to keep QuickBooks or Simply Accounting or whatever you’re using up to date so that you’re not, at the end of the year, going through everything. It just makes it so much more stressful.

PIPPIN: Oh, a nightmare.

BRAD: Yeah.

PIPPIN: I think a perfect example is that my bookkeeper works every single week on our books. And almost every single week she sends me an email and says, “Hey, what was this charge for? What should this be filed under?” Even like two days after that charge happens, I forget what it is.

BRAD: Yeah. Yeah.

PIPPIN: Good luck if it’s been nine months.

BRAD: Right. Yeah, exactly. All right.

PIPPIN: All right, so the next one comes from Jack McConnell. This is a good one for anybody that builds plugins or services like hosted services. So he asked, “How do you track users of your plugins and the used features?”

How do you figure out how many people are using it, where they’re using it, what kind of features they’re using, and what they’re not using, et cetera?

BRAD: We do this really, really poorly right now, and this is something that–

PIPPIN: Damn. I was really hoping you were going to say, “We do this really, really well.”

BRAD: No, this is something we have unlimited room to improve upon.

PIPPIN: Hey, that’s the way to look at it.

BRAD: Essentially, we don’t do anything. We don’t even have a log, really, of the pings that our API gets from people checking if their license is valid or anything like that. We don’t. We just simply don’t track things at all.

I think part of the reason for that is that WordPress.org, it’s kind of against their policies unless you get the users to opt in, so you have to specifically ask them to opt in, so we just haven’t crossed that bridge. But really there’s no excuse for our pro plugins, right? That could just be baked into the terms of service that you get a license with us; we track certain things. It’s in the terms of service.

How do you guys do it?

PIPPIN: We do do it, not as much as we should, so we do it in a couple different ways. For EDD, any time you install EDD you get a notice at the top that says, “Would you like to allow us to anonymously track your data, or pseudo anonymously?” We actually get the site URL, and we get the email address.

If you accept that, if you click “allow,” then it will send our site a ping once a week. Basically it sends the EDD version, the site URL, the plugins that are installed, the WordPress version, the PHP version, some of the server info. Basically the environmental variables that allow us to better — like for example, we can go in and look. All of those sites that we have tracked, we can find out what is the most commonly used plugin on all of them, how many sites of the ones that we know of are running OptimizeMember, how many of them are running Contact Form 7. We can go in and get some rough ideas on this.

Now it’s not great because it has to be opt in, meaning that we cannot assume that it’s entirely accurate, but it is a reasonably good representation. The other thing that we do with it is, once you click “allow,” basically as long as EDD is active and you haven’t disabled the check-ins, it sends a ping once a week that will send updated information. If your EDD version changes, your WordPress version changes, your plugin version changes, we can see those over time, which then also allows us to identify active versus inactive sites. We can go in and see how many sites does our tracking script report as active and then compare that to, say, WordPress.org. How many does WordPress.org report as active? It gives us a little bit better idea of the sites that we have.

For Affiliate WP, on the other hand, we do it a little differently. Affiliate WP is all behind the scenes. There is no opt in. There is no opt out. It sends it automatically when you activate a license key, and then it also sends it once a week after that. Once a week or any time you install an Affiliate WP update, it resents then so that we get new version numbers immediately. With the Affiliate WP one, we can actually get a really accurate representation of what we have. For example, I can go in and see the exact breakdown of WordPress versions, of Affiliate WP versions, of other plugin versions, of PHP versions.

Another metric that we recently started tracking was how many people are using each of our individual Affiliate WP add-ons, so we can see what the most popular add-on is, what the least popular add-on is. Oh, and we also, in EDD and Affiliate WP, we track the local so that we can see what the most used languages are. This has all been very, very valuable for us.

BRAD: Right. What kind of decisions are you making based on this data? Is there something recent that you decided on based on this data?

PIPPIN: PHP 5.2 support in EDD is a decent one. EDD core still has support for 5.2, and one of the reasons for that is because right now one percent of our known sites still run 5.2. Now, that’s not a huge number. I mean one percent is a pretty small number. But it is still significant enough that if we were to immediately remove 5.2 support, we would probably be flooded and we would be breaking a lot of sites.

One percent is still a very large number of sites. It’s not large in, like, WordPress’s 4% chunk, like 4% of WordPress sites is very different than one percent of EDD sites. But in terms of the impact it could have on us as a company, our support teams and also for our customers, it’s still a huge impact if we were to suddenly remove 5.2 support and then a whole bunch of sites updated and stopped working or got notices or what have you. That’s one example.

Another on that’s been kind of interesting is that, in EDD, our second biggest language is Farsi, which means that our second biggest language is a right to left language. I think a lot of people, especially that use left to right languages, such as English or Spanish or any of the romance languages, maybe sometimes unfortunately forget about right to left languages and forget how prevalent they are.

In EDD, literally our second biggest language, which accounts for over 5% of our user base, is right to left, which means that we have to be much more careful about testing right to left languages. It’s not that you shouldn’t ever not be careful about it. It just kind of reinforces the importance of it.

Seeing the WordPress versions is another one. In Affiliate WP, for example, we recently decided to increase our minimum version to 4.4. Well, we can actually see exact numbers on how many of our customers are still running older versions than 4.4. Thankfully, it’s actually a very small number, which was surprising.

The biggest one in Affiliate WP right now for us, though, is seeing the integrations. In Affiliate WP, we call. We integrate with other existing membership plugins, e-commerce plugins such as WooCommerce, Gravity Forms, Easy Digital Downloads, et cetera. And so those are called integrations. We can actually see an exact breakdown of how many people are using each integration, which then can tell us, is it worthwhile for us to add features to an integration, or should this integration get all of our attention?

The one things that we don’t track at all is we don’t track interfaces or screens of buttons or anything like that. We’re really interested in starting to track that, so maybe having some kind of JavaScript in the site that goes and, like, records click events throughout the interface so that we can see what screens are actually used and not used. This would all be anonymized. We wouldn’t be able to go and say, “Oh, well, John Doe clicked this screen X number of times.” We’re not interested in any kind of data like that. We just want to know what screens and what features are actually used versus not used. That’s something that we’re interested in adding in the future.

BRAD: For Affiliate WP you said it automatically tracks things in the background. Is that baked into your terms of service agreement when they buy, or where is that?

PIPPIN: It’s part of the license key. With the terms of service and, like, getting updates, it’s just sending that data along with the updates. We could probably be more clear about exactly what is tracked – note to self.

BRAD: Yeah, yeah.

PIPPIN: But, yeah. I mean at the moment it literally is just plugin versions. It’s site. It’s PHP version. It’s MySQL version. That’s really all it is. We don’t track the number of — we don’t do anything with value or dollars or order records or anything. None.

BRAD: Right. Yeah, I think the most important thing is how you store that data. If you’re storing the data and attaching it to an email address or a license key that can then be related back to a customer, then it can be a problem. But if it’s completely anonymized and it’s just aggregate data that helps you make decisions, yeah, I don’t see how that’s a privacy thing.

Anyways, the next question is from Patrick Garman, and he says, “In a world where Stripe and PayPal have disappeared.”

I feel like I should read this like a movie trailer. “In a world where Stripe and PayPal have disappeared. What is your new payment gateway?”

Oh, man.

PIPPIN: I have one: Recurly.

BRAD: Okay. I didn’t realize they were a gateway. I thought they were just a service that gateways plugged into.

PIPPIN: No. No, they have a gateway.

BRAD: Okay. Interesting. Why them?

PIPPIN: They have super robust subscription systems.

BRAD: Okay.

PIPPIN: They have a better subscription system than Stripe or PayPal.

BRAD: Okay.

PIPPIN: It’s actually significantly more powerful. I think the only downside to them is that, for one reason or another, they’re just not as popular. They’re not as used as often.

BRAD: Right, so the number of integrations and stuff, like complementary services.

PIPPIN: We have a basic integration for them with EDD, and I think we’ve sold a grand total of maybe three copies ever in, like, four years. But the gateway, their API is stellar. Their documentation is great. Their admin UI, like as a merchant, is awesome. Their features are awesome, so that’s mine.

BRAD: I think what I would say there is I would use whatever made sense for our customers. The only reason I use PayPal right now, in addition to Stripe, is because people, our customers, want it. I think about 50% of our customers pay with PayPal, so they clearly want PayPal, right? They wouldn’t choose it if they didn’t want to use it.

PIPPIN: We have almost a perfect 50/50 split.

BRAD: Yeah, so if PayPal disappeared, maybe they would go flock to Google’s wallet or whatever or Amazon’s pay or something. Whatever people flock to, I think that’s what I would go with. If it was just credit card processing, yeah, if Stripe wasn’t around I’d probably go with Moneris, which is a Canadian gateway provider that just works with banks and stuff here. That’s what I’ve used in the past, so that’s what I would go with.

PIPPIN: All right. This next one is from Tunbosun, and this is regarding a plugin update process. “I use EDD and the software licensing extension to sell WordPress plugins. Plugins hosted on the WordPress.org plugins directory are recognized by their slug. If a premium plugin I am selling using EDD had the same slug as a plugin on the WP.org plugins directory and an update is available, my version of the plugin will be overwritten by the one on WP.org. Is it possible to hijack the plugin update process so that my version is the one that’s updated?”

This is a kind of tricky little thing. It’s a nuance of “the plugin’s update API in WordPress.” The plugins update API in WordPress, if you are updating a plugin that is not on WordPress.org, there is no such thing as an API. It literally doesn’t exist. The update API for third party plugins is a filter. That’s the only API there is, so it’s not an API.

BRAD: But–

PIPPIN: Which also means–

BRAD: The answer is yes, you can definitely hijack the update process.

PIPPIN: Yes. Yeah, you can. But that functionality, I mean if you have a plugin called Gallery, and there’s one on WordPress.org, and then you sell a plugin called Gallery, and if the WordPress.org version is greater than your version, WordPress is going to look at a .org version and just assume it’s the same plugin, which is a problem. You have to be careful with plugin naming because of that.

Specifically in EDD, we did actually add an option to overwrite this. There is a flag that you can set in the updater class now that allows you to, say, overwrite the WordPress.org one. Basically the answer is all you’ve got to do is overwrite the data in the array after it checks WordPress.org and there you go. But that’s why it’s a pseudo API.

BRAD: Yeah. Yeah, I mean I think — so the other thing, the other point I would make here is about WordPress.org. I’m pretty sure if you’re an established — if there’s an established plugin out there using a certain slug, the .org team, Pippin included, would not approve that plugin, right? For example if someone decided tomorrow to submit WP Migrate DB Pro to the .org repo, that wouldn’t get approved.

PIPPIN: Well, I hear the owners of that plugin are jerks, so we’d probably approve it.

BRAD: No!

PIPPIN: No, you are correct.

BRAD: Yeah. Yeah.

PIPPIN: If it’s a known slug, I mean if we know about it. That doesn’t mean–

BRAD: Affiliate WP would be another example, right?

PIPPIN: Right. It doesn’t mean, however, if there’s a product out there and somebody submits a plugin with the same name. It’s not necessarily going to get caught because we’re human, so it depends entirely upon us recognizing it.

BRAD: Are you human, though? Are you?

PIPPIN: I’m halfway robot.

BRAD: Yeah.

PIPPIN: All right. I think we’ve got time for one more question.

BRAD: I just want to actually talk about Jack McConnell’s question again about tracking users of your plugins and the features that they use. If you’re just starting out, building something like that should not be on your priority list if you’re just getting started building plugins. But you could use something like Freemius.

Freemius provides analytics and insights for WordPress plugin and theme developers. I think you can get started for free and stuff. I’m not sure what their pricing is exactly, but certainly more affordable than building your own system at the very beginning when you’re just getting started.

PIPPIN: Yeah, that’s a really good point. It’s one of those services that’s provided so that you can take advantage of it and spend more time building your product instead of building the things to sell your product.

BRAD: Yeah. For sure. That’s at Freemius.com is that service. One more question?

PIPPIN: Yep.

BRAD: All right. Frank Corso asks, what does your project management look like, such as what tools, do you validate features with users, how do you decide on features, et cetera?

Well, go ahead.

PIPPIN: Project management for us is primarily three components. It’s Slack where we have all of our team communication. It’s Trello where we keep track of kind of longer term projects and discussions. And then it’s GitHub for all development. A lot of times there’s overlap because we might talk about a GitHub issue in Slack, make a decision there, and then report back to GitHub or to Trello or something like that.

I think validating features and deciding on features is the most important part of this question because wherever you decide to — I mean whatever you decide to use for project management is fine. There are tons of different solutions, tons of things that work great for people. For us, validating features is primarily paying attention to support and looking and watching out for feature requests, looking for repeat requests, looking for repeat bug reports, et cetera.

We used to build in tons of features, and I think all product developers probably go through this where any time somebody suggests a feature you build it. I mean assuming it’s reasonable. We don’t do that as much any more. We’re a little slower to build new features in because we try to make sure that it’s actually going to be used by a good number of people, which is where usage tracking comes in. For example, there are some integrations that we built in Affiliate WP early on that, looking back on now, were probably a mistake because they’re used by so few people if anyone at all.

With features now, we typically — we wait to build a feature until it’s been requested numerous times or it’s just one that inherently makes perfect sense for the system. There are some features that we built in that have never been requested, but, based on the nature of the feature, it’s just kind of a no-brainer. Then the other exception is since we use all of our own plugins to sell our plugins, there’s a lot of features that we want as a company, like, and as a user of our plugins. So sometimes we just make the decision to put those features in. But really listening to customers is, I think, super important.

BRAD: Yeah, I agree. What we do, we have a feature framework spreadsheet thingy that was inspired by–

PIPPIN: Is that a technical term?

BRAD: Yes, that’s right – thingy is inspired by Baremetrics. They published the spreadsheet that they use for tracking features. And they have, like, a little formula that creates a score. They use different dimensions, so the demand, the impact, and the effort. And so we tweaked it a little bit so that we can actually accurately measure the demand. Any time a feature request comes in through support, we log into the spreadsheet and add a vote for that feature. Then we get an accurate score of, like, what features we should really prioritize first, like prioritize next.

The downsides with that system is that it’s not perfect. People, you know, guys forget to add votes to the spreadsheet or maybe the numbers are a little off. When you’re measuring impact and effort, you’re just estimating. You don’t know exactly how much effort it’s going to be or what the impact is going to be. It’s kind of fuzzy, but it’s the best we’ve come up with so far in terms of prioritizing features.

PIPPIN: We don’t use a voting thing like that. We’ve considered it before. But we do, any time that we get a feature request, we typically log a GitHub issue as an enhancement. Then any time new requests for that come through, we drop a comment in with a link to the support ticket or to wherever that feature was requested, whether it’s Twitter, Facebook, email, or somewhere else. That way it’s also easy to then follow back up with those people–

BRAD: Yep.

PIPPIN: –when that feature does go in.

BRAD: Yep. Yeah, we do that as well. You’re supposed to add the vote to the spreadsheet and then go to the GitHub issue, which is linked in the same row in the spreadsheet. Go to the GitHub issue and paste the Help Scout URL into the issue. But like I said, it’s not a perfect system. I don’t think everyone does it every time, but you know it’s better than nothing. And so that’s what we’ve got.

PIPPIN: Cool. All right. Well, I think that’s going to be a wrap for today. We still have quite a few questions left, so whether it’s the next episode or soon after that, we will continue to address them. Feel free to keep sending in your questions. We really appreciate it.

BRAD: Awesome. Talk to you next time.

PIPPIN: Thanks, everyone.