Episode 511 | Raising Prices & Re-writing Your Codebase

Rob: Welcome to this week’s episode of Startups For The Rest of Us. I’m your host, Rob Walling. This week I’m talking with Mike Ritchie from seekwell.io. They’re a TinySeed batch two company. We’re going to walk through their story, pull out the interesting tidbits, tactical, and inspirational—all the stuff you’re used to from this podcast.

Before we dive in, I want to let you know about a MicroConf Remote, which is our virtual summit coming here on September 1st. New announcement, Jason Fried is going to be answering questions about the process and the journey of building and launching hey.com, which you’ve probably heard about, needs no introduction. The theme behind MicroConf Remote is founder stories, all the keynotes, the advice, and the segments we have going. We have a bunch of creative stuff. I’m super excited about it. Each of them is a story of that app or that founder’s stories of launching and building. We’re going to pull out all the stuff you’ve come to expect from this podcast and from MicroConf. It’s the inspiration, the tactics, and the strategies that can help you continue growing your business.

If you’re interested in that, microconfremote.com. You can grab your ticket, and I’ll see you on September 1st for that live stream. I’m going to be broadcasting live from a studio here. We’re going to actually have a film crew, social distancing, of course. Have a few in-person guests here in Minneapolis as well as some remote folks like Jason Fried and others. Microconfremote.com for the full scoop. As we dive in with my conversation with Mike Ritchie, he is the co-founder of seekwell.io with his co-founder Thabo Fisher. As I’ve mentioned, they’re in TinySeed batch two. Some interesting things about SeekWell. They got their first paying customer within 30 days of launching the app. You’ll hear me ask him how they did that because it doesn’t always happen that way. And how they kept listening to their customers, both from motivation and to keep going, but also to realign the app.

There was a point where they were going to try to go to the venture path. Their thought process there and the experience is useful to founders who might be thinking about it or think it’s the only way to do it, and then have the realization of, we don’t actually need to do that. We don’t need to be a billion-dollar company. We can still build an amazing, life-changing business, even if it’s only a $5 million, $10 million, or $20 million company.

You’ll also get to hear about massive pricing revamp that they did just two or three months ago and hear the results of that. With that, let’s dive into my conversation with Mike Ritchie.

Mike Ritchie, thank you so much for joining me in the show today.

Mike: Hey, Rob. Honored to be here. Thanks for having me, man.

Rob: Absolutely. If folks want to go check out what you’re working on, it’s SeekWell. That’s seekwell.io. You were telling me that you were leading analytics in a FinTech startup, and you realized the need for this kind of tool. To give folks an idea, SeekWell SQL, it adds Structured Query Language to the apps your team already uses including Google Sheets, Excel, Slack, and email. I took that from your website. Do you want to give folks an idea of what are the two most common use cases that customers come to you to solve, and they get a lot of value out of SeekWell for?

Mike: Yeah, absolutely. The way I describe the product is in two ways. One, that we are the SQL app that I wished I had in my last startup. Two, that we’re really push-first analytics. Instead of having to remember the login to your monthly revenue dashboard or having to log in and check new users, we push data out of your team. If you’re a data junkie, you’re an SQL jockey, you can write a couple of SQL queries and get data pushed out to the rest of your team in the places that they’re already hanging out like Google Sheets, email, and Slack.

Rob: Cool. You started working on this in 2017, but you were able to go full time on it in July 2018, so about two years ago. Did you raise funding in order to do that? Or did you have enough money saved that you were able to focus full time?

Mike: Yeah. We actually raised a little bit of money, and that’s what convinced us to go full time. After that, we decided we wanted to raise a lot more money, so we can go really big with the product. We weren’t really able to convince people that it was a billion-dollar opportunity. We ended up wasting a lot of time iterating the product and trying to convince people that we fit that narrative of the billion-dollar story. What we realized when we took a step back was people really love what we had already built. We made a pivot to double down and really focus on things that we were afraid of and the things that differentiated us. That was our foray into raising funds.

Rob: That’s interesting. You go to raise funds, no one’s convinced that it’s a billion-dollar idea, but it’s working anyway. Is that right? People were signing up. People were getting value. You’re making money from this thing. Was there a realization of like, oh, maybe this doesn’t need to be a billion-dollar idea. We can turn it into a great business anyway.?

