Ben Orenstein, welcome back to the ND Hackers podcast.
Thank you. It's good to be here. I'm excited to do this new format thing.
Yeah, just a more casual format, just as talking and catching up on what's going on.
When we last spoke, it was a few months ago on the podcast, you started a
screen sharing app called Tupel last year, and you 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 Tupel?
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 the story of how we ended up
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 Tupel is a pair programming app. And 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 be able to see the person that I'm
pair programming with. And that way I can sort of see if they're actually
following what I'm doing or if they're early bored and they need a break or if
they're just checked out or they're angry or whatever. There's just so much
detail in the human face and they want to be able to see each other.
And we've had customers tell us, yo, I'm using a second app to do a video call
at the same time as I'm using Tupel. And it's kind of annoying. It'd be great
if I could just use Tupel to do all 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 is yet another person emailed saying, hey, I
would love video support. And I kind of gave him my by now standard spiel,
which is like, yeah, totally agree. I think it's a great idea. We're just a
little bit worried about the complexity. So it was hard to prioritize.
And he shared a story. And this person was a startup 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.
And 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 like
a major milestone for them. And so I read that message. And I took it to heart.
I got kind of inspired. It really resonated with me. And so I said,
all right, we got to do this thing. And so I made a plan. And I think the plan
and what we did maybe 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 I said, so my second co-founder, Spencer, has been
doing a lot of the product development. And so I sat down with Spencer. 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 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. You're picturing all the edge cases and the challenges. And
it feels big and overwhelming. And so he was kind of against it. And what I
eventually pitched him on was, all right, 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 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. Or 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 so I think this approach is kind of good in general. And this is
something I picked up from my days working at a consultancy, is we would try to do
these 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. And 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 a course on a map.
From a zoomed out point of view, you're just 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 track, 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. And 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 made Spencer feel good enough about it where it's like, okay, look,
worst case scenario, we'll burn a week on this and determine that it's actually
a huge feature. And we'll have lost the week and that'll 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 complexity 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 just 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, no, 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. And 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've 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. And I think when you frame it like that, it's suddenly
not as scary as it used to be. And this big hairy feature that you didn't really
want to start, suddenly it feels easier to start.
Totally. I've just started to read Basecamp's book, Shape Up, which I think is
really useful. It's about their product development approach. And they talk about
these 6-week things. And they call them bets. They're not really... They don't
call them sprints because that's sort of a metaphor they don't 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. And that was how I was thinking about
that 1-week bet where it's actually not a huge bet. It's like 1 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 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 know? How do you
decide which request 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 we should have a vision of how the
product... Of what kind of product we want to build and work on and what kind of
lifestyle we want to have 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, 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
we will never support feature X because we think it's a bad idea. And 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 giving them what they want. But I think it's not a... I don't
think there's a very clear 100% answer here.
Yeah. I get 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 heard 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 scattershot. And that's kind of what 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
work. Yeah, just curious how you handle those situations where user feedback is
ambiguous.
Yeah. I'm just feeling it out as I go. I don't think I'm an amazing product
manager yet. So I'm 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 want to make a really good
communication tool. And 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 can 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. And maybe one day we expand outside that niche. But for
now, having that kind of positioning has helped us determine whether feature
requests make sense.
Totally. You got to know what you're about. You 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 think I found useful when people ask for things
is to have a public roadmap. So we have a roadmap link that we send people to.
And it shows what we finished building recently and what we plan on shipping
in the next couple of months, and then some smaller things that we hope to just
put on the edges. And that has been really useful. I think a lot of 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. And so being
able to share that video was on there for a while. People would say,
oh, we really want video. And we'd say, yes, we totally agree. Hey, check it out.
It's on the roadmap. 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's coming. It'll be here in a few months.
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 whereas not worth betting on.
Whereas if we say, hey, look, we put this on a public page, we wrote it down.
We mean it for real.
I find myself saying no a lot too. People get a lot of no's. I'm probably
never going to build a mobile app for ND hackers. It's just not on the roadmap.
Yeah. But in that case, I think when you're saying no, the roadmap 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 just be
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 ND hackers at some point. We'll see. I don't know when it's on my feature
roadmap to create a feature roadmap. But 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
and what you hope to accomplish.
Yeah. Thank you for clarifying that and 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 prepaid 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 prepaid for access. And since then, we've
been in early access. So we've been inviting people in 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. Exact date TBD, hopefully
we'll know soon. And so we want to have... The distinction is the new launch
will be like, you can just go to the website. You can just sign up. There'll
be pricing there. That'll be public. You don't have to talk to us. We feel
good enough about our self-serve. 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 the singular moment in time where before that, no one's
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 with 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 monthly 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.
You're not in the dark about how people are going to react. You prepared
for this moment for 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. And that was the kind of company
we wanted to build, the kind of posture we wanted to have was we wanted
to self-fund it so that there was no outside pressure to move faster or hit
certain targets that we weren't in control of. And 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.
We've steadily been loosing it, but it was useful early on to have that
confidence that like, okay, if everyone hates this for some reason, it'll
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.
Yeah. And that's been very calming for us. And 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 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 didn't seem fun. Yes. I'd much rather have a launch that's just kind of
one day among others. 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. I like say something
terrible happens. The app goes down or one of our providers happens to
have downtime or something. It's just like, if we had met 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'll probably put
it in 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 hopping on 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 deal. There's just
this kind of huge wave of our customers singing our praises at the exact
same time that a bunch of people were like mad at Slack and looking for
a new answer there. And that was probably our best sign up day yet was
when that happened. Yeah. You built up a lot of good will with your
customers. Yeah, exactly. After building that bank account up for a little
bit, you can occasionally draw against it. And so probably, I think we'll
probably have some element of that in our launch. I wouldn't say I'm not
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 have a thing where it's $100 for your first
month to use tuple regardless of team size. And that is a friction point,
like 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 a little, pour 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 or accomplish by launching?
So this is one 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 we'll send somebody an invite and
they'll be like, you want me to pay for beta software? And I'd be 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. And 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 today, 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 tripwires,
a lot of places where people can give us feedback. We have in-app
feedback and 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. And I 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 in 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.
And 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.
What's in these product market fit surveys that you're sending out?
Is it just the superhuman questions?
How disappointed would you be if you can no longer use Tuple?
That whole set of questions?
Yeah, it is currently like that. It's like, how disappointed would you be
if it went away? And then what value do you get out of it?
And what can 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.
So occasionally just email everybody and say,
what's the one thing we could do to improve the product for you?
And that's like, 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 roadmap 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,
and it's 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, nevermind. I'm not doing this.
Versus the email one got tons and tons of...
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 any hackers.
The first one gets sent a day or two after you join.
And then I send another one 60 days after you join.
And that one hasn't gone out to anybody 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.
Wow. 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.
Yeah. But apparently it takes 12.
I was surprised at that.
So our four question survey has a completion time of five and a half minutes.
And I would have guessed it'd be like one minute, but I guess not.
People take their time. They're thoughtful.
Yep. I appreciate it.
Let's talk about your podcast.
I briefly mentioned it earlier. It's called The Art of Product.
It's you and Derek Rimer 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 nonstop upward trajectory.
And then every week Derek comes on 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 you.
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. It's one of my favorite things to do.
It doesn't feel like work at all.
And 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 like a thousand or something. I'm like, how do you stick with that?
It's like, oh, it just doesn't feel like work for me.
And 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.
And I guess 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 Tupel and they're like, oh,
they'll ask me about something, but they'll say, by the way,
I listen to Art of Products so I know that you're thinking of this, this,
and this. They already have all this context, which is just wonderful.
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?
And I'm working on a thing and the thing is working pretty well.
And so it's like he feels this outside force to be like,
all right, figure out the next thing.
When in reality, he just sort of wrapped up his last effort.
And 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
and be 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 this 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.
And 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 struggle while knowing that he's obviously talented,
knowing that he's had some major successes in the past,
it 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 the good stuff and the bad stuff.
We think partly because we can help normalize failing and struggling
and rough mental health days and bad stretches
and disappointment and fear and all that.
And I've got an email from people thanking us for that and that openness.
And so that's something that we fully intend to continue.
I just launched a new feature on Indie Hackers.
Let's 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 have been.
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 groups feature.
And it's tough because it's like growing a community from scratch.
None of these groups have any users.
And I've got to kind of take-start them somehow.
And it makes me think about where you are with Tubal.
You've got a huge email list that you've been working through
for the last six or eight months or whatever
and just sending out invites to people.
But you're going to launch this month.
Tubal's going to be open.
And they're going to be kind of in the wild where I am
or you have to grow.
Your 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?
I don't really have a plan exactly.
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 slash tech-related content.
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.
And 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 they will then find their way into Tubal 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 to 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 thing.
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 Tubal?
Is it high enough that you guys can do direct sales profitably?
It is high enough that we could 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 XYZ.
And so I will actually do sales and 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.
And so I would say that starts to get 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 could eventually have a salesperson, possibly.
I'm not sure.
Oh, wow.
Yeah.
I was talking to Sahil Lavingia from Gumroad about this.
They grew Gumroad for like four or five years
off the back of direct sales.
They had a sales team.
And I presume they're 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 that 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.
And 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 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
and any 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.
Totally.
Yeah.
I think Nathan Barry has a great post on doing direct sales
as a bootstrapped startup.
I think this like lays all this out nicely, including that point,
which is you're getting feedback.
And just by doing, I would say probably 90% of our customers
do self-serve 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 Tupel every day for pairing.
Would you want to hear the results of that test?
And I was like, yeah.
Sure.
Obviously, that would be great.
So it's like someone is basically doing, you know,
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 the feedback and like,
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 Tupel
and maybe learn about your launch when it happens?
Sure.
If you are looking for a pair programming app,
chances are you're going to be hearing this right around
when we're launching or possibly after.
So Tupel.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 Cortland mentioned earlier,
that's called the art of product,
artofproductpodcast.com.
And I'm r00k on Twitter if you need some hot takes.
All right.
Thanks so much, Ben.
My pleasure.
Thanks for having me on.
Quick note for listeners.
If you're interested in coming on the podcast like Ben,
to have a quick chat with me,
go to ndhackers.com slash milestones
and post a milestone about what you're working on.
It can be pretty much anything.
People have posted milestones about launching
or finding their first customer.
They posted about growing their mailing list
or hitting a thousand followers on Twitter.
They posted about getting to a hundred or a thousand dollars
or a hundred thousand dollars a month in revenue.
The sky is the limit.
So whatever you're proud of,
come celebrate it on ndhackers.com slash milestones
and other ndhackers will help you celebrate.
We love encouraging each other
and supporting each other when we hit these milestones.
And what I will do is at the end of every week,
I'll look at the top milestones posted
and reach out to a few people to invite them
to come on the podcast for a quick chat.
So once again, that's ndhackers.com slash milestones.
I'm looking forward to seeing what you post.