Building a HubSpot App: Start to Finish. A Masterclass series with A8 Labs | Session 1

My name is Tyrone Clauson. I am the chief technical officer at aptitude 8. I head our product development and basically all the things that are kind of really overly techie. I'm probably involved in some way or somehow. So building HubSpot apps is something that we absolutely positively love to do. And I'm going to be talking a whole lot through this. Just a side note, my pronouns are he, his and for, for, for the impairment. I am also in a small office with video game stuff behind me because I'm very geeky like that.

So I am Dax Miller. I am head of product over eight labs. So I kind of ideate and think of concepts, go to market strategies, branding, visuals, video, pretty much all of the forward facing things for all of our apps. Tyrann builds it, I break it and kind of put gold wrapper around it. So everything that I'll be talking about will be more on the go to market side. How to get the app in the store, how to or in the ecosystem, whether you do or not. Kind of the implications of that and a little bit about some of the strategy of how to brand and how to put something together to make it commercial. That back to you. And timer is awkwardly unmute.

So awkward. So this first session, we're not building the app. This session that's really coming, the next session, I just want to make sure that's very clear. This is very high level and this is really for developers and stakeholders who are thinking about building an app. So we'll be talking about. I'm just going to read this straight off the list here. Translating your concept into a viable app because everyone has an idea. If you are a developer, I bet money someone named your friend or family just like, ooh, I got this idea for an app. Oh my God, I got this great idea. Have you ever thought about that? And they don't all come out, they don't all pan out. So there's a reason for that. We'll talk about setting up your developer account and getting going. How to connect your app to HubSpot once you've actually created it. And a lot of this is also going to be the development and business considerations. Before you actually start clickety clacking on the keyboard. There's a lot of things that you need to talk about or think about or consider before you actually start developing yourself or paying someone to develop things for you. All right. Translating your concept into a viable app. You know they say ideas of work, pennies. So kind of going back to what I was saying beforehand when everyone has an idea for an app, oh, next slide is fine. A lot of those apps don't pan out. When you are thinking about making your app, the number one thing you really need to be considering is what problem does it solve? Whoever's going to install this app, they're installing it because they either think it's going to help them do something bigger or faster, or understand something that they didn't understand beforehand. There needs to be a true benefit for it. And so you need to ensure that you're definitely solving a problem. And it's always good if you can. If it solves a problem for yourself, it's even better because you're almost kind of solidifying the idea, but you need to make sure that you're solving the problem. How long will it take for an mvp? You do not want to have a perfectionist mindset when it comes to app development because you will simply never finish it. This is also known as feature creep or scope creep. And you need to have a very delineated way of doing things to make sure that your app gets out the door and then you can iterate on it and then you can get some feedback and understand what people really want. Do you have a budget? If you're rich, great. I'm not quite sure what that's like, but let's connect after the meeting. We'd love to see what that's like, but kind of going back with how long will it take? A budget will for sure set you straight in terms of how long you can fund the development of an app before you absolutely need to have it out into the wild, especially if it's revenue generated. How complex is the app? Is your app something where, hey, I'm just showing more contact information? Or maybe your app needs to connect to some outside service. Maybe your connect. Maybe your app is a connector to BigQuery or something to that fashion. Maybe your app is going to have to deal with spikes in load. Maybe there's a lot of considerations and you will want to make sure that you know the true complexity of your app before you start developing. Otherwise you will for sure find yourself in a situation where you're almost kind of like behind and you're doing a lot of discovery as you're building. That will cause a lot of problems and delays down the line. Can you measure success? You want to think about some kind of metric. Maybe your metric is, can we get a thousand people to install the app? Maybe the metric is if people use my app, they'll be 20% more efficient in doing some particular activity. You want to have something where you can, once you have the app, you can measure how well it's performing in terms of what problem it's supposed to be solving. Who will manage app maintenance? So 60 to 80% of the cost of an app generally comes after launch. So you spend some capital to actually make the app. But then once it's out into the wild, that's when a lot of times you discover, hey, there are people who want feature X or Y or Z. This particular thing we don't need, this particular thing is broken. All of that generally costs money. And then there's a question of who is going to do it. Do you have an external development company do it? Is it going to be something that's in house? A lot of times people have an external company that does the development and then once it's over, they maintain it themselves. So you need to kind of have some idea of who is going to be grooming this bad boy once it's out there. Will there be customer support? So generally, if an app is small, the customer support is usually the development team. If your app is large and serves a very large audience, then that can really no longer be the case. Otherwise your developers will never have the capacities to develop. They'll just be on customer calls all day, all the entire time. So you may need a strategy for who is actually going to help people, people with the app once it's out there, while maintaining developer momentum. And what technical skills exist on your team. This can be a mix of what technologies that your team currently works with. It can also be a question of senior rich. Are they juniors or they're senior developers, so forth and so on. Does your team need a cloud architect? Do you have it? Do you need it? Does your team need to have really good database skills? I mean, you want to have. You want to know these things before you actually start your app so that you can actually build the right team to build the right product. Go to the next slide. Jackson, this is all on you, buddy.

