Raycast founder Thomas Paul Mann on iOS, community, and quality

Peter and myself, we basically came there with the idea. We had zero users. We started from scratch, right? And I mean, our superpower, Peter and Morris, is like we can... build product extremely fast like we're both engineers and so that's our our secret we like knew each other for years already so we can build things faster and higher quality than everybody else from tuple this is distributed

where we show how world-class engineers and their teams tackle the challenges of remote work. I'm Jack Hanna, your host. Hey everyone. In this conversation, I talk with Thomas Paul Mann, the co-founder and CEO of Raycast. And honestly, it was an absolute blast. I've been using Raycast for over two years now, so having the chance to talk with Thomas about how they build product, how they ship such high-quality stuff so consistently.

was just a ton of fun. And what was cool is that I actually talked with Thomas the day after they released their iOS app. And so we were even able to touch on what it meant to him to see that come to life after months and months of work.

So in this conversation, you'll hear about Thomas's background, about the recast origin story. You'll hear about their process for shipping product, about hiring. And of course, as I mentioned, you'll hear a little bit of Thomas's personal reflections on the iOS release. If you're interested in shipping amazing product quickly, this conversation would be a great one to listen to. I hope you enjoy. Well, Thomas, I don't know when this is going to publish, but...

It would be silly for me not to ask, given the timing. You just launched Raycast for iOS. What's been the reception? Oh man, like the launch of iOS was... very overwhelming so yesterday was our launch day and we tried to launch relatively early in the day just to get it out basically and then the rest of the day was just pure chaos trying to stay on top of everything

a lot of praise we knew that the app is highly anticipated so a lot of people have backed us basically the last couple of months being part of the beta and we then decided actually to be a bit more quiet and then just drop it out of nowhere. That was a large strategy. So I literally was prohibited by the team to talk about iOS publicly, where we are and that it's coming soon. So we got a bit more quiet, maybe some people noticed, and then we dropped it.

And so, yeah, perception was great. I think the highlight was sort of end of our day when... people started to share where we rank in the app stores around the world. So we were higher than some of the biggest apps out there, which was really nice to see. And so it was a wonderful day. I feel like... the team and myself get always so much energy out of this. And this energy comes basically from just users raving about that the product is great, that I love what we do.

And with every release, we also try to push basically not just what we built, but also how we present it. Yeah. It certainly shows the ad itself was beautiful. The demo was beautiful. Pedro clearly killed it in both those regards, as did, I'm sure, the rest of the team. What does it mean to stay on top of everything? Yeah, so our audience is very much active on X.

form on Twitter. So usually that's our main channel where we communicate. And so the video went out, it immediately got picked up by people. And then you're in this constant loop responding to like feedback there. picking up conversations in our Slack community. So we have a Slack community where all our members can hang and there are 30,000 people in there. So you can imagine there is quite a lot of communication in there. And then also just...

people exploring the app and see some features they're asking questions and so i myself try to be very much embedded in this and try to answer as many things as possible and so is the team and so throughout the day then also what all of us did is basically sharing a few highlights of the app um that it works on the ipad we shared some prototypes that didn't make it in the v1 which we hopefully can ship later like an apple watch app

which people requested. And so really trying to embedding ourselves of like, yes, surrounding us with the community and really try and be there and just be. be accessible because i feel like that's oftentimes when companies get big this somehow disappears and it's to be fair quite hard to manage the volume sometimes yeah but

That's also the fun, right? This is why we're doing it. We want to build tech. We want to give it to people. We want to change their lives. And so we want to hear the opinions of people as well and take them very seriously. And then also...

Things not always go great. So there are a few bugs that pop up and we're shipping actually an update today. And so we try to like group all of that and try to fix things as quick as possible to follow up and not disappoint people. It's so cool to hear that you're already shipping things. today that were maybe they're bug fixes and you had to do it. But again, I think it's a testament to some of the philosophies and things that you hold true. I understand that you had.

at least at one point in time some sort of on-call rotation for the slack community what did that look like yesterday was it all hands on deck the entire team's involved in the community online like how is the team organized to work together to keep up with everything. Yeah. So yeah, we have nowadays a dedicated community support team.

that basically observes what happens in the community. And when we talk about community, we mainly talk about our Slack community. And so they basically all hand on deck during those days. But then also, I think this actually started maybe this year, where we realized... the user base got bigger the community got bigger so did the team but we still want to have the same mentality if somebody ships something they should be there and hear the feedback straight away so usually what goes like we

