From Concept to Listing: Navigating the HubSpot App Marketplace Journey

Sa.

So.

Yeah.

Hello, everybody. Welcome to the next episode of the Developer Hug. And to bring us up to speed right now I have Anton Buenowski, who's going to lead us through the intro and we'll go into two and after that. So take it away, Anton.

Okay, perfect. So, welcome, everybody. We have this DHUG today about navigating the app marketplace. And if you're working on an app or want to create an app, this dhug is for you. And let's start with the agenda. So after the quick introduction, we have great speakers, Pete Nichols, Mike Eastwood, Jesse Cunningham, and Nicole Casera. And after that, we will have a panel discussion where you can just drop all your questions right in the chat. So have fun. And before we start, a quick note. The next event will be Code with Confidence best practices for HubSpot CMS developers. So if you are a CMS developer or want to become one, this DHUG should be a great start. And it will take place on the 21st of March, and you can sign up at the shown link. So, yeah, have fun with the dhug.

So I have the amazing honor to introduce our amazing guest speakers that are absolute industry experts about the subject that we have today. First of all, we have Pete Nichols, founder and CEO of Hub. We also have Mike Eastwood, founder of Webalite and Portal iq. Then we have joining us Nicole Caceres, developer process professor at the HubSpot Academy, and probably the MVP for most people who are already building apps is Jesse Cunningham, the skilled app partner manager at HubSpot. I'm going to give the mic to Pete Nichols, who is going to start the first session.