So one of the things that we always have to consider, once we're kind of ideating on, thinking, is this worth coming out? Do we have something to do? Does this work out? This was a great example. This is our customer. This is one of our first apps that we launched a couple years ago. We had to go through the idea of when is HubSpot going to come out with this? Does this have a purpose? Do people need. This is the community forum. Are people complaining about this being something that they need and all those pointed a. Yes, but we understood that when we talk about commercialization a little bit later that HubSpot is a platform and they may have something on their way to replace your app if it doesn't specific kind of thing. So you really have to differentiate see how viable this is before HubSpot does something about it or, and or afterwards the end user experience. So we're going to be talking about the limitations of HubSpot and also what's great about HubSpot when building an app within the, within that ecosystem. Will people be able to utilize this directly in the CRM on a CRM code? Is it something that's going to have to have your own admin, your own login to do some other specific features because of the limitations set currently set on the, on the platform. So, so it's about understanding not only how the end user experience looks, but where is it. User stories are super important to understand where and how you actually build this app. And as we'll learn a little bit more later on as well, this app will not live in Huxpot. So there's going to be a lot of things you have to talk about to understand how a user interacts. Market demand. So is, will people pay for this? How much will they pay for? One of the key things about building products is that your product needs should be a part of someone's worth. I'll say that one more time. Your product should be a part of someone's worth. That means it's gear replacement. That means it's going to be. You're going to have luxur. That means it's a part of the way that they do business and they don't want to change that because it helps. It saves time, it saves money, it saves energy, it saves clicking anything that's happening. What type of demand is that is available. So looking at this, building an app for one of your clients, they probably blow you up about something that they can't do and really want to be able to do it. Or you can look in the community forums and you see that the HubSpot community as a whole is begging for this product, this feature. And this is something that you could clearly build and extend HubSpot long term value. How long do you have? Do you have a target on it? Does it have a target on its back? A lot of the ideas that we had early on in the alchemist and a lab days were how long. If we, if we come out with this, it takes two months to build or three months to build. How much, how long could we profit from this? Or how long will it take to recoup the money that we invest in so that we could use it for any other method? That's a really big deal, especially in this ecosystem. When dealing with something commercial, when you're dealing with something for a client, it's about is it going to. Is it going to be outdated? Do you need to build it modularly so that if they, they won't keep asking for more and more features and they end up building kind of a kind of garbled, tangled mess of spaghetti code? So understanding what the long term value is, what's going to happen here once they have this, are they going to want more? Are they going to want less? That's some big things to understand on the being realistic and use the Tyrone as the one that helps me kind of be down the earth because I just want to. It's usually a problem. We'll go to the next slide.