We post something in our announcement channel and like a nice media and like this is what's new. And then there is like a threat happening on that. So this was hundreds of messages yesterday just to give you. An idea. And then the people, like literally the engineers and designers who build it, they're in there and responding to stuff. And that's really, I think, twofold one. They should be prouder for their build. They know best.

like how things should work right and so they first hand and reply to this but equally they really quickly see how a feature or like in this case an entire app lands with people like what they like what they dislike maybe what's a bit confusing

and so we really try to get this as unfiltered as possible but during those launch days usually the people that build it are basically responsible for the first volume support um day to day then because we're getting quite a lot of feedback right now we basically um have a dedicated team that responds to that and then escalates things to the dedicated engineers or designers who can then either way say like, hey, this is something you want to do or not want to do.

Because we often also want to be transparent if that is a feature we don't want to build. I feel like the least we can do are being honest about something. And we try to also give a reason to it. Like we try to say like, hey, look.

We thought about this. It's actually not that easy. Here are a few trade-offs that we would need to make. We can't do it right now. We maybe pick it up later. It's very often something that we say. It's really cool to see some of that stuff come to light at such a big moment for the company.

Watching iOS. I saw when you did your most recent raise, big fundraise, I think $30 million. There's two core things, iOS and Windows. Why iOS before Windows?

Yeah, it's a very interesting one. And we got this asked a bunch. And I tried to, also yesterday in the blog post, clarify that a bit. Because some people didn't know why we do iOS. And we felt like we... sort of need to explain ourselves right like we traditionally a mac application we're doing this for five years now we became sort of a drop-in replacement for spotlight with a lot more power and so basically people are really

knowing what we can do on the Mac. And then what started to happen essentially when we... First, launched Rekos Pro, which included AI, like basically an AI chat, which has all the context of the operating system, and people really adopted that.

they then quickly wanted to have the AI functionality on the go. And this kind of makes sense, right? Like I'm oftentimes somewhere and I want to ask a question and I don't want to have another app doing it. I want to have it synchronized and consistent and all of that.

And so that was sort of the first time when iOS popped up, which we, to be honest, haven't thought much about before. And so the second event was then when we launched a remake of our floating nodes, which now is just nodes. And so when we shipped that one... the voices basically became louder and and again i think this is quite natural it's sort of the first time you creating content within raycos like before

you would connect it to apps and you jump out of basically raycast to the app it's sort of a command center or like like a launcher to something but with ai chats and nodes you have really content and like that you want to have available wherever you really are.

Those two features really basically justified building an iOS application. Well, I'm sure we could talk about this ad nauseum, but there are other things that we are set to talk about today. I'm going to shift gears a little bit and take us back to some of the company's origin stories.

It's my understanding that COVID hit right before... demo day for you you and peter your co-founder uh you met at meta i think then facebook where you worked you left you did yc in san francisco and you were part of the batch where COVID interrupted right at the end, right before demo day. And I think something like the demo day format changed three times in the days or hours leading up to demo day, which had to have been incredible.

incredibly stressful knowing that this is supposed to be the culmination of this entire experience uh what did it feel like to receive that series of communication from the yc team that demo day was changing yeah so Beaming myself back, basically 6th of January 2020 was when YC started for us, for Peter and me. And I always describe it as probably the first class ticket into startup land.

Because YZ is extremely known, but therefore also there is extremely ambitious people around you. Oh, yeah. So it's really highly motivating. And just to give you a sense on the first day, like you come there and like then there's like, I think 200. The startups, I think, roughly speaking, were in our batch. Wow. And so Michael Seibel, the president back then, he was on stage and said like, so look around, 90% of you will not make it. And I was like, oh, wow.

That's pretty serious, right? You don't want to be one of those 90%ers that basically don't make it. And then you have this clock ticking, right? So it's literally like the demo day is set in stone. And it's basically...

How much progress can you make in three months? And for us, Peter and myself, we basically came there with the idea. We had zero users. We started from scratch, right? And I mean, our superpower, Peter and Moise, is like we can... build product extremely fast like we're both engineers and so that's our our secret we like knew each other for years already so our secret power is just we can build things faster and higher quality than everybody else and so

