bvQr6l5qyyU

Create a Software with AI

Watch on YouTube ↗

Transcript

[00:00] So, welcome to the last episode in this super long series about building software. I'm going to go over my experience in the last two years building out bumpups and everything I've learned. Let's jump in. Welcome back, y'all. In this video, we're going to go over a couple of topics. First one being branding and a mistake I made with branding early on in the software I was creating. The second topic is going to go over how to choose the right product for the right product fit. So, what's new? Next, I'll go over pricing and how to price your product for the market. Then we're going to dive a little bit deeper into the topic of mono or poly repository or another way of saying this

[00:31] whether to keep your entire codebase in one folder or separate it into multiple folders. For context, up to this point in this entire series, this has completely been a monor repo where our front end and our backend code is in one nice little folder that we can deploy together. And finally, I'm going to go over some tools that we leverage at BumpUps here that could possibly be very useful for your software for very specific things like product timelines, getting user feedback, everything of that nature. So, let's go ahead and jump in. First one here is branding. So, when I first started this software, the

[01:02] software was called Tube Stamp. And that was because at the time it was niched down just to provide AI timestamps for YouTubers, which makes sense. This was the use case. This was the value we provided. But as time went on, we started adding more and more features like giving titles, key takeaways, summaries, the ability to actually chat with the video, a bunch of other stuff. So the branding of Tube Stamp didn't really fit our use case on a longer horizon. So the first major thing I want to make sure you do is make sure you choose the correct branding for your company. The name of the company itself

[01:33] is pretty fundamental here. And this not only has to do with the fact that, for example, Tube Stamp, it was up for 6 months, we were getting good traffic, and then we had a pivot to bump ups. This also has to do with the fact with software and the nature of software when it comes to domains. Switching a software's domain from tube stamp to bumpups has further implications other than just completely changing the branding on the website it has implications with your backend and your front-end code. Therefore, when we made this change to bumpups.com, all of our current logic had to switch to this new URL. We had to set up new security

[02:05] associated this URL accepting the request from bumpups.com rather than tubestamp.com. You know, moving over the repository. It was just a bunch of grudging work that took two to four weeks where alternatively, if we chose the right name the first time, we could have avoided all of this. So, really understand what you're trying to build. If what you're trying to build is a simple one-sizefitit-all tool, we just provide timestamps, then proceed. Have a very niche name. This will tremendously help with search and SEO in Google and pushing the product itself because the

[02:35] name itself sells the product tube stamp. But if your intention is to maybe grow the product a little bit more, add more features to the product and sooner or later it becomes indistinguishable from its original value point of just timestamps like we did with our product, then choose a more general name, but something that really fits in your branding style. So the reason we chose bumpups is that in the first year we were really tailoring this platform for content creators. Therefore, the idea is that when you hear bump up, it's like you're getting a level up. You're bumping up your video. That's kind of the motion and the energy we wanted to

[03:07] give with branding when it comes to bump ups. But the name itself, bump ups, can be translated to now a more ubiquitous term when it comes to an AI model. Bump 1.0 bump ups. This kind of branding is more general. Therefore, we're not really cornered in if we state of tube stamp, which sounds like a platform that is just native to YouTube and providing timestamps. Therefore, when finding your branding name, take the time, whiteboard it out, draw it out, whatever it may be. Find the name that you see and you're

[03:38] going to really like 3 years from now. Which leads into the second topic here of choosing the correct product for you to spend all your time. Time is valuable. We only have so much. Therefore, whatever you put your energy towards, let's put it towards something that could actually give us a return on investment. My rule of thumb when it comes to this, and I'll give you a very specific story from bumpups here, is do a product that could not have been done 2 years ago. So, give yourself a 2-year window of hey, this could have been done in 2019. Should I still do this? Probably not. So, our two-year window

[04:09] and when we've used this logic within bumpups was our decision to either go down creating workspaces. So workspaces is that feature on bumpups that allows a user to chat with a video which we knew was a new piece of tech. This wasn't possible before, but now using AI models, we can actually contextualize a video, get information out of a video, and get value out of a video. Alternatively, the other path that we were thinking of is more of a social media scheduler. We may still entertain this path long term, but the idea with this at the time was create a social

[04:39] media scheduler like Buffer where the individual could upload a Tik Tok video, an Instagram reel, a YouTube video and then our AI model will contextualize the entire video automatically give the description or the caption or the hashtags. Essentially, the workflow for the user would be drag, drop, get value, publish. Now to surface level, yes, the idea of the captions and the descriptions being made could not have been done two years ago at the time, but the idea of being a social media scheduler, I mean, that's been here since probably 2012, if not earlier. So, the underlying concept itself could have

[05:11] been done years ago. Therefore, we opted to go towards workspaces here, which was not possible up to that point. It was brand new tech. When we made this decision, we did notice a tremendous increase in our MMR and a new spark of like, hey, what's going on here? let's check out this platform as it was new, it was cool and people wanted to leverage something that they hadn't seen before. So the rule of thumb here is go with something that when you create it and you're coding and you actually get it to work, the first feeling you get is like, whoa, that's actually kind of cool. If you get that feeling, you are