All right. Setting up a developer account so here's the thing that you really need to know when you're setting up a developer account and you will see screenshots of this stuff after the fact. You need a HubSpot account to do anything. And a HubSpot account is basically the same HubSpot account pretty much everyone has in fact HubSpot themselves actually use HubSpot. So what do you know? But you definitely need this. Once you actually created your account and granted just full transparency, it's not that you necessarily need to use it, you're not going to be necessarily managing contacts and deals and tickets and things of that nature. But it's. You have no choice but to have a HubSpot account. Okay. Once you have created a HubSpot account, once you are inside HubSpot, you can then create a HubSpot developer account. And your developer account is essentially your gateway to development. It is going to be where you actually get your API keys from. It's going to be where you actually register your app with HubSpot, it's going to be when you go to put your listing in the marketplaces. This is where you're going to start from as a developer. The HubSpot developer account is where you are going to spend a lot of your time. Once you actually have an app, you can now create test accounts. So and these test accounts look just like your basic HubSpot account. There's really no difference. They're usually all unlocked in enterprise, so you kind of get all of the features that you would Need. The true difference between a test account and your basic HubSpot account is that your test account can expire if it's not essentially getting attention or usage. In addition to, you need to make sure that you are not confusing the two, because it's really easy for people to think that I can access my test accounts through my basic account, and it's just not true. They are indeed different accounts. You just simply have control. And then once you are all set up, you will get a developer API key, which we were talking about, that is going to help you do some development things. And this developer API key is shockingly, a little bit separate from a account API key and separate from any OAuth keys or anything like that. Your developer key is this special key that you only use in special occasions during development. So I just want to make sure that's clear. We'll talk about it here in a little bit. In just a bit. All right. How you connect your app to HubSpot, the number one question we get is where does a HubSpot app live? And it lives wherever you host it. So a HubSpot app is not a traditional app in the sense of, hey, I've written all this code and now I'm going to download it onto someone's phone or I'm going to include it into my WordPress app. That is not the way it actually works. A HubSpot app, at its most basic, is just simply credentials that you use to make API calls to someone's HubSpot instance. That's what an app is. Where it lives is totally up to you. What it looks like is totally up to you. But it's kind of crucial to know that, because it really is different than the most traditional ideas that people have when it comes to application development. How do you connect to the app? Oh, back on the slide, please. So there's four ways to connect to the app. There's the API key, which I may have spoke about briefly. There's OAuth, there's private applications which are new to TubSpot themselves, and there's also the developer API key. We'll get to all these in the next slides. All right. The very first credential or way you can connect to HubSpot. And when I say connect to HubSpot, what I mean are. What I mean is making API calls. So you make API calls to basically run CRUD operations on someone's HubSpot instance. Generally speaking, the quickest way to start development is going to be with the API key. So if you're in your HubSpot and you go under settings and you go under integrations, you'll see an API key settings. The API key indeed gives you guide access to the entire HubSpot instance. That is, you can do, you can add contacts, remove contacts, deals, tickets, timelines, any kind of object that you can think of that can be manipulated via the API, you will be able to do with the API key. So the API key is good in the sense that it helps you get started pretty quickly. If you have done any API work beforehand with various integrations, this is really no different whatsoever. HubSpot themselves are actually trying to get people to kind of move away from using API keys and instead they will prefer you to use either OAuth or private app keys. Because the API key comes with an inherent risk. And that is, if I give someone my API key, they have God mode. If something goes wrong, they're the very first people you're going to go towards because it just gives so much unfettered access. So generally speaking, you will want to use an API key maybe just to get started for development out of its simplicity and ease of use. But once you get your application into the wild, you don't want that. You want to reduce your risk. So you want to move away from using an API key and API keys. The way you're using an API call is really, really simple. It's just a query string, key value pair, mega easy. Next slide number two is OAuth. So if you are familiar with the OAuth process, HubSpot, instead of using API keys, you can basically get an OAuth token. If you're familiar with the OAuth process, you basically get a code. You give that code back to HubSpot with a few other parameters. In exchange, they're going to give you an access token. That access token is what you will use to make API calls. So instead of having the API key in the query string, you will have this access token and it'll be used in your headers. It uses the authorization bearer header. So very common. And that token is really only going to last about 30 minutes. So you will need a mechanism in place to refresh tokens every 30 minutes. When you create your app and you set up this OAuth, you will then be asked to basically set permissions, and that is, hey, I'm making this app what all objects can it read or write to. And you will basically have to list that out. Once you list that out, HubSpot is going to give you an install Link, and it's using that install link is where the OAuth process to eventually get the access token will begin. OAuth is the way to go if you're making a public app. It definitely limits the risk that you have in terms of if something goes wrong, you don't want to jack up someone's HubSpot. It also ensures to the customer, whoever's going to use your app, that you're only accessing the things that are needed. So part of the OAuth process, customers will basically be shown what permissions your app is being given to and what they can actually. Which your app can actually create and add an update. Oh, sorry. Back one slide. Yeah, so with that comes API limits. Now, the API limits are pretty high, I think, for if I'm remembering this correctly, someone correct me if I'm wrong. You get about 500,000 API calls a day, which for sure handles about 99% of all the people you're really going to come across. That limit is tied to the app. It's tied to a combination of the app and the. And the customer who actually has it. So, for example, if I am, and this is, this is a bit of a caveat, if I'm hitting, if I have an app and it updates contacts and I hit that 500,000 per day limit, I can actually create another app that will update those contacts and then I have 500,000 more calls. So you didn't hear that from here. You didn't. You have no idea where you heard that from.

That was the secret. That was a secret.