That's sort of the card we played during the three months. And so we had no applications, left our partners at home. Just the two of us were there. And 24-7, we literally built Rekos. No weekend off. We woke up, coded, went to the gym, egged something, and so on. And so you're doing this for three months and we made quite some good progress. We launched in Hacker News, got a really good perception there, which got us a ton of users initially.

And then sort of the last weeks you're preparing for demo day. So you're meeting with your partner and thinking about fundraising. So demo day is like you go in front of like... I think hundreds of investors and pitch your startup in two minutes. It's very short. And so you've been preparing for that. So I think it was literally like a week before we got sort of the news of like, hey, look.

there is this virus going on and it seems to spread outside of China and other countries. And so Demo Day is still going to happen, but we're going to do a professional video of you where you pitch, basically, the two-minute pitch, and then we're sending it out to investors.

Okay, cool. Yeah, fine by me. And then two days later, it was like, yeah, well, scratch that. We only making one slide. So send us a slide with four bullet points about your startup. And by the way, if you're an international founder, you should get.

out of here asap and so for peter and myself that meant okay we put a slide together send it off to yc we booked ourselves a plane ticket and like within less than 24 hours we've basically been back in london and then when we landed in london this was literally when basically demo day started yeah and so demo day started means like well a bunch of slides are online essentially

On the flip side, like also this changed for investors from one day to another. Like nobody knew what Zoom is and all this remote thing nobody had an idea of. And so the first two weeks I remember I had like literally from the morning to the evening was like back to back 30 minutes Zoom calls with a ton of different investors and you're trying to pitch and you're learning yourself how to pitch better and so on and so forth.

But equally for investors, it's like something new as well. But also like what happened during that time is we had to start to build a team because we were at this point like we kind of needed to have a designer and some other engineers helping us. And so because everybody was under quarantine and like at home and like basically lockdowns everywhere, the first people he hired were in Germany, Norway. And so we were from one day to another, we were basically a remote company.

Peter and I haven't worked remotely before. I mean, both of us actually moved to London to work for Facebook. And so it was very new for us then. But it was also five years ago. That was the norm, right? This was basically every tech company out there. That was the way to go. And so that was sort of this weird coincidence how we stumbled into being a remote company, really.

Fast forward to today, I think you're around 35 people spread across 15 countries, two continents, four time zones. Clearly, you've leaned into that. yeah so we we very much lead into it i think there were a few nuances to it because remote isn't remote right so there's like every company setup is different early on the decision we made is like we want to stay

close together from a time zone so we basically limited our talent pool to europe or european friendly time zones but pretty much europe And for a few reasons, like we still are very much like a Synchronous culture. Like we hang out in Slack, we hop on calls. We're not so much async in a way of like somebody writes something down and then somebody else picks it up somewhere later.

And so this benefits really from being in the same time zone. We made that decision. And so that's basically condensed it where we can work pretty seamlessly together. While we are remote, we also try to get a team together. every now and then and so we have one like yearly offside where we get everybody together the whole company

But what we started actually since the beginning of the year, probably more often, is getting little teams together to work together. So the iOS team, they met a few weeks ago to... hack on a few final features before the release and so they came on to london we have a few people in berlin they go for lunch every now and then so you build still a bit of a relationship and for like

collaborative highly creative tasks we feel like those in-person things really help us to like make progress on those things that sometimes aren't clear and getting on the same page on some topics I want to talk about hiring a little bit. Let's start with just understanding how the team shakes out across functions, and then we can talk about specifically how you go about the hiring process. So yeah, what does the Raycast team look like across the 35 folks you have?

So biggest part is engineering. Then the second biggest is design, where we have five designers. And then the other bit's like sort of supportive roles, like managers. We have two engineering managers. And then the other angle is more...

the operational side of the business. So the support and community team that I mentioned before, which are three people by now. And then like the head of finance as well. But really how I oftentimes describe us, like we are one.

product org the company is one product org because early on peter and i made a decision like hey we're here to build product like that's the most important thing there is never going to be something more important than building product 80 of the people are basically product people and this is where we put our focus this is where i put my time this is where peter's time is and then we try to find

people to help us with those other things, the operational things. And they're equally important, obviously, because you need to have those to run everything. But even they are deeply embedded in the product. Support is not an isolated function. They talk directly to engineers. They work together. They organize community meetups. They're in this Slack community, right? So really embedded.