Mike: It was absolutely that. It was also our customers pulling us back in. We would release features that, again, we thought would pull us in that billion-dollar direction. Our customers say, hey, we don’t want this. We know there are already products that do these sorts of things—really fancy dashboards with maps and 1000 different features or 1000 different ways to look at charts. But what we realized is people really loved what we had built. Our intercom is completely filled with people saying, hey, I love this product. Thank you for building it. We’re thinking, why are we banging our heads against the wall trying to raise more money when we already have a product people love? Let’s just find more of those people.

Rob: Yeah. That’s really what MicroConf, Startups For The Rest of Us, and TinySeed are about. It’s like a billion-dollar opportunity is whatever. We can make up a number—it’s 1 in 1000 or 1 in 10,000. That means there are 999 or 9999 other businesses that can be amazing and life-changing for you as a founder, and frankly, solve a real pain point. Whether it becomes a $1 million, $10 million, or $50 million company, a lot of venture capitalists would look at $50 million in error as an abject failure. Whereas you can build a hell of a business with SeekWell if you get it into eight figures. Was there a mental shift then where you were like, okay, we’re not going to go the VC route. We are just going to focus on building a great product, serving customers, and essentially making it a profitable business?

Mike: Yeah, there was absolutely a shift towards laser-focus on profitability. There’s also a stress shift. We just became a lot less stressed out. I used to work extremely hard. We still all work extremely hard, but there was a lot less pressure of like, hey, you have to hit this one tiny home run of convincing 1 out of 1000 VCs to give you $1 million, give you $2 million. That went away, and we really just focused on making customers happy. That is a lot less stressful to me is one by one, making customers happy. They’re a lot easier to make happy, and that’s a lot more enjoyable.

Rob: Yeah. I often refer to that as asking permission to start a company. That’s how I have viewed venture capital for a decade or more. I see the same thing with filmmakers. If you’re a filmmaker, go make a […] film. Don’t wait around for a movie production company or studio to fund you. I believe it’s Robert Rodriguez, you look at Kevin Smith. There are these independent filmmakers that regrettably, put money on the credit cards, which is not something I would recommend. But Kevin Smith paid clerks for (I believe it was) $25,000 on his credit card. It’s a black and white movie. It’s kind of rough. It’s amateurish. But he went and made a film. He didn’t wait for permission. I think of writers as well. I need an agent. I need a publishing company to endorse me in order to publish a book. No, you don’t. If you’re a good writer, go write your book. Publish it on a blog like Andy Weir did. He wrote The Martian. He started publishing it, serializing it, and people we’re just like, this is amazing. Frankly, it’s a work of fiction, which is often hard to do. If you’re writing non-fiction, I’d say if you build an audience, it’s even easier. You don’t need permission to do this stuff. It sounds like you guys switched that up and said, hey, we don’t need permission if customers are banging at our door to use this tool.

Mike: Yeah. The Martian’s my favorite book, so that’s fitting, I guess.

Rob: Yeah, I love that book. My 14-year-old—who was probably 10 or 11 when we let him listen to it. I was like, It’s a really good book. There’s a lot of f-words in it. It’s funny. Did you see the movie as well?

Mike: Absolutely. I have the audiobook, I have the Kindle version. Kind of a Martian junkie, I guess.

Rob: We’re talking before I hit record. I was asking about your two customer avatars like who are your most common roles in a company that come to SeekWell and get value from it?

Mike: The first demographic we do extremely well with is technical product managers or just technical business people. They aren’t developers. They’re not planning to learn Python. They’re not planning to set up servers and web apps, but they do know SQL. They love it, and they like getting their hands dirty with it. That customer we do extremely well with, the product instantly clicks with them. The two things that click with them obviously is being able to push data out to the rest of their team. A lot of times, those technical product managers are the first data person at a company. They’re responsible for keeping the CEO informed, keeping the CFO informed, and everyone else. The second type of demographic we do really well with is the data person. Once you get into the 200-500 person company level, you generally have a heap of data and generally have a few data analysts. There, we also do really well. Especially those companies that don’t have really well-built out business intelligence. A company like Looker, they might come in and do a whole project to set up a pretty sophisticated data model and all of that type of work. The companies that haven’t done that yet, we also are extremely successful with. I mentioned too earlier, the third one we also do well with is even when that company goes past the point that they have really sophisticated data models. There’s a lot of edge cases that BI tools really do terribly with, especially some of the more traditional business intelligence platforms like Tableau. It’s really bad at pushing data out. It’s really bad at doing ad hoc analysis. It doesn’t have any ability at all to share SQL, with your team which is one of the core value props of SeekWell. You can store, tag, and search any SQL anyone in your team has ever written. It’s value props really resonate with those more scrappy data people.