That was the secret. Yeah, but API limits are tethered to the app. Next slide. All right, private applications. Private applications are made for when you are creating an app, but it is not for the public. Hence, you know the word private. It gives you the ease of an API key, so you don't have to worry about the whole OAuth token refreshment part. At the same time, it is very new to HubSpot, and so it is still mature. And so I say that because one of the things that you can't do with a private app is use CRM cards, which is pretty critical, especially when it comes to integrating your app or maybe some UI you have that you're hosting somewhere and bringing that into HubSpot. But private apps are for sure maturing. They are really good to use because unlike the API key, there are permissions that have to be set up when it comes to a private app. So you get protected from any operations that may potentially go Wrong on your site, so. But this is for sure the way HubSpot will prefer you to go as API keys. Their usage is never going to go away, but it's much preferred. It's kind of being depreciated in a way. And private apps are the better route to go. All right. Developer API key. Yeah, yeah, no, I see your bit there. Divis Developer API key. So the developer API key is a bit of the. What was it, the black swan. I'm trying to think ugly duckling in that you really only use it. As far as I can tell, I happen to be wrong. Don't think that's the case when it comes to running crud operations on workflow action definitions. This is definitely cart before the horse, but if you ever create an app and your app needs to show some UI within a person's workflow, that UI is generated from some JSON. And when you go to upload that JSON to HubSpot, you need your developer API key. And it makes sense in some way because, hey, we do want to kind of get away from API keys. The private app. You think it'd be there, Maybe it's coming, then it's happy again. Tell me if I'm wrong. Would be great if we could do it there. But for right now, when it comes to managing those workflow UI parts, you will need your developer API key. That's the only situation I can really see it in right now. But I do want to specify that the developer API key is absolutely not the regular API key, nor is it the API key you get from using a private app. It is its own thing. So I just want to make sure to reduce any level of confusion there. That's business decisions to make based on the app audience. I'm going to share my screen now.

Before you jump into the diagrams, kind of the business use case, I want call out. Ludwig had a question about private apps. So I know I'm jumping ahead of the QA section, but he said, would you use the private app way of authenticating to create webhooks, to listen to events on certain objects? Ludwig, I care about your answer. I wanted to throw that out there first.

Yeah, I mean, the answer is yes. I mean, that's as simple as it is for sure. You, you will always want to if you can use webhooks as much as possible only because you really want to avoid polling. And yeah, to answer your question, yes, especially that'll become helpful if you are concerned about maybe GDPR or HIPAA or something that Fashion. I'm actually going to talk about this in the next slide, but the webhooks are for sure the better way to go when it comes to getting event data out of HubSpot that is not based around a workflow. Do we have any more questions we want to talk about before we kind of dig into this? I certainly don't mind it. Nope. Okay, twice. Screen share. Give me one sec. Okay, so this is the decision tree that I've put together and it really is there to kind of give you a feel of things that you should be considering before you start developing anything. Or you may have heard me at Dax say clickety clacking. That means a lot of typing on the keyboard. Every. Every stroke on the keyboard is someone's time or potentially someone's money. So before we want to try to minimize that as much as possible, and we want to line ourselves up for success as much as possible before we actually start developing. When you start developing, I will tell you as a developer myself, there's always going to be surprises. There's always going to be something that you missed or didn't know or didn't understand or maybe wasn't available when you first started planning that. It's just the cost of doing business around development. And so we want to make sure that we nail as many things as possible before we start that process. Clickety clack is a technical term. I love that and I know that. But let's do that. So, number one, who is this app for? A lot of developers work for companies that are not development shops. I'd say it's probably mass majority of developers. Then you have your development shops, right? We actually build apps for the public. But if I'm building an app, the first thing is who in the world this is going to be for. Maybe it's for my company. If it's for my company, then private app makes a lot of sense. I don't necessarily need OAuth. Not that you can't use it, but private app is going to make a lot of sense here. We're not necessarily worried about more about extensibility than we are scalability. And we want to try to keep our development probably as simple as possible. Authorization methods one you like. I was kind of saying in a few slides beforehand, the private app is basically going to come with its own API key. So it makes it actually really easy. You can use a private app key or you can use an API key. Here again, API keys do give you guide access. Private apps are much more locked down by permissions, they will both do the job. And granted you're not making an app for the public, you still want to go down the private app route. Again, API key a lot of risk. Private app less risk the architecture of your app itself more than likely is going to be a monolith, which is what most apps are in general. At least you know, SAS based or web based apps. Not that you can't have something more complex, but of course you always want to build into your needs and monoliths kind of get you up and running as soon as humanly possible. If you're thinking it's going to be more complex, maybe you want to go a service orientated route right off the bat. Definitely increases the complexity. Generally speaking, private apps aren't nearly as big and not as complex, so it'd be something that you would maybe want to maybe consider. But more than likely, Monolith is where you're going to be developers and support. So when you have a small app, more than likely your developers are your support team. When tickets come up they usually go directly to the developers, or maybe they go to some kind of scrum master or someone who's in charge. But generally speaking there is not a lot of room between the customer slash stakeholder and the development team. This is very, very normal. Happens all the time. I mean you generally use something like Jira or something like that to do your organization parts, but that's just the normal setup. When it comes to databases, generally speaking, scalability is not so much the concern there. You all you're generally always going to have your own database from whatever company you're working for. You've got your data store and now you're extending yourself two hubspots, there's another one. But when it comes to data stores and you interacting, exchanging data with HubSpot, there are a few things you may want to kind of consider. Is GDPR or is HIPAA something that you need to worry about? Kind of going back to the question that was just asked. Do you need to be listening out to webhooks? You can have these things removed right away. More than likely your contact data is going to be in your golden source, which is going to be your company's database. And that should be reflected here in in HubSpot just to make sure you're doing things the right way. And you don't, you're not going to come across any particular issues. Keep in mind that HubSpot themselves will tell you right away they're not HIPAA compliant or anything. So a lot of the compliance stuff is totally on you to make sure that you are doing things the right way and then subscribe to webhooks for deletion. So we got a little bit ahead of ourselves. I love that kind of thinking. Someone was already thinking about it, but. Okay, I'm going to look at the questions. Chad, do you see anything? Dash, do you see anything. Questions you may want to throw out there before I move into the other audience part here?