even our head of finance he's like involved in like product development and stuff like that and so that's sort of how roughly the the organization is organized right now got it and uh you said that recounts Headcount growth looks like a step function. Why is that? Yeah. So initially...

uh we went i think up to five people and then we were like this for probably six months then we up to 10 people i think another six months and like also we tried to do this to plan the future a bit better but really what we understood or like realize that we want to see them break and then we know what we need and so we feel like having a really small team and we try to keep this team relatively small helps you to

Be nimble helps you to also understand what you can do, what you can't do. And then the stuff you can't do, you can decide if you want to do it. We oftentimes talk a lot about appetite. Do we want to do this? Do we have appetite for this? Sometimes you don't, right? And then you're not in the trap of hiring for that. And I think with this linear thing where you're just like, hire, hire, hire, hire, hire.

you really run quickly into the danger of like overhiring because it just like goes on and on and on. It's this constant thing, right? And we oftentimes like we run to this person doing a bunch of hiring like we did some at the beginning of the year where we know, okay. We need desperately people on the back end. We're about to scale a lot this year and we need more there. And with scale, we need more support help because that's something that goes up. So we hired for both of those.

It also helps like not spending time on hiring. Hiring is extremely time insensitive because you pull in a lot of people, right? And it's for many roads, very disruptive. And so we want to minimize that. And so hiring in those stages.

we feel really good about and the other thing which i would add is you also see like new people come and everybody brings something new to the table and then things like settle down a bit and everybody find their role and feel like comfortable with being here and then basically you can grow the team again a bit and so having like these steps really helps us for like building a team that works really efficiently together essentially

Yeah. What part of the hiring process do you feel like you're particularly good at? Because you've clearly assembled an amazing team to chip the quality of product that you do at the pace that you do. So yeah, what part of the hiring process are you most proud of? We recently looked back to this and looked like how many people came through referrals in our network and it was a shockingly high number. And I think that is what we nailed. Like you see now people come.

And then they bring over a bunch of other people that I worked with before. And the reason why they're doing it is first, they like it here. So you wouldn't recommend somebody if you don't like it, right? And they're about to plan to leave. But I also have worked with the people before. they get a sense if they're fitting into our culture, they know who is good or not good, and then they're bringing those in. And so network and basically like referrals have worked extremely well for us.

So that is probably something which helped us really building a strong team. Oftentimes, I'm not going to lie, our hiring process, many people say, I can't believe you hired that quality team with that process because... It's sometimes like we have like a few interviews and a lot of value, for example, we put on engineering, like designers giving them a test task. I think like this is so high signal for us. Yeah. Like basically see.

how they communicate, how they build stuff, how they think about stuff. And so that's probably our most important stage, sort of, like from just the quality angle of like, yeah, is this a good candidate for us or not? So those are, I think, the two secrets like network and referrals. And the other one, have a test task, which is very, very, very close to what you would do in that role.

I want to talk a little bit about culture. I know it can be a nebulous thing, but you have this blog post from, I think, 2021 titled, Be Obsessed with Feedback, Not Metrics. It seems like you've developed this culture where everybody at the company is really, really keen on engaging with the feedback from users. How did you cultivate that? How do you end up with a company of your size where folks are so bought into that?

Yeah. So essentially at the beginning, what we did is we have an in-app feedback, so everybody can send us a message from within Raycast or send us an email. It lands all in a single inbox.

And then Peter and I were first there and answered everything. And then we brought in other people. And then we realized like, oh, this is super valuable just sharing with everybody. So what we did, we set up a Slack channel where once a day we post the whole feedback in that went in there the previous day. And so everybody can read that. And the really interesting dynamic that we observed is...

If you build a feature and you get feedback about this feature, you're going to look at this very differently to a person that hasn't built a feature because you know, oh, I kind of know where this box comes from. Let me just fix it. And so this is the dynamic that we really saw happening quite often.

And so in the early days, when we were quite small, I was literally like, we got an email and it's like 30 minutes later, it's like, hey, this fix goes out with the next release. And building this flywheel, because... Let's be honest, how often did you send feedback and get something meaningful back? It doesn't happen often, right? And so we always set ourselves up, like we want to be better. We want to be how we wish others would be, right? And like really thinking about that. And also like...