Rob: I’m jumping around the timeline a bit, but I’d like you to take me back when you first launched. You told me you had your first paying customer within 30 days of launching, which is unusual (I will say). The first question I have is, you knew that you needed this tool at your previous job, did you do any validation? Did you have a conversation? Did you have a launch list? Did you have customers who said, yes, I want that? Or did you just go build it and launch it?

Mike: Yes. I think we did what was the best validation you can do is solve a problem you have yourself. I knew exactly what the solution needed to be. We built versions of it at my last company, but when we’ve really productized it and built it into an application, I already knew every single step that we needed to go through to build the product. I also knew exactly who the target user was and where they might find us. We launched on the G Suite Marketplace sometime in late 2017. From the time I pulled open Google Apps Script, which is what the original version of the product was written in, to the time we had our first paying customer was about 30 days.

Rob: Yeah, that’s crazy. There is a danger with just building for yourself because you can have a problem that is either so unique or maybe you can’t find any of your customers even though other people might need it. Did any of that enter your mind? Or was it, hey, I have this itch that needs scratching. I’m going to build it and I’m just going to expect that there are other people that I will find?

Mike: It definitely entered my mind. It also entered everyone we talked to when they were convinced it wasn’t a billion-dollar company because they just felt it was too small of a niche. I knew there were a lot of people and a lot of companies that were exactly like us out there. I did not know whether they would be interested in using a product like this, especially paying an amount that would make this profitable and great outcome for me and my co-founder. We did not know that going in. The validation was really like, hey, let’s throw this together, put it out there, and see what the response is. And the response was absolutely enough to keep us going.

Rob: Do you think that G Suite launch is still a viable approach today? It was almost three years ago. Because a lot of these things change and it gets too crowded. It becomes less viable over time. What’s your take on G Suite Marketplace?

Mike: Yeah. It was funny you said that. I was poking around in the Form’s marketplace—Google Forms—and there has been an explosion there. There are multiple applications that have millions of users. I think part of it is education. A lot of high schools, colleges, and even middle schools, use Google Sheets and Google Forms. It seemed like a lot of the products were tailored towards solving the problems that teachers, administrators, and schools might have. I think it’s absolutely still viable to build a business. We’ve had several copycats come on and launch similar products. I think we’ve been able to comfortably stay ahead of them. There are a lot of got yous when you’re building something, specifically in G Suite, and especially if you try to depend on Google’s architecture, sort of out of the box functionality of G Suite. The language is Google apps script. They let you pretty much build an entire application for free within the product, and it will run on its own. But the infrastructure has severe scalability and other limitations. There’s a lot of got yous in building one of those products. We’ve, again, been at this for a while and have found a way around all those issues.

Rob: You guys have been growing pretty well. Obviously, as a TinySeed company, I see your metrics. You guys have been growing pretty well over the past year or more. Is there a couple of lead sources or traffic sources? What’s working for you? Is it cold email? There are just so many ways to get new customers into B2B SaaS these days. I’m curious about what’s working for you guys.

Mike: It’s a little bit of everything. We’ve not tried cold emails, that’s on our to-do list. For anyone who hasn’t read it, the book Traction by […] founder is incredible. That’s the methodology we’re following is going through finding channels and running tests. Cold emails are tests we haven’t run yet. Honestly, most of the traffic to date just comes from either content of blog posts that we’ve put out there or just answers we’ve posted on places like Stack Overflow and Quora. It’s really just trying to be helpful on the internet and seeing who responds to that.

Rob: Yeah, overarching sounds like content marketing, but really you’ve focused some specific things on answering questions.

Mike: Absolutely.

Rob: At the end of 2019, which would’ve been around that time you applied for TinySeed, I believe our application was in the month of November 2019. You mentioned to me that you really double down on what customers love about SeekWell, and you completely rewrote your codebase, which is a big risk to do that. You want to walk me through what happened, how you made that decision to do it and did it go well? Was it worth it?

Mike: It goes back to what we’ve talked about before. We were adding features that our customer base, which was growing and happy, didn’t necessarily love. They weren’t things that they really wanted. We were adding those features to try to expand that base. We thought, hey, we might be too niche. What we’ve realized is that adding those features was making the application bloated. It was slowing things down. We weren’t getting those customers that we were going after with this new feature. At the end of 2019, we doubled down on what customers really loved about the application. Just made it blazing fast for the things they really cared about and made the app more stable, better performing, and really just focused on the features that they love.