No, no questions yet. I do want to just make sure that. Yeah, we're all good. Let's keep it moving.

Sweet. Okay. So the app is not for myself. It is for a company. It is for. It's not for a company. It's for the public. This is where things begin to kind of change. When you have a public app, there are a handful of things that you really want to start considering. One, you are probably not going to know what data is flowing through your app. So we go from public app straight to cyber insurance. I kid you not, this won't be necessary, especially if you're looking at contacts or if you're looking at deals. Deals generally contain a lot of proprietary information around the company's functions and customer base and things of that nature. Customers can kind of. Then they should be worried about where that data is going. Is it being stored, what's going on with that? Cyber insurance is going to be something that you want to have that's going to be your friend in the event of things go wrong. Full disclosure. If you are indeed dealing with customer data, which you will be, you want to not persist that in your own data store. You want to keep as much data as humanly possible. In HubSpot, maybe it's coming into your app and you're doing some level of manipulation and then you are sending it back. Or you need something to kind of consider. Maybe you need to purge that data. If you are persistent, it you want to purge it every so often and you want to ensure that your customers know, hey, listen, I'm not. This is. This is your data, it's not mine. We only use it to do processes X, Y and Z. I need to give them that reassurance and make sure that you're not keeping that stuff. When it comes to authorization, Oauth is for sure going to be the way you want to go. We have seen apps where people request users API keys, which is outright scary because you do not want God access to lots and lots of instances. It sets you up. It sets you up for a lot of Trouble down the line, then having a bid. You don't have those guardrails to keep you in place if something in development goes wrong, you really don't want that. So OAuth is for sure going to be the way you want to go here. And with that, keep in mind, the OAuth tokens expire every 30 minutes. So whatever app that you build, you will have to build a mechanism that refreshes these tokens every 30 minutes. And those tokens need to be ready at any given time, because you never know when a client is going to use your app, which is going to make those API calls in the background. One thing we'll think about here is does your app process workflow messages? This is crucial here because it will really help dictate how complex your app needs to be. The number of messages that come out of the HubSpot workflow engine can be tremendous. For example, we have an app called Associate that will basically do a bit of a dynamic lookup. For example, you want to associate a contact to a deal, and let's say the contact has a company ID field and the deal has a company ID field. And then what we can do is we can look, we can look at that contact that comes through a workflow and then do a search for all the deals that has the company's, the contact's company id, and then we can bulk associate them. You cannot really do this with a single server because the number of messages, that message activity that comes out of a workflow is tremendous. And so you then start to need to think about a microservices architecture, which will come with decoupling and maybe queues and scalability around your data store and cloud architecture, things of that nature. So microservices is going to be something you are, you're going to for sure have to work with and with Mark with Micro. Yeah, my gosh. Microservices comes a handful of things to kind of keep in mind. So, generally speaking, if you have a dev team and they've been making, let's say, PHP apps for. And this is what they do. Once you get into the microservices architecture part, you're probably going to have to deal with cloud architecture, which means you'll need a cloud architect, which means that your skillset for your team kind of has to expand. You need to determine which cloud service you're going to go with. You need to understand the limitations, maybe to understand the costs that go with that. More than likely, this is going to be a very complex app. So the seniors on your team is going to really expand. When you're dealing with a private app, you could probably just deal with junior to medium develop junior to medium level developers. When you're really talking about large scalable apps, more than likely you're really talking about senior developers. So that means that more than likely the cost for your app is going to go up. So what's then the cost that go with that? More than likely this is going to be a very complex app. If your app does not depend on workflows. Right. Okay. Then it's almost like a private app. Again, maybe you can probably go a mile with it. Maybe you're thinking about service oriented.

You.