[05:42] leaning towards the correct path for the software you're creating. Next is pricing. How do you price your product? And this is a big one as this was a big mess up that we did here originally for software product. So to give context, I went ahead and grabbed some frames from a earlier video I had on this product. But the original way we were pricing this product was either the user could choose subscription or a one-time purchase. So here's the onetime purchase, then moving in. That is the subscription. Now the issue here is that we granualized way too much when it came to usage of our platform. At this point,

[06:13] we were doing a credit based system still, but the idea was that, hey, only purchase the amount of credits that you want to purchase. So, if you only need 200 minutes a month, choose 200 minutes a month. If you only need to do a onetime purchase for 100 minutes, choose that as well. But, as you can tell from this user interface, there's just too many options. It gets too confusing and you find yourself in a position where the MMR doesn't grow as fast as you want it to because of how confusing it is to the underlying consumer. The individual that's willing to pay $50 for a bump plan at 600 minutes a month would

[06:45] probably opt to still pay that $20 that we offer now. or alternatively upgrade to $40 a month. The idea here is less pricing options is typically better for softer products. Too many pricing options can make the consumer feel overwhelmed and not really necessarily know what the right fit is. Like how would you realistically know am I 400 minutes a month? Am I a,000 minutes a month? So therefore, we just flipped it. Like you know what? Let's make it crystal clear. Let's get the discretion of the bottom line of the amount of minutes per month and we're just going

[07:15] to set that to a,000 minutes a month. We know that is sufficient based off our usage of our users that most users won't reach over 1,000 minutes a month. And of course, if they do, they can purchase a higher plan. But look how simple this pricing is. Now, we got annual, we got monthly. So, any user that comes to our website and wants the free 60 minutes that reoccurs. So, we always give them 60 minutes every single month. This is actually good stuff for practice as well. This is going to lead to users that maybe don't pay but constantly use your platform every month. And then at a certain point after receiving 60 minutes every single month, they're like, "You

[07:46] know what? It's been three months. I actually do like this platform." They could possibly upgrade to the $20 month plan. But beyond that, the idea here is that we're setting a baseline a,000 minutes a month. Do you want to do local processing? Do you want to leverage the creator studio? If the answer is yes, your entry price is $20. I also like doing this as well as this gives clarity with your MMR and running different projections for MMRS in the coming months and the coming years. What I mean by this is that now that we know that the standard user at the bottom line is going to only spend a minimum of 20 USD.

[08:16] Alternatively to what we originally had where we like $3.49 there or $8.99 there. It's a bunch of different plans at different tiers. With just the $20 a month plan though, we have clarity,000 users on the $20 a month plan. That equals 20,000 MMR a month. So not only is it better for the consumer, but it's also better for the operator. So rule of thumb here when creating your pricing page, have up to four tiers. Right now we only have two tiers, free pro, but in theory we can upgrade to more. The idea here is that you have two to four tiers. Provide value in each tier. When a user

[08:47] spends more in a tier, you get more value obviously. So when coming to mono poly repo and when to choose either one. I'll draw it out real quick. I'm also going to link in the description down below a video that I cover more in depth of why I made the switch from monopoly, but I'll give you a tlddr right now. So a monor repo is just your current codebase, one file, one go. A poly repo will take this monorreo and split it up into multiple different repositories in GitHub. So you know right now when you go to GitHub, you click your software's repo, it's just one. A poly repo would

[09:19] split that up into multiple. So you'd have one right here, one right here, here, and here. So to give a real quick example, it would be like one repository has all the back-end functions aligned with payment processing. One repository has all the functions associated with authentication. One would be all the value you provide. eg the pipelines and the custom pipelines that you're building for when you give the end consumer value whatever value is in your context. So for tube stamp that would be the timestamps we'd have one repository just dedicated to that and then finally one repository dedicated to the entire

[09:49] front end. This is twofold and the reason we do this is the first reason that when you grow and you possibly onboard employees/ interns you have the ability to only give access to certain repositories. So, for example, if you've onboarded an intern, maybe you want that intern only to work on the payment repo, then we just give access only to the payment repo and they don't have access to all the other repos here. If you're interested in learning the hiring process with LinkedIn and how to hire and onboard unpaid interns, I've actually created a whole series on that as well. So, I'll make sure I link that

[10:19] in the description down below in our school community here. I give all the lessons. It should be something along the lines of how to hire employees or a team. Check that out. I go over step by step how to hire unpaid interns and the processes that we used here at bumpups with a bunch of free resources for you to start leveraging. Another advantage of a poly repo is the ability to start deploying faster. So the idea is that instead of us every single time having to deploy from the monor repo which will therefore do the backend and the front end all the different functions in one go. Alternatively, this allows us to