We want to close the loop for the people that built the product. They should see it. They should think about what could be the next evolution of this feature look like. What did we get right or wrong? What we found is like oftentimes this is like the quality feedback, not the quantifiable things, right? So really the number that we look at as a company is our daily active users. We look if this number goes up.

That's great. If not, then probably we're not doing something good. And so that's like what we're basically optimizing for. And then the rest, like... our analytics is like we mentioned this is like this is basically anonymized we don't know who it is we maybe we see like if you do an action we don't know what a check did an action which we don't care about right we only want to see if people use the app

or if they're not using it. And so a lot of the stuff is basically just we in the community, we're listening, we're observing. And I think there was something interesting when you like hear a lot of the stuff. At some point you hear like, oh, this pops up all the time. We should do something about this. And then it cultivates an idea. And then this can be anybody. Like we have oftentimes like people come up then with ideas and say like, hey, I heard a bunch of this stuff. I tried that.

This was really how initially a lot of features got built, like people saw something. This is probably a luxury we have, similar to you guys as well, where you use your own product. You know what are the paper cards, what are the annoyances, what are the coolest things you could do. And so really we often solve our own problem and other people make us aware of them. And then we say, oh, this is cool. Let's do that inside of Raycast. And this only works if you have a closed feedback loop.

I don't believe this really works when you have a dashboard somewhere and looking at dashboard numbers because there you do a very different job. There you think like, how can I increase this number? Whereas we think, how can I make this user happy? Which are very different how you're tackling something. It's interesting that, on the one hand, you have basically known user tracking.

But on the other, you have this really robust and intimate relationship with your users through things like the community and the closed loop or the commitment to closing the loop for any feedback that's opt-in submitted. And so, yeah, it's just this interesting sort of thing where on the one hand, you're flying blind, almost forcing you to on the other have this.

much deeper, more meaningful connection with actual users that sounds like it serves you really, really well. Yeah, I think this is a really good observation, actually. Yeah, if you don't have analytics, we might get creative otherwise, right? And I think we always were steering towards we want to build a community. We really want to be surrounded by people, want to listen to them.

And so, yeah, we basically get a lot of insights out of this. And that helps us to like prioritize. And I think it also helps us to build this really loyal user base, like in the trust.

we're really listening like everything that gets shared good or bad we we take it not for granted we actually like very thankful for it and then try act on this stuff as well like if there are like people bad-mouthing us we're going in there and like say hey look like maybe we did something wrong how can we do better um and then that builds trust as well and i think like that's like it's something really important staying close to our users which

I think it initiated even NYC where they have this mantra, like talk to users. Whenever you go there and say, yeah, I have a problem. Like, did you talk to your users? Like, well, I didn't. Well, do that. And then so it sounds so obvious. But basically because we are on Slack, we're talking 24-7 to our users and getting so much insight out of it. And so this really, yeah, we cultivated that.

And it's a black thing and it's a curse. Like we're basically obviously super close with a lot of people and they're like DMing us everywhere and it's sometimes hard to manage. But I think the positive is obviously outweighing it. So you guys have this bi-weekly.

where you're putting a new release out into the world, which is what gives folks the impression that you're shipping constantly. It gives you something to talk about. It makes users feel really engaged and heard when they submit feedback and you act on it. And so could you talk a little bit more about this process? of shipping something to the public every two weeks, basically no matter what? Yeah. Peter and myself picked this up at Facebook, really. So they ship an update every week.

which is quite extraordinary. At some point we figured out like, hey, we want to highlight something every week almost. Like it feels nice. This is the new thing in the release instead of like bug fixes and improvements, right? And so we took this and basically run with it. This was just normal for us at this point, right? And so when Peter and I started...

If you go back in our Twitter in 2020, basically you see every Wednesday a tweet of like, this is new. And even when we had it in a closed beta, we were sharing publicly, this is what we do. To let users or future users know this is about to come. And it builds this interest because...

We're building a tool for other professionals, right? And it's this tool that is not the end result. It's a tool that you basically use to get something done, right? So we trust the tool. We saw it as a nice way to like... tell them what we do because they're interested in this they're most likely also engineers and designers and builders and so they want to hear this kind of stuff and that's really like resonated with people and so

