Subscribe
Share
Share
Embed
Rob Walling, co-founder of the TinySeed accelerator for bootstrapped SaaS companies, joins me to discuss what investors and potential acquirers look for in the technology they're investing in.
Solving big problems with small teams
Introduction: Ladies and gentlemen, The Tiny DevOps Guy.
[music]
Jonathan Hall: Hello, everybody. Welcome to another episode of Tiny DevOps where we talk about Dev and Ops and all related topics for small companies. I'm your host, Jonathan Hall and today I'm really excited to have special guest Rob Walling who has been doing this work far longer than I have. He is the host of a popular podcast, probably the first podcast I ever listened to, actually, Startups For the Rest of Us. He's also a founder or maybe co-founder of, I'll let you describe it, but TinySeed. He runs a conference for small mostly SaaS-type companies, but I won't say too much. Rob, why don't you tell us your background and fill in the gaps that I left there.
Rob Walling: For sure. Thanks for having me on the show, man, I appreciate it. TinySeed you mentioned, is the first startup accelerator that caters to SaaS bootstrappers. Our terms are bootstrapper-friendly. We're the not venture capital. We still invest in companies, we write checks and we have a year-long remote mentorship program advise. All the stuff that you would would want, we do it in batches too, there's a community. We are about two and a half, three years in, we funded 60 companies and we have money to fund another, geez, 150 or something in the next three years.
It's picking up and that's fun. To me, this is what I've been doing for free and on the side for 15 years, and I finally get to do it for a living. Then you mentioned MicroConf, which started in 2011 and started as in-person events for software entrepreneurs. Now, I think we run 13 in-person events this year, and then we have an online community and a lot of resources, a YouTube channel and all that.
It's all around helping, usually technical. I'd say we have about 80% technical folks because I used to be a developer and my co-founder was a developer. That's where we started with developers, but now we have 20%, 30% who are not, and that's helping them build startups, whether they're small or larger, that's what I've been doing for a while now.
Jonathan: Cool. I think I was first introduced to you with your book. I read, I think, the eBook, Start Small, Stay Small. From there, I learned about your podcast and your conferences and all that stuff. That book, if I recall, it's written for developers who want to advance their career and their independence, right?
Rob: That's right. The tagline is, "A developer's guide to launching a startup." That is literally the subtitle of it.
Jonathan: That's been your vision all along. I think personally, you wanted that freedom. I remember hearing you talk about it on your own podcast that you did the grind because you didn't want a boss anymore, if I'm not mistaken.
Rob: Yes. Freedom, purpose and relationships are what I was seeking and getting that freedom of like, "Hey, we're developers, we're makers." I didn't want to build stuff for other people anymore, and I didn't want to be told what to do and how to do it. Being your own boss really is all it's cracked up to be. It comes with its own headaches, but I love it. I couldn't go back.
Jonathan: Cool. I'm interested in learning from you, especially as you've now started doing investing in-- I know you are an investor, but you also run the TinySeed and you work with other investors. I'm curious in answering a question, what do external parties, whether it be a potential investor or maybe you're thinking of selling your company, what are the things that they look for that we as small companies, small teams, even individual practitioners, what can we do from a technical standpoint, whether it's development practices or should we use Kubernetes or not, or does that matter at all, those things. Maybe we'll start with the angle of TinySeed. What does TinySeed care about, if anything, in that regard?
Rob: It's a good question. I think it's helpful to think through different layers of it, because investors do a different level of diligence than an acquirer does. It makes sense because an investor usually is buying a super minority share of a company, 10%, 15%, and often an investor is investing in, depends on the fund, but it's 10 companies, 100 companies, 500 companies.
They have, I think, less time but also less skin in that game than if they're saying, "Hey, I'm going to pay you millions of dollars and own 100% of this," and I have to own it and operate it from here on out. I adopt all the headaches, whether there's people headaches with a crappy team, whether it's technical headaches that I think you and I will dive into, those levels are different.
To be clear, it took me a long time to stop identifying myself as a developer. I haven't written a line of production code in seven years, so now I'm not a developer, but I still consider myself an entrepreneur. People tell me, "You're an investor now," and that's not how I think, I actually think like a founder. I just happen to have budget to be able to write checks and advise people.
With all that said, TinySeed specifically, we will get, let's say, 1,000 applicants for a batch, 500 to 1,000, and then we narrow it down and we do 70, 80 Zoom calls. Then we wound up making 20 offers and we get 20 people. We do due diligence. We then go through the financials a little bit. We go through to make sure that they have- What's it called? It's a certificate with the state that says they're in good standing. There's all this stuff, it's a big checklist that you go through.
Technically, we ask questions, but we don't log into servers. We don't verify whatever, we don't do pen testing or hire an outside agency. Frankly, most investors don't because it's a time thing and also there's not as much risk than if you're going to buy the company and take on the liability. What I will say, though, is where DevOps and just the entire tech stack are important is in avoiding negative customer experiences, It's avoiding downtime, avoiding customer complaints, avoiding slow performance issues. That's the stuff that can come up in online forums if we search for the name.
In a light diligence, if people are complaining about the tech, we will ask, "What happened? Why did you have a two-day outage in May?" If someone can explain it like, "Oh, it was a one time thing and my web host went down or blah, blah, blah," then it's like, "Okay," but if it's like, "Well, we had this tech--" You get into it. What I'll say is the level of diligence for investors is cursory, I will say, and whether you use Kubernetes or not, doesn't-
Jonathan: Nobody cares, right?
Rob: No, we don't care. For an acquirer, though, because I've sold a few companies, and one of them was a big sale, that they hired multiple consultants to come scan through our codebase, to look for open source stuff that might be a problem where the license- I forget what all the licenses are, but you lose some open source components, and suddenly the open source project owns your codebase or whatever, where you have to open source the whole thing. They really want to avoid that because they're buying, they're paying millions of dollars for something.
They literally scanned the codebase, and then we did a big architecture walkthrough in front of a panel of engineers, in front of a big whiteboard. What's interesting is, and we did great because my co-founder is just a solid developer. Having been a developer, I gave him a ton of time at the beginning to set things up right. Even though we moved slower, we had this amazing foundation. We passed with flying colors.
In fact, at one point the lead engineer or the CTO turned to the CEO who had been doing the acquisition, we were already in, we had the offer, we had the purchase price, it was all set. He turns, he said, "I think their technical processes are better than ours are," and I was like, "Cool." We didn't fail that. What I'm curious about, though, is if ours had been really crappy, I don't know if they would've bailed on the acquisition or not. I'm doubtful. It would've had to have been really, really bad.
I will say that later, and then I'll stop talking because I know you have other questions, but later on, I was involved in another acquisition that didn't go through. I was on the acquiring side, I'll say advising and such, and their tech stack was such a mess because it was two non-technical founders and they had a bunch of contractors doing stuff. It was such a mess that we advised them not to who buy it and they didn't. I can't say who I was advising, it's a little [unintelligible 00:09:18] and stuff. I have been a party to one, it was going to be a multimillion-dollar acquisition that was two founders bootstrapped, and the technical side of things was a major hurdle because it was not set up well.
Jonathan: Are you free to talk in more detail about that? Obviously not the details of the thing, but what were the two or three biggest problems you saw there that might have changed your mind if they weren't there?
Rob: I'm going to have to go for memory because it's five years ago and I spent two hours thinking about it. We did a call and then it was like, "All right, do the vote." We looked around a table, and it was just all of us doing the thumbs down. My memory is they had servers in three different locations. They had AWS and then they had this one with this service for processing. It didn't make sense and they really couldn't answer. It was like, "Why do you have these? Why are you paying these three web hosts and sending data across the open internets per se? It should just be all AWS." It's like "Well, it's because when we originally built it, it was really bad legacy architecture."
Then the core of their business was using a component that was being deprecated or a service that was being deprecated, or that company was starting a competitor to this service. It was just very odd, and these are things they could have coded around. If it was two devs, if it was you and me in my heyday, we would've figured it out. We would've combined everything in some servers, because we wouldn't have lived with that tech debt. It was massive tech debt.
We did tell them, "Hey, this is why we can't go through with this." This is a huge part of it. To their credit, they spent the next six months, they hired a senior whatever, and they spent the next six months cleaning it up. They came back and actually thanked us and said, "Our business is in such better shape now because of this." They didn't have a lot of downtime, but, "Our performance and whatever else is so much improved. Now we feel like if we were to sell at some point, we're just in a better place to do it."
Jonathan: That's a nice ending to a bad story, that's good. There's a lot of things of course. DevOps, operations, software, these are all things that lie beneath the surface. As Daniel North likes to say, software is like surgery. The less you have the better. Nobody wants software, they want a solution to a problem. They want to send an email to their client, they don't care about the server that sits in between.
All these things that we do, that you did as a developer, they lie beneath the service and they manage that stuff. Although the problems, this tech debt isn't always visible to the end users, it can have an impact. I'm curious what impacts you might be looking for at TinySeed or as an acquirer that you wouldn't necessarily point your finger, "That's a technical problem"?
Some examples I can think of would be how frequently do you release to your customers? How frequently do they get updates to the software? Is that something that matters? Security concerns of course would be something. You've already mentioned tech debt and uptime. Maybe I'll just stop at those two, security and release frequency. Do those matter at all from an investment standpoint?
Rob: Security certainly does. Release frequency, I care about it because personally, I have built software both as a developer and as an entrepreneur. To me, I know that's a signal, but I would say most investors don't ask, don't care in terms of how often you- Again, they care as much as it impacts the business, because they're buying a business, it's really numbers-driven.
Security is a huge issue, though, with hacks. I've done 20 angel investments personally, my wife and I, and then we've funded almost 60 companies with TinySeed. I advise, I just know a lot of entrepreneurs, and I have been an advisor to two separate companies that have been hacked to varying degrees. It's really unfortunate. One company had already taken investment, and the other one actually- Let me think. I guess both of them had already taken it.
Being hacked, though, it sucks, but it's how you deal with it then. It's how you communicate it, it's how you resolve it, how you talk to your customers about it, but certainly security has a lot more liability than a lot of other things. If you release to your customers once a month and they're mad about it, fine, you could still build a great business. If your software or servers are insecure, you can literally end the company. You can put the company over the edge. Security's a big one, and it's something that investors care about, but again, it's not like they're doing pen testing or hiring people.
There's security, there's performance, speed of the app and speed of any service you're using. Then there's uptime, like you were saying, reliability and uptime. I guess the fourth is quality. It's bugginess. Some apps just get so damn buggy. I don't want to name names, but I've literally switched software platforms because of the bugginess. I think those are the key indicators. Those are the ones that are going to impact your customers. Those are the ones that are going to cause people to leap, to churn, and that then impacts all your metrics, and impacts your ability to grow.
Jonathan: Will investor look for these metrics specifically, or are these more leading indicators? They look for churn, they look for complaints on bulletin boards and whatever.
Rob: Pretty much, yes. It depends. When you get to a Series A- Series A is when you raised $10 million at a $50 million evaluation, it's a big number. Those venture capitalists tend to do more in-depth stuff. I'm guessing if they're writing a check that big, that they would treat it more like an acquisition.
I would probably in their shoes hire a consultant to come and literally look at your codebase, or scan it, or pen test, or just do some cursory stuff. There has to be that element of it, but most companies don't make it there. Most companies raise 250,000 from friends and family, or from an accelerator, or from an angel round. The diligence there is less, and that is more of, "Hey here's a slide deck with my numbers in the story of the company, and we're doing this much revenue and growing." It's like, "Cool, I'll take your word for it."
Jonathan: Then of course when you're doing an acquisition, it's more similar, it sounds like, to the Series A type of diligence.
Rob: That's at least been my experience. I've sold small apps where the exit price is in the six figure arena. I've done a couple of those, and that diligence was not huge, but it's when you get into the millions that it starts really mattering. Especially if you're going to acquire a team with it as well, it adds. You get into all kinds of stuff once you're bringing people on.
Jonathan: When you're consulting with companies, whether they're in TinySeed or they're asking your advice, what suggestions do you have for them when it comes to technical practices? They say, "Should we hire a senior developer or three juniors?" Or whatever kinds of things they might ask. We'll start really broad here and maybe I'll narrow down, but what advice do you give when it comes to technical practices to these people?
Rob: That's a really good question, actually. The interesting thing is, in the kind of world that I live in, which is the bootstrap and mostly bootstrap software space, most of it's SaaS, but there are people doing other stuff, it's 80% technical founders, 85% somewhere in that range of where there's at least one technical founder. Usually that technical founder, oftentimes they have a good head on their shoulders and they are making solid decisions.
Sometimes we do see where it's two non-technical founders, which is a rarity, it's one or two. As a non-developer trying to build software, especially SaaS which is pretty complex, we do see some struggles where they don't know what Agile is or Kanbans or Scrum. I'm not a proponent of any of these, but I do think having retrospectives and you do a sprint and this and that, some type of way that you manage this is helpful. If you've never been a developer, you just have no idea.
All that to say, there's a small subset where I do find myself, I don't directly coach them on," Hey, I think you should set up a monthly sprint blah, blah, blah." I'm not down at that level, but what I'll do is I'll connect them with a mentor who I know is really good at it. I'll say, "Talk to this person." There's actually a few of our TinySeed founders themselves who run SaaS for agile teams. This one is called ScatterSpoke, that is for agile retrospective. I would connect someone to them and say, "Talk to these folks. One of them is a certified Scrum master and does a bunch of speaking. She can basically give you in 30 minutes 10 times more than I could give you."
We have a small subset like that, but it's pretty rare. By the time they make it to us, a lot of folks have their head on their shoulders, but in terms of hiring, it's so interesting you bring that up, because that does come up a lot. I've talked to a lot of founders, advised them or I invested in them, who are basically making their first hire. It's one or two co-founders, and they've made it to 10,000, 40,000 a month, whatever it is, and it's just the two of them and a few contractors. It's how they're saying, "I'm making a full-time hire, we need to alleviate some of the development work. I need a backup when I want to go on vacation. We need another solid person."
Usually my advice is for that first hire, hire someone more senior than you think you need, because a lot of us, especially as bootstrappers, are penny-pinching. I'm way guilty of this and I'm looking for the cheapest. I can hire this developer for 40,000, because they're like, "Entry level this is going to be great." I think as you get bigger, there's room for that. I love apprenticeship, I love training, but when you're a two-person company, you just don't have time for that. When you're a two-person company competing and moving quickly, you need mid-level to senior people, and you should invest the money and spend the money to do it.
Jonathan: I would agree. I don't have the same experience you do or the same depth of experience that you do, but I have cleaned up enough codebases created by juniors to agree that it's well worth the investment if your business depends on that code to have a senior.
Rob: I agree. Again, there is a time and a place for juniors, and it's when you have a bit more scaffolding, you have more devs, maybe if you have three or four developers. Now you can bring a junior on because enough people can code review and make sure the quality is maintained, but when it's just you and you're sprinting as fast as you can, bring in someone on five-plus years experience, even though they're a lot more expensive, it's a no-brainer, really.
Jonathan: When you're working with these technical co-founders, I would imagine that a first hire probably is not a technical person, they're looking for sales or marketing or something like that. Is that accurate?
Rob: Yes. Support customer success, sales marketing. If we have two developer co-founders who want to hire a developer, I will say, "How complex is your product?" Because unless you're just growing amazingly, right now as it is, then why would you hire a third technical? Oftentimes, we have one dev, one non-dev, who's basically doing all of that, who's doing everything else.
What they find is they're in a competitive space, and it's moving so fast that they just can't ship features fast enough, and they do want to hire a dev as the first hire to both have backup, but it's redundancy too, when, "I do want to go on vacation, or I don't want to feel like I have to bring my laptop with me everywhere all the time to make sure the uptime is sufficient."
Jonathan: I think you've answered the big question I wanted to address, which is just get a sense for how much of these things matter to external parties if you're in that boat? I would like-- Go ahead.
Rob: I will say one other thing. External parties is one thing, and that's obviously important if you're going to raise a round, if you decide that you're going to get funding, or if you're going to sell as well, that's important. Also, if you're going to run this business for a decade, if some folks want to bootstrap and run it for 5, 10, 20 years, you shouldn't care about what external parties think, you should care about what you're going to have to put up with, and can you find good talent if your codebase sucks? People will quit. Bottom line.
I have known companies that churn through engineers because the codebase is so crafty, and there's so much technical debt that no one wants to work in it. It's just constant, make a change here, get a regression bug somewhere else, because there's no test coverage. Your ability to hire and retain people in long-term and then your feature velocity as well, just plummets after. You're doing great in the early days because you're shipping all this stuff with no test. "Look how fast we're moving." You get a year, two, three years in, if you're thinking about building a real business, you can't do it with a crappy codebase, or it's hard to do, because your feature velocity slows down, and then competitors catch you.
We've seen it. Look at whatever big tool that everybody complains about, Salesforce, or I don't know, Infusionsoft, I could name a few. That's what happens. They started early days, oftentimes with no technical co-founder, and you know that that codebase is rough. No one wants to work there. They have to pay a lot more to keep engineers as well as a combat pay, because it's not a fun place to work because everything's breaking all the time.
Jonathan: Good. I would like to talk a little bit more about what you're doing these days because I do think that what you do is likely relevant to many of the listeners, not all but many. You did talk about it briefly in the introduction. Do you want to give a little bit more introduction to what MicroConf is and who should be interested in attending, and then maybe TinySeed and anything else you're working on?
Rob: Yes, I appreciate that. Our tagline, I'm going to the website right now, because you know how you change your h1, often enough, you forget it. MicroConf is where bootstrap SaaS founders launch, meet, learn and grow. It started as one in-personal event in Las Vegas in 2011. It was me and a co-founder just bootstrapping this event. We had no idea what we were getting into, but we wanted to get together with other people, it was pretty much software developers, who wanted to build products that they can make a full-time living from.
That was the early thing. It was like, "We don't want funding." I think that the tagline for many years was, "The conference for self-funded products or self-funded startups." Later on, we realized there's a lot of folks who are still of that self-funded bootstrap mindset, who maybe go raise $100,000 or $200,000 to make it easier. You're still mostly bootstrapped. You're not going after Facebook and Google and you're not trying to become a unicorn.
We've had to adjust that to where we still stay bootstrapped or mostly bootstrapped, but now MicroConf is, like I said, we're going to do 13 events this year, COVID willing. There'll be three flagship events where there's a large one in the US in Minneapolis, and there's one in Europe in October, we don't know location yet. In addition to our in-person events, where we get together with folks, we also have an online community of about 2,500 bootstrap founders free, it's called MicroConf Connect, and that's in Slack.
If someone's interested, you go to microconfconnect.com and apply. We heavily moderate it, we have a community manager. That's a free service we offer too because there are only a few really good bootstrap communities, and we wanted to help folks with that, with the guidance and everything. Honestly, our YouTube channel is pretty good. It's 300 videos, it's a lot of conference talks for people who want to start software companies. It's youtube.com/microconf if folks want to check it out.
Then what we noticed, I'll lead us right into TinySeed, because they're sister companies, if you think about it. What I noticed is that, bootstrapping and bootstrapping SaaS just wasn't really a thing in 2011. There were a handful of SaaS companies that we knew about, there just weren't that many, but as the years went on, it became obvious that this idea of bootstrapping and bootstrapping SaaS specifically was evolving. I saw more and more founders start to raise small amounts of funding 100,000, 200,000, 300,000 and still keep that bootstrap capital-efficient ethos, be more ambitious, maybe, but not hop on the venture track.
Personally, I had an exit, I sold a company, and then I started investing in these founders. I had written maybe 10 angel checks, and I was like, "Okay, that's all the money I have to invest in bootstrap founders. That's great." Now I have to wait 10 years for the return. I kept getting people saying, "Well, someone should really raise a fund and do this for more people." I remember someone coming up at a conference at a MicroConf, and I said, "Yes, someone should really do that," and then I walked away.
[laughter]
Rob: An hour later it clicked, "Wait a minute, if someone's going to do it, it should be me." I didn't want to raise a fund. I've never raised funds in my life. I bootstrapped every company. I was never anti-funding, but it wasn't something that interested me. I found a co-founder who's really good at it. We started TinySeed, which is an arm of MicroConf that invests in bootstrap founders, and it's an accelerator. Like I said, it's a year-long remote program.
We actually have applications that I think are open now as this episode goes live. We have our Americas program, it's North, South America. Then we have, this is our first application process for European time zone founder. EMEA, it's a Middle East, Europe, and Africa. I'm excited about that.
Jonathan: It's exciting.
Rob: Yes, it's pretty cool.
Jonathan: Great. Then you have, of course, your podcast, too, that I mentioned early on.
Rob: Yes, folks listen to this podcast, and they're interested in entrepreneurship, because ours has a slight technical bent. We don't dig deep into the code and the stuff, but there's always that hint because you can't take that out of me as the host. That's how I think about things like an engineer. It's Startups For the Rest of Us if folks want to check it out.
Jonathan: Great. We'll have links to all of that. Rob, if anybody's interested in reaching out to you, are you open for contact, and if so how?
Rob: Yes, probably Twitter might be the best. I'm @robwalling and my DM's are open.
Jonathan: Great. Thank you, Rob. It's been educational. Is there anything you would like to add before we sign off today?
Rob: No, I just want to thank you for having me on. It's been fun.
Jonathan: Thanks. It's been a lot of fun for me too.
[music]
[00:29:27] [END OF AUDIO]