Hey, everyone. Great to see everybody here. We're. We're going to dive into a lot of detail here. And in fact, let me get back to my starting slides here. Give the game away. So, topic for the next 15 minutes is we're going to talk about building your first HubSpot app. But I'll phrase that here as HubSpot first, which you'll see why in a second. If you've ever developed an app, I think of that as like serving up a delicious dish. You might make a great spaghetti Bolognese, but someone says, hey, you should open a restaurant. There's a big difference from being able to cook a single dish and serve 100 spaghetti bologneses every day consistently. So we're going to talk about the challenges in doing that and try and take some of the mystery out and use the experience that we've had by doing that with several public apps to be able to help you with that. Make it easy. So, building your HubSpot first app, what type of apps are we talking about? I've coined the term HubSpot first as a way to differentiate the apps that are on the marketplace because many are integrations. So think of PandaDoc, for example. That's a big, standalone, fantastic app. It integrates really well with HubSpot. It also integrates well with Salesforce and a bunch of other platforms. So normally those apps are integrated to HubSpot from inside the app. Whereas if you're writing an app that is only for HubSpot, it's generally either going to be some middleware. So it's sitting between some other software and HubSpot that might be Stripe or some other enrichment service, or maybe you're feeding data back out to a reporting facility. So the middleware sits between. In this example, we have an app called Do Currencies from Hub do, which takes the currency rates from currency API.com and then updates those in the customer's HubSpot portal so they don't have to do it manually. When you're building middleware, just really check the T's and C's of the other servers, such as currency API.com because if you're charging for your app, there's a good chance that, that you're either not allowed to use their service that way or you have to pay a special distribution license because you're creating a paid service using their software or their API. So that's one to be careful of. And the third example is a feature addition. So we have an app called Dupricue, which sits in HubSpot and it only talks to HubSpot. Its whole purpose in life is to apply the right price and the right discount automatically to line items on deals and quotes. So it doesn't need to talk to other software. Everything is stored inside HubSpot. That's our HubSpot first apps. So let's say you have your idea for an app. You've got. You've got a cool idea, you know how to code it, and people you've told about the idea said, absolutely, you should build that. It's a game changer. They're not necessarily the people who are going to pay you, though. So just take that back a notch and consider what pain are you solving. You're looking for problems to solve, and that is pain. Now, you can find that in the HubSpot community forums. You can find it talking to the industries that you look after in real estate or manufacturing, whatever that is, you'll hear the pain and then to decide, does that pain equal pain with a Y as in pay? Is it likely that businesses are going to want to pay money to solve that problem on top of what they're already paying for their HubSpot? If your app runs on HubSpot, you're in addition to HubSpot. And then thirdly, there is always that risk that HubSpot might release a feature that makes your app redundant or changes. We've seen that happen when HubSpot Commerce Hub came out, then the Zebra app, which is a fantastic stripe subscription management. There's some confusion then of whether people choose Zebra go with HubSpot. So just being aware of what HubSpot might do. When you put your app out, you can't get a little bit pregnant on this. Your app is then installed, it's in the market, it's in HubSpot portals, it's doing its work and you can't just switch it off, but you need enough users to make it stand up as an app. And there's a very long tail of apps that don't have a lot of installs. I did a study late last year just looking at the active install counts of the 1500 or so apps on HubSpot Marketplace and found that over half of the apps that were in that 1500 have less than 100 active installs. Now you can look at the top figure, your market opportunity. HubSpot has just passed 200,000 portals installed. So I was like, wow, surely I'm going to get thousands. Well, the data is here. If you can get to 100 active installs, you've already beaten over half of the existing apps on the App Marketplace. That's why I really recommend that 100 Active Installs is your primary goal, whether it's a free app or a paid app, because there's a very long tail of 20% of apps have less than 20 active installs. Another 20% have less than 50. So you'll be ahead of over 800 apps. If you can get to 100 now, your goal might be revenue. Do you want to charge your monthly recurring revenue? Is it about revenue, in which case number of active installs and the price is really important. Or it could be we're starting to see a lot of free or freemium apps where agencies are producing apps purely like to replace the old lead magnets, because it's something that gives you a connection to the customer from which you could maybe offer them other services. So there's one agency in Italy that have produced a whole ton of free apps purely just to get those leads. So I've given you the example. We put out one free app, the do currencies one I mentioned earlier, that went out in September. So it's only been in the market for about four months. And we're generally getting one to two businesses a day. We'll install that. So it's about 136 installs now. And yeah, we're working out how to add more value to that audience. So then how do you price it? That's the challenge. If it's a free app, that's easy. If it's paid, there's confusion over what tiers are and what editions are and how. It's a real mystery. And so let me give you some rules of thumb that work really well. That is that you have three main levers that you can pull. There's the tiers lever, that is are you billing one time, monthly, annual quarter. Best to think of tiers as being the payment cycle. And then think of the feature sets. We'll offer these features to a basic customer and then these other features to a premium. So think like with HubSpot editions of starter and Pro and Enterprise, those are feature sets. And then the third dimension is the value. You want to anchor your your pricing to the value you create. HubSpot does that with more user licenses on sales hub or service hub or marketing Context just rejigs the pricing. So there's no perfect way to do this, but you're looking for value. So a good rule of thumb is that if you can establish in the customer's eyes that they see that you're creating $1,000 worth of value for them per month, month in, month out, then there's a good chance you can charge 10 to 20% of that 100 to $200 per month for your app if you can reliably generate $1,000 worth of value for them. This is a whole science in itself. It's a whole presentation in itself. But that's a starting point for, for pricing. A good tip is you don't always have to have a freemium version. You could offer a free trial and then have a free version, but hide it so that if you need to, you can apply it to customers if they really are resisting going to a paid edition. Or do paid add ons. Put the base, maybe a free product, and then put a separate app out as paid add ons. Here's a way you can potentially add value, add workflow actions. I recommend that you do only one in apps. From the research that I've done, only one in eight apps have workflow actions. If you don't put workflow actions in your app, then your customer probably has to get Operations Hub to automate things over and above the standard. And putting a workflow action in makes it easy for them to derive more value from your software. I've put a note on the slide here because I had a chat with with Cloud Files, which you may know already. It's a great app for linking SharePoint and so on into the CRM. It talks to HubSpot talks to Salesforce. I recorded a podcast episode with Sid, the founder, just over a year ago and they didn't have any workflow actions. They required the customers to buy Ops Hub to automate the creation of folders for new deals. So they built nine workflow actions after that that discussion. And they've just recently passed 1,000 active installs. And from the numbers you saw me share earlier, 1000 is a pretty serious milestone to reach. So congrats to Cloud Files for doing that. And I would say a big part of that is the workflow actions. The other way that you can add value is the settings screen. Hardly any app developers do this, maybe because many of them are not HubSpot first developers. But if you're a HubSpot first developer, if your app is going to live in HubSpot, you should have this. So you only need to define the settings screen within your app definition and then you've got the ability to put settings. So anyone who can reach this as a HubSpot admin can then tune the features of your app inside HubSpot instead of taking them out to some other interface. If you can put it right here on the Settings screen and you can add feature discovery as well with slides and videos that right inside HubSpot show what your app can do. And it's a great way to keep users inside HubSpot. If you're a HubSpot app, that's where you want them to be. Let's look at, say, an example listing of what happens when you have your app written and it's on the Marketplace and you have this Install app button. I think what is commonly not well understood is the mystery behind that button of what does HubSpot do for you when a user presses it? Nothing, actually. Everything that happens when the user clicks that button is up to you. So if you're going to set up a subscription and bill and charge stripe and all of those things. HubSpot doesn't do that today. Maybe they will in future, but this is down to you. So what I often see is that a single app is put out with all the subscription management and the stripe and the app is all in one. And then you end up kicking yourself in the shins when you go to write your second app because now you've got to do it all again and you have the friction that a user has to enter their credit card again. That's crazy. So you don't want to be a one hit wonder with one app if you're going to produce one. And HubSpot might make that redundant. You want a second or third or fourth app. So here's a way to do it. Every app is going to need some subscription management and so signing up for a free trial, free trial failed, or the card failed, card was suspended, free trial expired, converted into a paid user, all of these things. Pretty much every app that has a subscription needs this. I like to separate this into the control layer. This is your control layer. This really doesn't have anything to do with what your app actually does. It's just what every app requires. If you can separate it out, have your control layer be responsible for starting, upgrading, downgrading, canceling a subscription, changing the edition, adding more users, removing users, sending invoices, collecting payments, managing free trial through to active to suspended, put all that in a core platform. A lot of the multi app companies, such as Happily and so on who who have multiple apps out, have found with app two and app three and app four that you've got to have a dashboard central control and then loosely couple the control layer to your app. Your control layer really just needs to tell your app, make a subscription, change the subscription, change the addition, assign a user, unassign a user, not much more than that. The app then takes care of all the security side the authentication, the refresh and access tokens, the regular check. Because the customer might have uninstalled your app from HubSpot. How would you know? So the app can do the check of whether the tokens are still valid. The job of your app is also to count up the things that are part of your value. Like if you're charging per transaction, count up the transactions and then with the billing cycle the app sends up to your control layer. There's 2,000 line items created this month and so put that on the bill. Your app has no business knowing the what these things cost. It shouldn't care. Manage that in your control layer and then you can tweak your go to markets, you can do central billing, all of those adjustments without having to do another CICD lifecycle rollout of your code because you can make all those tweaks in your control layer. Right. Everything I've touched on here, just about every slide would be a whole hug session in itself. So I'm now going to go into a live demo in a couple of last minutes I've got before we then jump into Mike's session where we dive a little deeper on some of this technical content that we're going to just show you. If you've never seen this before. Actually, I'm going to dive into a developer account and do this live. I'm in a prod account where you if you've never seen this before, this is the developer account where it looks like HubSpot but the menus are completely different. So we have our apps here and on the App Marketplace tab we have our listings. And these are the live listings for Due Pricer and Do Currencies, the two apps that I've mentioned. And I can see there that there's 136 installs of do currencies, five reviews, really nice one come in today, 37 installs of Duprica. And you can see that Duprica has a button there to certify the app. Mike is going to talk about that. You only get that button when your app has been live for six months. So Do Currencies. It's not yet at the six month mark, so I can't certify that yet. We're just about to do that for Due Pricer. Let's make an app and make a listing. So if I go back to apps, create a HubSpot app, how hard could it be? Let's call it the D hug and we'll put an icon on it. That's the icon that's going to be used on the App Marketplace will be listed and and then on the authentication tab. HubSpot is just waiting for a couple of little magic items in here. It needs to know the scopes. So you only want to choose the scopes that your app needs. Do not choose more than you need it. Problems downstream with certification, if you've got more permission than you need, plus your listing will get bounced if you don't tell users what you're doing with those scopes. And the final thing you need when somebody installs your app is a landing page. So if you had I don't know, my app.com installed, there's there's an endpoint there that is waiting to hear from HubSpot that somebody's installed your app and you get the really important items of the refresh token. Because this is OAuth2. It's not like a private app. You get a refresh token and you get the portal that it's been installed into and a couple of other things, but with those I'll just create an app that's now ready to install. Like I could, I have an app ID that never changes and I could copy this full URL, I could send that to you in the chat and if you click that link, you'd be offered the chance to install this app. The app doesn't do anything yet because I haven't written any code. But that's the HubSpot piece. So then if you, if you want to define it further, this is where you can do things like your settings screen that I talked about earlier. You define that here, you define your webhooks here, timeline, events, CRM cards and so on. When you go to list your app, I go across to listings. I'll go to create an app and I can't list the D hug because it doesn't have installs. Nobody's installed it yet. I need three installs to start the listing. Those can be any. They could be three test portals if you like. And then you could start the listing. But you cannot submit that listing until you've got three real customers, not you, not your test portals. You need three real customers with it installed and then you can list it. Now I have one and I'm going to real quick show you do quotes. That's an app that's currently in beta. We're just doing the product market fit on that at the moment to create your listing. So it's an English only app. And then you get to follow the bouncing ball, fill out all the listing info. Do not underestimate how much time this takes. You've got a lot of content that you need to put together because you've got not only the selection of categories and URLs of what you want it to be on HubSpot at Marketplace, but you've got all the app description, the images. You've got to make a video to show a good job of how it works and what it does for HubSpot to approve. You also have to detail your shared data so all the scopes that you've defined. If you've got something that's reading and writing companies, you've got to Say I'm reading and writing companies or you won't get listed. Then your pricing, you've seen the challenges around that. Once you've figured out how to price detail all of that. And you've got to have links to your Terms of Service, your privacy policy, a link to the documentation. And the documentation must have a setup guide that shows screenshots of everything that a user has to do to install your app. And I know I'm moving through this fast, but I'm on the last screen here where you give some instructions to HubSpot. Here's how to test my app so that hopefully within two or three days your app waits, your listing waits in the queue and. And then you're listed and away you go. So that's my live demo that actually all worked. Let me finish with some quick tips. Marketplace listing I mentioned that takes a few days. Three real portals before you submit every step of the way. Setup guide and specify and use only the scopes that you need when you are live. Here's some other tips. If you want to figure out whether you've been uninstalled by the client, check if the refresh token still works, if that's valid. We do that every day, just daily heartbeat check. Make sure the app checks whether the subscription is suspended because you don't want to keep running workflows for somebody who is not paying you any longer. And something that maybe is not well known is you cannot force an uninstall of your app. So if somebody plugs your app into their portal and you've registered for a bunch of webhooks, and so you're now receiving 10,000 webhooks a day from that portal. Too bad you're gonna have to swallow those and dismiss those zombie webhooks because they're gonna keep coming at you until you can get that client to uninstall your app. I'm gonna stop there because the topics around rate limiting and so on, this is all coming into Mike's section. So I'm going to leave on something that we will bring up again in the. In the panel. I'm launching today an initiative of something you might be interested in if you've never released a public app and it's called my first App Beta, we've done a similar program before for small agencies that wanted to get to Silver and Gold and above. So I have a Slack group set up for this and the link is here. If you're interested in being part of a cohort of other developers to get your first app up and running. We want to try and try and do that together as a group. So that's me done. Mike, I'm going to hand over to you. Mike's in the land of the long white cloud in New Zealand. Mike, are you there?