Want to try to grow into your needs there. Again, you will more than likely be able to kind of retain your development team. Really probably won't need much augmentation. So whatever team you got is probably going to be just fine. Kind of circling back up here. Is the, is the, is the, is your app revenue generating? Okay, so if your app is revenue generating, it begins to really kind of change the way you will start looking at development. If you have a roadmap, which you will for sure need one, especially if you want to stay competitive. So the seniors on your team is going to really expand. When you're dealing with a private app, you could probably just deal with junior to medium develop junior to medium level. You need to make sure that your developers can always develop and there are not also full time support people. This will become crucial because as your development team starts to serve more people, if you don't have like dedicated support and granted this is much more of a, you know, six months to a year out thing, but it's something to really consider if your developers are basically inundated with being support people developers. When you're really talking about large scalable apps, more than likely you're really talking about senior developers. So that means that more than likely will grind development to a halt. And so you really need to kind of be considering how that is going to impact things. You need a V1 if your app is generating revenue, more than likely the app revenue is also going to impact how things get developed, how things get developed, what parts are getting developed, how expensive are these particular features we want to do. You need to think about what's it going to take for me to get V1 out the door because we may need to make money. And in addition to the HubSpot ecosystem is growing. There's a ton of people making ads. You need to get out there as soon as you can. You will for sure need a roadmap, especially if you want to stay competitive because competition is coming from all angles and to stay ahead of things, to make sure that you are really thinking about extensibility, you want to join as many HubSpot betas as humanly possible, even if they don't necessarily sound like they can are directly concerned to your app dev team and support team. I think I actually kind of spoke on that, so bit of a mistake. Okay, so if we're talking about a public app and we're also talking about data stores, then things tend to kind of get changed up a little bit. You again, kind of kind of going back to a point I was saying beforehand you do not want to persist a client's HubSpot data in your database. You truly don't want to now if you don't have to. If anything, you want to save maybe a customer ID or a deal ID some data that gives you a lot of ambiguity between what you store and what's actually in HubSpot. You don't want to save stuff like deal names. You don't want to save stuff like in the body of engagements that will definitely put you in trouble unless you absolutely need those things. Those storing that kind of data makes more sense if you're doing an app for yourself. Maybe you're doing an app for your company. If you are doing it for the general public. You do not want that. In addition to if you are saving everyone's data, it is going to rack up and those data costs are going to hit you and you need to kind of consider what those costs are going to be. The cost for your app is going to go up. So what if your app does not depend on workflows? Right. Okay, then it's almost like a private app again. Maybe you can probably go monolithic. Maybe you're thinking about service oriented. You want to try to grow into your needs there again you will more than likely be able to kind of retain to you to your app as things grow. GDPR and HIPAA really important here. I cannot stress the importance of being handed some level of notification because so and so's data did not get deleted. You want to make sure that you have an automated place in place to destroy people's personal any kind of pii. You'd be able to get rid of that essentially playing a game of hot potato. Also, we need to really think about high availability and high performance. So generally having one database is not going to cut it when you're Talking about an app for the general public, for sure it will not be the case. If you're talking about dealing with workflow messages, you will probably need read replicas. You will probably. Your development team really probably won't need much augmentation. So whatever team you got is probably need some level of caching. Those are things to really kind of strongly consider. And if you don't need those things, then great. Maybe just a single database will do it for you, maybe just a single MySQL database will do it for you that sits somewhere on your company server. But if you really want to stay focused and you don't want to necessarily have to be a database manager and you don't want to necessarily have to manage your own read replicas and stuff like that, you're going to be just fine. Kind of circling back up here, you will probably want to look at some cloud things like Amazon RDS or the like and use those to your advantage to make sure that you have enough redundancy and scalability in place. That is the end of the decision tree. I'm going to take a pause right there. Dax, you got the input or you got any questions maybe we can jump into?

Yeah, I want to call out a couple of questions. So Martin had a question. Microservices equals serverless and recommendation for hosting these microservices. So just touching on.

Is the, is the, is your app revenue generated?

How we. I think the assembly is a pretty good example of leveraging microservices.

Okay. So if your app is revenue generating, it begins to really kind of change the way you will start looking at development.

Okay, volume.

