Ben Orenstein (@r00k) is the founder of Tuple, a remote pair programming app for the Mac that fills the void left by ScreenHero's disappearance. Ben joined the show for a second time to catch us up on Tuple's progress as a profitable pre-launch business. We talked about the benefits of creating a public roadmap that you can share with customers, the importance of learning by selling, Ben's gameplan for Tuple's public launch, and why it's important to focus on growth long before launch day.
Ben Orenstein, welcome back to the Indie Hackers podcast.
Thank you, it’s good to be here. I’m excited to do this new format thing.
Yeah, it’s just a more casual format, just us talking and catching up on what’s going on. When we last spoke, it was a few months ago in the podcast, you started a screen training app called Tuple last year and you had just hit the point of ramen profitability, about $20,000 a month in revenue. So, why don’t you let us know what’s new with your app Tuple?
Yeah, totally. So, I’ve been working on this app for a while. I have two co-founders. I had an interesting thing happen recently that I thought might be some good fodder for us to talk about which is sort of a story of how we ended up how we shipping this fairly large feature for us.
So, we’ve been developing this app for about a year and we launched in January and basically since launch people have been asking us for this one particular feature which is video support. So, Tuple is a pair programming app so we have screen share, so you share your desktop. And we have audio so you can talk but people were pretty frequently saying I really want to go and see the person that I’m pair programing with. That way I can sort of see if they’re actually following what I’m doing or if they’re really bored and they need a break or they just checked out or they’re angry or whatever. There’s just so much detail in the human face and they wanted to be able to see each other.
And we’ve had customers tell us I’m using a second app to do a video call at the same time as I’m using Tuple and it’s kind of annoying. It would be great if I could just use Tuple to do all of this.
It’s always been in our vision for the product. We always wanted to ship this but it really intimidated us. We were scared about the UX of how it should work and also the technical complexity of just implementing real-time video streaming on top of our app.
So, for a long time we put it off and there was an interesting turning point that happened recently which was yet another person emailed saying hey, I would love video support and I kind of gave him my, by now, standard spiel. Yeah, I totally agree. I think it’s a great idea. We’re just a little bit worried about the complexities so it’s hard to prioritize.
And he shared a story and this person was a start-up founder himself and he said in the early days of my company there was this one feature that everyone was always asking for and it intimidated me. But eventually, I just decided to sit down and roll up my sleeves and actually get this thing done.
It took a few weeks, but eventually I was able to ship something that I was proud of and that was the turning point for our company where we went from kind of a side project to a really useful, solving real business problems kind of company that really has achieved product market fit. And that was a major milestone for them.
So, I read that message and I took it to heart. I got kind of inspired. It really resonated with me. So, I said alright, we’ve got to do this thing. So, I made a plan and I think the plan and what we did might be useful for other people that are dealing with something similar.
Cool, let’s hear it.
I have two co-founders and we’re all technical, we’re all developers but one of us was on vacation so my second co-founder, Spencer, has been doing a lot of the product development.
So, I sat down with Spenser and I was like, hey, I think we should try to do this now. I think it’s time for video. And at first, he was like definitely resistant. He was the one who would have to write all the code and having been in that position, too, you’re just picturing all these difficulties. Your picturing all the edge cases and the challenges and it feels big and overwhelming. So, he was kind of against it.
And what I eventually pitched him on was alright, let’s spend one week on this and we’ll just get a sense of how big this might be. So, if we spend a week and it looks like okay, this is actually a 10-week project okay, maybe we reevaluate it and step back from that. But let’s at least make our decision based on some real data and not just how it makes us feel when we consider shipping this feature.
Code’s weird like that where sometimes you have to dip your toe in the water to just figure out what you’re dealing with. You can’t just predict straight out of the gate, oh, this is going to take exactly one week or this is going to take exactly one month.
You don’t know.
Absolutely. And yeah, and so I think this approach is kind of good in general and this is something I picked up at my days working at a consultancy is we would try to do these sort of minimal efforts in order to find information because we’ve never found a way where you can learn as much as actually trying to implement the feature.
And then you bump into the things, then you start to get a sense of okay, here’s what this work might look like and what actually might be left to complete this feature.
Yeah, my favorite analogy for this is imagine you’re charting your course on a map. From a zoomed-out point of view you’re going to see point A and point B and you’re probably going to draw a straight line between the two but then when you actually start out on your trek, you run into all these obstacles.
You’ve got mountains and rivers and valleys and forests that you can’t really see when you’re zoomed out. So, your straight line turns into a very squiggly line. And so, if you don’t really know the terrain for something in detail, you’re probably always going to underestimate how long it takes to get done.
Mm-hmm. Yes, absolutely. This pitch is what actually got the ball rolling. This sort of made Spencer feel good enough about it where it’s like okay, worst case scenario, we’ll burn a week on this and determine that it’s actually a huge feature and we’ll have lost a week and that will be too bad – or sort of more or less lost the week – but that’s okay. We’re willing to place a bet on this and see how it goes.
So, we spent the week and during that week, two things happened. So, first of all, Spencer went off – and the mission was just kind of determine the technical feasibility and complexability of this. So, it wasn’t like try to ship the perfect, full version of this, because we know exactly what it should look like. It was more like see how hard this is going to be which is a much more tractable problem.
And while he was doing that, I actually stepped back and started writing up a design document about how I thought the user experience should work for this feature. That parallel effort, I think, was really useful, particularly in this case because there wasn’t just technical complexity, there was UX complexity.
And the nice thing that happened is after a day or two, Spencer said, actually, you know, this is not as bad as I thought it was going to be. I think the basics are fairly straightforward and I had written up a UX document and then shared it with several of our customers and iterated on that and gotten feedback and I felt like I had a pretty good description of how this should work, So, we kind of actually, after just a few days, had both pieces in place that then made future progress really easy.
I like how you gave yourself permission to fail. You kind of scoped it to a week so worst possible case scenario, this feature really sucks. It’s just as hairy as you thought and you wasted one week of time investigating it and decided not to do it.
I think when you frame it like that, it’s suddenly not as scary as it used to be, this hairy feature that you didn’t really want to start suddenly feels easier to start.
Totally. I just started to read, Ace Camp’s [ph] book, “Shape Up” which I think is really useful. It’s about their product development approach and they talk about these six-week things and they call them bets. They’re not really – they don’t call them sprints because that’s sort of a metaphor that I love but it’s like we’re putting a bet that this is a useful thing to try to add to the product and that it will turn out well if we do it.
That was how I was thinking about that one week where it’s actually not a huge bet. One week is not a huge deal. You might take a week of vacation and not really worry about it. But there’s a sort of asymmetric upside there where it’s like because this has been asked for for so much, this could really improve our product market fit, make our customers even happier.
Yeah, let’s talk about feature requests from customers because I’m sure you guys get all sorts of requests from customers at Tuple. How do you decide which requests to listen to and which ones to put on hold or just flat out say no to?
I don’t know that I have a concrete system for this. I’m kind of doing it by intuition and feel. I guess my rough rule is kind of we should have a vision of how the product – of what kind of product we want to build and work on. Like what kind of company and lifestyle and all that.
So that should inform what we actually end up building. I don’t know – I was actually just asking my co-host – my podcast co-host – the other day is like do you think it’s ever the case that you could get a request for a thing in the product thousands of times, hundreds of times and ignore it and be right?
And I’m not totally sure what the answer is there. I think if you care a lot about building exactly the kind of product that you think should exist, it could be the case that you’ve made a very intentional disciplined decision that like, look, we will never support feature X because we think it’s a bad idea.
So, even if people ask you for this all the time, you might be right. You might be very justified in ignoring that. I would default in general towards listening to the customers and hearing what they want but I think it’s not a – I don’t think there’s a very clear 100% answer here.
Yeah, I got a lot of feedback with Indie Hackers and I found that it’s way more concentrated and consistent when I’m doing something wrong. So, earlier this year, I introduced a bunch of UX changes that weren’t very popular to say the least. And I heard a steady drumbeat of the same exact feedback day after day, week after week.
Whereas, when things are going right, the feedback is all over the place. It’s totally scatter shot and that’s kind of where your judgment has to come into play because you’re like okay, well, what am I going to actually build? How do I prioritize what to build? And also, your users probably aren’t product designers. They can tell you what their pain points are. They can tell you what’s annoying them. But unless the solution is really obvious, they’re probably not going to tell you the exact best solution to build. So, I’m just kind of curious how you handle those situations where user feedback is ambiguous.
Yeah, I kind of just feel it out as I go. I don’t think I’m an amazing product manager yet so I’m kind of just going off a lot of intuitions and seeing what I think.
I think maybe one thing that’s helping us lately – or from the beginning really – is that we chose a niche early on so we didn’t want to make generic screen sharing or generic video chat or anything. We wanted to make a really good pair programming tool.
So, when feature requests come in, sometimes they don’t make sense given that niching. Sometimes people will say, oh, I would love to do a video chat with 10 people so we could do our standups on Tuple. And it’s like oh, yeah, I could see why you would want that. It’s kind of nice to have just one communication tool but it doesn’t match the niche that we’re trying to serve really well right now.
Maybe one day we expand outside that niche, but for now having that kind of positioning has helped us determine whether future requests make sense.
Totally. You’ve got to know what you’re about. You’ve got to know sort of the fundamentals behind your strategy, what direction you’re headed in, what direction you’re not headed in, in order to sort through these requests and figure out which ones actually align with you.
Yes. So, one other thing that I found useful when people ask for things is to have a public road map. So, we have a road map link that we send people to and it shows what we finished building recently and what we plan on shipping in the next couple months and then some smaller things that we hope to just kind of fit in around the edges.
And that has been really useful. I think a lot of the times, people send requests and we want to make sure they feel heard and they understand that we have a plan and where their idea might fit into our plan. So, being able to share that like video was on there for a while. People would say, oh, we really want video. And we’d say, yeah, we totally agree. Hey, check it out. It’s on the road map. We’re going to build this. We hear you and your thing has been prioritized.
Super smart. Because I find myself telling people the same things over and over again. Oh, yeah, that feature is coming. It will be here in a few months. But if I just had a link posted up somewhere then people could check that instead of emailing me.
Yeah. I think it makes it more real because I think the default customer support request is like yes, thank you for that idea. That’s very good. We’ll consider that. And I think everyone kind of knows that means like your chance of that actually happening is kind of low-ish or is not worth betting on. Whereas, if we say hey, look, we put this on the public page. We wrote it down. We mean it for real.
You know, I find myself saying no a lot, too. People get a lot of nos. I’m probably never going to build a mobile app for Indie Hackers. It’s just not on a road map.
Yeah, but in that case, I think when you’re saying no, that a road map can also be useful where it’s like no, I don’t plan on doing that but if you are curious about the other stuff, check this out. Because someone might be just like oh, well, I wanted that but the fact that I can see other cool stuff coming, I’m still excited about using this.
Yeah, you know what? I think you’ve convinced me. I’m going to try this out for Indie Hackers at some point. We’ll see. I don’t know what’s on my feature road map to create a feature road map.
Let’s switch gears for a second. Let’s talk about your launch. You mentioned that Tuple launched back in January but that wasn’t really a real launch. That was just you guys onboarding your first customers off your email list. Nobody could just go to your website and create a Tuple account to download the app.
That’s all going to change soon. This month, in August, you’re doing a real launch. You’re opening your doors to everybody. Tell me a little bit about that, what you hope to accomplish?
Yeah, thank you for clarifying that. Making sure the distinction is there. Yeah, so, in January, we launched – it was a private launch. It was an alpha actually. And we launched to people that had already pre-paid for the app.
So, while we were building it, I was off selling it and then in January we launched about 10 teams who had pre-paid for access. And since then, we’ve been in early access so we’ve been inviting people and cohorts and letting them come in. But you still can’t go to the website and sign up. You have to be invited.
But that is changing in August. The exact date TBD, hopefully we’ll know soon. So, the distinction is the new launch will be that you can just go to the website. You can just sign up. There will be pricing there. It will be public. You don’t have to talk to us. We feel good enough about our self-service sign-up and onboarding and all that to let people just come in.
I really love the way you guys have done things because a lot of people visualize launch as this singular moment in time where before that no one has ever heard of what you’re doing. No one’s seen it, no one’s touched it but then you launch and that’s sort of your initial unveiling to the world.
Whereas, at Tuple, you guys have been working on this app for well over a year now and you already have paying customers. In fact, you already have like $20,000 in month recurring revenue. More than that now. So, you already know the app works. You already know that people find it valuable enough to pay for it. As we just discussed, you’re already talking to your customers and implementing missing features.
There’s not a huge question mark in your mind about how this is going to do. Right? You’re not in the dark about how people are going to react. You prepared for this moment of a year and now you can go into your launch confident that people are going to like it and find it useful.
Yeah, that was always the plan for us. That was the kind of company we wanted to build. The kind of posture we wanted to have was we wanted this self-funded so that there was no outside pressure to move faster or hit certain targets that we weren’t in control of.
So, we wanted to invest a substantial amount of time where access to the product was limited so that we could iron out the issues. I didn’t want to have thousands of people try it and find it wanting. I wanted to control access quite a bit and we’ve steadily been loosening it but it was useful early on to have that confidence that like okay, if everyone hates this for some reason, it will only be like 20 people or 30 people. And that way we can fix it and iterate and make it better before the wide world gets exposure to it.
And that’s been like very calming for us. And it does – it is interesting because it changes the nature of this public launch that’s coming up. I’m not expecting it to be an enormous launch. I’m hoping to have a nice sort of bottom line benefit from it at the end of the day and I have some ideas for kind of goosing it a little bit.
But it’s not going to be like okay, this launch kind of makes or breaks us or it’s going to have a huge impact on our financials and we need to have a certain number show up or something like that. And that actually makes it feel better. I don’t feel like we have a big – there’s not a big risk on this.
I love that. I feel kind of the same way. I don’t like having some big, flashy launch. I don’t like putting all my eggs in one basket and having this one huge day where it has to go right and if it fails, my entire business is screwed and I’m sweating bullets the whole time up to launch. It just seems stressful. It doesn’t seem fun.
I’ve much rather have a launch that’s just kind of one day among others. You know, one of numerous things I’m doing to grow my business and I’m not worrying I have to check every single box to have the absolutely perfect textbook launch.
Right. Yeah. And say something terrible happens, the app goes down or one of our providers happens to have down time or something. It’s just like – if we had bet everything on one day, that would be particularly horrific, I think.
Yep. So, what’s your launch plan here? Do you guys have any particular strategy? Are you going to put it up on Hacker News or Product Hunt?
I think we will probably put it on all those things. One thing that has worked well for us in the past has been recruiting our existing, happy customers to sort of act as advocates for us.
So not too long ago, Slack announced that they were removing remote control from their Slack Calls product. This announcement went out and I actually emailed our customers and said, hey, I think there are going to be a lot of companies who all of a sudden, are going to be looking for a solution for this. If you wouldn’t mind popping onto Twitter and just sharing your experiences with the app and whether or not you like it, that would be really helpful.
And a lot of people did and there was just this kind of huge wave of our customers singing our praises at the exact same time that a bunch of people were mad at Slack and looking for a new answer there. That was probably our best sign-up day yet was when that happened.
Yeah, you’ve built up a lot of goodwill with your customers.
Yeah, exactly. After building that bank account up for a little while, you can occasionally draw against it. So, I think we’ll probably have some element of that in our launch. I wouldn’t say I’m that good at launches so I kind of need to do some research and talk to people who are great at this, like generating more buzz.
One thing I think we will do is we have been – up until today or actually up through including today – we charge for trials. So, we are of a thing where it’s $100 for your first month to use Tuple regardless of team size.
And that is a friction point – kind of an intentional friction point – where we want customers who are serious. Who have already gone through the purchasing process, can put down a real corporate credit card that we can just charge later, things like that. And that has been useful and has helped us control that growth which I’ve been talking about.
But I think for launch, to kind of give it a little extra – put a little extra gas on the fire – we have some ideas around a special kind of launch discount during that window.
Cool. Besides opening the doors to everybody obviously and making Tuple just publicly available, is there any other thing you want to test of accomplish by launching?
So there’s this funny thing that we kind of can’t shake which is people assume if they can’t sign up for it, it’s in beta and it’s not very good. I keep running into this objection where like we’ll send somebody an invite and they’ll be like you want me to pay for beta software? And I’m like well we’re not in beta. We have hundreds of customers. This has been live for months now. And they’re like, yeah, but I can’t sign up for it. It’s in beta.
So, I kind of can’t shake that thing. So, one thing that I’m kind of just hoping will be like okay, once there’s public pricing, once you can actually sign up for it, it will feel to the more risk averse people like this is a real product I can trust more.
Yes. So, this is the good thing about doing sales because you’re actually talking to people. So, when they tell you they’re not going to buy, you actually learn what that reason is. Whereas, most people who aren’t talking to every customer, they have no idea. They’re just like yeah, 100 people showed up to my website to day but nobody signed up. I wonder why? And they’ll never know.
Totally. Yeah, I’ve tried to more or less engineer a lot of trip wires, a lot of places where people can give us feedback. Like we have [unintelligible 00:18:16] feedback and we have website feedback. And we send product market fit survey questions and we just have a lot of opportunities for people to ask us things or tell us things.
I’ve found that to be very useful. I like to make sure that I have – as we’ve made our sales process, our onboarding process more automatic, I’ve tried to make sure it doesn’t get too automatic. There’s still a steady stream of feedback coming from new and existing customers and that we’re paying attention to.
Because I think that’s where you start to really fall apart. When people say nice things about us, it’s often that we’re so responsive. So, the fact that we’re paying attention to our current customers is making the product better but it’s also getting us new customers. So, even though it’s time consuming, and hard, it feels like something that’s important for the health of the business.
So what’s in these product market surveys that you’re sending out? Is it just the super human questions like how disappointed would you be if you could no longer use Tuple? That whole set of questions?
Yeah, it is currently like that. How disappointed would you be if it went away? What value do you get out of it and what could we improve about the product for you? Which has been super useful. Let’s just go to all three of us, the co-founders and so it’s nice to have that steady drip of those that just goes out automatically after you’ve been a user for a week or something like that.
But I also will occasionally just email and say what’s the one thing we could do to improve the product for you? No survey, just reply to this email. Keep it really, really frictionless. Last time I did that we got a ton of feedback and that really helped us set the road map for the next couple months.
I like that. Just like what’s the one thing. People don’t like long surveys. People don’t want to answer 100 questions but it makes sense that if you ask just one question, response rates will go up.
Definitely. Yeah, and the completion rate on that survey that we send out – the product market fit one – I think it’s only four questions and still like the completion rate is like 50% or 40% or something. So, a lot of people just get there and it’s like nope, never mind. I’m not doing this versus the email one got tons and tons. People are still responding to that email that I sent. It’s like two months old now but they’re still coming in.
Yeah. I send out surveys for Indie Hackers. The first one gets sent a day or two after you join and then I send another one 60 days after you join. That one hasn’t gone out to anyone yet because I set it up less than 60 days ago but my first survey – I’m looking at it right now – the average time to completion is 12 and a half minutes. The completion rate is 83% which is super high.
And it’s got like seven questions on there but I feel bad looking at it because in the email I’m like oh, yeah, this will only take three or four minutes. But apparently it takes 12.
I was surprised at that. So, our four question has a completion time of like five and a half minutes and I would have guessed it would be like one minute, but I guess not.
People take their time. They’re thoughtful.
Yep. Appreciate it.
Let’s talk about your podcast. You briefly mentioned it earlier. It’s called “The Art of Product”. It’s you and Derek Reimer just kind of riffing off each other. You’re both talking about what you’re working on. I joined as a listener about 15 episodes ago which was right when Derek’s business sort of imploded.
It’s when he decided to wind it down and stop working on it and it’s a pretty interesting show now. It’s this very stark dichotomy where on one hand there’s you and you’re talking about Tuple and all the great things that are going on, all these fortuitous events that are happening to you and it just seems like this non-stop upward trajectory.
And then every week Derek comes in and he’s in limbo. He’s just trying to figure out what he’s going to work on and he’s sort of in the dumps about it. And, I don’t know, I don’t really have any questions about the podcast. It’s just interesting to listen to. So, I recommend people listening to this. Go check it out. How do you feel about the podcast, Ben? How’s it going?
It’s going great. Yeah, it’s one of my favorite things to do. It doesn’t feel like work at all. I mean granted we’ve outsourced the editing and the publishing and all that, so it actually is very little work. But I’ve hosted a weekly podcast for six or seven years now, straight. And I just really love it. I find it super fun. It doesn’t feel hard to me.
I was talking to Paul Jarvis who does a weekly newsletter and has done so for – he’s got like a thousand of them or something and I’m like how do you stick with that? He’s like oh, it just doesn’t feel like work for me. I was like oh, I guess that’s just podcasting for me. There’s something that doesn’t feel like work for a lot of people and this is it for me. So, I love it.
That thing you talked about is an interesting dynamic now. I guess it’s kind of the – it’s the other side of the sword – of the double-edged sword – of working in public. So, because Derek and I are sharing our journey live, we’ve been able to get a lot of interest and early customers for the products that we’re building. So, it’s been super helpful and often customers will sign up for Tuple and they’re like oh – they’ll ask me about something but they’ll say, by the way, I listen to “The Art of the Product” so I know that you’re thinking of this, this and this. They already have all this context which is just wonderful and they feel sort of bought into the success which is tremendous. I love that.
Because Derek is now kind of between things and is figuring out his next thing, there’s this sort of unfortunate pressure where it’s like we’re trying to make good radio. Right? I’m working on a thing and the thing is working pretty well. So, it’s like he feels this outside force to be like, alright, figure out the next thing. When in reality he just sort of wrapped up his last effort. So, it’s probably good to explore really widely right now and not to get too invested into any one thing and not plant any flags.
But it’s hard to show up for the recording if you’re like yeah, I’m still thinking about stuff or I put up a landing page for this or I’m experimenting with that. So, it’s a bit of a tricky situation.
Yeah, I totally understand. I bet the pressure is immense for him but as awful as it sounds, as a listener, I kind of like it. I like the fact that it’s real. I like the juxtaposition between the two places where you guys are. It’s not just like oh, everything I touch turns to gold instantly. It’s more like it’s hard to figure out what to work on and this is a window into what that’s like.
I think hearing somebody’s struggle while knowing that he’s obviously talented, knowing that he’s had some major successes in the past makes it a little bit more okay for the rest of us to feel like we’re not the only ones struggling to figure this stuff out.
Absolutely and that was one of the core – I would say that’s one of our core philosophies of the podcast and it has been since the beginning is that we’re going to share everything. All of the good stuff and the bad stuff.
We think partly because we can normalize failing and struggling and rough mental health days and bad stretches and disappointment and fear and all that. I’ve gotten email from people thanking us for that and that openness. So that’s something that we fully intend to continue.
I just launched a new feature on Indie Hackers. When I say launched, I should just say I added a new feature to Indie Hackers. It’s a groups feature. And right now, there’s just one group. It’s super minimal. It’s a podcasters group. I actually invited you to it, Ben.
The purpose of this particular group is just to give podcasters a place to talk shop and connect with other podcasters and people making a living from their podcast. But I’ve got a whole bunch of different other groups I want to launch and hopefully, by the time this episode is out, a few of them will be up and running.
But I’m spending a lot of time trying to grow this group’s feature. And it’s tough because it’s like growing a community from scratch. None of these groups have any users. I kind of have to kick start them somehow. And it makes me think about where you are with Tuple.
You’ve got a huge email list that you’ve been working through for the least six or eight months or whatever and just sending out invites to people. But you’re going to launch this month. Tuple’s going to be open and then you’re going to be kind of in the wild where I am where you have to grow. You’re email list is exhausted. You’ve got to figure out other ways to bring users in the door. What’s your plan for that right now?
Fear, panic. I don’t really have a plan exactly. I have – I would say I have high-level plans. I have more or less made my living and my reputation teaching developers things, like making really good programming/tech related content.
So – and I think I’m good at it. I think I’m a good teacher and so I feel pretty confident that I could do that pretty well. So, I think that’s probably going to be the core of our future marketing strategy will be write and create interesting, high-quality things that programmers will find interesting. And hopefully, then will then find their way into Tuple as a customer at some point.
Yeah, and the cool thing is you guys are self-funded. You don’t have any investors whatsoever breathing down your neck, telling you grow faster. And so, it’s kind of okay if you try something and it works out well, that’s great. And if it doesn’t, then that’s fine too. No pressure. Just go on to the next.
Yeah and we’re fortunate enough that our revenue is covering the business expenses plus all of ours. We’re sustainable and so growth is great and we want to and we would love to have at least a part-time designer and things like that. So, we’d love to keep growing so we will try to. But it’s not urgent. It’s not like it was before where it’s like okay, if we don’t keep growing revenue, this company will die eventually.
What’s the price point for Tuple? Is it high enough that you guys can do direct sales profitably?
It is high enough that we can do direct sales I would say. So, we have sort of a standard monthly price that we charge for people but often people will reach out to us and say, hey, we have a bunch of developers and we think our use case is kind of special because of x, y, z.
So, I actually do sales and sort of negotiate one-off deals with a lot of people and the numbers are in the $5,000 to $10,000 a year kind of range for larger teams. This is not the average price but for big teams. So, I would say that starts to be the point where you could have someone profitably doing that. It certainly makes sense for me to do that. So, we’ll see. We can eventually have a sale person possibly. I’m not sure.
Oh, wow. Yeah, I was talking to Sahil Lavingia from Gumroad about this. They grew Gumroad for about four or five years off the back of direct sales. They have a sales team and I presume they are just talking to people, maybe emailing them or calling them up or something and trying to convince them to use Gumroad. That’s a pattern I’ve seen with a lot of successful founders so I’m always curious who’s planning to use it, who’s not and why.
Totally, yeah. I mean it does strike me that there’s a lot of people making content for developers out there. So, I can kind of try to compete with those folks for attention and all that and I think I could compete okay but it’s sort of crowded.
Whereas, maybe you just want to go find people that you think would be good customers and go talk to them as opposed to kind of passively hoping they figure out you exist after consuming some of the stuff you’ve made.
Yeah. I mean I brought this up earlier but the other good thing about sales is that you get feedback. I’m doing this for the podcasters group and the other groups in Indie Hackers as well. I’m just reaching out and inviting people to join individually and trying to get them participating and it’s not going to last forever. But even if I only do this for a month or two or three, it’s going to be a pretty good learning experience. I’m going to figure out a lot of stuff from those conversations.
Mm-hmm. Totally. Yeah, Nathan Berry has a great post on doing direct sales as a bootstrapped start-up. I think it like lays all this out nicely including that point which is you’re getting feedback. Just by doing – I would say, probably 90% of our customers do self-service sign-up but the 10% that I am talking to are providing a lot of information.
I’m talking to someone right now and he said okay – we sort of went through some of the sales process and came up with some pricing and some thoughts and he said, okay, we’re going to spend the next two weeks switching off between Zoom and Tuple every day for pairing. Would you want to hear the results of that test?
And I was like uh, yeah, obviously. That would be great. So, it’s like someone is basically doing real competitor analysis in real world use case. It’s very possible we’ll lose that deal for various reasons but I think we will learn a ton from it because I’m actually in touch with this person, I actually will get that feedback and here is where we fell down compared to a competitor, or here’s where we were better and here’s what ultimately made the difference or was the decision.
Very cool. Well, it’s been half an hour. This is supposed to be a quick chat but we could probably talk all day at this rate. So, why don’t we wrap it here? Ben, thank you so much for coming on the show and letting us know what you’re up to.
Can you tell listeners where they can go to learn more about Tuple and maybe learn about your launch when it happens?
Sure. If you are looking for a pair programmer app, chances are you’re going to be hearing this right around when we’re launching or possibly after. So, tuple.app – T-U-P-L-E – is our website. That’s the best place to go for that. If you’re interested in the podcast that Courtland mentioned earlier, that’s called “The Art of Product,” artofproductpodcast.com and I’m r00k on Twitter if you need some hot takes.
Alright, thanks so much, Ben.
My pleasure. Thanks for having me on.
Quick note for listeners. If you’re interested in coming onto the podcast like Reilly, to have a quick chat with me, go to indiehackers.com/milestones and post a milestone about what you’re working on.
It can be pretty much anything. People have posted about launching or finding their first customer. They’ve posted about growing their mailing list or hitting 1,000 followers on Twitter. They’ve posted about getting to $100 or $1,000 or even $100,000 a month in revenue. The sky’s really the limit here.
So, whatever you’re proud of, come celebrate it on indiehackers.com/milestones. Other Indie Hackers will help you celebrate. We love supporting each other. We love encouraging each other when we hit these milestones and what I will do is at the end of every week, I will look at the top milestones posted and reach out to people to invite them to come onto the podcast for a quick chat.
So, once again, that’s indiehackers.com/milestones. I’m looking forward to seeing what you post.
Did you know the Indie Hackers podcast has a newsletter?
Sign up to get insights, takeaways, and exclusive content from each new episosde, directly from the host, Courtland Allen.