Good morning. Thank you, Pete. Like, I love coming on talks where I'm learning lots, so I'm going to talk quickly with a funny accent, make it more difficult for you, just so I can finish early and go and implement some of the things I learned off Pete today. Hi, I'm Mike, I'm a geek. I've got a HubSpot partner agency. We're gold tier based in New Zealand and I'm also the creator of Portaliq, the world's first HubSpot audit tool, which is in the marketpl and I'll talk a bit about that today. There's a QR code there to connect with me on LinkedIn and I'm going to jump into the slides. So I've proposed the question to certify or not to certify. The app on the left is a primary contact tool, which is one of the case studies I'll talk about today. And it says in that little panel, when somebody installs it, this app hasn't been reviewed or approved by HubSpot. Not a good look, but people are installing it. The one on the right, however, is our Portal IQ app and that's got HubSpot certified app and I'm super proud of that and I'll dig into some of the journey, some of the mistakes I've made so you don't have to make, make them. So starting off with Portal IQ, it audits your HubSpot portal so you can implement best practices. And this is a bit geeky, so I'm going to go through this. So as a customer, you start with a cta, enter your contact form. This is on the Portal IQ website. It then takes you to go through the OAUTH and allow people to install the app in their HubSpot portal, which runs across the bottom. Number three comes back to a.

Form.

To get the company and the report details. Number four jumps out to stripe. I'm just rebuilding this at the moment. We've now got HubSpot payments available in New Zealand, which I'm pretty excited about. And then it jumps back to a thank you page. What happens in the background from there is that the Portal IQ app on the right creates a custom object. It then uses the APIs to benchmark the customer's portal and Saves that into the database. It then compiles and I actually pull out pages out of the HubSpot CMS to render the final report, which is published to a PDF, and then the system pushes it back into the CRM so that we can then talk to the customer and help them optimize their HubSpot portal. So case study number two was my first app, and this is a CRM card, and I was at the bleeding edge of CRM cards. This is quite a few haircuts ago. First mistake I made was I called it the HubSpot Toolkit and by WeBlade, and that got rejected in the marketplace. Now, what's in a name? It wasn't just the name, it was the fact that my URLs, my subdomains, my checkout cart, my documentation, the data in the app card, the CRM extension, everything. I'd used HubSpot on the name and it was rejected. And by the time I'd finished stripping all that out, rebuilding it, I didn't have the energy to actually launch this. This is basically the card. It's a CRM card that allows you to set the primary contact for a company. And this was an issue years ago. It's now been replaced. Well, it hasn't quite been replaced by association labels. Now, this is a really interesting point that Pete talked about, and in the app space we all talk about a lot. It's like if you create a need or solve a problem for a customer and create an app, HubSpot may roll over and just squash you. If the feature is missing in HubSpot, the chances are they're going to develop it. So please bear that in mind when you're thinking about your app. It may be a great idea, it probably is a good idea, and if it's a really good idea, then HubSpot may actually be working on it already. Now, the good news out of this, years after I created this and after association labels, I've still got customers using this app and I've got reviews where people prefer my app to the using association labels. So, good news, bad news, it's too soon to tell. So the first question I want to talk about is private apps versus OAuth. If you want to release the app publicly, you're going to use OAuth. It's a bit fiddly to learn, but please put the effort in because it will serve you really well. And now, as if I'm doing a custom integration for someone, I just zoom through the OAuth thing. No matter what system it is, your life will improve. It's even to the point now where I tend to do test apps as OAuth apps because I've got the infrastructure built and I just find it easy to use. Use OAuth now. If you'd asked me that a few years ago, I would have been muttering and swearing under my breath. On the left here, we've got private apps and private apps. You can't launch an app into the marketplace with private app. They're quite useful for developing apps that you don't want in the marketplace. But there are still restrictions and the restrictions, some of the APIs don't work with private apps. You've got to set up one per portal. There's a few gotchas there. So that's why I prefer to go with OAuth when I'm working on an app, even if it's not going to be sold in the marketplace. Scopes. Now, Pete touched on scopes. Scopes are super important. Let's look at a different angle. When you have a customer install their app into your app, into their portal, they're giving you permission to go into their HubSpot portal and pull out data. That's a big deal. There's a lot of trust there. And I'll talk a bit more about that later. Less is more. And a good example of this is portaliq, because we ask for dozens of scopes. We've not maxed out the scopes, however, they are read only and we never write data to the system. So I was very explicit with our process, both for the customer and our privacy and our code. And really grateful. Just a quick shout out to Isaac. Thank you for helping me through this process. There's an amazing team at HubSpot that are helping you get your app certified. I'm going to introduce Jesse soon, who's another one of those experts.