Now we like doing it bi-weekly because weekly got a bit too much. So we like slowed down in a way. So when you have bi-weekly releases, we then think about, okay, what are the two things you can release in a month, right? So you suddenly have like a monthly cadence and say, okay, cool. So we have two big highlighted features. There's a bunch of other bug fixes and improvements that continuously go in there.

But then when you work on a bigger project that doesn't fit into like two weeks, you then kind of need to think as well as like, oh, does this go into the next release or the one after? And so as the company crew, like you have a lot of like... projects in parallel right and they don't finish all at the same time and some are a bit longer and some are a bit shorter

And so we're basically playing Tetris. There is something going out this week. And then what are we going to ship in two weeks? Like what is currently happening in the organization? And then this thing here seems to be like developed enough that we could say like, okay.

let's make it ship ready and then the focus shifts a bit then you're like what do we need to make this ready for production within the next two weeks and then you work on that stuff which oftentimes means cutting scope right like okay let's do this later let's do that first

And then basically you're constantly doing this. There's always something just two weeks ahead. And so we don't plan too much in the future. We know those are the things we want to build for the future. There is a few things going on in parallel.

and then you're basically putting them sort of like into the release branch so to say and and put them out there but it really helps you build structure on that And then when you want to make it a bit smaller than two weeks, basically the other sort of habit we have is like we have a weekly team meeting every Monday, essentially, where a company comes together.

We oftentimes talk about the company priority of the week. Like this week we released iOS. So everybody was like, okay, this is happening. They kind of know where they need to help potentially with some stuff. But a big part of the meeting is essentially people demoing their projects that they're working on and the progress. So other people know about it as well.

That's something which basically helps as well, like being in this rhythm, because you constantly have something to show others and people can pick up. And then we can say, okay, this actually feels good. Let's put it into... into the release and then we're basically polishing up on that feature and so i think like we really find like this release schedule helps us have a consistent momentum

Externally it is maybe not so visible, but internally we feel it. Like when you don't have momentum, everything feels a bit harder. You feel like it's a bit slower. You feel like a bit dissatisfied. You feel like, ah, why is everything taking so long?

And it goes back to what I said earlier, really optimizing for product building. And so this two-weekly release cycle is maybe the single most important thing that we have. We stick to that. If we release every two weeks, there is a high chance we're going to do the right thing.

Yeah. And it's my understanding of like an iteration and polish process, because for a lot of this stuff, it's released internally well before it gets released externally. Can you talk a little bit about that interplay and how iteration works?

Yeah, definitely. Again, I think this is something which we took away from Facebook. But basically what we have, we have nightly builds. So everybody in the company gets a new build every morning. And that's with all the changes that went into the main branch the day before. And so that means we're constantly testing the features we built. And that means we solve a lot of the paper cuts in the user experience, but also just sheer bugs or crashes before it goes out into public.

Because we're now with 35 people, we all obviously have users of Raycast. So a lot of those things that otherwise users would experience the first time they use something, okay, they're basically getting solved with that. And so this is really like something when you join Raycast, the first thing you do is you basically install what we call the internal Raycast version, and that's going to be your new main driver.

And so there it has some extra features. And most importantly, it has some gated features, which are basically just for us internally. And then basically you can test certain things that are meant to go out, for example, next week or... Even like other things that are still taking weeks to build, you see the progress of it and you can test it and can give some early input and say like, this kind of feels a bit odd. Have we thought about doing it that way? And so...

It really helps that people also being involved in this and see a project or a feature from start to finish, essentially. You talked about the external feedback collection mechanism. Do you have a...

complementing internal one for these nightly builds when things go out? Just post in Slack and then people jump on it. So it's probably a bit more chaotic, but like, yeah, basically you have project channels or team channels and then people just post left and right. this actually works pretty well because also we rely really

a lot on Raycast ourselves. So if something goes off, like for example, we had like Reasoning and Insta crash. So the first two hours of the day, Raycast was internally crashing for everybody. And so everybody was like, oh my God, my day is ruined.

But then people are figuring it out immediately and putting out a new one. And so this perhaps is just preventing a lot of the things that maybe would happen otherwise, which I think our users then, what you came, I think, at the beginning of the episode about is like, that's why...

we also can ship a high-quality product because I believe quality is not really measurable. Maybe it is with a crash rate and so on and so forth, but really what it comes down to is when you use something, how many... paper cuts or friction points do you experience and if they're like none to zero you feel like it's a high quality product right by dogfooding and internally testing it