[10:50] only deploy the payment function when there's a change in the payment functions. So when do we know to make this switch? I suggest keep coding in your monor repo until you've proven that there is a market fit. Once you identified that hey I'm getting paid customers or I'm getting a lot of active users. This is when the transition should occur. Everything before that you should stay within the monor repo as it makes development faster. As I described in that one video I'll link down below. Idea here is this monor repo allows for faster deployments and faster work when coding of AI. Poly repo comes into play

[11:22] as your organization gets bigger and especially if you plan on going down the route of hiring unpaid interns or hiring employees a poly repo becomes fundamentally important. So, first six months of building out your software, stick with monor repo. Maybe even first year, wait for proof of concept, wait for a market validation, then transition to a poly repo, which I need to make a video on on how to transition a monor repo to a poly repo. That's a different story. That's a different video. Now, let me go over some tools that we use in bumpups that could be cool. Some are free, some are paid. Check them out. So, in bumpups, we can come down to the

[11:52] bottom. And one tool that's very useful that's free is Kenny. So, c an n y. I'm going to drag it down for y'all. Right up there. kenny.io. I like ky.io because what this allows you to do is not only get feedback from your users of your product and be able to respond to that as you can see with all this to my right, but also create a really cool change log. Now, change log is pretty standard practice with software development or any type of development. You know, if you ever played video games, they will push out an update and it'll be part of their change log. The idea behind a change log is that when

[12:22] you push out a big update for your software, you will give a real quick summary of the relevant update and maybe add an image as well. This is just really cool for you as an operator as well, just to see over time as your software grows, you have like little milestones, which are pretty cool, but also as well, it could be useful to anyone that wants to look at your platform and see how it's transformed over time. So, Cany's cool, Kenny's free, everything you've seen up to this point on Cany completely free. Another one that's going to be really helpful, especially if you're a small team, is going to be intercom. And that's going to be our help center here. Intercom is

[12:52] really cool because what we can do with intercom is that we can set up by category every single question that would typically incur with a new user of your of your software. Intercom is also used by OpenAI. I believe it's also used by Zapier as well. This is a pretty well-known help software. Idea being user comes here, frequently asked questions, which languages are supported, clicks here, and then they can see, you know, nice little help article of everything relevant to that. This mitigates tremendously the cost associated with dealing with a bunch of support tickets, especially stuff like billing. A lot of times users want to

[13:23] understand how to update their billing information, how to upgrade their plan, everything like that. Just mitigate the cost on your end when it comes to the labor associated with answering emails and just make the help articles. This is an evergreen asset that no matter what this how does subscription payment processing work will still have relevancy 6 months from now unless of course we've switched from a different payment processor. Now, for any of you that maybe are making an API based product or alternatively want to add an API layer, a good API documentation software that we like to use is Scaler.

[13:53] So, for our API documentation, it's very modern, very easy to use. Scaler.com, sar.com. You can create and start for free. Build out your entire documentation or whatever your relevant API is and get going. Another big thing as a rule of thumb is that whenever you're creating your software, if you like your branding name, take the initiative to try to get that handle within different social media platforms. For example, we got really lucky here, but somehow no one had the handle bumps. So, we took the handle bump ups on X. We went ahead and

[14:25] opted to take the handle on bumpups for LinkedIn as well, YouTube, even Instagram. Whatever you think you're possibly going to use in the future, take the initiative, take the handle, maybe just do one post. Let's just set the baseline. So, if your company does really well, you don't have to go through the headache of dealing with either buying the handle back or alternatively dealing with maybe giving a weird name to the handle just to get it, etc. One cool thing that you could add to your website as well is a newsroom. This is two birds of one stone. So, I like to do it where anytime there is a significant update, we'll put

[14:55] it in the change log. We'll also put it in the newsroom. And what we can do here is have a nice little article associated with the update. But on top of that, we can leverage the link up here, right there, copy it, and then paste it into a LinkedIn post, paste it into an expost. So, we give a little bit of a brief summary of like, hey, we got an update. If you want to read more, check out our newsroom. And to be honest with y'all, when I created this newsroom, it was extremely a lot simpler than you would expect. And it was pretty cool. You can search through different little blogs here. And creating a newsroom or a blog is pretty simple. So, to give an example

[15:25] of that kind of post, come over to X here. We gave you a nice little summary. added the relevant company that we were working with at the time. So that would be Zapier here and then we do read more and that would take us to the link. There we go. Meet bump ups on Zapier. More context, more information. To be honest with you, I'll probably make a series on how to just create a blog on a front end as the steps here are pretty simple and I can show how to do that with AI coding. So that just about does this super long series, y'all. I hope you enjoyed it. I know you probably got some coffee along the way. I plan on doing another series here showing how to do mobile apps, which will be a whole separate step-by-step process for iOS,

[15:56] Android, everything of that nature. But without further ado, as you already know, I'll see you in the next