So.

Think about your user experience, think about the privacy and security and less is more. But enough about that. In your developer account, which you just saw Pete racing around at the speed of light, I encourage you to create test apps. And that means you can have a like, like a development, a staging and a production test that and you can move your code and that means you're not going to break something that's in production or you might actually, but it just. It'll be less stressful for you. Yes, I know it's more work, but I recommend that. So this is in the developer account. You'll see here one of my mistakes. I created the primary contact toolkit The Weblight toolkit Primary contact just flows off the tongue, doesn't it? I hadn't mastered optional scopes at this stage, so I created an enterprise app which had more features. And my mistake there was if I'd used optional scopes, I could have put these in the same app and the install base would have counted as one app rather than splitting it across two, which dilutes my effect in the marketplace. So that was a gotcha. Learned that next. You can see my Sandbox API there. So that's got lots of scopes and I only use that for testing. In your developer account you also get the opportunity to create portals. So I'll do a development, a staging and a production portal for an app I'm working on. And again it means I can experience that safely without breaking things in production. I can test it, I can debug it, and we'll come to that soon. You'll notice here the trials expire after 90 days, but you can click the button and renew a trial and they will keep you'll get a full HubSpot portal. A little gotcha there. As a HubSpot partner, I get tripped up occasionally when I'm working in an enterprise portal. I go to do something in a starter portal or even a pro portal and that feature is not there. So one of the gotchas is the test accounts. You can't choose what tier, it's always enterprise and it's got all the features. So just be careful without over promising. Another feature in the developer portal is monitoring and you can come in here, filter by errors and this is really helpful for debugging because you get to see the object going in and out of HubSpot and you can dig down. You're going to come across weird areas that you don't know what's going on. This is a really good way of seeing white HubSpot sometimes shrugging its shoulders and just going, nope, have a dig around in there. There's logs for API calls, webhooks, CRM cards and app settings, which is the page Pete talked about. I've done my first app setting page this year and I love it and it's now going to be my standard Moving forwards, please use the SDKs SDK or Software Development Kit. There's basically some smart people have gone before us and created the code to call the APIs. This will save you a ton of time. One of the gotchas There is I'm php, I'm old school. There are multiple different SDKs for php. Check the version, check the release date and check the support. You should do this with anything you see in GitHub, but just make sure you've got a current version that's active and people are contributing and reporting errors. Yeah, the SDKs will save you a heap of time. They're also available for JavaScript nodes. I can't remember Python. Maybe there's a whole heap there. Download and use Postman now. This is a great tool. It allows you to send and receive data from HubSpot and see what's going on in the background. So great for debugging, great for digging into information, great for seeing why things aren't working. There's some really good videos that Dennis and the team have put together about using OAuth with Postman, which is another superpower of Postman. And that means you can use your tokens to send and receive data so you can test the way your code will work. So, great product. And in the documentation in the version three and above, there's a little button there you can say run in Postman and it will actually move the API endpoints into Postman and it's going to make your life easier and less stressful. Always use version control. Please, please, please. This is non negotiable. I use BitBucket because I'm in the Atlassian ecosystem, so I use Jira. You can see my Jira tickets are linked to these commits. You're just in dangerous waters if you're not using version control. Yeah, enough said. Use AI. This is a new slide. No presentation would be complete without an AI slide. I'm using Git Copilot in Visual Studio and while it's not ideal at handling Hubble, it's still learning for things like php. It is a game changer for me. Yes, it makes stuff up. It will make up methods, it will make up functions of native functions that don't exist. It makes stuff up. Fortunately, I've had the luck of writing bad code for decades, so I know bad code when I see it. And I'm pretty good at debugging bad code because I've had lots of practice. So if you're sort of on the fence with AI, I'd jump in, maybe do a little test project, maybe do your first app, give it a go for me, I think a normal hour, I'd save 10 minutes. On a good hour, I might save half an hour. So you think of the change in productivity if you're using a tool like this and it just keeps getting better. This is another always, always Always, please. When any information comes out of HubSpot there is a hash token that travels with the data that you can decrypt to authenticate that. Now I talked about SDKs before. The SDKs will have a function to decrypt that token and the token is made up with the the data in the JSON that comes through, it's made up with the date, it's made up with the HubSpot secret which only you know and HubSpot knows, which means you can compare the data at your end and make sure they match. Again this is. It's going to be annoying when you start, but the sooner you build this into your process, the less stress later on. So this will stop. Nothing's perfect. This will reduce drastically the possibility of anybody sending data to your system that's not originated in HubSpot. So it's in the developers doc. Have a look. Spend some time learning how this works because it is a game changer. I talked a bit about privacy before. This is super important for me. My role is if you don't need to store it, leave it in HubSpot, don't even save it. This is an example from Portaliq and shows where I do need to save the data. And this is a report on a benchmark from one portal. And you see there is no customer information, there's no process, private information, there's no emails, there's nothing there. So even if I publish this table online, there's nothing for anyone to get. So if there's nothing to get, then you're reducing your risk dramatically. One of the gotchas to look at is your log files. If HubSpot does a for example, a CRM calls a CRM card, there can be sensitive data in the parameters passed to your app and that may end up in your log file. A good example is an email address. It's pretty minor, but you know, we still don't want to be saving people's email addresses in our log files in our database, anywhere really, unless we absolutely have to. From that point, if you do need to store data, why not put it back into their HubSpot portal? Like there's a safe secure place and you can go, no, I read the data, I processed it, I put it back and it's sort of you're still responsible but it'll be less stressful for you and better privacy, more likely to be certified as an app Documentation Pete said before, don't underestimate how long it will take you to fill out your listing. Same goes for your documentation, the more you can put here, the better. And it's better for your users that ability for them to see what's going on, understand, create, trust. It's better for SEO. You've got an opportunity here to leverage these pages for Google and create good content. We all need good content. And then the other thing is the team at HubSpot are going to be reading this and they do read it and giving you feedback and the feedback is fantastic because I want to make my product better for my customers. And like going back to the certification team, they want to make it better for their customers. It's a win, win, win. Just a small little thing on pricing. So I always do a good, better, best pricing model and you could do free startup, pro, enterprise. I did some more creative versions. Like I can't remember I had a basic originally and now I don't even know what basic is. So I align my plans with HubSpot tiers now because it just makes more sense and people have that information in their head. Like going back to the primary contact tool. It's monthly, it's recurring revenue and it's just the drip. But it's a drip that turns up every month and people keep renewing their subscription. Portal IQ is a one time audit product. People pay. The value they get from it is huge. And pricing, we could do a whole talk on pricing. Pricing is hard, so I'll leave that there. So certify or not to certify? I think it's pretty unanimous. Getting that little badge to certify your app is the ideal way to go. But there's still cause for having apps that don't need certification, particularly if you're doing something for just a couple of customers. The certification process takes a while and I'm really excited to introduce Jesse. He's going to explain more and sort of demystify that. So thanks for your time.

