 How's everybody doing today? Good. I'm thankful and grateful that you came out today after lunch. Hopefully you don't fall asleep during this talk. I think I've got some exciting things to talk about. So thank you for coming and get to hear me talk about using WordPress as a SaaS, a software as a service platform. Before we get started, if you want to find me on Twitter, at Jay Thomas Griffin, you can find me there. I tweet lots of stuff about WordPress, lots of stuff about tech industry. I also have a lot of things, you know, just read WordPress development and all that type of stuff in general. There's also a link to the slides that you can find from my Twitter profile. So you want to check that out. And then you can also check out my website, thomasgriffin.io, and I have lots of things about WordPress written on there. Also on there I have a WordPress toolbox that you can sign up for if you'd like. And I get questions, I get asked pretty often about what are the tools that I use to help find success in WordPress. And so I've got those listed out there. So I wanted to get started by mentioning that. To whom I? Again, my name is Thomas Griffin, and I am the partner and CTO of a company called AwesomeMotive. You've probably never heard of it before, maybe you have. But you've probably heard of the stuff that we've built, especially in the WordPress space. I'm the technical co-founder of a product called OptinMonster. And then I also built a plug-in called Soliloquy, which appears to be the one that's most recognizable as a WordPress site or plug-in. And also built EnviroGallery. I've also built TGM plug-in activation. So if you've ever bought a theme from ThemeForrest, you've probably used TGM plug-in activation, which is for plug-in dependencies and themes and plug-ins. And we're fortunate to serve over 30,000 happy customers. What does TGM stand for real quick? Thomas Griffin Media. Sorry, so that's what it started out as. It was just me, Thomas Griffin Media. And yeah, so that's what it stands for. And so I'm fortunate to have a lot of experience in the WordPress space, building and selling distributed products. And so today I wanted to start us off with a quote. And I want you to read over this and think over this. By a guy you've probably heard of before called Winston Churchill. And he said, is to improve is to change. To be perfect is to change often. And so my talk today is really a story. It's really a story about pivoting and how pivoting is vital in your business. And I'm going to show you how we used WordPress to facilitate that pivot and how we've grown as a company and a product over the past two years. Who's ever heard of something called Bourbon? There was an app that was called Bourbon. Anyone ever heard of that, right? So Bourbon's kind of a cool story. Back in the day there's this whole thing about check-ins and everything. And you got Foursquare and Gawalla going after it. And there's this other thing called Bourbon. And it has some gamification stuff and has some photo-related stuff. And it's doing some really cool things. But the guys that created it were a little bit worried about something. They were worried that they wouldn't gain traction because there's too many distractions for the user. So they stripped everything down and simplified to one feature. They wanted to focus on photos. Does anybody know what that turned into? You've probably heard of it before. You've probably even used it before. It's something called Instagram, right? It's a story about them changing, improving upon the user experience, working to perfect that and creating something that was awesome and of a lot of value. I want to kind of go over that in Monster and show you how we've gone from a simple MVP product into a fully powered SAF solution built on top of WordPress. And it's the history and the story of pivoting and improving and wanting to change and to perfect what we offer for our customers. So I've got a little timeline. Hopefully you can read this. Whenever you present, you never know exactly how big the font and the screen you're going to get is going to be. So maybe you can read it. If not, you can always follow along in the slides. So January 1st of 2013, right? A year and a half ago, OptinMonster is born. You may have heard of a guy named SideBalky. He's the guy that's over WP Beginner. He's pretty prolific in the WordPress space. If you came to the first talk, the keynote that was given by Cary about connections, I'm living proof of connections that they work. I would not be here today without the connections that I made back in WordCamp in 2012 in Atlanta. So OptinMonster is born. We meet. We decide. I like building stuff. He's good at selling stuff. Let's get together. I think this could be a good partnership. OptinMonster is born. So we decide, all right, we want to build this product. We want to build a solution that brings this technology called exit intent to the mass markets. Previously, it had only been provided by one company and would literally cost you $10,000 a month to do this simple thing that's maybe five lines in JavaScript, right? And we want to take this technology and bring it to the masses because the data behind it is so persuasive. It works. But we thought, you know, our market is so much bigger than WordPress. So let's build it as a SaaS platform, right? SaaS is all the rage. Let's do it. Well, all I know is WordPress. All he knew is WordPress. So we said, okay, we're going to figure out how to build this thing on top of WordPress. Well, we couldn't figure out how to scale it. We spent eight months building this thing. We put it onto a couple of sites, big sites like WPBeginner and others. And within minutes, servers crashed. Everything's down. And we went into panic mode. Oh, no, we've just spent eight months building this thing. And now we have no clue how to scale this. So we thought, well, let's build on WordPress. Let's backport this into a plugin because the data is the same. So the way that you kind of save and go about going data and the structures and all that's kind of similar. So we did. So September 24, 2013, basically a month later, we launched an MVP, a minimum viable product called OptinMonster for WordPress. We failed to build the SaaS, so we built the plugin. We thought, well, you know, we can start with the WordPress market and maybe this is good. If it works well, then we can work and build up a customer base and move towards the SaaS. The idea that we had of bringing this technology to the masses at a price point at $199 a year versus $10,000 a month took off. And we began to rapidly grow our customer base. But we ran into some issues with WordPress. One, we connected with email service providers and API connections. And there's no shortage of plugins in the WordPress repository that do kind of the same thing. So we ran into all the time of class conflicts, of plugin conflicts and really, really marred the experience that we wanted people to have. People would buy the plugin and they couldn't get the thing connected to their provider so that we could send leads to them. And that was really frustrating for us. So we had to work to try to build and build facilities around that to try to get around it. So we got together and we worked on OptinMonster version two. We took all this data, we took all these things, and we tried to really make our platform rock solid. We introduced something called the live customizer, which took cues from the customizer in WordPress to allow them to live customize Optin's and things. And this was awesome. It only took us about six weeks to get all the kinks and bugs worked out and then it was a super rock solid product. Literally our support requests are coming down to just nothing but customizations. Bugs, nothing happening, which is awesome. It's a great place to be. But we noticed a discouraging or encouraging trend. One, our refund rate was so high. So we started to look at why is our refund rate so high? Well, one of the reasons and the primary reason was because people would buy it thinking that they could use it on something that was not WordPress. And they'd buy it. 10 minutes later we'd get a request and say, oh, you know, I really want this, but you know, my site's on Drupal or I use a Shopify site where I've got something with Squarespace on my own static HTML site or you know, like there's Magento that we have set up and we want to use this, but we can't because it's a WordPress plugin. So we noticed in a nerving trend that we continually were getting these emails and then the presale emails. Can I use it on this? Can I use it on that? Literally I counted between a period of time where a third of our presale emails were asking if we could integrate with something other than WordPress. So we knew we had to make a choice. Were we going to just stick with WordPress and what we knew? That had a rock solid product that worked really well or were we going to try to expand outside of the market? So we decided to take the plunge. But on October 8th we said, okay, our customers are asking for it. I think we need to do this if we want to continue to be a viable business and grow, but it has to be a SaaS platform. But this time we're going to figure out how to make WordPress work. We had a lot of knowledge. We had a lot of structure and everything and we thought, okay, we're going to figure out how to take it to the next level and take what we already have and put it into a SaaS platform. So we spent about eight months doing it and then on May 5th we released the OptinMonster app, the Husted Platform. Everything that you see with OptinMonster and use with OptinMonster, the API, the backend, all of that is all built on WordPress. And so in this talk, I want to give you kind of the process of what we had to go through to do that and how we set up our infrastructure and everything to make WordPress scale the way that it does. So before I get into this, I wanted to ask if there are any questions that you have about the history of getting into OptinMonster questions like that. If not, we'll get into the process. So OptinMonster is a lead generation tool that allows you to build OptinForms to put on your site names and email addresses to put into sales funnels. Yes, correct. Now, this is the PHP classes. Even though we namespace everything, it's still, there would be an endless variety of all this OAuth implementation that another plugin did is messing up with ours and now we can't connect to constant contact or there's five different MailChimp plugins installed on one thing. So it's messing up our output and all of these things. And we can't connect to any of the MailChimp forms, any number of those things. And that problem gets solved if we control the system. We have no control over their setup but if we control it then we can solve that problem for our users and we can always be sure that that very initial experience is what the customer would expect. Do what? We had a lot of things to consider. Data migration. We didn't get the benefit of launching a SaaS from a brand new starting point, right? We have thousands upon thousands upon thousands of customers that now we have a reputation built upon. And we can't mar that by moving to a new platform and then just isolating them out and say, sorry, you know, you got to use this now. So data migration, how do we do this to make this system easy for them to move? And how do we sell that value to them? How do we deal with scaling? You know, what's it going to be like when these thousands and thousands of people move on to us instantly? We don't have the benefit of growing gradually and putting resources on. We have to scale from day one. What about system architecture? Security. Payments. When you get a license key and then maybe 30 days before, we say, hey, you know, you hope you're renewed, you can continue to get support and updates, but if not, you can still use the plug-in. That's not the case anymore, right? It's a subscription and they expect that that subscription will occur automatically if they don't take any action and that their service will always be on. Onboarding. We don't have the benefit of the WordPress ecosystem anymore. We might be getting somebody that's using it for a Magento site or a Shopify site. So how are we going to deal with onboarding? What about support? We're no longer supporting sites that use WordPress and we're not going to be familiar with the structures of them. Caching. What's caching going to look like? High availability and redundancy. We can't go down now. If a user's website went down, that's their problem. But now if something happens on our end, we have a big issue. Our interfaces and user experience, no longer in plug-in, we have to control every piece of it. What's the development workflow look like? Now we have to have something where we can fix changes and make sure that they're not going to break. Because if we pushed out an update to a plug-in that broke, it might break a small subset of users that chose to update it. But now if we push out something and it breaks, it breaks for everyone immediately. So a lot of considerations to think about. So some practical application of this. We've served over 7 billion requests since we started. That's a lot. That's a lot of OptinMonster impressions and pop-ups that have been shown. In the past 30 days alone, there's been over 500 million requests. That's to our server. To give you some context, that's around 17 million requests a day. So that's just API requests. So that doesn't include anybody coming to the site, interacting with it, building opt-ins, editing opt-ins, managing their account, payments, anything like that. That's purely API requests. So that averaged around 200 requests every single second. So by the time I started my talk and the time I finished, there have been over 700,000 requests to our server for OptinMonster opt-ins. That's a ton. This is all on WordPress. So if anyone tells you that you can't scale WordPress, they're lying to you. You can do it. And I'm going to show you how. You've even generated 5 million leads in the past 30 days. That's a lot of dollars to a bottom line. That's a bunch of requests to email service providers. So that's that comes into our area and then we have to generate a request out and connect to it. So there's a lot of stuff that goes on in this back in the back end to make this stuff work. And yeah, WordPress handles all this. So that's a lot of money. Something that started as just a simple blogging platform, powering an application solution that's reached by millions and millions and millions of people every day. So let's get to some of the meat and potatoes of this. Each piece that I'm about to talk about kind of breaks down the different pieces of the system and setup and some of the things that we had to do in order to make sure that the OptinMonster that we know and use today works. We had a lot of database considerations. We had to make sure that we preferred NODB over MySM simply for performance. When you get to something like that it's just clear benchmarks that NODB will perform better, especially with all the reads that we're doing. We had to drop an index on the WP Options table because now they're not touched by API requests but now when you've got 1,000 users that are on your site at one particular moment and auto-loading all those options is just ridiculous if you don't have an index on it. So we had to drop indexes on the auto-load for performance. We use a persistent object caching with Redis to prevent extra database queries. Our setup and I'll talk about this little more but we use our setup with Amazon Web Services and this is really easy with their ElastiCache. You can set up a Redis instance and connect it to that and run object caching with it. We had to think about users. We used some of the simple basic WordPress user functions. WP getCurrentUser, WP setCurrentUser the different user meta functions. We had to get from the very bottom and start with the very, very basic most basic WordPress user and then strip everything out and build on top of that compilation because now we got to deal with all these people on our database on one site. We want to make sure that nobody can access something from another user. We have to build now custom data keys and everything for account access. So things that we have to consider that when you're just building a plugin to sell that you really don't have to worry about. The actual opt-in itself we had to get a little creative with this. We have a custom post-type handling everything but the way that we stored data is completely different than how you would normally store data. So normally in WordPress one of the reasons why it uses the utility of it so nice is you have a typical post and a post meta user and a user meta and while it makes stuff really easy it's not exactly the most efficient way to do things. What we found was we preferred to bypass meta altogether and that we stored stuff using JSON and that we would be able to instantly pull it out and it would be ready for an API request and I wrote a little bit about this and our experimentation and you can find on the website that goes into more detail about how this works but it was a huge performance benefit for us because it was super easy to just query one thing and bring it out and not have to worry about checking for meta here or there we just make one query immediately cache it and then we're good to go and it's already ready for an API response. We had their own custom Ajax request for saving and generating data and I'll give you some practical stuff with this too which is really cool and then we make the public output generated at save and update intervals for performance so as soon as they save and update something it immediately sends out a notification to rebuild their cache so that's automatically updated as soon as they do stuff we have our API request we had to figure out how to scale our API request and I had to get a little creative with this because WordPress and routing with WordPress doesn't really work in the way that you'd want it to for a SaaS application and so we had to get creative with how we ran routes in WordPress and what this involved was using a must use plugin that sits in front of everything else that loads in the WordPress bootstrap we'll call it and this plugin would check for a route that we had defined in our API settings and if it matched that route then we would go through and we would whitelist what needed to be loaded so that we can make sure that our API request for performance optimized because WordPress has lots of plugins and those plugins do really nice things they help automate at least for us not having to build all this other custom stuff but you don't want gravity forms loading on an API request that's crazy you don't want any other payment systems loading when you're handling an API request and other systems like Laravel you build your own custom routes and you don't have to worry about this but with WordPress this is something that you really have to worry about and if you really want to drill down and improve performance you have to consider it so by doing this we dropped our average non-cached API request from 800 milliseconds to anywhere between 105 and 150 milliseconds that's a huge huge performance increase that's five times more API request you can handle in a single amount of time which is big so things like this matter when you're having to deal with millions and millions of requests yeah I figured you probably wouldn't be able to read much of this there's a link in the slide that gives you a link to this but what this is is this is an actual implementation of the API thing that we did with the must use plugin except with your admin dash Ajax request if you ever want to scale these this is the perfect way to do it if you're ever having performance issues of admin dash ajax.php this is how you do it this is how you get around it this is a must use plugin so if you've never heard of must use plugins go check it out on the codex or the developer handbook and a must use plugin is something that's automatically loaded on every page load you don't have a choice whether it does or not it was something that was ported in from WordPress MU but it's actually kind of nice it's pretty helpful and so you drop this in you check to make sure it's a web request and then you check to make sure that the request that it's sending is to admin dash ajax.php and if it is then we're going to use the pre-option option name filter so we're going to filter the active plugins that are on the site we're going to run in that we're going to check the action because all admin dash ajax request to WordPress require an action for WordPress to do something on it so we check to make sure this is set and if it is then in this simple example we're going to check to see if this is a heartbeat request so we're just going to we're going to hook into the heartbeat API we're going to check to see alright is this request that we're about to get from the heartbeat API if it's not we still want to load all the plugins we're going to treat it like a normal request but if it is then we're going to determine what plugins load in that request in this example nothing because there's really nothing required for that heartbeat to load but I've also defined and commented out what you could choose to load in that request so this is what we did to help with our API request to admin dash ajax and for us an average request that took 300 milliseconds dropped to 75 milliseconds just by doing this something simple just in our own plugin where we checked our namespace for our requests and if it matched that then we only loaded a certain plugin that would handle was kind of like our Ajax Handler and ran only that as soon as it was done it exited and what's the benefit of this you don't even get to the theme setup hooks right your theme you don't even get to that part right you don't get to the init hook everything stops at plugins loaded because you have one plugin loaded and then you immediately fire your callback and then you exit out so you can just imagine how much faster that's going to be versus loading 40 plugins then loading your theme and then having the hook in to make it work again there's a link to this so that you can check it out see how it works caching, you literally have to cache everything that's how the system makes sure that it stays up and that it works persistent object cache we use redis and fast CGI cache keys with nginx makes 99.9% of our request hit the cache the idea here is that you never load PHP or WordPress for request it never even gets to that point just the server level takes that verifies that oh there's a cache key for this let's send back the data that it's requesting it minimizes the act of the non-cache hits to the database which helps it scale our infrastructure we love pagely the guys at pagely are really smart and they've done a really good job helping us with our infrastructure to make sure this would scale so we have a custom setup on AWS with EC2 load balanced instances that it distributes traffic across servers we have RDS for a database so that we have our own database server we use Route 53 for our DNS for high availability plus DNS having a really good DNS so you see that like time to first byte thing a lot of times that's your DNS and your server right so you have a really good server and a really fast DNS you can really really cut that time to first byte now a ton we have a smart and elastic cache with Redis so everything's been cached and job queues and things in Redis we have a smart cache purge policy on updates and save requests so that whenever somebody updates something we make sure that we purge out that cache for them and then we use Max CDN for images and for our API script requests so we're talking about terabytes of bandwidth a day for images and requests so something like a CDN is absolutely crucial for this you have to think about development flow so for us absolutely everything starts on a local machine we prevent anybody from doing anything on staging or production stuff so everything starts on local automatic updates and everything are completely disabled nothing like that can come in that might try to modify files for us, everything starts on a local machine so we have our own vagrant boxes that we've built for our marketing and our marketing site and our app sites and everything so we have our own vagrant boxes that our devs get that we send and we tell them to build gives them everything that they need to start building for our platform without ever actually having to touch any type of live code we split our marketing and app site into separate installs so that way if one goes down it's not going to affect the other we don't want our application suffering and then not be able to continue to make sales or we don't want something to happen on the marketing site and then affect our app site so we split those two things apart we have staging and production environments and we use the get feature branch development workflow there's a great link on this that talks about how that works basically you've got github and you've got issues in github and so you assign an issue to someone so they say alright I'm going to take that they go and they create a new branch typically what we do is we say give the number of the issue and then you know after that just add kind of what the issue is about work on that branch when you're good push that branch up and it'll create as a pull request and then any number of the team can take that pull request and pull it down in their box and test and verify that yeah okay this works and once that's good then we take it and we actually push it up to the master branch which gets hits the staging so then we can say to all of our team okay check this out make sure this works when that's good then we can tag or release and it'll push it out to production we have support and how we dealt with support with this so everything for us goes through help scout for easy ticket sharing for notes for workflows it's integrated with gravity form so we can automatically tag and segment requests to help speed up our support process so we have things like pre-sales or refunds documentation bug reports you name it so that's automatically segmented by folders so we know exactly where to look and who to assign the specific things we have tons of documentation this is one of the one of the things that we really focused on a lot we use something called fuse.js and fuse.js is like a fuzzy search that allows you to the person types up something and it kind of fuzzy searches what they're talking about and it gives them a whole array of different articles that are kind of similar and hopefully have the answer that they're looking for and then we had kind of a create doc for us type idea that we kind of took from help scout but at the bottom of the documentation article it's related to what we're talking about but they haven't found the answer there's a link it says still stuck how can we help they click on it and they tell us it tells us exactly what documentation article they're at who they are and they write their question they basically write our documentation for us we know exactly what to answer so the answer send it to them update the documentation article not helps us scale support and then we have happiness reports to identify trends and ways for us to improve so here are a couple image examples again I know you can't see them very well but in the presentation they're there check them out it gives you an example of kind of what our fuzzy search looks like and the link of how we were on our documentation something else that we had to build inside of WordPress that didn't exist was a notification system pretty much every SaaS platform has some type of in-app notification system WordPress and you know not that I knew had anything like this so we had to build it and it really wasn't that hard here's how you do it you can take a custom post type called notification and you start writing notifications that's that's basically it use user meta to check the state of the notification so is it red is it not red and then you check that against the user registered date to make sure that they only start getting notifications that are that are relevant after they subscribe that's it then you just have a little bit of a user interface to go in and you know maybe when they click it it sends a request back to change the state of it you know we have a pulsing dot to notify users when there's a new notification that's it again all this is on WordPress right all these type of things that you thought never could be done on WordPress really aren't that hard you can do them WordPress works we have jobs and queues so how does it work when you you want to generate a monthly conversion port for report for users you've got tens of thousands of users to generate this for right a simple web request just isn't going to work so we have daemons and workers that handle intensive long processes and they hook into which is really awesome WP the command line interface if you've never used that it's awesome and you can create custom commands to do stuff like this for you WP eval file cron dot PHP you can pass some arguments into it and you generate your own basically your own script code that runs loads the WordPress bootstrap for you and handles all that stuff really really nice we use utilize redis and job queues with workers to you know make sure the server doesn't completely crash when it's trying to do this it's useful for those things like conversion reports and platform data insights but I think the most important ingredient to all of this right so we've talked about process we've talked about code we've talked about infrastructure we've talked about all these different things but I really think that the most important ingredient is your team it's so incredibly important when you're building something like this that has to scale that has to be available for so many users that you have a solid team behind you processes and systems help but your team makes a difference right your team is there with you when you've just encountered an issue and you're going to have to spend 48 hours 72 hours however long to fix it it's got to be fixed your team's there to support you when you're going through that your team's there to congratulate you when you've had a win when you've had a milestone something like for us when we had a huge day where we served 60 million requests in one day and everything was smooth sailing that's all part of a team that's 700 requests a second on average that's a ton and we know that that's not the distributed thing because the majority of your traffic you know between 2 and 8 p.m. eastern time right so those times it's probably even more like a thousand or more requests a second all this stuff it's great to have but you've got to have a team to help make the difference so WordPress was it worth it there's so many other systems that you could use you could use Laravel you could use Ruby you could use Python there's so many other systems that we chose you WordPress so was it worth it totally worth it right it was totally worth it took a lot of work a lot of time but in the end it has been worth it and we're excited that we've been able to really push the boundaries of what WordPress can do to my knowledge I'm not sure I know of anybody else that's done or doing this yet but so far I'd love to know but if not I hope that OptinMonster can be an encouragement for you that if you want to get into something like this or you're thinking about something like this and have questions or doubts about WordPress let this put it to rest right this is battle tested and it's proved worked and it's working really really well so that's all I got thank you we've got a you know a good amount of time for questions so I'd love to take questions and try to answer them the best of my ability yes so she asked why do we think it was worth it well one we spent a lot of time working in it and we love WordPress you know we love the community behind WordPress we love everything about the ecosystem of WordPress but we had not seen anybody that really had tried to do this and there's so many naysayers that say WordPress can never do this WordPress can't function as a SaaS platform it's just not built for it we wanted to prove them wrong we wanted to be able to say no you're wrong WordPress can do this and it can do it very well and so for us not only does it work very well for our customers but I think it's a real benefit to the WordPress community that hopefully as OptinMonster grows as people continue to build applications SaaS applications on WordPress that the world goes out and sees okay you know like this this is a serious contender and we hope that this is a really good thing for the WordPress community on the whole so I hope that answers your question oh development time sorry um maybe but not necessarily at the cost that we did so right it took us eight months and it took us a while a small team of people right so the team dedicated to OptinMonster there's only five people and so it's really not economically viable for us to go out and find a developer and build something for us on Ruby or find somebody and build it for us on Laravel because we know WordPress right we know PHP and we know how to build things with it but we're not as proficient as we were with WordPress as far as development time I think so because eight months for an application that served this many requests and this many users I feel like you know it's pretty quick and for us you know along with the cost associated of us if we were to try to find somebody else or something else to build I think it was worth it sure yep so so it was all of us coming together so fortunately you know I was really by the first time when we tried to launch a SaaS platform and it just failed you know I'm a front end guy I'm not really a server level or architecture or systems guy and so that forced me into learning a lot about it and we have some really smart guys on our team developing that know a lot about it too so conceptually we knew how it needed to work putting it together we needed help with that so we said okay we know exactly how this needs to work now we need help of actually putting it together and that's where the team at Pagely came in so their guys are super smart they know how to scale WordPress and they helped us build a custom solution because their typical website that they host is you know built for page views and visitors ours is more API based and so they helped us build a custom solution to make sure that we would be able to scale and work and so it was a learning process for all of us involved we were pushing the boundaries of WordPress and you know we knew okay this conceptually this how it needs to work and we got it working as best we could and we said alright you know now it's going to be now or never and you know we got it launched we only had a little bit of downtime in the first week as we worked to figure out the caching especially with Redis but once that you know once that was set up and good really haven't been any issues since and since it's set up on Amazon web services it's very easy to scale it's easy to load balance add new instances and bring it into the infrastructure good first of all make a comment you said five people for eight months yes it doesn't sound like a whole long time you get over three main years of development work true yeah well I say they're five people in our team they're really two of us that were really working on the platform itself so we had support from the other folks that were in it that don't really do development it's a big project but yeah it is for a small company and a small product like that it's a lot of resources yes optinmonster.com no I mean like where is it used why are you a customer oh gosh give me a comment on it so recently we just worked with somebody called hodinki so hodinki so H-O-D-I-N-K-E-E they are the largest wristwatch magazine in the world so they do stuff all about wristwatches the guy that founded that is Kevin Rose he founded dig.com and so we've just worked with them to get a custom optinmonster solution for their site so you can find it and check it out there other big sites that you can check out are like the quickbooks blog Intuit blog they also use optinmonster as well okay good how do you feel about the decision to not immediately go back after trying to rebuild the first version and going through the plug-in route and then again failing on that and then going back to it do you feel like that was a worthwhile experience to go to the plug-in route and having to deal with some of the issues that you had listed out there was that a good experience in hindsight yes during it it was not fun it was very stressful in hindsight it really helped us to be able to one we were already comfortable with the WordPress ecosystem we had built products and things before so for us it made selling and marketing and supporting that type of thing a lot easier because we had already built efficiencies around that it allowed us to really figure out how users would use the product and some of the pain points that they would come in contact with and it allowed us to find out what are some of the common issues including opt-ins on different types of sites and all that how do we need to build our JavaScript API to accommodate that so that really came in handy when we wanted to take it and move it to any type of WordPress site essentially we move it to any type of WordPress site and the only issues that we have are migration issues that we have to deal with from WordPress to the platform but for new users of the platform it works really really really well and to them it's like a new product or service because they're not in the WordPress ecosystem they haven't heard about it and so for them to be able to sign up subscribe and use the service the technology works really well and they instantly see an increase in subscribers that's a huge benefit and a huge win so in hindsight yes it really prepared our team and helped prepare our team in that way at the time definitely not so the question is how do we plan on handling WordPress core updates so for us one in our development flow every type of update is disabled completely so there's never an update that goes out that's not audited by us first so we have that benefit of always knowing that everything we have will be audited on top of that we built a lot of systems that abstracted stuff outside of WordPress so that while our app is powered by WordPress it's not completely dependent on the things inside of it it's more built on top of the APIs that we know won't change like the user meta API or the transient API or the object cache API it's built on top of those things that if they change there would be a huge uproar right so it's more built on those stable components doesn't really have to worry about admin, UI issues and changing and all that because for the user when they come to it they never know it's WordPress right for them it's just another application dashboard and this is how you create things and all that same cool no and the reason why and I've talked to people about this as well and I talked about it here a little bit of that example that I gave about the API and the plugin the reason why the WordPress API is awesome right it's really cool but for us in the way that we needed to scale and performance it doesn't work because it doesn't register until the init hook right so you can't even process a route until after the init hook is fired that means all of your plugins have loaded all of your theme is loaded all of the functionality that the plugins provide has likely also loaded too and for us that's just not economically viable it really dense performance and it really it drags out a request makes our response time longer it hogs up bandwidth so it costs money and because of that unless some things change with it I don't for cs using that no actually to date I believe we spent zero dollars on it as far as I know we have I say that it's very very small amount if we have spent anything so we marketed to the audience of wp beginner you know they're a perfect audience to start that by this point soliloquy soliloquy had been launched and had a very established customer base and I'm fortunate that those customers are pretty loyal and so I was able to say hey check this out we got this new thing we were able to build customers from that and then we also had connections with other people that wanted to use this right again that ten thousand dollars a month is prohibitively expensive for a lot of people and so when we drop it down to price range it's so much more manageable they're like yeah we want to use this and we'll write about it you know it seems that it works we'll write about it so that was kind of our marketing we got some people on board when we first started that said we'll use this and we'll write a review about it we had our own customer base and then we had the audience of wp beginner and so that's kind of how we got started for marketing sure work press not work you wanted to offer functionality and stability work press fell flat when you went in and installed wall you didn't get around for what would have been your alternative to forget the project or go for some other sure so the question was if work press fell flat in his face and we failed again what would we do for us this particular market is very competitive and we could stay at work press plugin for a while and do really well but we could never grow beyond a certain point and obviously that didn't happen so this is only hypothetical of what we do we would try to figure out some way to make it into a SaaS platform we would figure out some way just because the sheer amount of requests that we had that's what you did but it's with wordpress did you ever consider an alternative to wordpress no we know wordpress and that's what we were going to do yes one customer demand when we have so many pre-sale inquiries about it we already know the demand is there we're already reaching that type of audience so for us it wasn't really an issue of worrying about was this going to be successful as far as new customers and all that because we already had the data to prove okay there are people that want this and they're coming to us expecting us to have it and we either have to tell them that they don't or we're refunding them money because we don't and so for us the decision to go to go that way as far as the marketing and business side was pretty easy the infrastructure side with wordpress was the one we said okay we know wordpress we're going to try to do it on that thank you are there any partnerships in place with these mail companies, mail champs contact today obviously you wrote the API store for time and support helped in any way sure so the question was do we have any email service provider companies that we've partnered with in particular not after we launched the application platform but that was because we had already built a lot of relationships previously with the plugin like we've done some webinars with Aweber and we've talked to other companies like infusionsoft to be featured integrated developed partners, marquetto all of these but in particular now okay any other questions? cool alright well thanks so much guys for coming you can find all this stuff online tweet at me