
Growth Leap
Welcome to Growth Leap, a Stun and Awe podcast that looks into how business builders design and grow their companies for performance and impact.
Growth Leap
From launch to successful exit in less than two years with bootstrapped startup expert Arvid Kahl
If you’re interested in building a startup that works like clockwork, you need to listen to our guest today. He’s done it, and he’s done pretty much everything right. He co-founded Feedbackpanda.com, a SaaS startup and went from launch to selling it in just under two years. Arvid Kahl is an entrepreneur, investor, author, software engineer, and bootstrapped startup expert. He’s the author of the book Zero to Sold: How to Start, Run, and Sell a Bootstrapped Business and he’s busy writing a second one.
We talk about what to do to build a sellable company, his approach to automation, how to stay in touch with end users, how he made build or buy decisions, his secret to onboarding employees quickly, and his take on founders’ mental health and bootstrapping. It was such a fun and insightful interview. Enjoy!
We cover:
- Arvid’s background and what he’s been up to since selling his startup
- What problem Arvid and his partner faced that led to the launch of FeebackPanda
- The simple marketing strategy that generated a constant influx of customers
- How Arvid avoided previous product validation mistakes
- The resources and frameworks that helped Arvid built an automated and sellable bootstrapped startup
- Arvid’s advice to allow engineers to do coding deep work without losing touch with the end users
- The automations Arvid put in place to increase effectiveness and productivity
- How Arvid made made or buy decisions while developing his product
- The biggest hiring mistake Arvid made
- Arvid’s secret to hire and get people up and running in a matter of hours
- Arvid documented his processes
- The habit you need to acquire to
- Why Arvid prefers startups who ride a sustainable linear curve instead of a hockey stick
For detailed show notes and relevant links, visit www.stunandawe.com
If you want to accelerate traction, hit the growth stage, and upgrade your scaling skills, check out our Growth Leap online course. It’s a step-by-step guide to design your tech startup for high performance and impact. It’s packed with actionable and proven frameworks and tools to improve your startups performance, from better customer acquisition to clear prioritization and more productive meetings.
Learn more here: https://growth.stunandawe.com/course
- Do you have a question you'd like me to answer on the podcast or feedback to share? Leave me a message here.
- You'll find all the show notes, transcripts, and past guests at stunandawe.com
- Up your growth game with our hands-on Growth Marketing Course
- For inquiries about sponsoring the podcast, email marketing@stunandawe.com.
- Support the show on Patreon
Follow us:
Hydro
Speaker 2:And welcome to another episode of growth leap. I'm your host, Michelle Daniel. We talked to pretty awesome business builders for designing disruptive and meaningful, Happy new year. Everyone. We've got some great interviews for you in the pipeline this year, and we want it to start strong. If you're interested in building a startup that works like clockwork, well, you need to listen to our guest today. He's done it and he's done pretty much everything, right? He co-founded feedback Panda the SAS startup and went from launch to selling it in just under two years. Arvind Kal is an entrepreneur investor author software engineer in bootstrap startup expert. He's the author of the book, zero to sold how to start, run and sell a bootstrap business. And he's busy writing a second book. We talk about what to do to build a sellable company, his approach to automation, how to stay in touch with end-users, how we made build or buy decisions is secret to onboarding employees quickly, and his take on founders, mental health and bootstrapping. It was such a fun and insightful interview. I really hope you enjoy Welcome to the show Arvin. It's a pleasure having you with us. Thanks for your time.
Speaker 3:Thanks so much for having me. I'm super excited.
Speaker 2:Our venue co-founded bootstrap and sold in just under two years feedback, panda.com and online teacher productivity, SAS company, before we delve into that experience, because it's quite an interesting one. Can you give us a quick rundown of your background and what you've been doing since you sold the business in 2019?
Speaker 3:Right. Well, I'm a software engineer by trade. I think that's, that's what I learned to do. That's what I was first paid to do. And that's what I always considered myself to be. But usually people are much more than just one thing. And that's what I figured out when I started building businesses with people, friends and colleagues, co-founded a couple of bootstrapped businesses worked for VC funded businesses as a software engineering tech kind of person person there, but turn out to be an entrepreneur as well. And then we founded and built a few depend on, like you said, me being my girlfriend and I. So it was a team effort, a relationship that was both private and business at the same time. Super interesting dynamics there. I can tell you that. And then after that, I started writing about it. Once we sold the business, once we exited and sold for what I'm allowed to say is a life-changing amount of money. I didn't have much to do, honestly, because once you give you a company away at you, you go run a full steam and then all of a sudden there's nothing, right. If you run into this, this void, this hole. And I felt that with writing about my experiences, both would fit the Panda and all the bootstrap project projects that I was part of before a couple here in Berlin as well, where I'm located and where I've been located for a couple of years now, I'm German. So it's a kind of logical way to go to the most interesting German city where lots of startups happen. So that's, that's where I'm, that's what I am. And yeah, I've been writing, uh, writing books, writing articles, having a podcast, all these kinds of things ever since we sold the business, which was mid 2019. So now over a year and a half, I've been releasing content. And I wrote a book called Sierra to sold, which has been doing really well in the bootstrapping, in the hacker indie founder community, which I'm super proud of and super happy about. Yeah, that's, that's what I've been doing.
Speaker 2:Great. Great. And, uh, let's go back a bit and talk about feedback Panda. You basically grew the company from an idea to a business generating 55,000 in monthly recurring revenue without hiring a single employee. And then you sold that to sure. Swift capital in less than two years. Can you just give us a bit of a brief on what feedback Panda is or was for you? Sure.
Speaker 3:Yeah, it still is. I'm sure capital acquired the property and just continued to run it, which was one of the things we really wanted to happen because we actually solved a problem that wasn't just there to make us money. It was a meaningful thing to be cared about. Like Panda is a result of Danielle, my girlfriend working as an English teacher and running into brick walls with one particular thing. And that was student feedback. And she was working from home because she had a leg injury. I couldn't go outside, couldn't do other things. So she needed to find some way to make money from home. She was teaching kids in China, English as second language over the internet through a browser, which is highly specific if you think about it. But knowing that is such a specific task, we could also really pinpoint the problems in that space. And those were problems that all these other teachers that these Chinese companies had hired North American teachers, Canadians people from the U S or British people, anybody who speaks English natively, they would be hired as a contractor for these Chinese companies. So it was Danielle, my girlfriend, and she was often teaching eight, 10 hours a day. And then she had to do student feedback for an additional two hours, but that was unpaid. And if she didn't do it, she wouldn't be paid for the lessons she taught anyway. So it was this really annoying central problem that all these other teachers had as well. And Danielle one, one point came to me and said, what can we solve this? Then I, we looked into it together and I built like a prototype, little sass, a little technical solution to her problem involving templating. And don't really need to go into the details, but it's a productivity tool. It takes you two hours of doing one task and condense it into five minutes, which is significant because that's two more hours you can either spend with your kids. If you're a teacher or you can teach to more kids and make like 50 bucks more a day, which is significant because most of those teachers, and that's what I kind of trying to hint at with. We cared about this. Most of these teachers were doing this as their second or third job. Like this was a group of people that was had a full-time job, being a teacher. And then in the morning before they would go to school to teach, they would wake up at like three in the morning and teach for two hours online to make, I don't know, a hundred bucks a day, so they could make ends meet. That was the kind of community that these teachers were in. And that was the kind of financial situation that they were all experiencing. So building something for them that solved this problem and allowed them to actually have more time with their family and their loved ones. That was the mission of feedback Panda. And that was why it was so well adopted by our customers because they understood that it wasn't just a company that was trying to make money off their problem. Like we actually needed this for ourselves because the first person to actually suffer this was then yell. Like she had to at least two hours every day. But the second person was I, cause I didn't have my partner. Like there, she was sitting there after 10 hours of teaching typing away for two hours. What's, what's the point of that. So we solved the problem. We essentially scratched on it. And we knew since, and I explained this earlier, this was such a specific niche community. We knew exactly that there was at that point, like 7,000 other people who had the exact same problem. And if you know that everybody's doing the same job and they all have the same problem, well, then you can relate to them and you can give them this product as a solution for the problem, which we did the first and kind of only marketing we only ever really did was comment on a Facebook post in a Facebook group where all these teachers would hang out that was still kind of water cooler. And then y'all posted as a response to somebody asking what, um, how do you deal with feedback? She said, well, I use feedback. I also made fitter Panda, but I use it right. And then people would try it out. We had like 80 sign-ups on the first day. And we had a, a conversion rate of like 30 something, 40%. Cause it was just such a specifically tailored solution to this extremely common and equally felt problem in this community. And then we're the mouth was our marketing strategy. Essentially. Like we put every single effort piece of a kind of effort that we had into facilitating where the foster communication building a newsletter where we wouldn't only hide out a product, but we would also highlight one of the users of our product. We would often just take a random user from a database, send them an email and say, Hey, you're cool. What's your story? Tell us about like how you came into online teaching, send us a picture of you with your family and why are you doing this? Just answer a couple of questions. And we put this front and center into any every newsletter episode that we send out there because it was more important to highlight people in the community than to push our product in there. Because if you have something that elevates the whole community, people will look at your product anyway, and really cared about actually building community. I mean also cared about building a product. Let's be honest here and making money, but we knew that this teacher community was so tribal. It was such a tight knit group of that by facilitating building community. We knew we would never run out of customers. And we did, like, we had a constant influx of people without having to do any kind of paid advertising without having to do any like school outreach. People did that for us. They refer to our product before we even had a referral system in place because it was just such a yeah. Right. And then we, we actually increased our prices one year after we relaunched a product and to make the deal a bit sweeter. When you put in a referral system where people could kind of recoup the additional amount of money they would pay, and that didn't make a difference. People still and already shared so much that the referral system didn't make much of a dent. It just kind of allowed us to do a customer driven onboarding customers, allowed other customers to learn how to use the product, that kind of stuff. But in the end, the whole marketing approach that we had was highly word of mouth tribal, community driven.
Speaker 2:You've touched on quite a few interesting points here. You've talked about basically you, a lot of people make the mistake of billing and product and trying to find a problem afterwards, what you did is you knew you had a problem and you build a suit and solution for yourself and your partner, which is a great way to start a business. And you knew that there were other people who have the same challenges. You also talked about getting traction. Is this something that you thought about, um, you know, did you have a business plan with a marketing strategy and say, we could do this. We could have Facebook ads or these, these things, or you, you just, you know, as you said, then y'all made the comment and, you got the initial traction. And we said, well, maybe we're onto something.
Speaker 3:It's the kind of overnight success that is 10 years in the making kind of story. You know, because I've been burned a couple of times in the past trying to build businesses and fail to validate that there was an audience fail to validate that it was a critical problem that we're solving failed to validate that the solution to a validated problem was actually a good one and then failed to validate that the product that we're building would actually implement that solution and the way that fits into the workflow of the people. There's so many potential points in the evolution of a product or a business where you really have to make sure that you're not doing absolutely everything wrong, just like figuring out like re removing uncertain degree. And we miss those marks a couple of times in the past. So I have this kind of learned understanding of where you need to make sure to stop for a second and take a look around and make sure you're not going into the completely wrong direction there. So that was a couple of learnings that I had from my own past experiences. And maybe, maybe as an aside, but important parts the two years before we started feedback, Canada would be 2015. Around that time I had a drop in Hamburg in Germany that is, um, two and a half hours by train from Berlin. And that was, uh, a half presence, half remote job. So I would spend days a week commuting from Berlin to Hamburg, which means you essentially sit in an ice, the German high-speed train for two and a half hours there and two and a half hours back. And since we're talking about Germany, the cell reception between cities is non-existent. So you can't even go like I'll go online or watch a video or anything like that. You kind of have to come in prepared. So I read a lot and I download a lot of podcasts on the subject, the indie hackers podcast, or of startups for the rest of us, just kind of indie specific founder podcasts. Honestly, if you ask me why I did that, no idea. I just found them interesting. There was some something in me that just yelled. I really need to learn more about this. And I was listening to all these shows, like from the beginning hundreds of episodes. Cause I had a lot of time, three, three times, five hours a week. It's like 15 hours a week filled with a lot of podcasts and read a lot of books. And in these two years, I just learned a lot about the potential pitfalls of those businesses, like other people's problems essentially, and where they had challenges. And it kind of internalized that to a certain degree, I read a couple books like built to sell by John Warrillow, right, building a business while you can remove yourself then, and it would still continue running it. This concerts were already in my mind that four hour workweek like automating as much as you can and the passing delegating to other people and the E-Myth by Michael Gerber would just not, you're not just a technician, you're also a manager. And you also visionary. If you have those frameworks, if you understand them, then decisions that you make, even if you've never built a business before you make them from a different perspective. So these two years were formative for me because I just got all this framework knowledge, and then I had to apply it. I still had to build it. Right. But at least I had this foundation of, okay, I've heard about this problem before. And I've seen where people take this from here. So I might aim into the same direction. So that, that was super helpful. And I think that's, that is what's important, was important for me because if I hadn't done this, we probably would have failed on the feature prioritization level. Like what do we build next? Or how do we communicate with people? Do we even communicate with our customers at all? Right. If I wouldn't have understood that people really have a lot of feedback cycles and their first couple of months, and that's important, that's essential to get the first couple of things, right. I probably wouldn't have integrated Intercom into the product. And then maybe if we would just never talk to her first couple of customers and never learned where they struggle and you know, all these little things, it really helped her understand how other people did it timely, both at that point, right? Where people that were under the same journey at the same point where they struggled, but also about people who have worked at that point a couple of years ago and where they, I know and what they struggle with now, it's just learning as much as you can. It's a good start. You still have to actually act on it. But if I hadn't learned all these things, I probably would have failed much more and lost much more money along the way. And maybe would've lost motivation along the way. So my is always to read and listen, before you start, of course you have to start, but there's a lot out there to learn from and about and not listening to other people's stories is kind of closing your eyes and ears to the reality of what business might be.
Speaker 2:What is very interesting is that you're an engineer, turned entrepreneur, turned writer in many tech startups. You, at one point you get to that tension between tech and business and you know, the bigger you get, sometimes the bigger that tension is you've talked about feature prioritization. What I've seen in my experience sometimes is that you end up at a certain point sometimes earlier than later, where the engineering team or the engineer in your case becomes a bit loose touch with the business or the customer. You know, I've talked to some, uh, startups a few weeks back where they were saying, well, I want to hire a product owner. So, so that the engineer can just code right from your experience, you know, with what'd you just said about feature privatization and how you went along to build a, the product. What's your advice? What are your learnings as an engineer? What's the best way for an engineer to be able to do deep work, which has to do to build the right code without losing touch with the end user.
Speaker 3:Yeah. There's just two extremes, right? There's the extreme where there's this absolute disconnect between the engineering team and the customer service team and the product team or whoever where it's extremely, just silo kind of thing, where they don't hear from other people they don't even hear from the other teams. If you don't tell them, I hate this has said that one extreme and the other extreme is where everybody does everything. And that is also bad, like equally bad, I guess, because that's what you say. Deep work is impossible. And I felt this with feedback Panda, when you're both responsible for telling people that you're fixing the thing and you're fixing the thing. At the same time, we had a couple of these situations where there was a problem with login with Facebook because they changed their API or something. And then people start yelling at us. And like you said, in the beginning, we never hired and it's not necessarily a good thing, but it was just two people. And we automated everything as much as we could. So we didn't have to deal with our Indian, like 5,000 customers constantly talking to us, but some would, and then one of us would have to talk to them, right? If they didn't find an answer to their problem, with the knowledge base, we would need to talk to them. And the moment you talk to somebody, no matter what it is, you pulled out of any kind of meaningful state for engineering. It should. It's just like, that's how I work. At least I have to focus. I have to tunnel vision, find the bug, fix it and hit it and then deploy and test, you know, all these things. And if you cannot do this, because there's this Intercom bubble in the, on both the side of your browser and in your mind what people are telling you, it doesn't work. It doesn't work. Yeah. I know. I'm, you know, I'm working over here and if you don't have anybody to do this for you, then you can really fix the problem. And you can not tell people I'm going to fix it because by telling them you're gonna fix it, you can't fix it because it's just a conflict of operational capacity. So what I found, um, what we did even without having anybody that would do this for us finding this kind of first level of automation where people's conversations wouldn't immediately come through, but people would try to talk to, I don't know, like a, a chat bot or an automated system that would try to figure out what the actual problem is. And you could come and Deere the system Intercom has these kinds of bots, uh, response, automated response things where if they have a trigger keyword, you can send them a message and it doesn't go through to the agent. So if people say it's down, you'd take this as a little message. And you say, Oh, I know it's down, I'm working on it. I'll tell you once it's back. And you just protect yourself from this initial onslaught of information. So I think like I'm saying two extremes, extreme silo, extreme everything. At the same time, you have to find some spot in between where the initial load of customer interaction is kind of this. Yeah. If somebody needs to take all of this, the brunt of these things and respond to them with either you've taken care of this, or here is how you can solve it. If this, if it's an easy thing to solve and only the specifically complicated things should ever reach the engineering team. So that's what I wouldn't have loved to have with a person that we tried to automate it. And once we sold the business, they immediately hired a customer service person to take this load off the engineer that we also hired because essentially, if you are a solopreneur or in a really small team, then you're everything at the same time. And you could only, timebox so much because the reality of customer service interactions is that they're random. So you have to figure out a way to protect yourself in this deep work state from these initial things. And if you can hire somebody part-time, who does like four hours of customer servers, where you know that in those four hours, everything goes to them. If that is what you need, right? If you need four hours of focus, time every day and do that, that's small steps. And that's what I forgot to do. What we built a business as that you can actually hire people part time. I thought, Hey, if we hire a customer service person, then that'd be enough work for a full-time customer service person. And the same with engineering, I always had to do a little things, but it was never really worth a full-time position. And my mistake was to think, not going to hire an engineer until there's worked for two, which is this because as a, as a founder, you do anything anyway, right? You, you throw like 10 hours, 12 hours, 14 hours a day at a problem because you're the only one who could solve it. And it doesn't feel like this should be done by two people. So be realistic about what time you need deep work time you need and find somebody or something, AI, whatever you have to take, you have to protect you to shield you from this four bit. Like most things can wait. And that's probably also, it's also important to understand that even if a customer is reaching out to you doesn't necessarily mean that you need to immediately look at it, right? You might, and having somebody prefilled of this for you is as important or a useful thing, but most things can actually wait. So it's also a mindset thing.
Speaker 2:I want to go back a bit later to hiring, but just before that, in, in, in the hacker podcast interview, I believe it was last year. You mentioned that what is key to build a bootstrap and syllable companies to make you the founder, let's say the least important person, at least that you can remove yourself from the business. And you said you've accomplished at, with feedback panel that by setting up automations and optimizations, which you touched on a bit earlier, if we dig deeper, what kind of automations optimizations that you put in place to, to actually reach that goal?
Speaker 3:Yeah. So I'm, I'm not trying to do any advertising for Intercom here today. There's probably a lot of really good alternatives that work just as well, but one thing that they had, and I think this is now an extended in the industry. So I guess it's okay for me to talk about this in an Intercom, like product was an integration between the chat product and the knowledge base product, right? Once you get your customer, like, I don't know how to edit a student, then their system would figure out, okay, that's an article called how to edit your student might as well suggest that. And then people would solve their own problem. And that's like the self-service kind of customer service, which if you just do people, you need that, right. You can have synchronous communication where you chat with people or asynchronous where you email back and forth. That's fine, but you need self-serve at a certain scale. It's just not possible to build a bootstrap solo or small team funded business with people who consistently ask you questions that you always respond to in the same way in the end feedback, Panda itself was a templating tool, right? So why would I not take this? I write it once and use it multiple times approach in our customer service. So that's what we did. Whenever somebody asks us a question that we didn't have a written response to, we would answer the question in the chat, guide them through the thing, and then immediately write an article on this particular issue and put it into knowledge base. So when somebody else would ask the same question, it would be automatically responded to as an option. They would click on it. It would have screenshots, maybe a little video of the walkthrough that I did and or Danielle did, and then their problem with most cases. And in most cases be solved automatically forever, immediately, right? It's like, that is saving you a lot of time in the future. And we did this every time, something new came up, which meant that after a couple of months, our knowledge base had like 192 articles just to, how do I edit the student? How do I delete the student? How do I edit the template? How do we create a new template? How do I import the template? All these things that people would consistently wonder about when they started an onboarding journey or at some later point when they were in a, like a weird situation, we would have an answer to. And that freed up our time, almost completely. I said earlier that we always had a couple of customer service conversations in today, but even with 5,000 customers, that it would not exceed 10 to 15 per day conversations, but that's, I can handle that. That's like one conversation an hour. There's still some space in between to do some work, right? And that is mostly due to this particular automation, taking the questions that people have turning it into an article with many kinds of media. Some people need video. Some people need screenshots. Some people need texts, all four, all three, because might just as well, it's an investment into your future and your future time that you save. So give it some time at that moment. And, um, they are, then people would usually solve their own problems. We also, I kind of talked about this earlier. I had this automated response mechanism to certain keywords, right? When people, there were certain problems that happen in customer service that need an immediate response, even though they don't need an immediate human interaction stuff. Like I can't log it. That's just something where if you don't help them right. Then at that point, Dave get mad, right? Because you lose them both as a customer and as a person who would actually talk well about your business in the community. And that's what we wanted, right? We didn't want people going out there yelling, feed their Panna. I can't login. They don't even respond to my comments or to my questions that is bad. That's bad PR to tribal community. It gets amplified. Anything in the tribal community gets amplified the good and the bad. So we made sure that for those people, we had an automated response that would capture most of the cases that would likely be the reason for this. We had login with Facebook login with Google and login with email. Usually people would try to log in with one of the three, but the actual account was another one, you know, and like they were actually signed up with Facebook, but tried to log in with Google minor problem. We eventually built like emerging tool where you could like put multiple accounts, login methods into one. But the initial response you give, it seems like you might be using the wrong login provider. Like I would try the other one and that would solve like 95% of the lock-in problems. Right. And that is something that if you respond to, can log in as a string, it's a column that solves all these immediately critical yet easily answer problems. So by finding those things and building the proper automations communication automations, we built a system that was very resilient because even when there was a problem with something, we could quickly put a message out there that would be automated as a reply. And then we could deal with fixing this as the two people that we were, or at me as the one engineer in the company, it also led to some stress levels. And we can also talk about anxiety, burnout, and stress, because if you're just two people and you're responsible for 5,000 and the business that you have, as well as it's doing, it's your only real asset, quite stressful. So in that situation, I should have hired more. We can talk about that later. So that is the automation part on the customer service side. And then on the engineering side, any kind of deployment, any kind of building the Docker containers in which our software ran. And we had a Coobernetti's system onto Google cloud where it's a self-healing kind of system. Anything that I could automate a way I would, we used a database as a service provider. So we didn't run our own database. We used IBM has acquired a think. They were usually initially called Mongo HQ, but now called compose. It's a service that just office you a Postgres database or Mongo DB database with like full depth of support on there. And so it always runs. And if it breaks, then they fix it quickly. That was at some point before we sold it, or when we sold that, that was the biggest thing that we paid for. I think we at India ended up paying three of those$4,000 for that monthly, which is hefty, but it's almost the same as actually hiring somebody that would do it in house with the exception that that person only works eight hours a day. But the people that composed were 24, right? And there's a whole army of engineers who could jump at a problem. So anything that was not my expertise and I'm a software engineer that works well with backend and front end stuff, but I'm not that good with administrative or like dev ops kind of activities. We would outsource in a sense that we would have an automated system or a company that would deal with that specifically deal with that for us. And those were things that they really made a big difference.
Speaker 2:And this is the last point is very interesting because you know, when you have engineers, you, well, you can ask them, could we do this? Could we build this? And the answer is usually, well, technically everything's possible, right? And depending on the team, depending on, on yourself, the individual you saw, you know, you will jump on it and, you know, start building are, you will like you decide to outsource, is this a question of personality where you said, well, I don't want to get into this too complicated. Or you made a conscious decision when you prioritize, what is it? What's my core. Let's say product. What's my core value proposition and where I, my core competency let's call it that way. And what is it that, you know, I should outsource,
Speaker 3:It's almost like the feature prioritization thing we talked about earlier, just on a, on a higher obstruction, right? It's like what parts of the system that I'm building and the system here is not just the software, but business, right? It's the infrastructure of the business. What parts of, of that am I comfortable with what parts of that are critical? And th the thing is many people consider critical things to be the things that need to be in house. I do not necessarily agree with that. Like if you, if you have your own servers and you maintain your own service, because only you can be responsible for these things, that is an argument that I sometimes hear. And I don't agree with. I would rather trust a platform like AWS or the Google cloud or Heroku for that matter, which am I in my new SAS that I'm currently buildings running on. I would trust them with that because as much as there's platform risk there, at least I know that's their business is to keep my business running my business. The purpose of my business is to serve my customers. It's not to maintain an infrastructure product, right? Servers. Aren't a necessity. They're not the core function of my business. I need servers to be able to build a SAS, but I don't want to maintain them. So that would be like the measuring stick to which I would put any kind of service. And the same thing goes for authentication and for payment and for invoice stuff, right? These little things that are so hilariously complicated and boring, gotta say invoices, most boring subject on earth. That I would always try to find somebody who reliably can solve this for me and integrate them, even at the risk that their business might explode, or they may have downtime at some point. And we had that. We use off zero, the service for, for logins and authentication. And they had an issue at one point. And for one hour, you couldn't log in using the login with Facebook little buckets. And it sucked. We had to own that. We had to tell our customers story for that. So are you kind of looking at right now, it's a problem with one of the services that we use, but we take full responsibility because as much as it's their fault, we use them, we chose them, right? So we kind of had to own that, but that was one hour in two years, if I had built my own little login with Facebook's a software kind of thing that would probably have been more times in two years, and then I wouldn't have anybody working on fixing that I would have to do that. And we had this, like, I would have to tell people and fixing it and then fix it. And it's complicated. Like anything involving other services out there, it's a risk. Nothing is up a hundred percent. So there's always these little error modes in between. And for payments, we use Stripe because we knew they would deal with payments. They would deal with credit cards. Non-working they would deal with fraud detection. I don't want to do that. Right. Like why would I ever build a payment system myself? I it's nice to have people's credit card information, but is it really like, are you GDPR compliant? Are you PCI compliant? Like all these little things, the moment you outsource that to companies who are you're rid of that responsibility too. And honestly talking from a legal perspective, if you can say that your business is GDPR compliant, it's PCI, it's HIPAA compliant. If you do medical stuff or, you know, all these little kind of a compliance things, if you can say we are compliant because the vendors that we use, they have to be compliant and they are, and here are the certificates. That's just less of a threat, right? Nobody will attack your business. If they know that your data is secured with a big compliance, secure provider. But if they know that you have a database somewhere with this usernames and passwords and credit cards, you become a target. And what I wanted to be a founder didn't want to be a target. So I took all these things and let other people solve them. For me, the only things that we had in house was our call it intellectual property, right? The secrets to how we did this templating and how we built our little template sharing system. And we had a machine learning system in the background for template, pronoun translation to complicate it. But we had some stuff that we needed in house, but all these other things that are not business critical, we outsource as much as we go,
Speaker 2:Pretty smart approach to focus on the core things. And let's talk about hiring you. You talked about the fact that maybe it was a mistake for you not hiring earlier. Can you tell us a bit why? Uh, I mean, you kind of mentioned there was not enough work for one person, but was there any other reasons why you did not hire
Speaker 3:I've I've actually had this conversation on Twitter a couple of days ago. And I remember what I said, so I'm just going to quad myself here. I, as an engineer, I was trained my whole life to be hired. Really like I'm a technical specialist. I can solve problems. I'm hired to build solutions and I'm trained to build solutions. So everything I see is a potential solution, which is the other problem, which is why most technical founders don't start with an audience and their problem and their solution, but they start with the idea and then they try to backpedal, is this solving a problem for whom maybe it's that maybe, you know, like that whole problem. Um, but that's the other side. The hiring part is I was never trained to do anything meaningful in terms of leadership and the team, because people just really took me, put me in the seat and said, here's a screen. Here's a keyboard solve this problem for me, which is probably also my fault, because I didn't grow beyond that maybe, but I was never trained to hire. I was always just trained to be hired. And I think many engineers, many people from a technical background, but maybe also from like a marketing or from a design background, they have the same problem. Right? They don't go through this managerial approach. And that's what I, what I said earlier with Michael, Gerber's the, E-Myth the book, right. That talks about this. And I read it and I still messed it up. Right. It's this kind of situation where I didn't understand, even though I wasn't teams before that, I could have the two, it's just like everything you do. When you found a business for the first time you build a business for the first time, everything was new. Like talking to customers is new because all of a sudden, it's not just you as an engineer doing your job. It's you trying to build something that has never existed before, right? A whole business, a whole entity, a whole thing. And they're feeling overwhelmed, becomes a normal thing in that, in a business like that and learning to do new things. Every single day is also normal financials, reporting taxes, never done this before. And all of a sudden you have to report huge sums of money. At least we did that in the end to an agency that is very specific and, you know, Germany and tax agencies, they're really like looking into stuff. And now you need to do this, right. Even though you've never done this before, nobody told you how to do it. The people out there who could tell you how to do are super expensive. It's just every day is a new challenge. And in that situation, hiring just didn't feel that important to me because there was all these other things around that I needed to deal with. And I could, that was the worst part. I could actually deal with these things. You know, like if there was an engineering problem, maybe I couldn't solve it today, but I would solve it tomorrow. And if there was a business problem or an infrastructure problem, I would kind of figure out a way. And there was never really a hard ceiling that I hit. I could always stretch myself further and increase my anxiety levels and my mental health destabilization levels. But I could always go further and I didn't have anybody tell me, why don't you just hire somebody? I mean, Danielle told me that and she was the CEO of the business and she saw that, but she couldn't really convince me that it was me, that I was standing in my own way. I felt like, Oh no, no, I can, I can deal with this. I can, I can do it. Let's just try to do it this way. And she's said, sure, you are the tech I, you, you know, best. Right. I thought I did, but I didn't shut up, listen to her much, much earlier and hired. So it is my personal, I wouldn't call it incompetence, but not being able to recognize when I'm stretched too far. That was because you have this community of founders that is super helpful and super nice, but there's still a lot of glorification of hustling at all times, right? Everybody hustles and hustling is nice, doing stuff. Getting places is great. It will actually improve your life, but you can do too much, right. Can go too far. You can neglect yourself, your family, your loved ones, your mental health. And that part was something I was not aware of. And honestly, the reason that I started writing once we sold the business was because I was on the verge of a mental breakdown. Like there was a, there was one thing that I wrote during all the feedback, Canada. That was the only thing that I had time to write because, you know, 24 seven dealing with customers engineering and doing marketing as much as it was like writing and all these things, I didn't have time for myself. But at some point I was so broken by this whole stressful situation that I just had to write a blog post on how I dealing with my mental health problems while there was still running the business. I never released that. But in writing that post, it was clear to me that I needed the valve for this, like to just let it out. So that triggered a list of blog posts that I was gonna write the most we sold. I made lists, you know, we as engineers, we, we plan and we have tutors and stuff. So I made this gigantic list of blockers that I wanted to write in the future. And I think the first, like 25 of them were all about emotional, did the emotional journey of which shopping to rollercoaster of that and how I would deal with imposter syndrome, how I would deal with being overcome with grief, for selling the product and you know, all these little things they were so present on my mind. And that is something that we don't really talk about much in the community because we talk about success. We talk about MRR, great. We talk about sales exits and failure, but we don't really talk about this constant droning of stress in the actual real evolution of a business. And that's where I started. I've gone more into the actual pragmatic parts of building a business. Well then into complaining about like mental problems. But I still sometimes touch up on that. And I feel it's the thing that we don't talk enough about. And that's, that's why I'm bringing it up right here. Because every founder that I talked to eventually comes to a point where it gets like slightly too much and that's already too far. I think they should already consider their life, their, the lifestyle and how they run their business before. And I think that's where, like I said, automation and well-documented system is a system that other people can run for you, which is the whole point of the bill to sell approach. Right? A sellable business is a business that runs without you, cause then you could sell it and it was still run for the other person. It's a whole, it's the whole point of the book in a sentence, right? Build a business where you can take yourself out and put somebody else in. And it's still doing this, the exact same amount of money. Maybe even more, then you have a good and sellable business. And if you look at every business decision that you make, from that perspective, how can I remove myself more from this business without it becoming worse? Then I think you have a pretty clear North star on, on how to stay sane while doing it, because you can work yourself to death, like literally with this, right? You can become so weak that you're having a heart attack, or I guess now you become more susceptive to the virus or whatever's out there. That's going to get you, you, you just really need to stay healthy and mentally capable to deal with the business. And the easiest way of doing this, in my opinion, I hate there's other people who think differently is by removing yourself from the operational part of the business, going more into the ownership role and into the leadership role. And having people take over, which is what hiring is, which makes this hilariously ironic that I'm telling you that. And I, during the, running the business up to the very end, consider this to be the wrong approach. Only once we sold, did we actually start hiring? Right? Once when Surescripts took over, we were responsible for finding our replacement and all of the placements were essentially for me, it was an engineer and a customer service person. And for Danielle, it was a business owner product on our product manager kind of situation. So we hired each of us hired like two people, four to replace themselves. And once I did that with the, um, the chief of, or the VP of engineering Schwartzberg, we did that together because he wanted to make sure that people fit into his business. I needed to make sure that they fit into feedback. Once we did that, it was such an enjoyable experience. It's like, I thought, Oh, it's going to be super complicated. And I don't know how to talk to people. And then we just had a talk like we're having now. And we talked about tech and we talked about like elixir and Phoenix, like the language of framework that I use for feedback, Brenda and Vue JS and all this technology and like startups and bootstrapping, it was such a nice experience. And I kind of, because face palmed extensively at that point, because it's like, why didn't I do this sooner? This is so enjoyable. This is so nice. And these people, they actually are driven. They want to help the same people. They want to help teachers. They want to help them make more money and have more time with their family. Why didn't they see this? So I guess finding somebody who can tell you, mentor you into this would be important. In retrospect, that's what I would have loved to have like a mentor who could tell me, okay, now I hear somebody, right? Why? Well, because of this, that would have been great. But if you don't have that, just consider how your time is valuable and somebody else's time might be better spent on this because they might actually enjoy it even more than you do customer service. I liked it. Never loved it. Some people love customer service. Honestly, they, even if they get yelled at by people, they just love it. They just need to help. Why not hire them? They might be much better than you are. Right? So it's like all about putting yourself into a perspective where you're not the most important thing, like where your ego is not bound to the company. The company is something you, as an owner have one role, do you, as a leader of the business, have another role and you as a technician have a third role and that's kind of hard cause it's kind of schizophrenia because you make, as an owner for a business might be diametrically opposed to the technology decisions that you make, or even the CEO level decisions that you make. But you have to make sure that you're not just one of these and the other two come crashing down upon you at some point, because you can work them.
Speaker 2:I think also, you know, you talked about the glorification of hustling. I totally agree with that. And I think sometime hustling becomes a synonym of lack of structure and lack of productivity, right? It's, it's kind of, instead of slowing down to go faster, you just do whatever comes to mind, but you're too much in the weeds. Another thing that also happens when you hire is that it takes time, right? It's not like you hire somebody and that person is up to speed and everything's fine, you know, in a week or two. So it's, I think sometimes also founders think about, Oh my God, you know, hiring is another thing on the top of your, to do list. And it requires effort and coaching.
Speaker 3:Funny enough, if I may interject here, sorry about that. But the hour tech replacement for me, it literally took them a week to get up to speed. But guys I've been documenting extensively knowing that at some point that's the almost contradictory nature of this. I didn't want to hire, but it built a solid piece of software that was manageable by a team because that's how I was trained to build software, right codes, nice
Speaker 4:Commit messages in the repository and comments into code, wherever something might be unclear. So the whole code base was well-documented. And now even that 11 hour video walkthrough to the code base where I just really scrolled through the code base and explained every single piece of code for my replacement, like took me a day. But once that was there, they could literally listen to this for a whole day or two. And then they would know exactly everything about the code base and how the software is working. Right? So by having good documentation, that's like the flip side of good automation is good documentation. Because if you have SLPs that are essentially documentation in an actionable format, you can hand those over and somebody else can look at them and say, okay, if somebody asked this question, I respond with that. And then I do these things. It clearly laid out, right? There's no guesswork there. And if you have documentation in your code and engineer, it goes in there and say, Oh, okay. Yeah, that's the problem. And then they go to the point of reference and the things are named while they understand it well. Or they might check out the video where I explain exactly how this is supposed to work and then that's fine. And that's why it actually didn't take our replacements that long cause we had it all. And that's the funny part. I could literally have hired somebody who within a week could have done my job. And I didn't of course what you're saying. There are certain situations where somebody takes longer, I would guess with a product manager or with somebody who really needs deep insight, not just into the product, but also into the audience, into the customer base, into the market itself that they may not be part of. That can be a teaching kind of period, where you have to divide your attention between dealing with the business. Maybe even dealing with business, adjacent things like a sale and dealing with teaching this person at the same time. So that's a lot on the plate and that's also one of the reasons why I didn't do it because they feared that it would take that long. Had I known that it was just going to be a week and then they would be super autonomous would have done it much harder.
Speaker 2:So you recorded basically when you talk about the condensation, you didn't build like 20 pages or 20 page PDFs, right? You, you recorded, right.
Speaker 4:I actually recorded the video. We had a lot of different shapes of documentation. We had SOP for customer service interaction and for things like deployment and release stuff, like we had a, we had a browser extension and a desktop application that people would install and use with their teaching portal for integration reasons. And those needed to be, it was quite complicated to deploy a browser extension, to deploy a piece of installable software, not that easy, but we had step by step. So I put like little Google doc or something with step by step screenshots and stuff. So that was there. Then there were the SOP is, which will also 50 page Google doc with like, if a person can log into their account and they tried everything, here's how to restore it, go to the admin dashboard, click here and enter the name. And, you know, these kinds of things that was all in the document kind of shape shareable document and like Google doc kind of situation. And then we had like mission statement, company vision, and the history of the company, how we made certain decisions, like why we chose Stripe over charge B or why we chose Google over AWS. You can probably tell I'm German. I do like documentation. And I do like to write things down, but that helped a lot because those documents, once we handed them over during, um, even just a couple of those documents, we could hand over during the initial conversations with trust, with Capitol that made the deal so much sweeter for them because they knew, okay, there's more of this that we can already take this, give this to an engineer and they don't need to talk to the founders at all. It's all here. Awesome. So there was a win-win situation that's just called call it that, and that makes the company extremely sellable. The automation is great, but people who buy a company, they might have the funds to hire a couple people. So you don't necessarily need all of that automation at all times when you sell, but having documentation that is extensive and thorough. No, no, that is important because that's usually where the dip happens. Right? You sell your business and the business is doing well and then they have to climatize and then it just dips for a bit before they find their way and deal with the business, the way it should be done, but we didn't have a dip or you just went straight up from when we sold because we had everything in place. And that makes it very interesting for an acquirer.
Speaker 2:Yeah. And just also for the people listening to us, it's something that you've built that, that documentation over time, right? Yeah. So, so yeah,
Speaker 4:Document it just like when people ask me to do something or ask me why something would work and I would tell them how to do it. When I would implement a new mechanism to deploy my Docker containers to communities, I would take the comment command I use in the terminal. Copy it, put it into the document where the SOP was and modify the, the steps we have before. Just keep it current. Because I knew that if I do this, like let's say we deploy something like an auxiliary service. You deploy it once every couple months, you forget, you literally forget how you logged into your server. And I know that if something breaks, you need to be there quickly. And if you have to figure out how you did something six years or six months ago, well, this is going to take time. So whenever you do something that you only do once I just take the command, I used put it into a document and I put what I did there to hopefully in the future, know exactly how to get back there and how to quickly do it. So I trained myself to document new things as I was doing them to have reliable thing that it could execute later. Right. But I could just go step by step by step and have a reliable result. Not just me, but everybody who would do it.
Speaker 2:I want to take too much of your time. But there's something else I want to talk about is, you know, we we've talked about hustling being glorified these days, but there are other things that are being glorified. We live in a world where startups who are successfully raising a new round of funding, celebrated a bit like a pop stars or noble noble prize winners. You wrote that. Uh, and I quote, bootstrapping is a desirable value and wealth generating way of running a company and still many people shy away from it. That's a bit contrarian to what we're saying at the moment in the startup scene around the world. Can you tell us a bit about that? Elaborate.
Speaker 4:Yeah. W well, first, the first thing to understand is that all kinds of funding are fine. Let's just want to like lay out the foundation here. If you need VC capital, if you have an idea that only works, if you capture the whole market and you know, the built the biggest thing, perfect. Go for VC, go for funding like that perfectly fine, but you don't need that amount of money to build a sustainable business. And often enough, the unicorns they're not sustainable. And if you, if you look at a recent IPO's and the businesses that didn't make it there, they just really grew and grew and grew and imploded, right. Or almost imploded, and then still IPO for some reason. So no judgment there, but there's this whole thing where the hockey stick is glorified, but the sustainable linear curve is not right. And the hockey stick only works because there's more money being thrown into the system to just amplify growth and just hypergrowth to, to, to fuel that, to what ends, I don't know. But the thing is only a couple of those companies can succeed. That's the whole point of venture capital. That's baked into the mathematics, right? One out of 10 might succeed. One out of a hundred will succeed. If you are one of those 99 or nine or whatever in between, well then you're out of luck. Then you just failed and you have to do something else. I believe that if we look at sustainable businesses, like what feedback Panda was, but like what many other bootstrapped businesses are, all of them succeed? Right? Of course not everybody who starts a bootstrap business succeeds at building a business. But if you build a business that creates a sustainable stream of revenue and grow sustainably, that is success too. It doesn't have to explode. It doesn't have to become like 10 X year over year. That is not what success means to me. Success means like you make 10,000 bucks a month, which is SAS or your info product, or your course or whatever. And you can feed yourself, feed your family, you pay the mortgage, pay the car loan and your life is there. That is the lifestyle you can live. Like it's literally the lifestyle business approach, right? Which many people have, because it sounds like it's like Instagram kind of self promoting lifestyle, but it's really not. It's more about building something that can sustain your life, that you have full control over and does no dilution. Right? If you are in a business, you own your business. And I mean, there are now options for funding that are actually aligned with goals for bootstrappers and furnace is one of those, right? The thing that Tyler drinkers, who also sold his business to show Swift capital, by the way, just made it happen. It's a funding source and I'm an investor there. So just, just so you know, that is aligned with the bootstrappers. Is it like a revenue based financing? Its revenue base agreement is the thing I think they call it. And the idea is that if all of these businesses get funding and grow and they slowly, slowly grow that in the end, we'll all benefit, right? Because if you, if you have 10 businesses in a batch and 10 businesses succeed, even if they don't explode, they don't need to because they all grow and they all produce profits for themselves and for the investors and for essentially the families that are surrounded or that surrounded the founders and for the local businesses around them. I think it's an interesting and equally valid way of approaching business, right? You don't have to want to become the next Microsoft or Google. You can just be the next, I don't know, even base camp is a great example, right? If that is the North star, as a calm business is slow growing, but profitable business with like one 50 people or something. And they are the stars in the community because they've understood that you can build a business without burning out and you can build a business without like doing shady marketing tricks without like tricking people into buying your product. You can just be honest with your customers. And that is perfectly fine too. So that's, that's why I advocate bootstrapping again, you don't have to bootstrap your business, but it's just as well, an option as VC funding or getting loans or whatever they is out there. It does many different, different ways of funding a business, but bootstrapping is fine. And of course there are prerequisites to that, right? Either you find something like earnest capital, a tiny seed accelerators that go for bootstrap businesses and help them a little bit and have a mentoring network around them where people can learn something from people who've done this before, or you have some, you put your personal money in there, which is risky, but it's also an option in suck self-funded business. But in the end, what you want to accomplish is being a customer funded business. And it's funny that this is a novel term, that it's such a good term though. Any business should be customer funded, but some are not. And that's, that's where we see comes in, right? They are not necessarily customer funded. They are investor funded, hoping that through valuation explosion, the investors cash out at some point. And then the business is stable enough to sustain itself. But for bootstrap businesses, it's the other way around. You will have complete ownership over the destiny of your business. You grow it at any speed you want and you stay in your niche. That's also a thing we haven't really talked about this. I alluded to it with feedback Panda because the niche that we serve is so specific. But if that is Denise that we served and we could build a six-figure business, right? We made like the end$600,000 a year in ARR with that, with that business. Well then go the next niche and build that for them, build whatever they need the most for them. And we, uh, our customer really was online English as a second language teacher from North America, teaching to Chinese children over the internet or web browser. It's like seven filters over the global audience, seven nested niches in one, just go to the next one, online biology or an unmanned music teachers, teaching kids from all over the world, how to play music, build something for them, or go back on just online teachers. And that you can really find a niche anywhere. And in those niches is a lot of potential. Some are already full, some are completely unexplored. There's still some kind of work you have to do to find your audience. And that's funny enough, the next book that I'm writing.
Speaker 2:Yeah. Sorry. You're stealing my questions. You still think that, I mean, that was perfect. Perfect segue. Keep going. So your next, your next book is audience first, right? That's right.
Speaker 4:Because I'm in writing secrets of soul. I figured out like you start with an audience to detect a critical problem. You find your solution that fits into the workflow. Then you build a product that works in the medium that they're used to. That's like the condensed version of the first 250 pages that the audience is the most important part. And audience here is not just like Twitter audience or like people who listen to you or something. It's really the group of people. You want to empower some call it market some call it potential prospective customers or a total addressable market. You know, all these phrases. But to me, it's the audience. Because at some point they will be listening to you or at least they shouldn't be listening to you at some point, right? So that's what it is to me. And finding that, finding the people you want to serve, the people you want to help the people you want to lift up. That's the critical moment in your entrepreneurial journey. Because we found that in an online English teachers, because we knew how desperate they were for help. Like here was this group of people tap thousands of teachers and they had to use Excel sheets and word documents to just being able to cope with this. And whenever somebody has to use Excel, I want to help them because
Speaker 2:They shouldn't have to, you know, and, and
Speaker 4:Moments, we just knew this group of people is in dire need. They exist. This group of people is there that it's like this group of 7,000 people in this one Facebook group already, that all are doing the same job. They are validated out there and they are hungry for a solution to what? Well, here's the critical problem. We found it because we experienced it ourselves. And being able to find this problem requires you to know who you're serving. Right? If you go audience problem, solution product, you cannot build a product without knowing which solution you're doing. You don't know what solution your building without knowing which problem is solving. And you not know, you can't know how, which problem is solving without knowing who you're solving it for. So that's where you start. And that's what I'm currently working on to give like a more structured approach to finding the audience that works best for you, which is, could be anything. It could be somebody, some kind of group of people that you're already part of, but also some group of people that you don't even know. You're part of just yet, you know, like there's a lot in the reflection and actually going out there and embedding yourself in communities to see if that is the community that you want to empower and help. But that's what I'm working on right now. And that's what I feel is the most important part in the whole entrepreneurial journey. One that's often skipped because like we said earlier, most technical founders are solution driven. So they see problems out there. So they immediately jumped on product. I'm going to build 10 to four cats. I'm going to build like Facebook for plumbers, you know, like product vision. And then they have the idea. And then they try to backpedal into the audience, which is often hard because Tinder for cats, like, you know, it's a stupid idea because it's supposed to, but I mean, deliver a delivery service for cats. That might be a good one. Or is it not that you, you don't know because you don't solve a critical problem. You solve a problem maybe, but you don't know if it's critical enough. So audience first is in progress. When should we expect that to be available for the public? Just to put a bit of pressure. The fun part about audience first is that it itself an audience first product. So I've started collecting, I guess, an email list of people who are my alpha draft readers. So I want to put a book out there that I'm actually building with the audience that I'm writing it for. So right now I have like a couple hundred people on that email list and the draft is it's getting somewhere, but I would say I'm probably not going to finish it this year. So somewhere around January, February is going to be the time when the first draft is going out. And then I'm going to do a lot of feedback cycles with this audience to make sure that this book actually solves the problem, because that would be a stupid mistake to make, to write a book without actually involving the people. You know, it's just a meetup project. It's an audience first book about audience first and yeah, at some point next year, it's going to be out. I've been very heavily inspired by Rob Fitzpatrick. The guy who wrote the book, the mom test, which is one of the most important books for anybody who reads, who does customer exploration, just calls with customers for validation or verification reasons. He wrote a new book, write useful books is the title. It just released it a week or two ago. And it's his experience in writing really, really good non-fiction books is now co has no cost him to write a book about how to write good non-fiction books. And that has been super helpful. He's been extremely actively engaging in customer feedback cycles and I'm approaching it his way at this point as well. So if you're writing a book, anybody out there check out Ron, Fitzpatrick's latest. It's really, really useful because he explains how his mom test book came to be and how he finessed it into what it eventually turned out to be. And the other book that he wrote in between about workshops as well, it's really been insightful. So I'm trying to make this a public thing and building and public, not just a SAS, which I'm also building, I'm building a SAS for, for authors called permanent for people who have like links to their books. And they don't want them to start failing when the original websites go down. So I'm building a solution to help people have control over the links in their books, which is important because I'm solving my own problem here. I have a book with links. I need to put links to the book that I have control over. So I'm build a SAS to solve this problem. That's the kind of the entrepreneurial journey. You find something, you do something, you find something in there that doesn't work. Then once you're done doing the thing, you know, fix the little thing in there. And it becomes a new thing with a little problem in there. And it's just like this, this Russian doll situation where it just layers upon layers of little problem solving exercises. But yeah, that's what I'm working on right now. I'm super excited because it's awesome to work with the bootstrapping community on this because people have asked me to put certain things in the book. Cause I asked them to tell me what they want to read about things I would never thought of and things that are extremely challenging to deal with. So it's awesome for me to be able to do the research and put that into one cohesive unit. Right. That's great. Well, we're really looking forward to be able to read this. Where is the best place for our audience to follow you? Harvard easiest thing is Twitter because I'm on Twitter at 12 hours a day. Apparently you can find me on Twitter at a R V I D K H L. And yeah, I guess the bootstrap founder is my block and I have a podcast there and links to the book and everything. So the boots are founded.com that those two places. Perfect. Well, thank you so much for your time. You're just really passionate and generous with your time. I think we could have gone like this for another hour or two, but thanks for joining us on the show and hopefully we'll be able to meet face to face when the world will comes back to normal. Absolute pleasure. It was really nice. And I do hope that, I mean, that's, the whole pandemic has been really tough on everybody and it would be really nice to be able to connect physically in the same location with founders again. So I'll take you up on that when well, vaccinated and happy. Perfect.
Speaker 2:You so much. Thanks again for listening. I hope you enjoy the show. Make sure you subscribe to the podcast. And as usual you can find the show notes@stunning.com. Also, if you want to accelerate your startup growth and build something meaningful. Well, check out our growth lead for tech startups online course@growthdotstunning.com. Thanks a lot.