Thanks for the intro, Mike. It's going to be challenging to follow up with two great speakers who covered a lot of the nuances and technical details of pricing and listing and subscription. I'm going to be talking more about today. Why are we building an app, who is it for and how are we going to get them to use it? Looking more at the strategy side of driving awareness and adoption and solving for customer problems. So I'm going to go ahead and start by looking at two questions. Who's going to use this? Are we solving for existing shared customers? Are we trying to drive new customers through this app or or integration? So when we're looking at existing customers and a tool that's building an integration with HubSpot, we want to think of how and why is the tool better with HubSpot, what can we unlock for the shared customers by having the two data sources connected and syncing back and forth? How can marketing, sales and services, a lot of the users who are using these core hubs of HubSpot, how can they benefit from the two tools working together and also thinking how many customers can benefit from this? It's a really important question to understand when looking at the opportunity of building an integration. We know from a lot of research on our side and a lot of research in the partnership space at large, a great integration often leads to better customer value, higher usage and better retention of their app. In solving for the customer, I always like to put that first and foremost. That should dictate what an integration does, figure out what gaps they have and the pains they have and how we can solve for that. A great example that I have listed here is project management tools. If you're using a project management solution and HubSpot is your CRM and you know for each new client that your sales team is closing, you're going to create a new project for them that should be a custom workflow action when a deal hits a closed one stage, trigger that project to be created in your project management tool. Less are going to be slipping through the cracks for human error, always going to be fast and efficient with it and just going to make the two teams more efficient together and again making it stickier and better for the customer. Next is looking at how do we identify the opportunity? How do we know if it makes sense to build an integration with HubSpot? A big one is learning about what's the ROI and what is the total market size for the integration. The first thing I would recommend looking into is what is the lead customer and prospect overlap. There's tools like Reveal where if you're a listed partner or prospective partner, we can submit an NDA and get connected on Reveal to understand what this overlap looks like. There's other tools like Wappalyzer and Chat Spot if you're a HubSpot customer as well. So we just want to better understand existing customers. How more can we retain better and drive stronger value with them? And from the prospect side, how many more customers can we win for your business and how much faster can we win them by leaning into the integration and the stronger value of the two tools better together? Next is what do HubSpot customers look like to your business. And this is a really interesting point. When companies are coming and considering building an integration, when we dive into the data oftentimes, or in most cases, we see that on one of these metrics, deal size, close rate or close speed, that HubSpot customers are performing better than other customers. They're a bigger company size and deal size, they're closing at a higher percentage or they're closing even faster. If we're seeing one or all of these metrics, it's a good thing to show to stakeholders, to get them bought in on building integration, because it's going to make a lot of sense. Next is the new customer side. I think this is probably a lot of the audience that's watching today is thinking about how am I going to drive new customers through an integration? A big question to ask is what problems are we solving for existing customers? Pete brought up the example earlier, which I think is a great one, is the do price or by Hub, Do Automating discounts and price lists in HubSpot is something that that product just simply doesn't do today. I think HubSpot, and maybe I'm biased because I work for HubSpot, but I think it's a robust and remarkable tool. But it doesn't do everything possibly imaginable, which it probably shouldn't anyways. So automating, something like that is where a partner can fill that green space or arrows with onboarding. HubSpot doesn't have an onboarding solution right now, and that's where Arrows can build an integration in an app and come in and say and solve for that. HubSpot's not doing this. We know customers need it. We're going to build that and they're our number one onboarding app in the marketplace today. Even being a small team and small startup when they first got started, we also want to think of how does this tool make their experience better and drive better results for their business. HubSpot has a calling solution already. You can use calling within HubSpot. So why is Air Call still one of our most used integrations or apps? Because the depth and robust solution they built is further than what HubSpot has today, which really drives a lot of value for customers. And again, that green space, look at what the HubSpot product has today. Can you build beyond that and deeper than that? And can you build it faster? HubSpot being a big company, some things need to get put on the roadmap and it might be a couple quarters or even a year before something gets built. And that's green space for partners to build as long as we're keeping in mind that some of these features may come later on. So I touched on maybe building multiple apps. A key, key piece that I cannot stress enough is that is this really a solution that HubSpot customers need and are looking for? Pete touched on this as well. Sometimes we see apps come in and they're building what seems like a great idea, but they don't have any beta testers, they don't have anyone to use it. So how do we understand the validity of the app or if it's really solving for what these customers are looking for? So again, I cannot stress enough, it's really important to understand Is this something HubSpot customers want? Is it something they need and at what exactly do they need on making sure that we're building that specifically. So next is building the integration and like I mentioned earlier and I'm if you see me on LinkedIn or ever talk to me, you're always going to hear me beating the same drum. We want to solve for the customer. Like what are we unlocking with this integration? I think that's a really important piece to really hone in on. And how's the data going to be used within HubSpot? Is this in a feature add on that it's going to be doing something within HubSpot or are you syncing data over how are the teams going to be using it and how can you tie that into their bigger workflow to drive stronger retention and better usage? Things like list creation, reporting, automation triggers, it goes on and on. And I also challenge anyone who's building an app or have an existing app to think beyond the obvious and of what other term other teams may be using the tool for. Especially if you're putting this certain CRM cards on objects or I've got a couple examples here and the CRM card is one for cpq. CPQ is more of a sales tool and sales teams are going to be leveraging that more than most other teams. But when customer support or service is working with a customer and they want to come and see what was agreed upon, they have that CPQ CRM card directly on the deal record. So it was built for a sales team can actually be used by those others as well. An ETL is often brought for product analytics, but sales teams can use that to reach out for low engagement customer success similar or marketing promoting IT service. If someone's having issues, they can check the call logs or usage logs. Again, the opportunities beyond the obvious can yield a lot of fruit in the usage and retention of an integration. There's tons of resources. Just want to call that out. We've got HubSpot developer, docs developer, Slack Channel Developer, Community Forum and this App Partner team. This is an alias that if you want to connect with potentially getting listed in the marketplace. I want to answer some key questions. App-partnersubspot.com is one way you can reach out to me and manage that alias. And we also have Solutions partners. If you want to build an integration, just don't have the resources to do so. That's a great place to come to as there's a lot of experts in developing integrations with HubSpot's API there. So I want to touch on the driving awareness and adoption next. We we figured out who's going to use it. We built the app. How are we going to get people to use it now? So one thing I a common question I see is that we know that integration solves for all the problems for our shared customers. We know it's going to provide so much value for their business. Everybody should be installing it, right? I wish it was that easy. A really key step. And I'm also going to be beating the same drum is educating your customers and helping them understand why they should be installing the integration. What does it actually do for their business and how can they use it? Arrows that app partner I mentioned before has a vault of bite sized examples of how you could use their app in so many different ways. A lot of other partners are doing this as well. I've just happened to see a lot of customers commenting on theirs because again, it's just so easy to find. Download the app, come and see how do I actually use this and how can I make my business better today in ways that I'm not aware of? Super valuable for a lot of these customers and creating a seamless onboarding experience after they install the app. What does that look like? Are you sending them onboarding emails? And hey, you've installed the app, you haven't made an API call, here's how to set up. Or maybe you've had the app for two weeks. Here's a couple of use cases you should be taking advantage of. Again, these are really great ways to drive better usage and retention. They learn about the app, they install it, you want to make sure they're using it, getting value from it as well. And on the new customer side, a lot of those learnings are still across the board. But one thing here is that if you're building an app native to HubSpot, you gotta help customers understand the problem that you're solving for. They may not even be aware that they have this problem. They may just see, oh, this is a limitation with HubSpot product. I've been living with it and I'm going to continue to live with it, not realizing that an app you built can help them be more efficient, overcome that. And this is something that is hard to say to apps, but it's so, so true is that nobody can install your app if they don't know it exists. Being listed in the marketplace is a great place to get, you know, drive better visibility and adoption of the app, but you have to be creating educational content around it. So how are you finding customers now? How can you tie the HubSpot app into that? And are you collecting and targeting CRM information, specifically HubSpot customers? So speaking on the educational content, all of our best partners and top performing app partners are doing this. And by this I mean tying that HubSpot integration into a broader marketing strategy. SEO, videos, blogs, case studies, success stories, testimonials, paid ads. Everything you'd be doing to promote a business, you should be doing to promote your integration. And if those two go hand in hand, then you should be creating a strategy around that. So two just quick bullets on that is you want to get your app in front of your leads, customers and prospects and you want to educate them on the value of the integration and why they should install it. I see it oftentimes where I want to show you what it does, not how it benefits your business. I always, always see how it benefits your business relating to and driving a lot more conversion with customers rather than let me show you this really cool app. So retention and quality is also a key piece we need to touch on. I see this with so many partners in the Marketplace reviews, it's a great place to get candid feedback on how to improve your app. Sometimes they're not the best reviews and sometimes they could be a scathing review. But that's often where customers are telling you exactly what's wrong with it and exactly the challenges they're having. Rather than getting on a call and saying everything's great, we love it. Here's where they're going to be brutally honest sometimes. And reviews, if you're driving good ones, can drive a lot of trust and credibility with visitors who are coming and seeing your integration listing page or deter them if you're collecting too many bad ones. However, if you do get bad Reviews, you can respond to them on your listing page. You can address this issue and say thank you for your feedback. We've actually implemented that and improved the integration. So when new users come and they discover your app and they see that bad review and they may not want to install it for that same reason, they see you've commented and have addressed the issue and that brings that credibility back. Or if they're leaving good reviews, you can add a delight moment and respond to that saying, hey, thank you, we love your feedback, maybe even unlocking some testimonial opportunities. I know there's so much more we can dive into, so we're keeping a high level just for the sake of time. So now I'm going to be passing it over to Nicole who's going to be touching on a course of certifying your app.