for weeks to basically cut away all of that kind of stuff. And that's, I think, what makes Raycost appear to be a quality product. Yeah. It's interesting because it doesn't sound like you have... a ton of regimented process around this, but you don't need a lot of process around some of the stuff.

People give you feedback, you act on it because you care, because you're high agency, and because you're using it all the time, you understand what they're saying and have that empathy and then can just act. Yeah, 100%. I think this really nails it. To strive at rate cost, you basically... shouldn't wait and somebody tells you what to do you just just run and like

there's other people really i think we wanted to attract and like having high agency having fun to build stuff trying out some new stuff but also not forgetting about maintaining something which sometimes can be knally figuring out a few bucks here and there it's not

the stuff that we want to spend our the most time on but needs to get done um but yeah really i think like you really needed with your description we've talked about a lot of the things you do have done that have gone well what's been the toughest part of building the company and building a remote team i think the toughest part like we talked about like hiring in stages right and up to the stage of 15 people let's say

Peter and myself were involved with everything, right? Like we were always there. Going from 15 or like above 20 people, like you no longer know what everybody is doing, kind of. Or at least I'm not in the room anymore when certain decisions get made. Also, I don't want to be in the room always. So I'm not this kind of person that needs to oversee everything.

But in the end of the day, it also needs to be somewhat cohesive, right? Because if it's not cohesive, you probably build something that isn't nice. I think that was like for us in the last, probably particularly in two years, like really a challenge. How do we... build up an organization that could effectively operate without us right and make the right decisions and the right cause and goes in the right direction and have the the thinking that we have and not meant to be that we have

all the right answers but have more of the the values we care about right like what we talked today about like being fast like pick like good design, being elegant. And if things go wrong, be there and be responsible, work with the community. And I think over the last couple of years, if you look, for example, our hype team was petro they're running completely on their own right now um they um are highly functional like this we have big projects like windows where the team works on their own

um in ios as well so i think we managed to get to this point but it's like by no means easy and it's quite unintuitive at least for me as an engineer who like builds, and builds oftentimes means you're hands-on, and I'm still hands-on in code and stuff and help wherever I can. But I try to basically be maybe not a critical part of something and help coding some stuff.

I try to spend more time on like prototyping some things and find validation in something where I can then say like, hey, look, we should do that and try to make room for this. And then also just making room for.

authors to shine as silly as it sounds but we also like um want to basically be inspire author and give them the room to shine and that's i feel like really fulfilling when i see things coming together where i wasn't involved much and i feel like oh wow like the team really knocked it out the door and so that's a bit of like the the journey went through like over those five years

It's basically building out an organization that can operate highly efficiently and making sure we can put some good stuff out into the world. Just before we wrap, is there one message or anything you want to leave the audience with before we close?

yeah i think like because this is like we did a day after we relaunched ios and i'm usually not a very emotional guy but i felt yesterday it's just so it's very rewarding i must say like you put something out that you worked on for months and i know how hard the team worked day and night to get make this thing happen and how much effort to put in this how many designs we went through how many prototypes we tried out how many things we

discarded like the graveyard of things we didn't ship is immense and then coming to this end and you're shipping it it's very rewarding seeing people liking it and using it and praising it and we thank by no means for granted and So whenever we do something wrong, we want to hear it. But we also like when we're doing things right and hear it as well. So I think that's what I would leave for the audience. And I think this is not just for us. I think this is for every other product.

There is always other people building something. And so telling them when they did a good job, I think is very important because we tend to like reach only out to companies if something is bad, but more often than.

never they probably do the right thing and i feel like it's it's very important telling them that as well yeah it's really easy to do it's easy not to do but it makes a big difference for folks exactly yes i love it cool well if folks want to learn more about raycast or follow you and your work where should they go

Easiest is follow us on Twitter. Raycast app is our handle. That's where we're most active. If you really want to nerd out on Raycast, you can go to our Slack community, which is raycast.com slash community. Very cool. Well, we'll link to both in the show notes. Thank you again, Thomas, for being generous with your time and perspective. It was great chatting. Thank you very much, Jack. It was very happy to be here and telling the audience a bit how we build product. Good deal. Take it easy.

Thanks for joining us on Distributed. If you want to learn more about what we covered in this episode or if you want to share your own thoughts, follow at Tupel on X or visit distributed.fm.