So microservices does not mean service. They are strongly probably coupled together especially and if you have a roadmap, which you will for sure need one, especially if you want to stay competitive in popular lines of thought, more than likely you need to make sure that your developers can always develop and there are not there are other ways to go about microservices than just a lambda, not also full time support people, this will become crucial. I would easily advocate for lambda because one, there's a tool because as your development team starts to serve more people, if you don't have that there, there's a cost component that's probably going to be better than just maybe having a really have like dedicated support. And granted this is much more of a, you know, six months to a year out thing, but it's beefed up EC2 instance or compute instance out there. So there's, there's something to really consider if your developers are basically inundated with being support people, the cost component to that. I think what I've also seen is a lot of companies especially so for example, if you're a PHP company and you need to make a serverless lambda, then you can probably use PHP with that, but you're probably actually going to want to do it in like Node Js because Node JS is faster. And of course when it comes to serverless lambdas, you pay for the invocation and you also pay for the duration. So you want, while you may not necessarily be directly in control of the invocation, you are more of in control of the duration. And while AWS lambdas are definitely cheap, if that's all that you rely on, you will definitely see your cost begin to kind of climb. So you will want to use a technology that gets the duration down as low as human possible. And in addition to there's RAM concerns as well. So you want to use something that's pretty lightweight, pretty quick, gets the job done and out, boom, done. We actually for our app associate we use pretty much Node js. It will grind development to a halt. And so you really need to kind of be considering how that across the board we do have a handful of EC2 instances that search for other for other purposes. But when you are working with workflow stuff decoupling and queues and lambda quickly become the name of the game. If it isn't a queue. Maybe it's Kafka or something to that fashion. But it's pretty easy for me to subscribe the usage of aws. I think because AWS is the score to impact things. You need a V1 if your app is generating a revenue. More than likely the app revenue is also going to impact how the most mature cloud platform out there. I would say it's not even really up for dispute. If you're a bit more cost conscious, then probably Microsoft Azure. I would say Google isn't quite there yet. Maybe they're two, three years behind. But AWS is pretty much the way to go, at least for right now. What was the other question there? Let's get developed. How do things get developed? What parts are getting developed? How expensive are these particular features we want to build? You need to think about what's it going to take for me to get V1 out the door.

Touch on the question regarding.

I believe.

Let's see, we had scrolling up through the chat, we had a question regarding kind of workflows and the positive negatives of consistency there.

So the things to consider about workflows and if you're ever building a workflow app, you're probably going to hear me say the words, yeah, just do it. Because we may need to make money. And in addition to the HubSpot ecosystem is growing. Just get a lambda and be done with it. Because what you will learn is that the workflow engine, let's say someone has a workflow and they're going to send 50,000 contacts through that HubSpot workflow. And part of that workflow, your app is in that workflow. So your app is going to encounter these 50,000 contacts. You may think that your app is going to encounter 50,000 contacts one after another in really rapid succession. That is not the case. Your app is going to encounter all 50,000 at the exact same time. It is a massive deluge of information that comes out of the work the HubSpot workflow engine. And so what we have done is we do a few things. One, we use AWS Gateway to help regulate the low ton of people making apps. You need to get out there as soon as you can. You will for sure need a roadmap, especially if you want to stay competitive because competition is coming from all angles and the stay ahead that kind of comes in the door. We also use Lambdas and we use EC2 instances to basically take in that data and route it to where it needs to go. We also leverage 8500 responses to some of our API responses if things start getting hairy. One thing you will know about most APIs is that um, if they start banging on your door too hard, every API is set up to if they bang on your door too hard, you should give them a response that they can understand where then they can say okay, let me back down a little bit. And for HubSpot that's a 500. The things to make sure that you are really thinking about extensibility. You want to join a response. So if your, if your lambdas can't keep up, if your EC2 instances can't keep up, you need to return a 5, 100 response so that HubSpot says okay, okay, okay, okay. See in 72 hours, I think that's the, the time span they work with and you will, they will resend that message to you again. So you don't necessarily have to deal with data loss, but you definitely need to architect your, your app in a way where being over capacitated is, is a.

Got another question on from Nicholas in the chat recommending someone that's familiar with.

HubSpot many HubSpot betas is humanly possible even if they don't necessarily sound like they can are directly concerned to your app dev team is support team. I think I actually kind of spoke on that. So a bit of a mistake.

BB API Python talks about the server response payload being a Python class object. Well, this is nice talking my language and how can I use it as a built in dictionary and select specific keys inside the many layers of this div multidimensional inheritance. So we're talking.

I see that. Okay, so I don't necessarily use Python.

Well, your dictionary is your is going to be like your object for the most part. Ish.

Yeah, but the response. Okay, so if we're talking about a public app and we're also talking about.

I don't see the kick me in the face.

Oh, you know, maybe you're using the Python SDK. I imagine that's probably. If that's the case, I'm probably gonna have to deflect you and find you someone who does use if you're using the Python SDK which I meant in this case. Otherwise it's just we're just talking about API calls. How can I use the built in dictionary and then select specific keys inside that is for sure much more of a Python question. My assumption here is going to be much more general. If you have a dump method where you can kind of see the innards of some variable I would dig into that and then more than likely that variable is going to have a bunch of properties and methods and see if you can which one of them are public and if you can call any of them you'll basically just kind of have to call it ones and make sure I'm addressing your question here. Have the many layers of this. Yeah, you're going to need to dump and kind of see what's going on that object. I don't necessarily about data stores. Then things tend to kind of get changed up a little bit. You again kind of kind of going back to a point. I was saying beforehand you do not want to persist a client's HubSpot data in your database. You truly. I can't ask some questions. I'm not a Python guy but Nicholas, if you want to use your email address, try to find someone to give you a right direct a right answer.