Yeah. Thank you, Jesse.

Yes.

So I want to give you a preview into Academy's new course. Getting your app certified on Marketplace. So once you have your app listed and you get six installs and meet the technical requirements, you get a little badge that says, well you have to apply. You can get a little badge that says that you're hubs, your app is certified and the course is meant to help you move through this certification process really smoothly. So here are some of the course lessons. We will be discussing technical best practices so learning about the technical requirements and how to scale your app from 6 to 150 users. Marketing best practices, so really learning about go to market strategies and how to really get users to understand the value of your app and really drive usage. Working with the HubSpot team. So the certification process is not done through the computer. You're working with actual people and this lesson will go through that submission process and we will also be showcasing success stories and how partners partners valuable insights and how to gain from studying their achievements. And we value your feedback. So this course is designed to teach app partners the most effective practices for developing and marketing your app right from the start. Here are some ways that you can help. We have a four question survey. You can provide feedback on the course outline. It hasn't been built yet, so this is a great time to hear your thoughts. You can sign up to be a.

Case study.

Or you can contact us for an interview. Dennis is adding some of the links into the chat and that's it.

Thank you Nicole. Thank you everyone. And let's just go ahead and I know we are actually out of time but we promised a panel discussion so we're going to do it. Anton if you don't mind, let's go and bring everybody up and just hide these slides real quickly. I want to first say thank you to everyone who has presented today. You all are amazing and keep up the good work. Just for the sake of time, I want to go straight into some questions that were asked real quickly and then we'll go into some questions I have for you. Other than that, a while back, this one's. This is a CMSE type question, but I figured we'll just get it out there right now. Can I build and sell themes on the marketplace and do I need a paid portal? Does anyone want to answer that real quickly? I know it's not app specific, but. But I know we have some people here that might have some answers to that.

