Welcome to episode twenty-nine of the SaaS Backwards podcast, where we interview CEOs and CMOs of fast-growing SaaS firms to reveal what they are doing that's working, and lessons learned from things that didn't work as planned.
You can listen to the full episode directly below via Spotify, or visit SaaS Backwards on Buzzsprout or wherever you listen to podcasts.
How to successfully bootstrap a SaaS to provide more founder opportunities
With Markup Hero’s founder Jeff Solomon
Edited for clarity and readability
Host, Ken Lempit:
Welcome to another episode of SaaS Backwards, a podcast that helps SaaS CMOs and CEOs to accelerate growth and enhance profitability. Our guest today is Jeff Solomon, founder at Markup Hero, a SaaS product that is a screenshot and annotation suite and enables these functions for other SaaS products as well. But before we get into the conversation, could you tell us a little bit about your background as well as Markup Hero?
Markup Hero is my current project, but I've been in the SaaS space and startup ecosystem for the last 20 years. I founded a SaaS CRM company called Velocify in 2004, which we sold in 2017. That was a sizable exit with a good cap table. I also founded an incubator accelerator called Amplify. We're on our fifth fund. We've deployed more than 50 million in capital to very early-stage companies and had several exits. It's been a nice run, and it gave me an opportunity to sit on the other side of the table--the investor side as well as the founder side.
Now, I'm building this annotation product, Markup Hero. It started out as a side project, a little side hustle, like a lot of us do, and it's gained some traction. We're trying to scale that and trying to see if we can get it into other SaaS applications as an annotation API developer library, which is a new approach. That's what I'm up to.
This is a bootstrap, right? I think that’s interesting for a guy that's got good venture capital connections. Would you talk about the mindset and how you're approaching the growth of Markup Hero?
I'd say I'm probably more of a bootstrapped-oriented founder than a venture-oriented founder.
I've certainly raised a ton of money and I've helped and deployed a lot of capital, so I've been on that side, but I really excel working in a very small team with limited resources and growing things from the ground up that way.
Even Velocify, which we ended up raising 30-some-odd million for over the course of the run for the first several years, getting it $300-$400K in monthly recurring revenue was all bootstrap. We got it to that point on our own steam, so I've been very effective at that.
It has its pros and cons. But for me, that's been my sweet spot and what I really enjoy, and having had some success in my career, I obviously would love to have another monster exit, but it's not the primary driver of what I do these days. I really want to enjoy myself.
With Markup Hero, like I said, we started it as a side project. Me and then two other guys were consulting for a company here in L.A. and that company was kind of headed out and we saw the path that was going down and we were like, "Hey, let's work on something on the side." We evaluated a lot of ideas, and I shared this screenshot and annotation thing was something that I did multiple times a day, and they did often.
It's a competitive space. There are a lot of products in the space, and in somewhat of a commoditized space, so we were concerned about that as a reason why not to do it, but just because there are competitors and the product has somewhat become commoditized, we still saw that there were a lot of holes--I certainly did as a power user of this space and really thought we could build something fairly quickly that we could get to market and build a nice cashflow machine without having to raise money or do a lot on that side.
That's how we started the business and now it's starting to scale and go beyond and we're spending more and more time on it.
There’s a lot to unpack there.
- The notion of the SaaS as a lifestyle business.
- Going after a crowded space
- What it takes to bootstrap a tech product and having founders
I want to visit with something we didn't talk about very briefly, which is the founder group, these people that you knew before you were working on this other project. Is this a band of people that have played together multiple times?
Since we met it has. Markup Hero was a second thing we worked on together, but I think you bring up a good point about the founder team structure. I've dealt with that a lot over my career. My very first company that I started had six founders, which was too many, and I learned that the hard way. Four of those founders were best friends and that did not work.
That's not to say you can't start a company with your best friends, but in that case, it was very challenging. It just did not work, and I damaged some great relationships from that, and I learned a lot from that first startup, which crashed and burned.
Subsequently, I started thinking about how to structure a founding team and what was important. This is something that I get a lot from people that I advise. Working with founders and building your founding team is a big challenge, and really, I'd say, a key factor in whether the company is successful. For me, I found that the optimal team is about three people, and those three people really need to have a well-rounded skillset.
If you're building SaaS in particular, obviously, you need someone that's strong in the engineering front. One of these three guys was extremely strong. I've worked with a lot of engineers in my career and some great ones, and this guy was very talented, and we got along well, which is a key component.
The other guy was a front-end designer product person that had some marketing chops and was well-rounded on that front. Then myself, being able to do grassroots marketing, content, business development, sales, really having a wide range of skills, not being a great programmer, I can write code, but it's kind of ugly, so I didn't really need to focus in that area at all, but the three of us can essentially build anything.
Incidentally, while we were building Markup Hero and not making any money at first, I would essentially bring them to my consulting project, so I'd pick up a new consulting project, they'd need engineering and product work, I would bring those two guys over, so the three of us would essentially be building other people's stuff, and then on the side, working on our stuff, which is a very typical model for a bootstrap.
That's interesting. I recorded an episode earlier this week and the founder called it "founder dating." This group of people did not know each other before they came together. It's like founder trooping or trooping from one thing to another, you sort of find your troop, and you try and hold them together for multiple things. It's an interesting idea.
Yeah, I do. I've been known to do that when I find a good crew. Whether or not I'm starting my own thing or just working on consulting arrangements or taking projects, I'll try and bring my same crew because I know I can get stuff done. When I go into a company and they've got some outsourced team, I don't know for sure if I can build it in the timelines that they want or that I think, and when I have my own team, someone says, "Hey, we want to build this feature," I can certainly scope out any feature, and then I can get a pretty good sense of what it's going to take to actually get it launched and QAed and working when I have my own crew, so we've been able to build a lot of stuff.
In fact, just as an example, I came into a project about 18 months ago that the guy had already spent half a million dollars with an outsourced team to build this product and it went awry, which is too common.
It's something I advise founders on a lot in this outsourcing, SaaS gone wild project. We essentially rebuilt the entire platform in six months from scratch and it was 10X better than what they had, and it ended up costing them significantly less than they had already spent. People often think, "Hey, you bring in a developer that's $200 an hour. I can't afford that," but you pay someone $200 an hour versus $30 an hour overseas, and they get something done at a higher quality in like an eighth of the time, it ends up being cheaper. That's something I try to alert new founders to. It's not always best to go with the cheapest rate because it doesn't always work out. It's sometimes better to just pay a premium to get someone amazing.
I love that little insight. There are two things in there. One is the notion of building your crew as you navigate other things maybe before you do your startup and have an idea, so building your network and building your team. I think having built software early in my career taught me the difference between capable and inexpensive. There's a lot of margins between those two. This business, it's bootstrapped and you're not driving for growth at any cost, right? You're doing an organic growth of this business to the extent possible. When we talked, you hadn't decided whether it is a lifestyle business or are you going to try and grow it to exit? How does that work internally with your co-founders?
Sometimes you have co-founders where one is like, "We have to shoot for the stars and have a monster exit or nothing."
In this case, these founders are open to both options. I'm open to both options because I'm not driven by monster exit. I really want to enjoy myself, and I obviously want to continue to make money, but a lifestyle business appeal to me at this stage, so they're open to both, which is cool, so we are evaluating when it makes sense. If we can get some significant traction on this developer library product, which is sort of the Twilio for annotation, maybe it makes sense to try and raise and scale that.
But raising money comes with a whole bunch of strings and so even if I could go out to my network and be like, "I'm going to scale this thing to a $500 million company and raise a couple of million bucks," it doesn't necessarily mean that's the best decision. I've seen too many companies sell for a hundred million and the founder walk away with a million bucks versus a lifestyle business that's throwing off half a million dollars in excess cashflow every year and they run it for five years and they just made 2.5 million bucks, so it could be significantly more profitable for you as a founder to just have a lifestyle business than it is to have a big exit. Just something to keep in mind.
Yeah, I think this underrepresented viewpoint in entrepreneurism, and in the software space, but in so many other parts of entrepreneurial endeavor--the lifestyle business is the goal.
A friend of mine had a business with 200 engineers working on environmental consulting and the guy was basically phoning it in. He didn't have to do anything. He had 200 people working for him, which is a big lifestyle business, but it was a great lifestyle. Ultimately, when he sold it, it didn't grab any headlines, but that looks pretty good from where I sit. I think that's an aspiration we can uncover, even beyond this episode, talk about how to look for the opportunities that create lifestyle, business, and software. Maybe we should become champions of the lifestyle business or something.
There’s something to be said about it. I'm not discouraging anyone from going for a monster exit. Certainly, a lot of learning to be had there. It's very exciting, but it's very challenging.
But once you bring in outside capital into your business to try and grow it, you have restrictions on the decisions that you can make.
You're put into a particular funnel, and it doesn't give you as much flexibility. I think the best way to look at it as a founder is 1. what's important to you in terms of what you want to be doing for the next five to 10 years, and 2. does it make sense for the business to try and raise and go that path?
If those answers point you in one direction, then go that direction. If not, then be okay with the different direction. Be open to different options.
Fair enough. Hey, let's talk a little bit about how you were able to learn what was important for this product. You did some customer interviewing, and you have a point of view on the interviews and extracting needs before building product or while building products. I'd love for you to share some of your advice on that.
I'm a big advocate of customer development and trying to understand the real needs and pains before building something. This is one of the reasons that some of the best startups are solving their own problem first. Dropbox is a great example. Drew said something like, "This is my problem and I want to solve it for me, and certainly, a lot of other people have that same problem.”
That's a good way to think about a startup.
I always want to talk to more potential customers before I start building something. In fact, I've framed my career around that and created an online course about it.
I've been teaching a high-school-level entrepreneurship class for eight years and the framework for that class is customer development.
These students come in thinking they want to build an app, or can make this or that, and I say, "Okay, those are cool ideas, but let's go talk to some customers and see if other people actually that have need."
It's a very nuanced skill in that you can't just go ask someone, "Hey, do you have this problem? "If you load the question with the problem, nine out of 10 times, you're going to get a false positive, and so it becomes a real art in trying to extract those problems from customers and the questions you ask and the conversations you have to get them to tell you they have a problem without loading the question with the actual problem.
What's the secret?
The real secret is just to have conversations and not necessarily treat it like a survey. Typically, people go out with a survey. In a survey, the answers you're looking for are often pre-loaded inside the questions, so I really encourage people to just get on the phone with customers and really get them to tell you stories.
When customers start sharing a story about how they operate in that area, or what they do, a lot of problems tend to pop up. That's really what I encourage people to do is get on the phone with them and listen for the pain. Almost always, people will be like, "Yeah, I do this, I do this, I do this, and then this happens and it's so annoying. Then I do this, I do this." "Oh wait, tell me about that little annoying thing. What was that?" You try and dig in on those hints.
If we get on the phone with someone, we have a discussion guide, but we don't have 20 questions.
You really do have a guide. You have some ways to keep them in the realm and not get too off-topic but let them share the pain from their own natural flow of the conversation.
It takes practice. I encourage and train a lot of entrepreneurs on this stuff, and it takes multiple times. In fact, the reason I got so interested in this is because the very first company I started crashed and burned and I didn't do any of that because I didn't know that was necessary. I didn't have any mentors at that time.
We basically built something that nobody wanted that nobody needed, and so of course, they didn't use it, and of course, they're not going to pay for it. But when I told them, "Hey, we're building this thing," they were like, "Oh, that sounds cool," right? "Oh, that sounds really neat." But it really wasn't scratching an edge, and so from that experience, I said, "There's got to be another way."
Even in the second startup, I still didn't have a true framework developed, but I had an insight that there was a need to talk to people.
The way that Velocify was created was out of observing what I was doing with other clients. I had a consulting firm and was working with clients and listening to their problems and solving them with software when I realized that a lot of my clients have the same issue and that was a problem.
So, we built a SaaS product to accommodate that issue for any of these clients--the ones we have today and the ones that are like them. That was essentially the first step at customer development in a non-organized way.
I view consulting as a great path to other things, whether it's building SaaS products by getting enough industry knowledge in different places to say, "Ah, I see a problem," or I've had friends in the advertising business go into consulting, only to be able to go back into the advertising business at a much higher level. I think maybe that's underappreciated, too, is that providing consulting services gives you opportunity to really look in a lot of different businesses and start to generalize some problems or contextualize them.
Absolutely. I'd say a lot of great startups have started by way of the founders working in other things and observing and seeing, "Oh, well, why does this happen this way? This could be an interesting product." I think that's a great way to get some exposure and I really encourage a lot of founders because I see so many high school founders that are going to college that want to start their companies right away and I encourage them to take a few jobs and work on a few projects first and get some experience there before jumping into their first startup because like you said, you'll observe a lot of things and be able to hone in on potentially a better opportunity than what you had when you were 17.
Let's talk a little bit about scaling up a business like yours. What do you think the steps are within the constructs as the business is today? What is it going to take to scale this business? What are the strategy and tactics that are going to help you scale acquisition and onboarding?
I always start with content marketing because it's effective and it's inexpensive if your team can do it in-house. I can write content myself; I can do outreach to other sites and places where I want that content distributed, or I want links to that content. It's something that I can bootstrap myself and not outsource. It's also something that you can scale. As you get a process down, you can then bring on other people to replicate that process.
I always start with that and that brings in organic traffic. It's basically an SEO tactic. Organic traffic is always high-quality relative to paid traffic. With paid, you have people higher up in the funnel, there's less intent, and so it's something you need to do to scale.
But early on, finding that low-hanging fruit of people that are looking to solve the problem that your product solves is where I want to start. I want to get those early adopters. Also, content marketing is something that takes time to build up your domain authority and SEO footprint, so you need to start early when I really encourage founders to always begin that process from day one and then scale it from there.
That's where I always start, depending on where the path of the business goes. If there's opportunity for paid acquisition (certain businesses are better suited for that) getting into AdWords and other kinds of ad placement, I'll start to work on that. Then in the case of Markup Hero, as we move into this developer API, there's some real sales and business development effort that is needed to get in front of these other SaaS applications and get them to see that this is something that might be beneficial for them to add.
I had mentioned the company Twilio and I had an interesting experience with them in their early stage. In fact, Velocify was one of the first clients to heavily use Twilio back in 2008, and at one point for a good 18, 24 months, we were the largest client of Twilio. I knew Jeff Lawson personally and we worked to try and build his API to suit our needs and we really worked closely together to build that product.
That's when I realized, at that point, a business that just provides an API service to another SaaS company could be a big business. Obviously, that turned out to be the case. I should have swapped stock with him.
Back in the day, I remember sitting in a coffee shop and he was telling me about this business, and I was like, "This could actually work for our business." We have this need, and we were growing and I probably could have said, "Hey, let's swap a couple points," and he might have done it. We were bigger than him at that time. That was a missed opportunity, for sure, but he did a great job of that company.
We all have our woulda, coulda, shouldas-- so those are yours right there.
Maybe it's good to dig in a little bit on this API as a service for another SaaS. You shared with me the venture capital index of those firms. It looks like it's a vibrant space that maybe is a little under the radar. What attracts you about that space versus selling to the end-user? What's the dynamic there for you?
The potential to scale the business rapidly is very high because if you take the Twilio example, if you go to an Uber, which they ultimately did get that client, who has a lot of scale already, you land one client, and you are essentially landing thousands and thousands of clients because you're tapping into their reach.
For an early-stage company that's trying to grow, you can add one user at a time. Especially in the case of Markup Hero, it's an inexpensive product. We're talking about $5 a month. It's a very low-end SaaS product, so for us to get to hundreds of thousands or millions of users, it's a slow grow at one at a time. But if we can do a deal with a Notion or an Asana or one of these companies that has tons and tons of users, instantaneously, we have huge scale potential.
That's very appealing. That doesn't mean that getting those deals is not hard. It's very hard. Doing B2B deals is challenging.
But if there's a real pain point there and need, I think more and more companies are starting to see that even if they have a team of a hundred developers or whatever they have, it doesn't always make sense to build everything, even though they could. They're not going to rebuild things that are commoditized services when they could just use someone else's and that's becoming more and more accepted. I think that's very appealing for a founder to think about how they can build an API as a service and not necessarily only have the software as a service to direct it to end-user.
Maybe generalizing from your experience, even if the space on the end-user side is crowded, might not be crowded in the API business, right?
Yeah, and the reason this one really made sense to us is a real-world example, I used to use Evernote religiously. I think you still use Evernote.
Oh, right now.
Okay, but I switched to Notion several years ago, but Evernote, maybe 10 years ago bought this product, Skitch, essentially a competitor to Markup Hero, right? It's a screenshot and annotation product and they bought it and they integrated it into Evernote in a seamless way and it was fantastic. In fact, it was the only reason I didn't leave Evernote for years is because they had this feature, and you could do the annotation directly in a note. Nobody else has that. You can't do that in Notion. You can't do that in Coda. You can't do that in Asana--none of those products.
Having had that experience that was so useful, and other people shared the same thing, our thinking was, "Hey, if we could get these other products to see the value there, it's something that we could get some real scale with some of these clients."
Right now, we have small guys, we've got small products using the API, but the question back to you, how do you scale, there's a point where we will say, "You know what? It's time to implement a small sales team or an EP team to really go after these companies and be more deliberate on trying to acquire new customers." I'd say we're not quite there yet, but that is a path that we could go down, and that might make sense to raise money if we knock down a couple of these bigger guys, and our list is huge, that could get us to millions of users, could be a significant business.
Well, I think that's a great place to land the podcast. I feel like we covered the topics we had hoped to cover. I think Markup Hero is an interesting utility and we're going to check it out for our own use. If people want to try the product, where do they go to learn more?
Great. How can people get in touch with you, Jeff?
Personally, the best way is through my personal website, which is bak.me, Bak Me. You can reach out to me via email. I do, like I said, a lot of advisory calls. You can access my course from there, so I'm very reachable in that way. Happy and love to talk to entrepreneurs, love to help founders, so feel free to connect with me.
Well, thanks so much for offering all that resource and access to our listeners. For those of you listening to the podcast for the first time, if you found this episode of value, please subscribe wherever you find your podcast. We're pretty much widely distributed. Jeff, thanks so much for making this a great episode as SaaS Backwards.
Awesome, man. Thanks, Ken. I really appreciate it. Thanks for having me.
Thanks for listening to the SaaS Backwards podcast brought to you by Austin Lawrence Group. We are a growth marketing agency that helps SaaS firms reduce churn, accelerate sales, and generate demand. Learn more about us at www.austinlawrence.com. You can email Ken Lempit at firstname.lastname@example.org about any SaaS marketing or customer retention subject. We hope you'll subscribe, and thanks again for listening.