Rob: Why did you have to rewrite your codebase? That’s something that I tend to discourage people unless something is really a nightmare because it often takes five times longer than you think, and it doesn’t solve as many problems as you think. But there, of course, are exceptions to these. I’m curious why you decided to do it and whether you thought in the end it was a worthwhile decision.

Mike: I’ll answer that last question first. It was absolutely worth it. I learned a lot on the job. I did not go to school for computer science. The first iteration of the application was a lot of googling, a lot of pasting things together, pasting things from Stack Overflow, and just trying to figure out—as we went along—how to build a web application. I learned a ton during that process and realized that there were some major flaws in the way application was designed that were ground level or base flow. We actually were able to launch that new version of the app extremely quickly because of everything that we had learned. We also finally implemented a front end framework that basically tripled, quadrupled the amount of time we’re able to launch the new features in.

Rob: It didn’t triple or quadrupled it, but you’re saying it dropped it dramatically—cut it down in half or more to launch features.

Mike: Absolutely, yeah.

Rob: Around that time—late 2019—you applied to TinySeed. I’m curious, you had already raised a small round, as you’ve mentioned before. You had some traction. You guys were rewriting the app, so I think you were doubling down on the bet. What motivated you to apply for TinySeed? What did you think you would get out of it?

Mike: The two biggest things were, one, we were really looking for a community. At the time, it was just me and my co-founder. Things get lonely as a founder, and there’s not a ton of great communities that are active. Since we were going into this direction of building a profitable company, that we wanted to really focus on profit, TinySeed popped on our radar. It felt like a great program to at least apply to. After talking to Einar, yourself, and Tracy, it just felt like a great place for us. Also, I spoke with a few founders from batch one, and after that conversation, it was already pretty obvious that if you were to accept those, we want to go in.

Rob: Cool. You said two things. You said you want a community, what was the other?

Mike: The cash obviously doesn’t hurt. When I said we raised a small round, it was a very, very, small round. We were digging into savings a bit to keep the company running. Obviously, financial stress was a distraction that we didn’t want. That bit of capital definitely helped alleviate that stress. With our trajectory, we felt pretty good that we wouldn’t need to dig into the cash too heavily. But it was just a good buffer and a good way for us to put some stress at ease.

Rob: Yeah, that makes sense. Folks listening may not know, but in the first month or two of the TinySeed program, we go to the TinySeed playbook where we’ve distilled a decade or more of SaaS knowledge. We start by looking really hard at funnels and different types of marketing funnels—high touch, low touch, and duo funnels (as I call them) that have a bit of both. We really dig in the pricing. We pound pricing into the ground pretty hard and bust everybody’s chops. Most SaaS are not priced correctly if you haven’t really dug into it. We talk about sales, lead generation, and hiring. We spend 5, 6 weeks going through pretty directive. We try to make it 101, but we also have pretty strong recommendations. Part of that is we find that most TinySeed companies adjust their pricing in some way. Maybe it’s a price increase, which is pretty common, but also, there’s the changing of value metric is another big one. For folks who aren’t familiar, if you run an email service provider where people add their subscribers to your system, then typically, you’re going to price based on how many subscribers they have. That’s what the Mailchimp model, the Drip model is. You call the number of subscribers the value metric. Oftentimes, that value metric, if you just take a guess at it, you’re wrong. You don’t know that until 6 or 12 months in. In fact, early Drip pricing, we didn’t charge based on subscriber count. We charged based on the number of new subscribers you received each month. That was a terrible way to go. People didn’t really understand it. We didn’t have expansion revenue. It was a mess. I had taken a guess. I was trying to zig, one other zagged, and it didn’t turn out correctly. Within six or eight months of launching, we switched the value metrics from a number of new subscribers to total subscriber count. That’s what made Drip a great business is the expansion revenue. All that said, there are a bunch of ways to tweak pricing. There are a bunch of ways to start to grow the business. I know that you guys adjusted your pricing value metric. You raised pricing. That was a pretty involved process. You want to talk us through your thought process there and the mental state of what that felt like to do something that could really accelerate growth or it can break your business.

Mike: You absolutely nailed it. We were completely misaligned—the value we were delivering with how we’re charging with pricing. We were pricing pretty much $49 or $99 a month based on a couple of different feature gates and then charging $19 more for each additional user. The fact was that people could get a tremendous amount of value out of the product but just having one user sign in. They might even sign in with a data@theirdomain.com, and then they can do an absolute ton of damage with the product. They can do a ton of automation, and we get a $49 monthly charge out of it. The strategy was to better align the value we’re delivering with the cost or the price of the product. The first thing we did was to try to base it on a sliding scale. In your example of an email provider, the analogy would be to charge based on the pure number of emails that you were sending and just factor it up by some cost per email.