Yeah, happy to jump on that one. I recommend similar best practices to building themes. You're still going to need a development, staging production. You're still going to need to support users. You can still earn money. It's something I haven't done a paid theme yet, but it's on my list. My list is quite long at the moment. So yes, and I dig in there. Most of the developer resources, in fact, I can't think of any that actually need to be paid. So yes, you can start doing it free and grow from there. So go for it.

Great answer. Now moving on. And this one. This question is going to solve about 30% of the questions are asked on the developer forums and it's about the installs. What's the typical best way of getting those first three installs, especially if you haven't built any custom apps yet. This is seriously. I've heard this question about 3 million times and I would love to hear y' all's advice on tackling this.

Well, I might jump in first. Only that I did put a comment in there response to Philippe before he had to leave the call. And that is if you don't know three customers who would potentially use your app, then don't write the app because you're writing it in a vacuum. You've got to know people who would actually pay to have your app to solve their problem. You learn far more from the customers and it's always different to what you were going to write when you dreamed it up. So don't do it. I think the three is a good little test. Do a sanity check before you start coding.

That was some spicy advice right there. Do we all agree with that?

I think that's a hot take. I think it is true in some regards. I think There are times where a great app has been built and they're so focused on development, they're not even thinking about beta testers or how to drive adoption awareness. I see a lot of that with small startups where there's a founder and a developer or that is the same same person. In cases like that, where you're trying to solve a gap and figure out who's going to use this, there's a few different ways you can go about it. One is searching the community forums. That's often where you see customers giving feedback on HubSpot and gaps that they see or problems they're having. You can find who's asking for that specifically and reach out to them and ask them to test out your integration, see if it solves for that use case. Or you can talk to other agencies and see if they've gotten feedback on that problem. If you've got your own existing customer base and you've got a tool like Reveal or Chat Spot to identify if they're HubSpot users again, you can reach out to them and say, are you facing this challenge? Here's an app we built to solve for it. You can try it out for free as a beta tester before we do a paid tier for other users. Those are a couple of ways I've seen partners overcome this hurdle.

Yeah, I would agree with that. And also just marketing yourself, right, like just really putting it out there on your site anywhere you possibly can. I really push for the community forums and the developer slack because there's a ton of people in there with a lot of needs and are going to be super willing to test out your app to see if it actually fixes their issues. Moving on to the next question I see here. All right, let's see, we go. Regarding optional scopes, is there anyone out here utilizing scopes differently based on HubSpot product license in their portal? I saved this one for you, Mike, because I'm very curious to know how you go about your scoping for Portal iq. Because I mean, you Portal IQ can run on any subscription tier with HubSpot, right? So you had to really be thinking basically the entire spectrum. How do you go about that?

With great difficulty. Back in the olden days, the HubSpot API had an endpoint that you could hit and it would tell you what tier they're on and you could make decisions based on that. It was removed from privacy reasons, although if it's still there, please let me know. I need to use it. What I do is, and this is an imperfect solution is that I interrogate the optional scopes to make some assumptions based on what they have or don't have. And what I mean by that. If you I'll use surveys because that's the easiest one. Well the, the one I get the best results with. If I put an optional scope for feedback submissions and they go through the OAUTH process and the token does not have that scope. So you can interrogate the token and it will turn a list of scopes that token has. If I see feedback submissions is not in there, then I put a page into the portal IQ report that's got hey feedback surveys you can do nps. And so that way I use it as a sales pitch in the report to say you should be using Service Hub. That's the only way one I can do conclusively things like if I fish for marketing automation that could be a single seat of Sales Hub Pro startup that didn't make sense anyway that's enough to trigger the scope for marketing automation. So I can't make a decision on that. So I've then got to interrogate and go do I get an error if I try and get the workflows? So it's tedious and I'm sorry but.

Yeah, no, that's totally fine. It's an adequate answer for this. I want to drive a little bit further into the whole scoping issue or issue like just process and Pete, I'm going to ask you this one. I know, I think it was Mike, one of you said talking about you want to use the minimum amount of scopes necessary for your app for going through the marketplace. What happens? I mean how do you decide that? Let's say like you're thinking about your growth. I have to get rid of my thumbs up thing. Oh my gosh, I can turn that off. You're going through the growth, you're thinking about how your app is going to grow and you realize that you if you change the scopes, you actually need them to reinstall the app to get those scopes. So A, what is your decision process on the minimum amount of scopes and B, if you do have to add more scopes, what is your process for having them reinstall the app?

Yeah, it's a really good question. I think this is like a least privileges type of discussion where within your own coding you want to apply least privilege only allow things to access what they're entitled to. And I think same thing is here, you do want to give your app the least amount of permissions and then really securely store those access and refresh tokens. You're looking at GDPR issues as well, because you don't really want to have access to any personal data if you don't want there to be a showstopper that people can't install your app because you've got too much access. One way around it would be, first of all, if on your product feature roadmap that you know you're going to be releasing a feature in the next few months, then put the scopes in for that. But if it's further out there as something that you might do, then consider doing that as a plugin, as an add on so the core app is installed. And then if you want to release this as a feature, it doesn't necessarily have to be rolled into the core app. You can put it out as a second app that someone installs into the app as well and then only those users have those extra scopes. It doesn't have to be a monolithic app these days. It should be more modular.

