Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike take a group of listener questions including Per User Pricing for SaaS, Drip Email Sequences for Freemium, and SaaS Subscription vs. Commission Pricing.
Items mentioned in this episode:
Transcript
Rob [00:00:00]: In this episode of “Startups for the Rest of Us,” Mike and I discuss per-user pricing for SaaS apps, Drip email sequences for Freemium and SaaS subscription versus commission pricing. This is “Startups for the Rest of Us,” episode 263.
[Theme Music]
Rob [00:00:21]: “Welcome to Startups for the Rest of Us,” the podcast that helps developers, designers and entrepreneurs be awesome at launching software products, whether you’ve built your first product or you’re just thinking about it. I’m Rob.
Mike [00:00:30]: And I’m Mike.
Rob [00:00:30]: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. So, where you this week, sir?
Mike [00:00:35]: Well, I’ve been spending the past couple of weeks working on getting the Founder Café data migrated over into Discourse and been working with a DBA who’s been extremely helpful on that front. I think you kind of referred him over to me, and his name is Creston. He runs Ruby Tree Software, so you can go to rubytreesoftware.com if you’re looking for a DBA. He’s done a really fantastic job of getting a lot of the data converted over into a format that we can use inside of Discourse using the [postgreSQL?] back end. I’m really happy with how things stand right now, and right now it’s just a matter of working on a lot of the mundane stuff like onboarding instructions, the terms of service, privacy policy, CSS and things like that. So, things are looking good.
Rob [00:01:13]: Yeah, and so far, so good with Discourse, huh? I mean it seems to be a pretty good platform. We had looked at it – was it two and-a-half years ago when we moved from basically WordPress forms over to our current platform, which is Communifire? I think it was –
Mike [00:01:25]: Yeah, it was about that.
Rob [00:01:26]: – a while ago.
Mike [00:01:26]: Yeah, it was –
Rob [00:01:27]: At the time, Discourse was, like – I don’t know – an alpha or something, because it was pretty early-stage. But we had our eye on it, and we actually looked at it at that point, and our experience with Communifire has been mixed, and it isn’t exactly meeting the needs of what we want to do. So, we feel like moving over to Discourse is a good choice. A lot of people are familiar with it, and the usability is really good, right? Jeff Howard has done a good job making really usable forms.
Mike [00:01:50]: Yeah, so definitely looking forward to that. Hopefully, we’ll be done by the end of the month.
Rob [00:01:53]: Awesome.
Mike [00:01:54]: What about you?
Rob [00:01:54]: Well, we have two job openings right now with Drip. If you’re a content marketer and you want to help us with the blog and help crank out content – it’s not just about writing, but it’s about promotion and all that stuff – definitely get in touch with me. I’m hiring in the next couple weeks, soon as I find someone. It’s pretty much, I would say, anywhere in the world. Ideally, it’s within three hours of Pacific time zone either way, but we’re looking for someone with experience. You can email me directly, or hit the Start Ups for the Rest of Us site and contact me through there. The other thing we’re looking for is someone with a lot of UX experience, like a mid-level to senior UX person. Some Rails experience would be ideal, but we can work. If you know Python or know some type of service ad language, even if you’re not an expert, what we really need is heavy UX experience.
[00:02:39] So, things are growing and moving, and I think we’re going to probably have some more job openings here in the next few months as well.
Mike [00:02:45]: Very cool. So, what are we talking about this week?
Rob [00:02:47]: Well, we’re going to answer a group of listener questions. They continue to stack up, and we have some pretty good ones related to SaaS – pricing and development platforms and stuff like that. So, let’s dive into our first one. This first question is from Vincent Pruyer [phonetic], and he’s from wearewizards.io. He says, “Hey, guys. Thanks for the podcast. Lots of interesting stuff every week. We currently have a side project. It’s a password manager called ‘Passopolis.com.’ It was originally from another company, and then they open-sourced it when they shut down, and we’re currently running it for free and thinking about how we can monetize it. Our main competitor is LastPass, and it’s around $24 per user per year, and this kind of pricing only seems sustainable once you get to 100,000 users because the pricing is so low. If we decide to monetize it, we’d need to invest in design and do some other stuff.”
[00:03:34] To summarize Vincent’s question, he’s wondering if they should do this low per-user pricing, if they could compete at that – looking at, like, 10 to 12 British pounds per user per year – or, doing tiers, where it’s like one to five users is 30 pounds a year and six to ten is 100 pounds. But, really, his question is, “Should we just keep running it for free and not try to actually monetize this? Or, do you see a way to make this work?”
Mike [00:03:57]: Well, I think this is a pretty hard question to answer. One of the things that I see here is that it’s definitely aimed at the consumer market, or at least it feels that way; because in order to monetize it, especially if you’re going to try and compete against LastPass, the pricing on LastPass is just so low that you’re going to need a ton of users in order to be able to make ends meet. You could run it as a side project, but that’s probably all it’s ever going to be; and your number of users still has to be very, very high in order for it to just work, in general, for you.
[00:04:26] I think that it’d probably make a little bit more sense to look at other ways that you can solve similar, but related, problems using the same type of technology and possibly target businesses instead. So, if you’re looking, for example, at – your main competitor’s LastPass at this point. I think I might try and compete against something like Passpack, where you are instead selling it to teams of people and specifically at teams of, let’s say, five people or more and then charge those people on a monthly basis and give them team management of accounts. You could use that in situations where you have a bunch of people who are working together, and they need shared credentials to different machines, for example; or, to different websites for a variety of different reasons. But I think that competing head-to-head against LastPass is probably not the wisest choice in this situation.
Rob [00:05:12]: Because you’re not just competing against LastPass. There’s one password and a bazillion other of these password managers; and trying to make money, if you’re bootstrapping, charging $10 or, I guess in this case, 10 pounds sterling per year is insane. I mean the price points just aren’t there, and as Vincent pointed out, you need 10,000 paying users to make $100,000 a year; and just trying to find 10,000 users, unless you have just this enormous funnel and enormous channel of people using it now, there’s just no way you’re going to get there. You don’t have the team. You don’t have the traffic sources to get that many people.
[00:05:48] The worst thing I think you could do is to try out that pricing and get 100 or 500 paying customers. The problem with that is once you’ve done that, now you kind of owe them something. They’ve paid for a year, and you’re stuck to supporting them, and you really haven’t made much money. If you got 10,000 customers, that’d be great. If you have zero paying customers, then you’re home free; but once you make this leap into this really cheap pricing and you have to support these people for a year, and you’ve only made hundreds or a few thousand bucks, it’s not going to be worth it.
[00:06:15] I agree with Mike. There’s no way I would try to compete directly with LastPass on this. They’re just so far ahead. Unless you have a major differentiator, that’s where I would look for – is the competitive advantage you have is that, since it’s open source, I imagine you have some type of user base. Well, what is that user base contributing or asking to be built that’s different than LastPass that would allow you, in one sentence or one headline, to describe how we are the opposite of LastPass, how we’re way better, or way different.
[00:06:40]: You look at how Gabriel Weinberg is competing with Google. He has DuckDuckGo as a search engine, and he’s been on the podcast a couple times, I think, now. He didn’t do it by trying to compete head-to-head with Google. He figured out “how can I be different than Google in a way that I can sum up in one sentence?” And, typically, he uses the phrase, “Google tracks you. We don’t.” Right? It’s about privacy and tracking. Now, there’s also some other points: where they’re only going to have one ad at the top. They do some other stuff, but that’s been his big focus, and that’s the only way he’s competing with Google. It’s not by trying to be better than Google, or cheaper than Google, or faster than Google; because you can’t out-Google them.
[00:07:13] I think the same goes with LastPass. They’re just too big. You can’t out-LastPass LastPass. Figure out a major differentiator, whether it’s what Mike said, where you’re actually pivoting into another space; or, that you just pick a niche and you are the best password manager for web designers, or whatever. Maybe you add something that allows them to share with their clients, that no one else does, then you have a real differentiator. Then you don’t charge 10 pounds per year. That’s when you charge 50 or 100, or you charge monthly because you are so much better for that small group of people, that it’s warranted and they’re willing to pay for it. I hope that helps, Vincent.
[00:07:46] Our next question is from Chris Sciora [phonetic]. He’s from gomobileiq.com. and he says, “Hey, guys. It sounds like both of you started with a handful of different languages in the past. Maybe C# for Mike, and Rob has also definitely used .NET. Rob recently using Rails for developing the last, two web applications; and he’s indicated he doesn’t have much experience with it, certainly not enough to actually write the apps. Without arguing about the merits of the different frameworks, I’m curious what benefits you saw by making that change. It effectively removes you permanently from the development review process, while adding another layer of complexity. What were the reasons for dropping a familiar platform and effectively starting from scratch?”
Mike [00:08:24]: Well, I think this is mainly aimed at you. My take on the different languages is, in most cases, you’re going to use the best tool for the job; and I think that if you’re going to go in a direction for using something where you don’t know the technology at all, then it would probably be an intentional choice to help keep you out of the technology. That would probably be the main reason that I would go in that direction; but, Rob, obviously you have your own reasons for having chosen Rails. Was it based on pricing? Just finding people who knew that technology? What was it?
Rob [00:08:53]: Your first point of intentionally keeping yourself out of the development is actually a good one. That was part of the reason, is that I found with all the products I had – from Dot Invoice to HitTail to WeddingToolbox and the other ones that I was managing – that I kept getting pulled into these little fixes and these little issues and these little bugs, and I would kill half a day troubleshooting something in PHP or, heaven forbid, in ColdFusion with WeddingToolbox. Not being able to do it is actually a benefit to me, because it means that I just can’t these days. That’s giving something up. You have to get over the fact that you can’t go in and do it.
[00:09:33] At the same time, though, I was able to find a trusted resource who I knew could help support it, and that was Derek, right? He was contracting for me at the time. He’s now cofounder of Drip, and early on, we discussed what language should we build Drip in. He knows Rails like the back of his hand. He’s very knowledgeable and just a senior, senior dev in it; knows about architecture and how it works. So, that was kind of a no-brainer, right – the fact that he knew it so well. Then, you can find Rails developers. Rails developers have heavy UX emphasis, typically, and wanted to make it very UX-friendly.
[00:10:04] Finally, I had run into real issues. I got an acquisition offer on HitTail several years ago, and since it was written in ASP.net stuff, the person didn’t want it. They really wanted something in PHP, Python, or Rails. If you’re going to build line-of-business enterprise apps, then, yeah, Java.net – those are great. But if you’re going to build startups, essentially; or web applications, and you want to be able to find developers that aren’t really expensive, find developers that have the startup mentality in general and maybe someday be able to sell it, or transition it to another company – whether that’s your plan from the start, or not – building in an enterprise language like a .NET or a Java will be to your detriment. That’s where I’d say Python and Rails would be my top two choices. I think PHP would be another one that’s perfectly reasonable. We can go into the merits of doing everything in node and using bits and that, but it probably isn’t worth the time of it.
[00:10:56] The bottom line is the reason that I dropped the platform is: 1) so that I wouldn’t get sucked into development; 2) because Derek knew the language really well; and 3) because it makes it easier to find people to work on; and if someday there was some exit event, or someone merged, or there was ever that need to transition it to another team, it’s just an easier transition when you’re using a language like this.
Mike [00:11:17]: I’ll just interject here to point out that I’ve heard that as well in terms of using something like Rails, or Python, or anything like that. Those types of languages, it’s easier to find the developers, especially the ones who are motivated to self-teach and are in the startup space. The pricing for apps that are built with those tends to be a little bit higher, so if you’re looking longer-term, I’ve heard that as well. It’s just the types of technologies that people tend to be more interested in acquiring then the C#s and Javas of the world.
Rob 00:11:50]: All right. Our next question is from Nathan Rimmer. His subject line was “20 percent of IT spending creates no value. I need your advice on how to fix that.” He says, “I’m a requirements analyst and a startup fanatic. I’m a huge fan of the podcast. Studies show that about 20 percent of IT spending creates no value. It’s like throwing a fifth of your IT budget out the window. This is a huge problem for startups who have limited funding, which is pretty much everyone. Reclaiming the lost value would allow startups to employ more people,” et cetera, et cetera.
[00:12:18] As you know, there are frameworks for coding and product development, like Bootstrap [?] startup, but there’s no framework for creating, communicating and managing business requirements. I see there’s a fundamental need in reclaiming the lost 20 percent. I’d love to hear any thoughts you have on what a business requirements framework should contain or take into account. I’d even be interested to hear if you think it isn’t needed.” So, what do you think?
Mike [00:12:37]: I think the first mistake here is assuming that startups and enterprise companies that have a full-blown IT department are the same, and that’s just a blatant falsehood. I don’t think that those two things are even remotely close to each other, so when you start looking at studies like this that come back and say 20 percent of IT spending creates no value, my inclination would be to believe that something like that comes from Gartner or Forester. Those are wildly different environments than a startup that’s got less than ten employees, for example. So, to try and equate them is just a nonstarter. There’s just no equivalence there.
[00:13:12] The other inclination I have is that when you’re looking at this type of spending, that 20 percent of IT spending is probably on technologies that are purchased because they are – either this person was sold on a dream of – some sales rep came in and said, “Hey, buy this software, and these particular problems will go away.” Or, they purchased a bunch of consulting, and the project was mismanaged, so all that money basically went out the window. Those are very, very common things that I’ve seen when I’ve been doing consulting, so those are the types of things that would factor into studies like this. I think that, honestly, this is just probably bad data. Maybe that’s a gross assumption on my part; but my guess is that, because it’s not applicable to startups, you can’t really draw a line of equivalency between them.
Rob [00:13:56]: Yeah, I would second that. I also think that, since the environments are so different, that this requirements framework that Nathan was asking about is much, much less applicable, if not totally inapplicable. It depends on what you mean by “startup,” but let’s just say it’s someone that’s less than 20 employees or a company that’s less than 30 employees. At that level, basically just a kanban process, where you’re writing stuff down on notecards and you’re sticking them up on a wall, or you’re using a Trello board, is a really good way to get requirements across; or, simply using an issue tracker. We use Codetree, which is over GitHub issues, and there has not been a single feature that we have released in Drip that has required more than a few paragraphs of discussion and description in our issue tracker.
[00:14:40] We don’t spec out these massive, waterfall projects like you do in IT, where you have these requirements that you have to manage, and you have this – you know, you used to have the 300-page spec doc. None of that is done in the startups that I know that are moving quickly. We release multiple features per week, sometimes multiple per day, and so each is individually specked out and is its own, little, tiny micro issue. So, for startups, honestly, I just don’t see the need. Maybe for enterprise IT there needs to be some framework, but I wouldn’t even be able to speak to that now. I’ve been out of that so long.
I hope that helps, Nathan. Thanks for sending in your question.
[00:15:12] Our next question is from Christopher Gimmer, and he says, “Hi, Mike and Rob. Huge fan of the show. I had a question about auto responders for freemium SaaS products. With a typical SaaS trial, you’re hoping to help users find value and convert to paid before the trial runs out. With a freemium product, there’s no time limit and not everyone will be interested in a paid version. Just wondering what kind of advice you would give on how to set up an auto responder for a freemium product. Would it be any different than a normal trial sequence?”
Mike [00:15:39] Yeah, I think that there’s a couple of different things that you can do – different approaches, I’ll say. The first approach is when you have somebody come into a funnel like that, are you trying to sell them directly on the higher-level version of the product, or are you just trying to get them in the door to start using it? I think the answer to that depends a little bit on how complicated your product is to get up and running for people and how valuable it becomes to them over time. Obviously, in a SaaS scenario, you want to be charging people on a recurring basis if the value of your product goes up over time. So, something like – to throw to an example here, bug tracking software, or anything where you’re aggregating data over a time period. Over time, hopefully, the users are sending more data into that system so that as they use it more and more, it becomes more valuable to them.
[00:16:27] Now, if you’re trying to get them to just use the product, then you probably want to get them onto a paid version, assuming that they’re a big enough customer that they’re going to be using it extensively. Or, if they’re on the smaller side, you just want to encourage them to use it in case they end up larger companies later on and be able to bring it in the door. In each of those situations, you’re going to do one of two things. You’re going to try to get them onto a paid plan first and then essentially back off if they end up going into the freemium plan for the product and then over time, try and pitch them on the benefits.
[00:17:00] I think that when you start seeing their usage of the product over time, you can check to see whether or not they’re going to run up against any of your internal barriers for that freemium product. So, let’s say that you’ve got BugTracker. You only allow them to track 100 bugs, for example; or, only manage two or three projects at a time; or, only have a certain number of users. When they get close to that user limit, you hit them with an email that says, “Hey, you’re getting close to this limit. Would you like to upgrade?” That’s a trick that came from Patrick McKinsey at one of the previous MicroConfs, but there’s lots of ways that you can monitor what their usage is and then perform specific, targeted emails to identify those people and try and get them to upgrade; but I don’t think that you want to beat them over the head with it every, single week. Then just on a rolling basis, maybe every three or six months, try and pitch them on the benefits of upgrading to a paid plan.
[00:17:49] What about you, Rob? What do you think?
Rob [00:17:50] Yeah, the sequence is worlds different than free trial. When you have a free trial that runs out, you have a time pressure there, and you are trying to get them on board before the end of that free trial. With a freemium product, like you said, you’re trying to get them to activate. That’s the first thing I’d focus on – is just hitting them up once, twice a week and saying, “Hey, you haven’t done this yet.” “Hey, you haven’t set that up,” because if they never do that, then they’re never going to use the product, and they’re never going to upgrade to free. So, you really want to get them to use the product, or get them to say, “Stop emailing me.” It’s kind of like that follow-up thing from Steli. If you’re getting this big traffic of freemium and no one’s activating, that’s a real problem, so the email should gently nudge them to do that. Then as their usage increases, touch base with them via these point-in-time emails based on actions or based on levels in their account. Then let them know that, “Hey, we do have these extra features,” or, “We have more that you can get by using our paid plan.”
[00:18:40] Just like you said, I’d probably pitch it more often than every three to six months. I would think about, say, every six weeks to three months. If you do have this free user base and you really do have something that’s much more valuable to them, I feel like it’s worth mentioning. And you don’t do it directly. Maybe every six weeks you don’t pitch them with this direct hard sales pitch. Maybe that is every three to six months, but in between there you want to touch base with them about new stuff you’re releasing and then have just a little pitch. You know, if you’re using marketing automation and you have tags, then you’ll know that they’re freemium, and you can actually put something different in there than if they’re an actual paying customer. In even a feature announcement email, you can basically include a paragraph only if they’re on the free plan and say, “Hey, this stuff’s only available to paying customers.”
Rob [00:19:20] Yeah, I definitely think this trial sequence is quite a bit different than freemium. You really just need to think through what their journey is and how different it is from a typical paid trial. I hope that helps, Christopher.
[00:19:33] Our next question is from Caesar, and he asks about when to show pricing. He says, “I’m struggling a bit about when should I show pricing on my marketing website. Should I do this right from the beta? Should I do it after the beta? Should I show the cheapest tier first and for the rest have people contact us? Should I start inviting testers even if they don’t know about pricing? I realize most of the answers will be ‘it depends,’ but it’d probably be interesting to hear your experience about it.”
Mike [00:19:59]: I think when you’re early on and you’re still trying to figure out what the value of the product that you’re billing is worth to people, it’s a lot harder to figure out what to charge people. One thing that you might want to try is essentially just asking those people who are early on, “What is this worth to your business?” “Is it going to cost you to not use this particular software?” That will help give you an idea of what the value proposition is going to be to them in terms of dollars for the product.
[00:20:27] Once you’ve done that, you can start showing that information, but I think that you need to start taking orders from people. It can just be maybe your first 20, or 30, or even 50 customers. Maybe every, single one of them pays something different; but if you don’t post the pricing, then you can have each one of them pay something completely different, and nobody’s going to know anyone – not unless they start talking to each other and say, “Hey, I’m only paying this,” or, “I’m paying that.” You want to figure out what it is that people are willing to pay for it, and why; because your feelings of what the value are of the product are probably going to be different than what your customers feel it’s worth. That’s a common theme among people in the startup world – is that they’re essentially undercharging for their products because they don’t understand the value that it provides to their customers.
[00:21:12] Then there’s also – the flipside of it is maybe you think that it’s worth a lot more than it is, and the only people who are going to be able to tell you that is the people who are cutting you a check. So, charging them different amounts for the first 50 or 100 people is probably fine. Maybe it’s only the first ten or 15 people, but if you can get an idea of what those prices are and talk through why those beta customers think that those prices are justified, then it gives you a better idea of what to put on your home page.
Rob [00:21:37]: Yeah. If you’re pre-launch and you’re still hand-holding folks into your app – at that point with Drip, we didn’t even have a marketing website. I don’t even think we had placeholder text. We were literally just getting people in. I had told them in an early email, “I think our pricing for this long-term is going to be between 49 and 99 a month for our lowest plan.” That was kind of the first thing we said, but I did let them know up front that we were going to be charging. This was not going to be some free-forever plan. So, if you’re still handholding, you have the luxury of being able to do that one on one.
[00:22:11] If you’re not and you’re starting to let larger groups in, I would be charging by that point. If you’re starting to let 100, 200, 500 people in, that’s the point where I know my pricing; or, at least I have an idea of it, and I’ve picked a price. Then I’m going to test it with that first group. I don’t believe betas should be free. I think beta testing is you’re building it. You’re doing unit testing. Then you do integration testing with everything together. Then you test the crap out of it with your own stuff, and then you get maybe ten people who you one-on-one handhold through the app, and you get them all set up. You’re going to have worked out a ton of stuff by that point, and from then on you’re done. Beta’s done. This is not something where you let 100 people use it for free until you decide on pricing.
[00:22:52] Maybe you give them a really long trial, if that’s what it takes. We were doing – if I recall, with our early beta testers, I didn’t know how long the trial would be at all, and some people got months and months to try it out; because we just didn’t know. We were trying to build features to make it valuable enough for them. Once we got out of that, it’s pretty much been a 21-day trial since day one. A few people have asked for extensions based on extenuating circumstances, but that’s it.
[00:23:15] Then in terms of the other part of this question, he asked if you should show pricing on the marketing site, or just show the cheapest tier and have “Contact Us.” If you’re selling to enterprise and you’re going to do the whole figure out how much people can spend and negotiate pricing, then, yeah, everything should be “Contact Us.” But if you are just selling a typical SaaS app or a downloadable app, I think you should have all your tiers up there and then a big enterprise tier that says, “Contact Us” for people who do want to spend a lot of money and get more. There’s always a need for someone who wants to spend $10,000 on your software, but aside from that, I don’t see a ton of value in trying to obfuscate your tiers or hide pricing from people.
So, thanks for the question, Caesar. I hope that was helpful.
[00:23:53] Our next question is from Jeff, and he asks about SaaS subscriptions versus commission pricing. He says, “Hi, guys. I’ve listened to a couple shows where you discuss SaaS pricing models, and I haven’t heard you mention commission-based pricing at all. We recently launched our SaaS offering, which is a marketplace platform around the wedding industry.”
[00:24:11] So, stepping in here, I think what he’s saying is they have kind of a two-sided marketplace where they have brides and grooms who are about to get married, and then they have providers. I would guess it’s like people who sell wedding cakes and flowers and maybe wedding planning services and venues and that kind of stuff. So, I wouldn’t actually call this really a SaaS offering as much as it’s just a wedding marketplace. Now back to his email.
[00:24:32] He says, “We’ve had great traffic to the site, but our conversion rates have been pretty low. Our packages include a percentage commission on sales, and I’m wondering if that is turning people off to the product. We’ve tried emailing our customers along with everyone that’s expressed interest, but we didn’t get much of a response. I’m curious to hear your thoughts on commission-based pricing for a marketplace site like this. My gut is telling me that it must not work in most instances since there doesn’t appear to be many SaaS offerings out there that are using this pricing model.”
Mike [00:24:59] If I understand this correctly, what he’s essentially saying is they have a marketplace platform for the wedding industry, and they have brides and grooms who’re getting married on one side of it and then the vendors on the other side. One of the two complaints, or issues, that they have is they’ve got a lot of traffic, but their conversion rates have been really low.
If you’re charging the vendors, but not the brides and grooms, then that would almost be expected; because the brides and grooms that are visiting the website are probably going to outnumber the vendors by a pretty wide margin. That’s going to drive your apparent conversion rate pretty far lower than it probably otherwise should be counted. You might have, let’s say, 10,000 brides and grooms who visit, but you only have 200 vendors that visit. Well –
Rob [00:25:43]: Right.
Mike [00:25:43]: – how do you know which 200 vendors there are versus the 10,000 people? And what number are you going to count it against?
Rob [00:25:48]: I would agree –
Mike [00:25:49]: So, I think that –
Rob [00:25:49]: – and I think we should clarify here he says, “We’ve had great traffic, but our conversion rate has been pretty low.” We’re making the assumption that he means that it’s the vendor conversion rate.
Mike [00:26:01]: Yeah, so that’s –
Rob [00:26:01]: And I’m not 100 percent sure.
Mike [00:26:03]: Yeah, I’m not either, so – that’s just a point for him to take home, though, is that might be an issue if that’s what he’s looking at and he’s just not thinking about that piece of that – that division between the two – as one issue.
[00:26:15] The other thing is that if you are charging the vendors and you’re charging them on a commission basis, essentially what you’re doing is – let’s say that somebody buys a $50,000 wedding package and you’re charging the vendor, let’s say, 5 percent, something like that. Well, that becomes a $2500 fee that that vendor has to pay versus if you have a static pricing tier for each of these things, then it would be, let’s say, $500 for them.
[00:26:42] Since you and I run MicroConf, one of the things that we really don’t like is having to deal with any sort of variable costs. It is a lot easier to run an event when you know exactly how many people are going to show up, because you know exactly what your budget is, and you can plan and anticipate things in advance. You can make decisions about what you’re going to spend and what you’re not going to spend. But if you’re a vendor, and you’re on this marketplace, and your costs are going to be variable, it makes it much more difficult to get a handle on some of that stuff. Quite frankly, there’s a lot to be said for just avoiding the hassle of even bothering.
[00:27:19] I would wonder whether or not a commission-based pricing structure is even the way to go here. Maybe it’s a flat fee on a per-event basis. That would be my thought; but, again, if you’re having a hard time seeking feedback from people and getting responses from them, then it seems to me like there’s a completely different problem that you actually have to tackle, which is why are you even not getting feedback from these people?
Rob [00:27:43]: Yeah. Let’s just be clear here. In no circumstance should you charge the consumers here, because they’re going to be super price-sensitive. It’s the vendors that you should be charging, so I think we’re just making the assumption that that’s going on. If not, then you should definitely do that. I can’t imagine at this stage charging a subscription fee to the vendors, because I can’t imagine a vendor that’s going to want to pay for a completely unproven solution. Maybe if you have millions of people coming and you have tons of money going through your system, you can move to subscription fees; but at this point, you’re probably going to need either a flat fee per event like Mike said, or a flat commission.
[00:28:18] I think a flat commission is fine. I probably wouldn’t call it a “commission,” though. I typically call it, like, a “transaction fee.” If you look at Gumroad, or another platform like this, that’s what they add on. If you’re going to pick 5 percent or 10 percent, that’s fine. Mike’s objection to it being variable, I think, is a valid one; and I think the way you could get around that is have a maximum. You could say it’s 5 or 10 percent, and it’s capped at 250 bucks, or 500 bucks – just a maximum somewhere. Maybe for different vendor types, it’s different amounts because, obviously, flowers might only be a few thousand and a venue might be more than that.
[00:28:51] To be honest, it doesn’t sound to me like this is the major issue, if you have all this in place. I would guess that there’s something else at play here, and that people aren’t engaged – or, that none of the people who visited were actually vendors and that everybody who came in was a consumer, and that’s why you got a lot of traffic and no one converted. So, this is a tricky one. There’s a lot to dig in here.
[00:29:11] I think, in general, my advice would be don’t try to bootstrap a marketplace; because they’re really, really hard. Even if you make this work and you start getting people signed up, making 5 or 10 percent on a fraction of these transactions, you have to be at scale to make any money at it. We just saw last week Gumroad laid off 90 percent of their employees. If you go to Tech [?] and search for it, you can see that even them, who – everybody in our space knows who they are, but they’re trying to take these tiny, tiny, little snippets of fees from these transactions; and it seems to me that they just couldn’t get enough volume, because unless you’re doing Uber-level, or Stripe-level volumes of transactions, then you’re not making any real money. You’re making thousands or tens of thousands a month, and that’s not enough to justify all the employees and all the support you need to handle a set like this.
[00:29:59] So, that’s our two cents. Hope that’s helpful, Jeff.
[00:30:01] Our last question for the day is from Ely Gescheit [phonetic], and he says, “I’m a big fan of the show. I’ve listened to you for the past couple years. My startup is focused on helping the building industry, such as town planners, architects, et cetera. However, the app could also be applied to the legal profession, because it essentially converts boring legislation into a more user-friendly format. There are around 600 town planners listed in Sydney, Australia, on Yellow Pages and around 10,000 lawyers. My initial idea was to focus the app on the building industry and later pivot to the legal profession. The idea behind this was to test the waters with a smaller target market. Given the app will be more scalable in the legal profession, I’m thinking of switching my strategy and focusing on legal first and then moving into building.”
[00:30:43] To me, the risk trying to target a smaller market is really high, and I’m not sure whether it will even be worth all the effort for just a small market. What are your thoughts?
Mike [00:30:51]: I think I’d be very hesitant to target either town planners or lawyers, regardless of the numbers. Essentially, when you start weighing these against each other – the numbers he throws out are 600 town planners versus 10,000 lawyers that he’s identified. With town planners, you’re going to be dealing with government paperwork and government budgets, and they’re going to be on strict timelines. They’re going to have to plan it in advance, and your sales cycle is probably going to be longer for most of them. That’s a blatant assumption, but you could just make some phone calls to five or ten town planners and ask what their purchasing process looks like and find out pretty quickly how long it’s going to take to onboard them as a customer based on however much it is that you’re going to be charging them.
[00:31:31] For the lawyers, I know people who have startups in the legal space, and it’s not always easy to get customers. Sometimes it is. Sometimes you can get to the right people very quickly and they are willing to talk to you as long as you are going to be providing a service to them that you can essentially pitch very quickly and that they can see a justifiable ROI on it; but you’re still probably going to do a lot of handholding, because those types of customers are probably not searching online for stuff. The legal profession is – in a way, they’re stuck in the ‘80s. They use fax machines for everything. They’re somewhat technology-averse, and you’re probably going to have to find a way to gather them as customers, and it’s not going to be through a lot of the things that we talk about on this podcast, like SEO and online marketing and things like that. You’re going to have to really go after them.
[00:32:19] With those things said, I don’t know if it actually makes a heck of a lot of difference which one you go after. What I would do is, if you’re still in this early stage, talk to ten, or 15, or 20 of them and test the waters a little bit and see which one of those two things is going to do better for you. Come up with a short list of identifying factors or traits that you would like to see and then ask those questions and find out if those are actually present in that particular market. If they’re not, maybe you kill the idea and move on to something else, or move over to the other market instead. Come up with a list of pros and cons for each of them, iterate through them and then see what the numbers come out; because it seems like you can get a lot of the information you need just by talking to ten or 15 people in each of those two industries.
Rob [00:33:03]: Yeah, I’m also pretty bearish on this idea, especially if it’s your first app. I would go for a smaller, easier win that you can market online. But if you really enjoy high-tech sales and you’re willing to do six-month sales cycles, and you’re building something that either of these niches would pay – let’s say $12,000 a year is probably the smallest annual contract value I would do when targeting these niches. I’m pulling that out of the air a little bit, but if you build something that’s 50 bucks a month or 99 bucks a month, you’re nuts to try to go after these markets. They’re just too hard to sell into when you’re getting started, especially if it’s your first time doing it. You don’t have any competitive advantage in these markets.
[00:33:42] So, all that to say I would think really hard if not all of those things are in place. If you’re thinking that you can set up a marketing side and drive SEO traffic and pay-per-click traffic and convert on an app that’s 20, 50, $100 a month, this does not sound like that idea.
Mike [00:33:59] Thanks for the question, Ely. Hope you found it helpful.
[00:34:01] If you have a question for us, you can call it in to our voicemail number at 1.888.801.9690, or you can email it to us at: questions@startupsfortherestofus.com. Our theme music is an excerpt from “We’re Outta Control” by MoOt, used under Creative Commons. Subscribe to us on iTunes by searching for “startups” and visit startupsfortherestofus.com for a full transcript of each episode.
[00:38:18] Thanks for listening, and we’ll see you next time.