After getting feedback both from our customers, some trusted advisors, TinySeed founders, yourself, and Einar as well, we’ve realized that was going to be way too confusing. Not enough people were going to understand how many (what we call) runs they were going to need coming into the product to really be able to pull the trigger and sign up for a trial with the product. We went back to the drawing board and decided to just make it tier, but based on that same metric so that if you have 10,000 runs, that feels like a lot. Customers were willing to at least try to start a trial there. What we really didn’t want to do is nickel and dime and have your price change for month-to-month and fluctuate every month. That strategy and that pricing model we launched in April. You said the emotional side of it, that was really stressful. We were really worried about whether or not existing customers would be confused like, hey, this is the way I paid today. Now you’re offering this pricing. Or whether or not we’re going to have a huge drop off in trial sign-ups. We don’t really have the volume that you can AB test something like this. We went ahead, launched it, and then tracked metrics closely.

The first thing that happened was that trials did drop. We had also, at the same time, removed our “free plan.” That was what we attributed most of the drop to. Relaunched with a continued free or basic plan, and saw trials tick back up to where we were before the pricing changed. Once we got to that point, we felt comfortable and confident to change. Two to three weeks later, when those trials started to invert, we felt great because we started seeing customers that would’ve been paying $49 a month were now in the $150 or higher plan, and they were all happy. They understood the pricing. They all got unlimited users, which I think used to cause angst. It’s that, should I go around the system? Create this data@mydomain.com to try to skirt the per-user pricing? Now that people have unlimited users, they sign up their entire team—so 12, 15. We have one company that has over 300 users now, and that never would’ve happened before without the unlimited pricing. We’re extremely happy with the results. We definitely have some work to do, but it honestly probably couldn’t have gone any better.

Rob: Yeah. That’s great to hear. It is always stressful to add or remove a credit card upfront, to launch your premium plan, to launch a lower-priced plan, to remove your lower price plan, to increase prices, to change value metrics, or any of these things. It’s terrifying as a founder because you know your numbers, and you know how many people should be converting at this rate. Suddenly, everything goes sideways. You really can damage your business, you can cut your business in half, or you can double it or triple it overnight. Obviously, the goal is to get to the point where you are doubling or tripling that with the same amount of effort. That’s the thing. I’ve been beating this drum. The number one, the biggest lever in SaaS—or in any business—is your pricing. Instead of having to build new features; instead of having to find more customers; instead of having to add more things, get them to invite more users, or whatever; you just change a number. You change numbers on a screen and then your stripe account. Obviously, there’s more to it than that. I’m exaggerating a little bit, but realistically, it’s the least amount of effort if you can optimize that price to accelerate growth. The other thing I want to touch on is you mentioned before you do per-user pricing or per-seat pricing—as I would typically talk about. For folks listening, the rule of thumb is if two people log into your app from the same team, and they see different things, then you can and probably should charge based on seats, based on user logins. But if people can log into Mailchimp—two people log in to Mailchimp—they see the same thing.

You don’t want to charge, as a rule, based on seats because people will do exactly what you said. They’ll just set up data at or support at. They share logins. At that point, they’re trying to work around it and it just doesn’t make sense. It makes a lot of sense that you’ve moved away from it.

So folks have an idea, you talked about your plans before. You do still have a free plan with some manual runs, but as soon as you start automating things, you have $50 a month, $150 a month, $300 a month, and $500 a month. When this works, it’s magical. It’s a massive lever. It’s been about two months since you changed pricing. Obviously, you said you still have work to do, but it sounds like that was a great choice for you.

Mike: Absolutely. Honestly, the only work is that $500 plan tapping it out or capping it there is where we might need to go next. We don’t really have that enterprise, call us type tier, and that’s probably where we need to add.

Rob: As we start to wrap up, I had this thought. Back before we sold Drip, there were certain things that we were trying to automate on a recurring basis. I remember always having to go to Derrick, my co-founder, to say, all right, I need our customer support person to have a button in our admin console that allows them to downgrade someone from this plan to that plan, or allows them to add… There were different add-ons that someone could do. I’m going to pay $30 a month then I get the Salesforce integration. Just little things like that. All it was was a SQL query. In essence, he would go to the Rails console. Before we had a button, he would have to type it in. Then that would get translated into an SQL query that would run against the Postgres database. Is that the kind of thing that you could plugin to SQL? Where hey, I’m going to write this SQL statement once, and then I could just come in and click it like a button. I could have my support person or customer success person come and click it once? This is a long question, but the second part of the question is there were also things that we want to run on a daily or weekly basis to notify our customer success person to be like, hey, we think that this big account might churn. Or here’s a list of accounts that are suddenly inactive and not logging in but pay as more than $300 or $400 a month. Are those use cases that a SaaS founder or a small SaaS team could integrate or could use?

