In this episode, Amaury and Mitchie go over the last 2 levels of the prototyping process, where your MVP will gradually transform into an established product. This includes educating founders on the bare minimum of tech CEO’s need to understand.
Pre-order a copy of Amaury’s new book, Startup Without a CTO, and get an early digital version two months before the official launch: http://startupwithoutcto.com/
Disclamer!
This episode has a lot of technical terms. The idea is for you to get the concept more than memorizing the technologies. You can always refer to our notes and other content to address more specific topics in the prototyping stage.
We talk about level 0 and level 1 of the prototyping stages on episode 11 – Your MVP with almost no Tech
No, you pretty much have to go through a self-assessment exercise to figure out where you should start.
For example:
The point is if there’s enough market understanding you can invest a little in a real functional app.
So when setting up a simple WordPress website, headless CMS or a business intelligence tool -aka. a reporting tool- is not cutting it anymore, how do you move forward?
5% of Tech : Real app with a bit of customization
GOAL: To build a better Customer Experience (not just talking about graphic design, but also functionalities, experience, interactions…
You can set up your own SaaS solution with a membership LMS/Business intelligence
For this you will need a bit of a developer’s and/or an engineer’s time, to install and combine the right tools.
Also identify resources on a global marketplace, or people that are good with specific types of development…
Suggestion:
10- 15% of Tech: Make the gradual transition to your own product.
GOAL: Get rid of what is inefficient, transform what works and standardize it.
You should focus on developing the core of your application, while still using most of the tools you have so far.
This is probably a good time to refactor the interface and to focus on more specific needs.
You should keep using external services that are relevant and reliable!
A good example of what you would drop is Zapier. It's an extremely useful tool, but at this scale it becomes extremely unreliable, so stop using it. Move on to real cloud functions.
A great way to guarantee reliability is by moving onto real microservices, with the option of rollback or a fail-over process in case of failure.
Instead of developing one big software that includes all of the actions one may ever ask of it, we create one small piece of software for each clear and independent feature or function. That small piece of software is referred to as a Microservice.
Let's assume that we want to recognize a text on an image. We can have a microservice that is going to take the image from one directory, analyze what is inside, and put the result in a database or maybe in a text file next to the image. And that's it, that's the whole purpose of that one specific microservice
These microservices have been specifically designed for “small tasks”, they are ready to go, reliable and optimized. Recognize what parts of your solution can be optimized by using existing APIs, and integrate them in your process.
Then comes your innovative / disruptive side, you can identify the other kinds of functionalities that are maybe more specific to your solution and particularly to what you want to develop. Those can be custom developed to your needs snd those would represent that 15% of tech required in level 3 of prototyping your MVP
Reusing pieces of software
Do not reinvent the wheel !
There are plenty of options out there for real Saas API Solutions, covering any need you might have. Making the most of them helps you transition onto building an entire ecosystem, where you can create future versions
A legacy system, in the context of computing, refers to outdated computer systems, programming languages or application software that are used instead of available upgraded versions
By choosing to build an MVP, in some way we are creating legacy on purpose, because we don’t know if things are going to work, and we don’t want to spend too much money upfront…
By starting with a microservice approach, we ensure that we will be able to move away from those legacy blocks and create more up-to-date and reliable solutions.
Mitchie Ruiz: Welcome to Episode 12 of My CTO Friend the Podcast where founders come to learn how to manage a tech startup. This is me Mitchie Ruiz and I'm with Amaury Khelifi. Hi Amaury?
Amaury Khelifi: Hi Mitchie, and welcome, startupers, to today's podcast. Scale your MVP with almost no money. In this episode, we are going to learn how you can improve your prototype—your MVP, and how to gradually build it up. There are always some doubts on which technology we should use, and transitioning smoothly to an established product is a process a CEO needs to understand.
Mitchie: Remember that for this first series of the podcast, we are working our way down Amaury's book, going through the tips and real startup experiences he's gathered throughout the years. So if you're a founder without technical background, listen up, because you're in the right place. Let's just go ahead and jump right in, Amaury.
So last episode we discussed the first two levels of prototyping your MVP, or of starting your product. Right now we're going to tackle the next two levels. These four levels are actually separated according to complexity and cost. So the first level, so Level 0, had no tech, no tech involvement at all. Everything was manual. Level 1 had a little tech and some stuff that anyone can learn with just 1% of custom development and automation. Level 2 and Level 3, which are the ones that we're going to tackle today, do have 5% and 10% of costs and development, and they're basically just using real applications with a bit of customization. And then on Level 3, we're going to move to a proper development.
Now the goal here is to educate founders on the option we have to industrialize a prototype based on existing technologies. In last episode, we were focusing more on how you can do things yourself. Here we're focusing on what your options are. Now we do have a little bit of a disclaimer here. Today's episode is a little bit technical. Especially because this is a podcast for non-technical startup founders, we'll do our best to explain every technical term throughout the episode. And the idea for you is to get the concept more than the actual technologies. You can look at the notes for our episode to refer to certain tools and certain technologies. The idea is to just get what we're talking about and if you have any questions, you can always ask on myctofriend.co/podcast. Now here, we just want to grow a product and MVP, and the idea is how we're going to move forward from what we did on the previous episode, the first two levels. Is there anything else we should add to that disclaimer, Amaury?
Amaury: No, I think that's a very good start, and maybe we should just reexplain or summarize how we left our listeners in the previous episode. Basically on Level 2, we were building our first MVP with maybe based on WordPress or CMS solution. It can be…
Mitchie: Sorry, that would be Level 1?
Amaury: Sorry, yes. Excuse me, Level 1, don't get confused. Last time we were mentioning the Level 1 where you might have built an MVP based on WordPress, or an existing headless CMS, or on some tools that helps you just to get out and start selling something. But the drawbacks of using someone else’s tools is it hasn't been built for your business, for your clients, for your customers, and you will get to the limitations of that tool pretty quickly. So now the goal is to customize and to create a better customer experience, a better tool, not only in terms of design, but it's also having better interactions, generating better emails automatically, having maybe SMS that can come or text message that can come on mobiles as well if it's required. It's just to create a real solution that is not adopted from something existing, but something that is built for your client.
Mitchie: Got It. Now, that's getting into Level 2, which is 5% of technical necessities. Before we get to it, I just want to go back a little bit. And since we are covering four levels of prototyping, we did cover this in the previous episode, but just to refresh, are all of these levels necessary?
Amaury: Yeah, it's not mandatory to go through all that levels. If you have a budget, if you know your market, if you really know what your clients need, you don't need to go just by your landing page and to see there are some people that subscribe, and then creating a website based on WordPress and adapting and tweaking, and wasting a bit of time. We have to say that going through all that level is a bit of a waste of time, but this time is also a way to ensure that what you are building will work.
So if you are building something that is not proven—honesty, I really recommend you to go through that process so that you ensure that your client will be willing to pay your service, that's what I always say. Now let's assume that you are a company that provides a service for 10 years. You know exactly what people want, in that case, maybe you can jump right into Level 2 and to consider building an application based on something already existing, which might be the 95%, and doing right away some 5% of real custom development. So having developers or a provider that is going to tweak the tool and that you might choose, and then creating your first application at a Level 2 right off the bat.
Mitchie: Got It. We did cover this, like I mentioned in the previous episode, when we were discussing your focus. On the Level 1, you would need to have a focus if you needed to make sure that your concept worked and you need a proven concept, then that would be focusing on developing customer experience. And on Level 1, you also had the opportunity of developing the back end or what you as a founder would interact with to provide that service. And it's the same here. The idea would be for you as a founder to recognize where you're at, what your skills are, and what point in your startup-founder journey you're in to identify which level would be the most relevant for you to start on.
So just an idea without much market understanding, start from Level 0 right away. Make sure you know that this is going to have an audience. If, like Amaury mentioned, you're already there, you've worked on this for so long, start from Level 2 or start from Level 1, if you're not sure how to structure things. It's a self-assessment exercise that you need to go through, depending on what your idea is, what your startup is going to be, and who you are as an entrepreneur as well. So let's move on and let's tackle a Level 2 right away.
Amaury: So maybe we should define what type of technology approach we have on that type of level. Previously, the goal was to use an existing tool and to try to adapt it. Now it's time to build something. So you have several options, I think the technology that represents the most what I want to share on that level is Bubble.is. Bubble.is is a prototyping technology, kind of—if there are some old entrepreneurs here, the Microsoft Access approach, which is something that has been built 20, 25 years ago. It's like designing screens and making links between some screens and a database, and you do it just with your mouse and your keyboard. It does not require a tech background. And it works. You can build a startup from there.
I don't think you can really scale to a large audience, but you can definitely have maybe 1,000, maybe up to 10,000 users with this type of technology. And that's just great because you can have custom design, you can have a real website, a real application. And they also have some, if I'm right, virtual reality and augmented reality plugins, so you can do things for real with kind of zero code. And I use the term “zero code” because there is a website which is called Zeroqode with a Q-O-D-E at the end, dot com. And that's lots of tutorials to build whatever website you want. If want to create a booking website or a mobile application, you have a tutorial for that. If you want to create an online course, LMS (learning management system), you can do it as well. And there are lots of templates, just tutorial to follow to create what you need, and that's just amazing.
Mitchie: Yeah, and just to go over that, that would be Bubble.is, that's the website where you can find the tool.
Amaury: Yeah, absolutely.
Mitchie: And you can learn about the tool and how you can actually use it at zeroqode.com. I already googled it. It's zeroqode.com.
Amaury: Yeah, that's some tutorials. They are quite well known in this industry. Of course, these are paid. We don't get any interest in that, but definitely that's an option. It will still require one week of work to build a website like Airbnb, for example. But honestly, it's nothing. If you would ask a real developer to do it, he will budget a month or even more. It should be at least something like three months. And yeah, that's definitely a good option. The other approach, now that you have this kind of tool which is a real proprietary technology, which means that it belongs to a company and you will need at some point to move away from it. So you have other options.
You can use existing open-source software. We were mentioning a WordPress or a headless CMS, which are some type of software, but you can find some more specific software. Like you might find some custom templates for WordPress, and you can get deeper by developing on this type of open-source software. If I would create like an LMS, a learning management system, another option would be either to use a SaaS solution, so they are a very professional LMS that you can pay on a monthly basis and you can build your entire product on it.
Again, you will have to move away one day or another. And you can also use open-source approach like using Moodle or Open edX, which are the technology that are used by universities and schools to provide learning environment to their students. And you can tweak it and redesign it, and maybe change the process, develop plugins on these type of solutions so that you can maybe add something that do not exist and create your own ecosystem, if you are on a learning and teaching way of providing value to your audience.
Mitchie: Wonderful. Let's see. So just to go back a little bit, some of these options are working in an app, some of these are working in a website. Those would be the two different approaches. Which one would be which?
Amaury: If you take Moodle, for example, it exists in both versions. You can have a template mobile application. So you can download the application, give it to a developer who will need a bit of time to just get used to it. He is going to design the application and all your own colors. And within one day or two, you might have your own application. You can also find some providers that are specialized in this type of technology, and in that case, instead of one day or two, maybe they are going to do it in a couple of hours. And that's exactly the same with other technologies. If you need to build an e-commerce website and you need to tweak it exactly the same way, you can find an open-source technology. You can ask a professional that is used to that technology, and then having your solution.
So that's why it's very important as a CEO to understand finally what technology is the best to achieve my goal so that I can ask one company or another which is really the expert in that technology. Because if you ask the Web agency that is just next to your office, they will have their own technology. There is a good chance that it will not be the most effective. They might offer you a solution that will work at the end, but the cost might be higher than if you choose the right technology from the beginning and then select the company that is really relevant for that technology.
Mitchie: Okay. So I'm just going to go ahead and paraphrase a little bit and make sure I understood and that our listeners understood. On Level 2, we're mostly recognizing the different apps or different websites that have some use to our own startup, and identifying which technologies they use so we can test them out, so we can use them as a base for our own product. Would that be the case?
Amaury: Yes, absolutely. You can get inspired by what exists, Ad you can also, if they are open source just get the source code and build your own plugin on it to have your own features, your own templates, your own aspects, and create a better custom customer experience.
Mitchie: Wonderful. And from that part, we would be moving towards Level 3.
Amaury: Yes. Before we tackle the Level 3, maybe we should mention, “What do we need?” If I assume that I am a CEO, I don't know anything about tech. I did a couple of things on WordPress, installing a template, etcetera. But now I need to make it better. What do I need?” You need someone who is an expert in that technology. And you can find them, either finding an agency as I said, but you can also search for people like freelancers on platforms like Upwork. You also have Fiverr, maybe it's not the best. You have lots of marketplaces. In Europe, you have—it's a French one in the beginning—it's Malt, M-A-L-T. It should be dot F-R, but there are lots of other domains in Europe. You have all these websites, these marketplaces where you can find some resources that are really specialized and that are going to be very cost effective.
Mitchie: So after identifying the right technologies for you, you would look for the right people to develop them. So make sure that they have previous experience on these technologies, and if there are other technologies that you are considering to use, making sure that they are familiar with them as well and letting them advise you, I would suggest as well, if they're familiar with the technology, they can let you know, “We can add this,” or, “We cannot add this.”
Amaury: Yes, absolutely. They will confirm what you thought what is possible or not. And yeah, you just need at the end to evaluate if they are good or not. I have several videos on My CTO Friend, by the way, that are just free, on YouTube as well, on how to select a developer or how to select a CTO, or how to select a provider. You can find several recommendations and questions to ask.
Mitchie: Wonderful. Is there anything else we should cover in Level 2?
Amaury: No, let's jump to the next level now. And let's say that you have a proper website, a proper application that does the job. The drawback of using this approach and, of course, building an MVP, is it hasn't been built for that. It works, but sometimes you can find some difficulties, or maybe they are going to have a crash. Like if you were using Zapier, for example. Maybe the connection wasn't up when the automation was supposed to run. So what happens? You need to catch up manually. So definitely, now the goal of this level is to become more professional and to move slightly to a real product.
Mitchie: Got It. So in this level, we are recognizing what's holding us back. We are recognizing what's not efficient enough or what is actually extra. If we have things that we're not using in the open-source applications that we're using, and these extra parts that were not taken advantage of, they're making it crash or they're just taking space. We need to make sure that we know what we really need. So developing the core of what your application is going to be or your website, your product is going to be.
Amaury: Yeah, building a startup is all about managing and playing with the quality of what you are creating. So in the beginning, we were focusing on values and well-designed stuff just to be able to test. Now the goal is to really prove that it's reliable, that people can count on it, especially if they pay for it. And that's where maybe you will have to repurpose the core of your application if you choose, for example, to go with WordPress, you will have to set it aside at some point. If you choose to go with a headless CMS, that's a better option, and you will be able to keep growing around it and connect your new development directly to your application. And I was talking about Zapier, and the fact that Zapier might not be reliable in the long run.
Amaury: If you have, let's assume several hundred subscriptions every day, maybe at some point, the zap on Zapier will not do the subscription automatically and launch the automation that is supposed to be launched. And you will have to create your own piece of software, and the real approach is to create what we call microservices. And that's what we've done. That's what we recommended so farm by using a zap somewhere, a tool on Zapier by using a piece of software, maybe having a piece of script somewhere else, that's a micro rule that are in the ecosystem of your software, and now we are just going to develop them in a more reliable way. And that's what we call microservices.
Microservices is a concept that has several years ago, maybe something like 10 years ago or seven more, I think. And the concept is simple. Instead of developing one software, I create one piece of software for each clear and independent feature or function. Let's assume that we want to recognize a text on an image. We can have a microservice that is going to take the image from one directory, analyze what is inside, and put the result in a database or maybe in a text file next to the image. That can be the role of one microservice.
By the away, this type of microservice is not worth to develop yourself as you already have lots of microservices and SaaS service that do exactly this on AWS, Google Vision. You might have Microsoft Azure that does the same as well. So there are some microservices that exist that are very effective in performance. Use them, they are reliable. They are built for it. They are built for larger scales unlike Zapier, and you can build your architecture on it. And if there's something that does not exist yet, in that case, you have to create your own development and reproduce what your Zapier processes were doing with maybe 10, 20 or 30 lines of code.
Mitchie: Got It. So let's just go ahead and paraphrase that a little bit, make sure I understood, make sure our listeners would understand. So what we have done so far is using existing tools to make sure that everything that we're using is connected. So we have different kinds of tools to organize our solution and to organize ourselves managing that solution, and we have other tools like we're using in this case, Zapier, whose only goal is to connect those tools that we're using.
Right now the idea would be to go a little bit more specific. So for each feature, and this you should have separated on your roadmap when you are defining your roadmap—if you haven't, you're a little bit ahead, you should go back to Episode 9: Roadmap definition. So when you were defining the features, you would use that same separation here to identify the functions within those features.
So you would go more specific on what your actions are within your solution, and identifying what actions you can automate through existing APIs, things that are very basic, very straightforward, many people need, so you have already developed solutions, existing solutions that are optimized, they're ready to go, you can use them; and then identifying the other kinds of functionalities that are maybe more specific to your solution, more specific to what you want to develop. And you should have some of those since if you're a startup founder, you're doing something new and innovative—again, if you want to do things innovative go to Episode 8: From an idea to an innovative startup. And that innovation comes with doing things you haven't done before, so those functionalities would be done more custom. You would identify each function and check what you can do yourself with the developer, and integrate that with your other APIs and what you've developed so far. I don't know if what I just said made sense. Did that make sense?
Amaury: Absolutely. That makes perfect sense. That's the 15% we were mentioning. Instead of developing an application on 100%, I always seek of existing components that we can use and that fits to the quality that we aim, and that's exactly what we are doing now. We are replacing what is not adapted, what is not effective, what is not reliable, and we build just better components on our ecosystem. And having these microservices architecture will help. And you might also consider replacing the core of your application, for example, if you went through Bubble.is in the beginning or WordPress option to get started and to have just proof of concept website, you might consider replacing your core database by something more reliable.
Mitchie: Got It. That would be Level 3, replacing what you used temporarily. And that's clear. This process, prototyping and MVP, those are temporary solutions that you're using to prove your concept, to get investors, to get incubators, to build an audience. This is part of it. So it's fine if they're temporary solutions. So we talked about reusing existing solutions and identifying what you can use from other people. How do founders navigate that? How do they find that? How do they know what has been invented?
Amaury: So there are several things. First off, if you are wondering if something already exists, there are some marketplaces. The bigger marketplace in terms of API is called RapidAPI, which was before Mashape. I was using Mashape, but now it's RapidAPI. You can search on this marketplace almost any type of function. Like if you want to create a cloud word, you can do it. If you want to recognize the text that is on an audio file, you can do it. And you can do the opposite as well. You can transcribe a text file into a speech, and you have lots of functionalities in terms of AI and analyzing text with the natural language processing (NLP). You can analyze some images, you can do whatever you want. So on these type of marketplace, you will find thousands and thousands of specific functions that have been developed by developers, and developers provide the service, and you pay just per request.
And you also have large cloud providers. Not to mention AWS, Amazon Web Services, Microsoft Azure, Google Cloud and IBM. These are the most known that provides some microservices as well. So basic things like image recognition, voice—they have all quite the same tools, some are better than others. If we mentioned a natural language processing, I know that Microsoft is pretty good with it. Maybe if we are more on artificial intelligence, AWS is very good as well. They all have their own specific strengths, of course.
So navigate on these websites. Try to figure out how things work. They have a bunch of tutorials that are more directed towards CTOs, I have to say, but that you can just get to know what's possible, and above all, knowing that something that could cost maybe two, three, five months, or maybe more than a year of development or 10 years of development—we were mentioning natural language processing, that’s an algorithm that takes several years to develop, using their service is just available in five minutes. if you have a developer, you just redirect them to the right solution. Five minutes later, they can convert your audio file into a text file, and that works. And that's something that you really need to be aware of.
Mitchie: Wonderful. That is something that before I started working with you, I didn't know, which was the fact that building an app is not just getting someone who knows how to program. Because for me, that's just something ethereal, if you know how to tell a computer what to do with all those numbers and dashes and slashes, you are a god to me. So for me to actually identify that the process of building a prototype or an app, it's not you telling someone who understands these types of techie things exactly everything you need for your app, and for them to take care of it. That's not the way to go at all, and that's the whole purpose of this podcast.
The reason why I mentioned this in this episode is that for me that would be the way to go. Just do your verbal speech and long speech of what you want on an app and let the other person take care of it, and just give all of your trust to these people. And actually, what you should be doing is being hands on, learning a little bit of what you can do, and identifying that you don't have to develop everything from scratch. There's a lot of things, you could probably build most of your application out of these APIs, out of these RapidAPIs that are there. They're already developed. They're all ready to go. Just a bunch of them, it's your app. I find that amazing.
Amaury: Absolutely. You should build your application. When you build a startup, you should aim to have 90% of your app that is reused software, reused source code. And if it's not 90%, maybe you are going to decrease to 80% or 70%. And after five years, maybe you will be at 60%. But in the beginning, definitely, you need to reuse. And that's also why, when Apple started and launched their Mac OS X, it was built over FreeBSD, and FreeBSD is open source. They used 90% of what already exists to build their next operating system. If they used it, basically you can do exactly the same.
Mitchie: Yeah, Apple is a good example of what you can do.
Amaury: Yeah, quite a good example. Maybe we should go to the conclusion of today.
Mitchie: Yes, let's wrap this up. It was a little bit techie, but we did cover a lot. So let's just go ahead and see. We are doing all of this. For what? For being able to move to your own product.
Amaury: Yes. When you build a startup, you have small investments, small budget, and you need to prove your market. So you do things manually, you do things with tools that already exist. Then you build something a bit better, Level 1, Level 2. And then at some point, you will have to be established, you have a real business, you will have some investors. Investors might want to run some audit on what you have so far, of what you built, and that's fine. Just be transparent. “We did this. We were smart. We had this approach. Now we need to make it more reliable, and we have something better.” And the goal is to build your entire ecosystem for your future version.
Amaury: We use the word “legacy” in computer science. It's usually to mention old development, old software that are not ready, not effective enough, and that's fine. When we build a startup, that's okay to have a bit of legacy as long as you do not waste your time to build software yourself. As long as it's because you reused someone else’s tool, that's fine. Then you can move and refactor, and repurpose, and just rebuild some stuff from scratch as soon as you have these microservices approach, that's fine.
Mitchie: So some of these microservices might be close to being outdated or something like that, but we're just using them for their functionality and they can be replaced later on.
Amaury: Yeah, that's the approach, definitely.
Mitchie: Perfect. Also, now that I'm thinking of it, if you use some kind of legacy technology, you would be able to find a lot of people that are familiar with it, and they would be able to help you,
Amaury: Well, it depends. Because if someone is really specialized and expert in one old technology, he might not be aware of how we do things now. So the best way is to talk to IT architects, to people, engineers at AWS maybe, at Microsoft Azure and Google, because they know the trend. They know what are the latest frameworks. They know what are the latest, best options to build this type of software. And sharing how you did things with them and asking them, “What do you think I should do now? I want to build things faster. I don't want to waste time in managing servers, in deploying the application. I want to do things automatically, as automatic as we can. What do you recommend?” And they are going to give you some real insight on how you should do things.
Mitchie: So IT architects are your friends.
Amaury: They’re the best CTOs’ friends, absolutely. And if you don't have CTOs, don't be afraid to go and talk to these architects as well as businessmen. there are lots of businessmen at this type of cloud providers, and they are here to make you understand what are the benefits. Everything we are talking today—actually the role of these cloud providers, it’s their role to make you understand why it's relevant for you to use their technology.
Mitchie: Got It. Perfect. This microservices approach, it's very promising and it's pretty much what we did on the previous episode, just other microservices were tools and applications and things that already existed, and right now we're just seeing what we can replace and what we can optimize. We've covered a lot.
Amaury: Thank you, Mitchie, for the explanation and for making things more understandable for everyone.
Mitchie: I try. I'm non-technical myself. I'm here to represent our listeners and identify like, “Sorry, this is too techie for me. Can you explain that again?”
Amaury: You did a good job.
Mitchie: That's why I'm here. That was very informative. I'm finishing every episode with, “That was a lot,” because I'm just learning so much, and I'm sure our listeners are too. If there was something that was a little bit tricky to follow, tricky to understand, which, of course, we understand, it's a techie episode, again, you can look at the notes at myctofriend.co/12, which is the number of today's episode. And if you want to look at other tech management stuff, Amaury has a lot of videos, a lot of courses, a lot of things that you can go ahead and review again at myctofriend.co. Is there anything else they should check out, Amaury?
Amaury: There is just the book that we are currently writing. You can preorder the book at startupwithoutcto.com. And if you preorder that book, you will get the digital version two months before the official launch. That’s startupwithoutcto.com. And yeah, we had a good time one more time.
Mitchie: We did, we always do. Thank you everyone for listening, and until next time. Thank you, Amaury.
Amaury: Thank you, Mitchie. And again, tiny thing, if you can go on iTunes and give us a small review, we would really appreciate it. Thanks for your time, and until next time, bye.