And moving on to just pricing. And this is. Anyone can jump in on this one. Jesse, Pete, Mike, Tune, anyone here. I'm curious to know how do you find that correct pricing model are there? I mean, how do you update it to get to the right, you know, Goldilocks, perfect, you know, temperature soup.

Well, maybe if I touch on that because I had a slide just around that. I think one of the fundamental problems is that when you ask someone the question, what value does your app create? That they think of it from their own terms as the app creator, the only person that determines the value is the customer. That can be hard to define, but sometimes you got to help customers understand what value are you creating. If your app does something automatic they're doing manually today, you can help them with the maths for them to realize, oh my God, that's costing me like 1,000 bucks a month. But they won't have thought about it that way. So you get that from your customers. If you can determine the value, then the 10 to 20% of that value is a good rule of thumb of what you can charge. The other thing is you just keep cranking the price up. If you've got visibility of who's uninstalling your app, you crank the price up until you get about 20% of people uninstalling it. And the reason is that it was too expensive to find the sweet spot.

20. So when you say 20%, let's say I have 10 people, you know, so 20, like is that still number still viable for a.

Well, you need throughput. This is a little bit like, you know, split testing pages. You need people to be installing your app. You need some quantity to see, okay, we've seen the churn rate go up when we did that last little price tweak. The price tweaks don't have to affect your existing customers. You're really just experimenting with the price of your new customers to see whether your win rate drops off.

Cool.

How do you all track metrics on installed apps? What are you all looking for? I know someone says, API calls being made, and I think that was you, Mike, saying, what's going on there? How are you measuring success at that point after it's installed?

I think for a recurring product, it's really looking at those numbers. I actually record statistical information in the database, so I know what features are being used inside the app. And so, for example, the primary contact integration, I know whether somebody set the primary contact or the account contact or click the support link, which opens a modal inside HubSpot. That, for me is useful, whereas the pure number of uses is in the millions and it's of no value because I don't know whether they've actively used that or not. So tracking those interactions rather than just general statistics, otherwise you just end up with a big number. That sounds impressive, but it doesn't mean anything.

Yeah, indeed. Kevin asked a question I want to put up here. Speaking of themes and apps, are there any restrictions of providing apps through an app integration? Maybe around updating the theme source code? Jesse, I will put that at you, and I'm trying to reread it to make sure that I understand the question clearly myself.

I think I'm actually going through that same challenge.

Kevin, if you want to follow up a little more detail, that'd be great. If you have an idea, go for it.

Yeah, I mean, Kevin, correct me if I'm wrong, but I think you're asking about creating an app which will be connected to a theme, I would say. And you want to keep pushing updates to your theme through the app. Right. And if I'm not completely off, I would say technically it could be possible, but I don't think that is legally possible because HubSpot checks every update on a theme. Right.

So I think we have the wrong crew on here to actually properly give a HubSpot answer to that. But yeah, yeah, that's a good. As a matter of fact, Kevin said correct. So we'll take that. Anton understood the question and we'll Leave it there for now. I, I want to touch on there's something in the chat going on with free and I just wanted to discuss that real quickly. How much value do you all find in using free apps to kind of market your paid apps or a setup like that? I'm going to ask Pete. I think you'd be a great person to talk about to this.

You've got to look at what your goals are for that app, but also your whole strategy of if you have multiple apps. In our case, we chose strategically to make do currencies free and we get a nice run rate of a new customer per day off that. And we're getting visibility into the usage of multi currency. We're learning from that and we're using that to think of other things that we could build. So that was the goal of that. Plus we would have had to pay a much higher license fee to the currency API to allow us to sell a paid app that drew on that currency data. But we've taken the free tier out of Duprica. We started with a freemium and just found that it was more painful because it confused people. They expected to pay if it was going to add value and it just complicated things. So we switched to a different model of having free trial. Then we do have a free tier, but it's hidden, so it's up the sleeve. When you're talking to a customer and they're like, we need another month to get approved on this, you can slip them onto a free tier instead of an extended trial, give you that flexibility. Free has its place, but you got to invest time to then upgrade people. If that's meant to be a paid app.

Oh, for sure. Oh, go ahead, Pete. All right, Jesse, go, go.

Yeah, I just wanted to chime in on that. I've seen success on both sides of it. On the free side, if you're a solutions partner and maybe you're building services on top of the integration, then it makes sense from a lead generation standpoint or if it's so low cost for you to build and maintain the integration that you can give it free to provide better, better visibility for your other apps. Again, that's a great avenue. What I see working often better than that is the freemium side following HubSpot's pricing strategy and how HubSpot customers are used to buying and are familiar with buying, provide the value upfront so they understand how to use it and get to play with it enough where they really see the value and feel the value and then they will pay for it. If the user have to pay right up front, that often is going to deter people where it could solve for them. They just didn't really fully understand what it can do and they were just scared by the price and didn't even want to try it. And then approach like that to drive more adoption and get more people trying it out, I would lean on a freemium approach, but it does vary depending on your strategy and what the app is really trying to do.

Last question I think that I'm going to ask for today and it's going to go to Tune and Mike because Tune is a silent app developer who's not listed anything in the marketplace, but is a solid app developer. And I want to talk about app lifecycle, the software lifecycle and how you do a continuous integration, development and deployment. What is your process? How do you make sure you're not breaking things on the production end? Just either one of you want to start? No, you know what, Tune, you haven't spoken much today. I want you to go ahead, if you don't mind, give us how you are handling this.

Yeah, that's a great question. And it's something that we're still improving day by day because. Because there are still things popping up that we see that we can improve. Just FYI, we really only build custom integrations per client, but we are leveraging the public apps for that. But we still have the same build process there. Like Mike already said, it's really important to have a testing environment, a staging environment available and have a production environment available as well. If possible. If you either have GitHub or BitBucket or a deployment tool, it would be great to add some automated testing in your software just to make sure that everything is passing the tests. That is going to be a lifesaver. Just to make sure that the most important critical parts of your integration or your application are going to be working once you publish your code. So the combination of having great version control, working on the right branches, having a good git.