Mike: Yeah, absolutely. I could give a concrete example of how we use it internally. We have a “DevOps” dashboard that just has, like you said, buttons. There are forms, buttons, and we even have a way to just edit an SQL table or the results of an SQL query as if it was a spreadsheet. We have this one dashboard that just has those items on it. Instead of a dashboard with a bunch of charts, it’s a dashboard with a bunch of actions that you can take.

For example, if you need to, on the fly, extend somebody trial or on the fly downgrade somebody for whatever reason, there’s a form that you can just enter the information. You can even have it pre-populate with the only values that are allowed to be entered for that field, and then submit the form or update the spreadsheet.

Again, it’s very much a spreadsheet fill where you just edit it and submit the edits. That’s sort of our solution or answer to that first problem. Again, that harkens back to the last company I was at. There were tons of operations things that we are constantly emailing our DevOps support for to just, like you said, write an SQL query. There might have been an hour-long or two hour-long turnarounds, whereas DevOps can write the query once and then expose it to the rest of their team. That’s kind of the first piece. The second piece is really exactly what the initial insight was around building SeekWell, which is push first. People want data and information pushed to them versus having to remember to go check it. Then, you can obviously schedule it to automate that. We have alerts for, hey, it looks like the usage for this really important account has dramatically dropped off the face of the Earth. We should possibly reach out to that customer, we should check if all of their automation is working, or check if the connection of their database is working. All of those types of alerts, we have to set up. They only send when you actually need to know about it. You can trust that it’s there if you need it, but you’re not distracted or bothered if you don’t need it.

Rob: Yeah, that makes a lot of sense. The last question for you is you’ve been working on this app now for three years (in essence), give or take. Has there been a moment where it just felt like a […] show? I’m basically asking for the low point. Over three years is a long time to ask. Has there been a time where you’ve been so discouraged that you didn’t want to do it or you didn’t think it was going to work? Or maybe when all the servers were done, you thought, we’ve had a good run?

Mike: Oh yeah, man. Every other day. Just kidding. Mid-2019, there were some times like that. We had, again, a product that wasn’t built by an engineer. It was built by someone that was learning as they went. We had issues with our server and scaling. We had issues financially—we’re running out of cash. That was probably the dark time in mid-2019. Again, what really saved us was just listening to customers. Like, hey, we love this thing. You have to fix these couple of items. This is something that will continue to pay for and we love paying for. That was both the low point, but also was when we came out of the trail. That was definitely the hardest point.

Rob: It’s so nice to have those voices because without those customers telling you that, it’s hard to keep going. It’s hard to convince yourself to keep pushing on something that feels like maybe it’s not working, or it’s really pushing against you. Customers that get that much value out of it and telling you to keep going, I have to imagine that was a big help for you.

Mike: Yeah. I had built things before that never got a customer. You can feel on top of the world before you get your first customer. We actually joked about this at my last company is everything runs smoothly until we had our first customers. It’s very easy to completely drop your database schema, make massive changes, and have your app down for hours or days. The other side of that was if you don’t have customers, you don’t know if you’re headed in the right direction. To me, now, that’s even scarier. If you’re building something, get it out there as quickly as you can to get feedback and make sure you’re headed in the right direction before you waste a ton of time.

Rob: Mike Ritchie, thank you so much for joining me on the show, sir. If folks want to check out what you’ve been working on, it’s seekwell.io, and on Twitter, you’re @seekwell_io. Thanks for joining me.

Mike: Thanks, Rob.

Rob: Thanks again to Mike for coming on the show. I haven’t done a listener question call in a while, and I think we’re going to have a listener question episode coming up soon. If you have a question for me or for a guest that I bring on my show, please email questions@startupsfortherestofus.com. The voicemails, if you attach an audio file or send me in Dropbox or Google Drive link, those go to the top of the stack but definitely running low on text questions as well. I would love any questions that you have about SaaS; about building, growing, and launching; and all of those things. Thanks again for joining me this week. I’ll be back in your earbuds next Tuesday morning.