There we have one in the qa. Some love from Michael. Much love.

So you truly don't want to now if you don't have to. If anything you want to save maybe.

A custom about kind of what we call our lab, where we have multiple apps, and the lab is kind of an external, externally hosted application as well, where everything is listed. So, Tyler, if you could speak to kind of how that architecture is set up, where we have all of our apps speaking to our old app and the way that the APIs are set up.

Yeah, so we have a portal, which is an app. It's not. It basically houses everything. So we basically use Cold Fusion and Vue JS and MySQL that's. That's pretty much our primary stack. But our portal basically allows our customers to log in, and then once they log in, they can see there's a. For every app that we distribute, we have essentially like a baby Vue JS app that acts like an overview. So if, for example, if you have the ticket portal and you log in, you can see stuff about your ticket portal. You can see, hey, here's. Here's the. All the tick here. Here's what the ticket portal looks like from the outside world. Here are settings about my ticket portal, customer ID or a deal id. Some data that gives you a lot of ambiguity between what you store and what's actually in HubSpot. You don't want to save stuff. Like, some of these things are actually saved to our database. Some of these things are saved to a user's HubSpot. For example, we have an app called Associate. And when you log into our portal, the part you see about Associate is a Vue JS app that basically connects directly to our database and just pulls up like, a report and pretty much dumps it out to the user. If you have our app, Superg actually clone Attack. Here we go. Clontag also gives you a listing page that comes directly from our database. So what we do is we tend to log a lot of our actions for development purposes and for accountability and display purposes. Kind of keep us, you know, nice and honest. We tend to try to show people what's going on in the background because a lot of the things in HubSpot, you know, they're API calls. They're. They're really headless. A lot of customers have no idea what's really going on, but they definitely appreciate when you're actually able to show, like, hey, deal names. You don't want to say stuff like in the body of engagements, that will definitely put you in trouble unless you absolutely need those things. Those. Storing that kind of data makes more sense if you're doing an app for yourself, maybe you're doing an app. Here's what's actually going on when you're not looking. When you click a button. Here are the actions that are kind of being taken or at least for your company, if you are doing it for the general public, you do not want that. In addition to here are some of the results that occurred when you took action A, B or C. But for every app that we build, we basically create another another baby Vue JS app and we kind of roll that right into our portal. Oh, and our portal also manages our subscription management for the apps. Also allows you to kind of manage your HubSpot team in terms of how they interact with our apps. So when we basically built our portal, there were no user permissions, not the way it is now. And so we still kind of have a handful of things that we're probably going to transition over fully the HubSpot. But if you are saving everyone's data, it is going to rack up and those data costs are going to hit. We do some level of management of HubSpot users and the way they interact with our apps in our portal.

One thing I would love to touch on just real quick, I know we're running up on time is the action talk about public app, public apps and are they revenue generated. And I know we're leading into kind of the next class where we'll talk a little bit more about the actual implication of a public app issue.

And you need to kind of consider what those costs are going to be to you to your app is things from GDPR and Hippo.

But HubSpot does now manage the billing by any means.

Really important here. I cannot stress when someone purchases your.

Public app, you need to be billed. The payments link up with your stripe or your favorite soup du jour payment processes. All that is managed outside of hunts. So you're provisioning if you have charging per user or per advanced user for your app. Like for example, our upcoming one of our upcoming apps has different levels of users. Users can see things in the CRM card and others actually see a button and click and do actions on that app. But all of that is managed yourselves.

The importance of being handed some level of notification because so we talk about.

Building Portal, you will need to build some way to transact because that's completely external. Anything that there's nothing that is for fortune, you know of good, good faith. Altoid does not take any percentage of that transaction nor do they facilitate it. So everything is external. So you'll need to at least have some sort of payment processor and tiering and all of that done yourself or a public ads. So to touch on David's question, uh, it is a little bit complicated. We kind of just threw ourselves into the public app space. Uh, but we did actually start with.

Building something for so so and so's data did not get deleted. You want to make sure that you have.

And that was before it wasn't publicly available. We had to learn kind of how.

The automated place in place to destroy people's purpose.

This all works a few years ago is learning how to to interact with the APIs.

First and foremost personal. Any kind of PII, you'd be able to get rid of that essentially playing a game of hot potatoes.

And then once we understood that there was a marketplace, then we kind of backtracked of what we all did. And Tyrone, I wouldn't say we. I say Tyrone was the one that kind of brought everything that's actually packaged and commercialized. Lots of trial and error there. And that's kind of what we're going to talk about in the the second and next class and a little bit in the third class as well, how to actually make that package.

Also we need to really think about high availability.