Loading summary
A
Over the last few months, one product has risen to the top of my inspiration list.
B
You're, like, chipping away, like carving something, like you don't quite know how it's going to fully end up.
A
So the point of this episode is to figure out what it takes to consistently hit that bar for excellence.
C
We're just iterating continuously, but we're also going back over. And we don't just leave that work and say, right, that's done.
A
How do you maintain that level of attention to detail while preserving the speed that you need while going 0 to 1 on a new product?
B
It doesn't feel like work right for me. Like just sweating over the UI and building that in and just all the tiny little details is right. It's just super fun for me.
A
Welcome to Dive Club. My name is Rid, and this is where designers never stop learning. This week's episode is with David and Neil, the co founders of Supercut, which has quickly become one of my favorite pieces of software in my stack. So we're going to do a deep dive into how they work, how they think about product and all of the tiny decisions that they make that together lead to a truly excellent user experience. But before we get into all of that, this story actually starts at Typeform.
B
I founded Typeform, so obviously been in the company a long time. I think we wanted to do other things as well. I mean, we've just been stuck in forms. I'd been stuck in forms for like 12 years, and we were just. We wanted to be stuck in video, so we just left. We decided to leave pretty much the same time. And, yeah, you know, we just. We knew we were going to work together and carry on. And so we kind of want to repeat the same formula of what we were doing in Type Film Labs, which was, you know, moving really fast, like, iterating. The idea was to be, like, completely independent of the rest of the organization. So we were kind of like the misfits now on the sides, like building products and not having any dependencies and stuff, and just moving really fast.
C
And we'd also decided to set up Float Lab for Float before we kind of really zeroed in on a product idea. So that was kind of. The idea was already there, if that makes sense in terms of setting something like this up.
B
Eventually this will be. What we do is a multitude of products. But right now we're just doing Supercut because we raised money on the back of Supercart for Float, and obviously we need to be there to see it get successful. So I don't know how many years it's going to take us now to kind of be able to extract ourselves. But I think the idea would be that we can build a core team around Supercut and eventually we can move on to the next thing. But I think we're quite, quite far away from that. But that's the model, essentially a product lab where we build a team around and then we float it out, per se, and then we work on the next thing.
C
I mean, Supercut is a big idea.
A
So, yeah, not a small start.
C
It's not one you can kind of jump in out of that quickly. So it's not like we're gonna just disappear. But, you know, we want to make.
B
Supercut and, you know, it's a big hill to climb. Obviously, you know, there's like some big players there and it's like obviously a huge market. Right. A lot of people record their screens. It's kind of just part of a normal workflow. Well, you know, you've also got a screen recording product and, you know, there's just such a wide audience that can use these things. I think we've got a good product entering the market. We've kind of, like, innovated somewhat. We've got a really good platform to kind of build on.
C
Yeah, I think we've had this. We've talked about this a lot in the past, but obviously there's lots of products where you can spin them off a feature so you can kind of break into a market from a small feature. We've had lots of ideas for Supercut, but the reality is there's a lot of table stakes you have to build in this type of product. So as much as we've done some bits of innovation, I suppose a lot of the innovation is yet to come, if that makes sense, because we had to build all of this baseline product to get there. And video. Well, you know, Rid, like David said, you. You've got your own. You tell us how hard is building video product?
A
Yeah, well, and that's kind of why I wanted to have this episode, because I'm operating zero to one tangential space, looking at all the players. Right. And it didn't take me long to realize that what you're doing is excellent. Like, it's excellent. I study the output and everything that you have made because it's so clear that you sweat the details. And you care too. Like, you know, you just genuinely care about the craft of the product. So that's kind of my goal for this episode, is to just get really nerdy with people who are excited, exceptional at the craft and everything that is involved in going 0 to 1 and doing something high quality. So maybe we could start with one of the principles that you have on the Float website. You talk about how your mantra is less fuss and like simplicity as a way to achieve elegance in design. So what does that look like in practice while designing Supercut?
B
I think we're quite kind of similar. We're both like quite obsessive about things and if something doesn't quite fit, we'll just iterate. It's right until we're really happy with it. I think that, that. I think that's the starting point. Right?
C
Yeah, I think. Well, also, we're a similar age. Rude, me and David.
B
What are you talking about? You're much older.
C
You're always gonna do.
B
We're dad, so dad. Dad jokes a lot.
C
We're a similar age and I think maybe that helped part of the reason why we got on so well when we first met. Maybe it's not all to do with age, of course, but I think it helped that we're from the same kind of era and have a similar kind of mindset in terms of how we work. So we really. For good or bad? Some people might say bad. We do obsess, probably a bit too much and we do a lot of work. So continuously working on all the details and just want to get it right and we want it to be just wanting it to be the best.
B
I mean, we do love working to the point that it doesn't feel like work. Right. For me, just sweating over the UI and building that in and just all the tiny little details is right is just super fun for me. It's like an iterative process where you like this, you like chip in a way, like carving something like you don't quite know how it's going to fully end up. You make little changes and little changes. And I do a lot of design and code now as well because actually I think that's kind of a nice way, like kind of get better outcomes as well. For some things. Some things, some other things not. But I just, just love that process of like iterating and. And yeah, Neil's just like. He just wants things to work so well. Right. So you'll never settle.
C
Well, I think, yeah, I mean, I think as well, it's like when you have breakthrough moments on ideas, even if it's a small thing, when you break through and you think, wow, we're doing something quite unique here. There's something really exciting about that. Right. That's the bit where you're like, wow, I've got to show everybody. I need everyone to see this in the team. Even if it's just a prototype. That's the bit I think we probably all get super excited about. And then, you know, that just leads to more ideas or more thinking. But one of the fundamental things we said when starting float in particular was that we want to keep it simple.
B
Yeah. So no fuss.
C
Yeah. So when we talk about features, if we put a feature in, can we take a feature away but still give it to you? That makes sense. So things just work and things happen for you. So the idea of Supercut is you can just do a recording and get a great outcome. You don't have to then drop into an editor or make lots of decisions.
B
It's just done, it just works. That's kind of the ethos with your RAW tools, which is your camera and your screen. You record and you get something that starts to approach production values kind of thing. That's where we're going. We've got auto edit that's come in. Obviously that's something you have to do after the fact. So there is some lead time to getting an auto edited video. But, you know, with time I think the vision is like by the time you finish recording, you haven't edited the video, everyone records. How can we make just anyone that kind of talks to their screen, like come up with a professionally looking video which makes your content look better. Whatever you're presenting just come across better. And that works for teams internally or if you're reaching out to a customer, we just really think that's important and we care about again, we care about all those details about how you come across. So we're just trying to do it with that as a kind of mantra. Yeah.
C
We're also feeding different Personas. Right. So some people will absolutely love the editing auto edit stuff, even if it's not 100% perfect because it speeds things up. You know, they get a faster video, it's faster for people to watch, it gets to the point it's more concise. Other people will be way more kind of sensitive to the edits and what that looks like and what it feels like. So there's different Personas you're catering for. And the challenge is how do you build this and cater for these people?
A
Real quick message and then we can jump back into it. I didn't see this coming, but I'm all in on using voice as the primary way that I interact with my computer, especially when prototyping with AI. And it's way faster than typing and perfect for brain dumping context. But I used to have to use a separate tool, except now voice mode is built directly into Lovable. So building your ideas is as simple as having a conversation. It's just another reason why Lovable is my first choice for AI prototyping. So head to Dive Club Lovable to try it today. So Granola just launched a new feature called Recipes and I already can't imagine life without it. It's a simple way to run advanced prompts across all of the context of your Granola notes and they have some pretty great defaults out of the box too. You can even use the prompt that I made for inflight called Gather Product Feedback, which looks at all of your user interviews or customer calls and pulls out product related feedback with clear and actionable themes including direct quotes, which is one of my favorite parts. I use it all the time. And it's just another reason why I'm completely obsessed with Granola. If you haven't tried it yet, they're offering three months free for you and anyone on your team if you head to Dive Club slash Granola. Okay, now on to the episode. I want to talk about a bunch of the design process behind Auto Edit. But first I'd like to just go super deep into some of the details and all of the little micro decisions that you're making. So I'm curious, is there a part of the supercut product that we could drill into to just get a sense for how you all collaborate and all of the little decisions that you're making as you're relentlessly refining and iterating.
B
We don't have a design process.
C
Right.
B
So like we have different roles in the team. Right. Obviously we're like overseeing the product and the biggest design, the biggest decisions in terms of how things are panning out, what we're working on. But I work just on design and front end. Neil is looking after everything which is to do with the pipeline, rendering, layouts, the Mac app of course, which is a native Mac app.
C
I think we're all obsessed with product.
B
Yeah.
C
So like all of these things, like I would, I would probably argue that most of us in the company are on a generalist level, but we all care about product and then we all go off and have certain focuses where we kind of put more time into, if that makes sense. A daily puts a lot of time into design.
B
Exactly. So for example, the rest of the team like you know, they're not designers but they're super good developers. So if they're building a feature, they start building it rough and then they, they, then I jump in, right. And we call it gimping. Like I become the design gimp for the feature, just work it. And then I work it alongside the other developer as well. And we just iterate, right. And he gives me feedback and then I keep on working on it. I guess we do the same thing. I mean a lot of the design decisions in the, in the Mac app and Neil's as well. So also Neil like jumps into design stuff, but there isn't a process as such. It's not like we have team reviews where we look at designs. It's more like let's, we're going to start building this like, and then we just start doing it, right. And then we just iterate, iterate.
C
So there isn't that also I think like the design can influence how you build something. You know, you might come up with like an innovative way of how you're rendering video and that can completely change then how we design the product.
A
Yeah.
C
So it's like a constant communication. Like you can affect a product through various channels. And all we're doing is saying, well, how can we just make this better? How can we simplify it? Can we simplify it on a tech level? And if we do, how will that affect the design? Or you know, hey, the design is really important. We have to communicate this. How does that affect the tech? So it's just that constant feeling and.
B
Sometimes you have your constant feedback loop.
A
Right.
B
And I think also to be completely honest, I think we're very allergic to process. We're just kind of pure builders I guess would be the term. And so we've built like the company like around like how we are as builders, which is we just want to get our hands on thing, just obsess and just like bring it to production level. So I mean we do do planning of features. You know, we sit down every two weeks and we say like, you know, we look at the roadmap, we say like we gather feedback and we decide on what we're going to work on when we work on it. There's no like, hey, design team goes off for like a week and does some UX testing with users and then we come together and then we have a panel and then this like we've seen processor Typeform, like a lot of design process and development process and that's led to like really slow moving. That's Kind of why I started Typeform Labs, because I wanted to have, like, an arm in the comfort in Typeform, to be able to move really fast and to move really fast. The right ingredients are the right people with the right mindset who just want to move, move, move, and just. Just really care about those details, are obsessive about getting stuff out. And in that kind of jumbled mess of, like, what happens inside, you can birth, like, a really nice product out of that because there's just so much love to what you're doing that really, everything underneath doesn't matter. And of course, yeah, you could argue that. Well, you're not doing user testing early on, Prot. So how do you know you're not making mistakes? I mean, my philosophy on this is like, just move fast, make the mistake, and then fix them. Right. And so I think that compounds over time into you getting the product in a better state faster anyway. So that's kind of like our philosophy with this stuff. Just want to move fast.
C
We also ship and test. Like, I know that, like David, for example, when we shift features, we'll just be checking it constantly. Refreshing. You know, you're obsessed because it's nice to see that thing out in the wild and you're checking it, and then. So we probably see bugs before most people, and we're fixing it straight away, right? So you get a level. It's not the perfect scenario, but you get a level of quality control out the box.
B
Well, it works at our team size, right? And that's the thing. Like, I think there's an equation here, is like, how. How small can we keep the team on. On supercut to get it as far as possible? That's, like, a really interesting question because obviously I. The more people we put in, the more some process will have to creep in and so forth, and then the more it will slow down people. So it's like, yeah, we can add, like, five more engineers, but will we actually go faster kind of thing.
A
There's a tension here because you've said the word fast quite a few times about how you work, but there's also a level of polish that you guys achieve that it takes extra effort to get there. You know, like, in my head, I'm thinking about the tiny little animation when I hover over the transcript and the keyboard shortcut C pops in and out a few times, and it's beautiful. Or the way that the text shimmers in places or the notification bell jiggles. You are pushing into that final two. 3% of delight and Polish that in many ways. Correct me if I'm wrong. I always equate to stealing from speed a little bit. So where does that come from? How do you keep hitting there? How do you even think of all of those little details and justify it?
C
I would say that's the going back to what we said earlier, which is the obsessiveness. Like for example, some of those features you mentioned. David, he obsesses over those details. So he'll be waking up and thinking, I need to change this, I need to play with it. And so just continuously going back over things across the design, across the tech. Can we speed this up? I'm not happy with this. I think we can make it better.
B
It's not fast for the sake of going fast. It's fast whilst like making it delightful.
C
Yeah.
B
It's like how can we build a delightful product as fast as possible? Yeah, it's not like let's just put out anything, it's also a process.
C
Right. Like it's fast because we're just iterating continuously but we're also going back over and we don't just leave that work and say, right, that's done.
B
Yeah, yeah, we're constantly going back over.
A
Yeah.
B
I mean the player for example, I mean constantly evolving that. I mean just yesterday we redid the UI on the comments on the comments page also.
C
This is true of every team. There's a lot of stuff we want to do. Like sometimes we have to ship stuff that we're not 100% happy with because it's very time consuming to build some features in. But we know we've got to ship part of it now out the door now. So for example, Auto Edit is available for some people to use now and it's not optimally where we want it to be. So we're still sweating those details but we know we can't quite get there yet until we do a lot more work on bigger pieces of the infrastructure or spend can spend more time over here. So like anything, there's big pieces in there that just want to go back to and improve.
B
I think product building isn't it? Well, can be and I would say should be an iterative process. It's like you're just chipping away and fine tuning and getting this is like as great as you can. There's other ways to build product for sure, but as I said like from building product and the way we set up the company, we just want it to do it to suit our personalities because we're both co CEOs but we don't. It's like not like we want to be like the archetypal CEOs. We just want to keep our hands on the product.
A
And you're builders.
B
Yeah, we're builders. Exactly. So I mean, anything that takes us.
C
Away from that, I don't even think we talk about it really like that do. We're a small team, the team are great and we just all work together to. Through the roadmap to solve the problems.
A
I know this is a hard question to answer, but I want to just keep double clicking on how you all think about what to work on. Even so, obviously you have a lot of net new things to build. You're accounting for a pretty wide surface area and people have quite a few expectations because products like this exist and you're just finding all the little ways that you can do it better. So what's the breakdown between pushing into new surface areas, new features, versus continuing to iterate and refine and sand down the product that you've already built?
B
In terms of balancing, like the innovation and what we need to do in terms of table stakes, I don't know if there's like a calculation that we will do, but we will try and like have like a balanced portfolio of things that we work on after the launch, right?
C
Yeah, totally. And you have to be. We have to be a bit careful as well with the features we do because there's some pretty natural features that people ask for. So like, editing obviously is one that comes up all the time. And people probably wonder why we haven't got that piece in super cup right now. Or just to explain why we haven't got that yet is because we really wanted to get everything right before we fall back on that. As soon as you plug that piece in, it becomes an excuse why you don't have to do other features, right? Oh, we don't need auto Edit to be amazing because you can edit your way out of it. So the part of the reason why we're tackling auto edit first is to make auto edit as good as we can get it so that when we do bring an editor in, it doesn't feel like, oh, well, this is your fallback because the edit wasn't. So that's the idea. And for example, even on that feature, we've gone super deep on transcription. Most transcriptions aren't actually very accurate. They're good for captions, not really good for editing. And then when you consider that the AI AI has to edit and the AI is making a decision on Those cuts. Well, it's no good at all. We have to go really deep to make the transcription as accurate as possible. That is an ongoing task.
B
Yeah. And you've gone incredibly deep in that. Right.
C
And I think that's the point. When we look at these features, how do we make them better or how do we adjust them? But we have to be careful because equally you can fall into a trap where you start changing something for the sake of it. Oh well, we'll do it this way because it's radically different, but is actually the right thing to do. Depends.
A
Which is so tempting when you're working on a product where there are clear incumbents, where people can draw a bunch of parallels and you just want to change things just for the sake of doing it differently. Let's talk about the Auto Edit piece because it sounds like you have maybe even since the inception of the company, I'm not sure, had this vision that you should be able to record and it should just be edited by the time you're done recording. Basically. Still within that high level objective, there are many, many different design paths that you can take. So can you talk a little bit about some of the explorations that you've done, what that design processes look like and how you have arrived at ultimately what you're going to launch?
B
Let's just say that on Auto Edit what we wanted to do is if you make any mistakes, you can just carry on and then you can just.
C
Pick up where you were.
B
And that avoids this thing, this problem that most people are having on Supercar. I'm sure on all these platforms that you've recorded five minutes and you screwed up and it's like, no, I have to start again. And then it happens two or three times. I know because it happens in my investor updates. I get a little bit more tense, let's say. And I mess up like five minutes and I'm like, so that's the first thing. Also bring in close ups. Well, I call it close ups or just like camera only shots. So when you intro in like you've got your, your, your face up front and when we detect activity on the screen, then we move into, into the screen and then of course like ums and ahs and all that. So I think that that's kind of the baseline from there. But we could do some more things which we haven't explored yet. Right. Like B roll and stuff. But I think we have to like, like put a caveat around that because we are really in the video messaging world. We don't want to be seen as a video creation tool. Like, we want Supercut to be the tool that people pick up because they just want to communicate fast. We want to take you a little bit further to, like, up the production values. But we're not trying to be descript, let's say. Right. Because no one pick up Descript and, like, communicate with their team or just quickly communicate with customers. They're going to use it because they're doing, like, this video that's high stakes, that has to go out here on this date and so forth.
C
Not to say that we want the quality and the output to be there, but we just want to that our focus is the speed to delivery. We still want to give you that production thing, but we are pulling back. We're not. We're being a little bit careful what we plug in. We get a lot of people asking us for zooms.
B
Zooms is our Achilles hero.
A
Yeah, I knew that was going to come up. It's come up for me even, too. I'm like, seeing more and more designers using Screen Studio to share your work. And I'm like, really? You're taking that much time? That's like a. It raises the bar too much where it's like, now all of a sudden, I'm going to share less because I have this bar that I have to hit. And I'm like, oh, man, I don't know about that.
B
Just zoom in your figma file. Yeah, yeah.
C
It's just, you know, for us, you know, the delay on. Why haven't we put zooms in? Well, zooms immediately opened up the editor. It was like, well, you know, auto zooms, do they work that well? It's debatable. I mean, you could say yes. Some people say, yeah, great. Some people say, no.
B
Yeah, we've spoken to people that just hate them.
C
Yeah, exactly.
B
And they're like, they would just want to remove them or the zoom's not right.
C
Exactly. And then we were like, well, if we do the zoom, then you immediately. It makes total sense that the person making the video wants some level of control over that. Oh, you've done an auto zoom. But I would have tweaked it. I would have moved it slightly. So we were like, well, we've played with concepts. We've got some stuff we've been messing with. But you have to be careful because we don't want to just end up back in the editor going, right, here's the editing with all your zooms just like everybody else.
B
I mean, really, if you want to do like a sit down and make a video video that you're gonna release in three weeks by all means. Like there are plenty of good tools to do that. Right. Which have a wider feature set. But we're just really focused on this like time to delivery from when I record, how quickly I can get it out and with the best production values possible. So auto edit takes around three minutes right now because we have to do a whole bunch of stuff like realigning the transcript to the sound waves. We've got to run it through reasoning LLMs as well. And so that takes a lot more time because we want to get a good result. But I think over time, like I said, the vision would be that imagine you just record and doesn't matter how bad your performance is, we'll just fix it and you'll have it immediately.
C
Everybody uses the. It's probably the most worn out button in the app, the retake button.
B
That's where we are actually. If you look closely, there's like wear and tear.
C
Hey, stop pressing the retake button.
B
You know what we should do? We should put little details. Maybe we should wear out the retake button if you use it too much.
A
Yeah. If you retake three in a row, it just kind of cracks a little bit.
C
I love that. We spoke to loads of people and everyone's the same. They're saying, every platform I've used, nobody solved the retake. So we're like, well, maybe we can solve it.
B
Yeah.
A
So we're talking about using AI in creative ways to like solve these big problems that exist at an industry level. But there are also a lot of different micro use cases that you've worked into the product. So can you talk a little bit about the strategy there? When you were looking at the surface area and everything that you were going to make, how did you think about and know what to prioritize in terms of where to inject these little AI processes?
B
One thing we typically see in screen recording is very cluttered players where there's just loads of stuff shoved in. We felt that one of the most important thing when watching a video is having a clear index of what's in the video. And chapters are perfect for that. So why not put the chapters? Well, first of all, obviously those are AI generated and we do that really fast because we've decluttered everything we've put. Literally that is the first thing you see on the side of the video. So you get a real clear index of what's there and where you want to jump to the sidebar has four sections. You've got your chapters, your transcript, and then we have this thing called Ask AI, which is just a section where you can just ask the LLM any questions on the video or generate a document. And then you've got like, if you look at other platforms and I have one in mind, which I'm not going to mention, but there is just, literally just shit all over the place. So it devalues the value of each thing that you put in, right. If you've just got so many of them. So this is about like holding things back as much as possible. Like trying to make the UI as minimal as possible, right? Because if you look at the design of a supercut and text size, icons, everything is like. Just tries not to be too heavy so that we have room for more things.
A
Is there a specific example of a time where you felt some temptation to add, but then you have intentionally held back or trimmed something down in order to get at this mantra of simplicity that we were talking about earlier?
B
I have the opposite, which is some people were saying, I'm not getting as many comments as I should. And that's because there's two ways to access the comments. One is with the sidebar just hitting the fourth icon and the other one is just below the video. We have a message icon and a reaction icon. We've changed that now to be a bit more busy by putting those inside buttons. And it was like, had to kind of resist that, right? Because it's like, hey, this is just more visual clutter, more visual noise. But in this case it was like, well, you know, people respond better to buttons. So we did go the other way there. But at the same time, we're very considerate about putting those things in.
A
You had to start from the extreme end and just like work your way back. It reminds me of something. I think it was from Steve from Tailwind talked about the white space rule. Like always add more white space than you need and then take away versus incrementally adding white space to get to the point. Because you'll end up in very different spots. Probably same logic here. It's like, go as streamlined as possible and then just add enough.
C
The same thing happened with the Denoise feature, actually. We do normalization and we do Denoise on your audio and we plug the Denoise in for everybody. And then some people turn up with professional mics and Denoise isn't always optimal for those scenarios. So then we'd have people complaining, hey, I don't want Denoise. So Actually we ended up stripping it back and we just do step process and let you pick now what you want to use. But just make it, make it really quick. And we're just making all of that stuff quicker as well. So again, it's like the speed of how you do it and then trying to be too clever maybe with that initially and then bringing it back a little bit.
B
Other maybe design consideration is that when you, when you load a supercut, the title is, is really big on the page. Right. But it's only there as like a bumper at the front. And then when you continue, it just gets folded into like below the video. And maybe on other products the title will be like a size so it's visible really well all the time.
C
Right.
B
Like at the top, let's say. So it needs to be a certain font size. But because we've got the title on the bumper then we can, you know, once you play the video we can fold the title into a smaller font that's like less important, just for reference. It's those kind of things. Right? It's always like trying to declutter as much as possible.
C
And also this is a slight tangent maybe, but the bumpers are also built. They're not like, they're not on the video. But we design them to look like they're rendered as part of the video. So you can scrub them. We didn't want them to just be an animation that fires off. We wanted to make it so you could scrub through this, through the bumper and the end bumper. And then we have the. When we do exports, we can mimic that or we can take it away. We can do all sorts of stuff. But it's that feeling that you're watching a video. It's a video. So the title's part of the video that kind of.
A
Yeah, that was the first thing that stood out when I used Supercut when I saw that like gradient fade and the chapter title came in and I could scroll in between the different chapters in that like bumper and see that overlay. And I was like, oh, that was good. That was good. I wouldn't have thought of doing that. That was, that was pretty nice.
B
We're trying to like bring the presentation to us. It's not just here's a video kind of thing to watch. Like, here's something that I've taken care to create for you and I want to be in a nice environment when I share that with you. That's the philosophy. And some people will might say, well, for like inter team updates. That doesn't matter. But that's something that we're championing ourselves because actually I think like learning from Typeform and how people share presentations, one of my, well not video presented, just like slideshows, let's say. One of my pet hates in the company was that when people were doing like present presentations internally, they would kind of just riff themselves off like the brand guidelines and you just end up with some monstrosity presentations and they were like all over the company. It didn't matter, let's say because they weren't getting into any customers. But the thing is that eventually leaks to customers. Like if internally you're not doing things right, then eventually that will leak to external, right? So then the philosophy is here like get your shit right internally your brand and then like whatever you put externally will easily follow those brand guidelines. So I think that's also why being able to brand your supercuts is really important. And actually when you create a workspace and you invite people as members of that workspace, they have to use the workspace brand that you are put so the first time they may make a recording. When they're invited to your workspace, they will inherit the logo, the font, the colors of the player, etc. So they're already on brand.
C
That's one of the nice details in my opinion as well. Like you mentioned it before, when you first come in, a video swipes across with the loading screen. It's like your brand, your logo and it's like those are the creative inputs that personally if I use a product, if I can add my brand to it and it does all that stuff. Yeah, that's really nice.
A
Hey, really quickly let me tell you about the all new Dive Talent Network. I've hand assembled over a hundred of the most talented designers and builders that I know so I can recommend them to my favorite companies. So if you're listening to this, this and you're open to new opportunities, the Talent Network is anonymous and super low pressure. It's just an easy way to see what's out there without having to post on social media. So if you're interested in joining or maybe you're looking for your next hire, head to Dive Club Talent. We've talked about the video pipeline, we talked a little bit about the web app where the video is actually being rendered. Can we talk about the dashboard? Like in some ways maybe an easier part to overlook. But the more that I listen to you talk, the clearer it is that you're just obsessing over little every little piece. So what does that obsession look like when you were thinking about, okay, we need a dashboard? There's probably a lot of familiarity that exists here. How do you think about the little places where you really wanted to sweat the details? Is there a part of that where you're like, yeah, like, we, you know, we went above and beyond here, or I'm really proud of this. Anything that we could talk about inside of the dashboard that you think shines a light on how you all work?
B
Which I don't know if you know him.
A
Yeah, he comes up on this show quite often.
B
He's one of our investors and he was just going on a day like, he didn't know the dashboard existed because he was just recording photocuts and just, Just sharing them.
C
But actually. But that's before you go into the details of the dashboard. That's an important point because that's a good thing. Yeah, well, we've used other products and we were always like, we've got to make this thing through super fast, super quick. You get the share link like our products do as well, but they suffer because the dashboards get either neglected or overlooked or they can't.
B
Was always a heavy thing.
C
Well, you can't get people back into it because you've optimized for sharing and so will we. But our next phase of things was like, well, we want people to. We want there to be features and reasons to come back in and do these things. And so how do we tackle it so that this is all part of what we're doing?
A
Side note, Soleil was the one who told me about supercut. It would have probably been at least a year ago. And the fact that he still didn't know that the dashboard existed is hilariously beautiful.
B
It's amazing. I mean, to be honest, like, you wouldn't need to use your dashboard unless you were starting to create stacks.
C
Right.
B
Which we can talk about if you're just like using supercut to just like, hey, just quick video message, like, don't use the dashboard. It's like you just want to create a video and share it. I think there's. There's other products which have done such a hash of their dashboards in terms of trying to organize stuff. I think we've taken a bit of a different approach because the idea of doing folders, like, I know stacks is kind of close to that, but. But it's kind of different because stacks are more like collections of videos. So when you go into your dashboard, you have all the super cuts that you've recorded you can search those and it's just. It's just a list then. And then the next page, well, down the sidebar is like everything you've watched. And then there's your stacks. So stacks are videos that you want to put into collections, which you can actually collaborate with your team on. So different people can add to the same stack and actually they will be notified when new stuff comes into the stack. But essentially these are collections of videos that can be followed or added to. You can even make these stacks public if you want, so that you don't even need to go to the dashboard to see these collections of videos. So that's one thing. But in terms of, like, I don't know, design and details, I think the approach was to make it, again, as lightweight as possible visually. Like, the sidebar is not even separated from the rest of the content in terms of having a different color on the sidebar. Try to make it feel as integrated as possible. Then there was a product which I like, which did this, called Ozone. It's a video product, actually. It was just like, just keep it simple, right? You've just got your videos, your sidebar. Don't, like, put too much UI there. Just keep it like that. I am thinking now, at times it does feel a little bit like you don't have enough separation. So there'll probably be some iterations on the dashboard. But maybe what are the things that you particularly like that you picked up on? Actually, that would kind of help me to maybe explain it.
A
The thing that I've looked at so much is your notifications panel. Like, I've looked at so many different notifications panel, I have so many screenshots of different implementations, and yours is just different. Right. I hadn't quite seen the full overlay where it's clear, like you're pulling from a lot of familiar patterns. But the combination took you to a place that was really unique. And so I was curious, one, how you arrived there. But also even two, where are you drawing inspiration from? When you're thinking about something that's so familiar, it's so predictable, like a notifications panel in a dashboard. What's that design process look like?
B
There is no process in that one. It was just like, how's this going to look? I mean, one thing that I do do is, like, I try sometimes not to look at too many references because that kind of conditions you, and then you start copying. I'm personally not that happy with it because sometimes I feel that there's so much information in it. It's hard to kind of differentiate between different notifications. And maybe that needs to be reviewed a bit. But this was just, you know, one of these things in terms of, okay, we need two tabs, right? We'll have like the unread notifications, which will be the first view. So at least that will be like. There won't be like information overload. It will just be like the stuff that you haven't read. And if you want to dive into your older notifications, you can just tab into the next tab. I think that was one of the things. I think there was like. There's kind of like a timeline element down the side that we use to denote like who's the notification from. And it's accompanied by the type of notification it is with an icon. So there's that kind of like timeline effect on it. And then we just kind of bubble out with like the actual notification itself. Again, I think this is just a process, just when to design it. I don't think that was designed in figma. Pretty sure that I don't have a design for that. It's just something that's just jumped into really.
A
How do you think about when to jump straight into code versus when to explore in figma?
C
It's all AI driven, I read.
B
Yeah, don't do anything anymore.
C
Type it in.
B
I don't know, it's like you just feel it, I guess. Designing the editor that we're now building that I went into Figma because I knew, like, well, actually I started in Figma and I said, I just like, forget about this. Let's just carry on in code. So there's many iterations of this. Sometimes it's like get it to high fidelity in figma and then go to code. Sometimes it's like, start a bit in figma, very rough, just to sketch some ideas and then go to code and sometimes straight to code. The thing is, since I'm coding the UI straight away, there's no handoffs. I don't have to worry about getting things like production ready for someone to work on. So I think I kind of, kind of have that flexibility. If there's like one good piece of advice that I can give is like any designers that you have on your team should, if they can do this, just saves so much time, right? Going back and forth with developers in terms of implementation and like trying to do like overly complex like figmas with like auto layout and everything. Of course, at certain size you start to need that and your foundation and atoms and the whole thing. Right? But for now, it's just like, I would be embarrassed to show you my master Figma file. Actually, to be completely honest, years ago.
A
Even when you're working on things within Typeform, was that process similar? Do you find yourself doing more coding now or has it always been a part of your practice?
B
No. So early on in Typeform, I just designed. So I had to get things to high fidelity. And that was a frustration, right? It's always like handing it off and developers always just hashing. I mean, things are better now because there's better handoff tools and so forth. But there it was like, it doesn't take longer just to measure the height of this button or make sure the text is centered in the middle. Because typically what people do is like, you can't center a piece of text in the middle of the button, depending on the font, by just flexing it and putting it in the middle. Depends like, the font you use, because sometimes they have, like, weird X heights. It also depends if in the button you're using. Well, usually you will, but if you're not using a capital in the first letter, then that just like, unbalances the button. So you kind of have to do like a bit of a juggle where you do some negative, like, less padding on top and the bottom. So all these things, like, developers usually, well, didn't get the time. But even just like. Just like looking at the height of the button, they wouldn't even read that right. It's just like, well, it just looks like a button that's good enough and then we'll literally that back and forth, having to jump in with a developer and me not being able because I couldn't touch the code, being able to fix that, it's just like endless frustration. So when I started Typeform Labs, I started like learning React and started just being able to get to code. And then that was kind of my. My liberation, per se.
C
The thing is, though, like, we've always. The way you describe it, you hear that all the time, all that frustration, handing stuff over. That's a very. I've done it all. It's designed. Here you go.
B
Build it.
C
Kind of. That's immediately how it makes me feel.
B
Yeah.
C
And I think, like, the way we work and the way I think, like, we're just totally iterative because we literally will design and build it at the.
B
Same time and it will change during the day.
C
There's no point in David going away, going back and saying, hey, I've concocted this editor. This is what it's going to look like now building it.
B
I mean, here's the prototype in Scotland is going to change. Because the problem is then if you have these like really sophisticated Figma files, you have to go back and bloody like, yeah, we'll say you don't change all those.
C
There's no way you're going to get every detail correct as to how things can or should work. Equally, the developer isn't going to be able to go, well, it should be exactly like this. It's about working together to say, well, actually I've come up with this new paradigm in tech or open up a new paradigm in design, can we achieve it? Those things have to work together. And then at the same time you might be saying, well, do we want to do a stereotypical editor? How do we simplify this back down? And how do I still let people have the ability to edit in a nice way? Right. So that's a totally iterative approach. But when you talk about that just then I immediately felt like, like, here's the design work, build it and then.
B
It'S like it's just rigid and it can work, right? It can work if like, you know, because in a bigger company that's how you have to do things, right? Yeah, I'll work in that chaotic way. If you're like a big team like Airbnb, amazing company, produces amazing design. Like it's great, right? It's innovative, it's fresh, they do new things, they're rewriting the rulebook, right? I can't imagine it's just like, you know, just a small team like iterating on this stuff. Just one designer and then, and hey, let's get it in. And then maybe there is some of that. But I would have thought that there was like a kind of like proper process where they have a design team with design reviews, it goes back, it gets tested and then like it gets handed over to an engineer. But it has to be very well prepared for the handover. Then maybe there's some checks after.
A
Well, there might even be another person too. Like that's like the trend that I've kind of noticed is for bigger teams, you have smaller teams on one hand where the designer is the front end developer and there are no scenes. And then in bigger teams, there's the designer, there's the developer, but then there's also this UI engineer, prototyping specialist that's handling how everything feels. So you actually need a whole other role to kind of bridge the gap more effectively than what a Figma file can do.
C
On top of that, there's also stakeholders in bigger companies outside of that small team who have an opinion, oh, the sales team think this shouldn't look like that, or the marketing team thought it should be like this. And to some extent, that. And they might be right or wrong, but it sometimes holds too much weight.
B
Well, people slow them down. The more people you have, the slower things just have to satisfy so many people. It's just hard. So, yeah, we're a big believer in small teams, right? Yeah, Small teams are a product, and.
C
Also we can get it wrong and we can change it so we can ship something and think it's the best thing in the world. Completely delusional. And then we can see that no one's using it and we can fix it.
A
Your model is the thing that's most attractive to me now, where you ask the question, how small can we keep supercut? Which is a similar question that I've been asking. And that's such a stark contrast to maybe me in my 20s, where it's so easy to have these dreams and aspirations of the big team with the huge office and all these employees, and I'm just like, I don't want anything to do with that. I want to put myself in a group of builders that all have extreme autonomy and taste. And we just run, you know, we just run. And there's no real. It's very fluid, like. Like the way you are operating. I hope that we see a lot more of that, especially as AI kind of drives a lot of the costs down to zero. So I view what you are doing as the playbook in many ways.
B
It's funny you say that, because I remember early days of tideform. Like, whenever people would ask me how. How tideform is doing from outside, I'd always say, yeah, we're like. We're 80 people now.
A
How many people? Yep.
B
How well we're doing kind of thing. It's like more people we have, the more exciting it would become. And now it's, like, completely opposite. It's like, yeah, same. Scared of, like, going down that path. I think you're gonna see more and more small teams becoming winners.
C
Right.
B
Because obviously, you can leverage a lot of stuff with AI and, you know, bloated teams, they can't keep up with the pace that some products are moving, or they split up into smaller surfaces, and they just specialize in that and have no dependencies.
A
I have another question about how you guys work. So on a spectrum, where on one end, everything is a hex code and there's no components and everything is copied and pasted with the entire code base. And on the other you have a really well thought out UI kit of core components and semantic variables attached to all of the layers. Where do you all fit on that spectrum and why?
B
No, we're not on either extreme. So there are components of course, and there's like a library and there's. That there's stuff in there because we've moved so fast is kind of a little bit messy as well. I mean it's a tailwind project. So we have a lot of settings there. And then, you know, we've built on top of Shad CN as well to kind of customize the components. So there is that, but it's not so atomized to the point where it's gotten a little bit messy in some parts. So this is the thing, you move fast and there's some things you just can't.
C
Well, there's always a debt. There's always going to be something, a debt to pay at some point. It's just making a decision about when and where you're going to pay that debt. It's really difficult to build, especially if you're going to do more innovative piece. It's really difficult not to create debt. And I think you can beat yourself. But the reality is this thing is going to get redesigned, it's going to get sections of it are going to get rebuilt. It's inevitable regardless how much debt we have. And I think for us it's like an iterative approach.
B
It's like we want to get to market, right? We want to be first past the post on, on like let's say what we're doing, let's say we're okay with some imperfections. The people were joining the team like when we first started recruiting, we're now six people. We said, we said to people, look, me and Neil are a bit cat. We're cowboys. You have to deal with this ambiguity. It's got to work super well. It's got to look amazing and all that. That's like non negotiable. But we can take some shortcuts. For example, we do have some components, but those components aren't like referenced in a figma file because they just evolved inside the code base by themselves. Right. And so, and of course there's refactoring to do that. But you know, you have to be able to work if you want to move fast, you have to be able to work with a certain level of ambiguity and that doesn't mean that we won't like improve this over time. I definitely want to at some point take a look back and say, well, maybe there's just too many button styles here. There's even some overrides on buttons that I've put into to put a certain style where that's no good because now we have too many variants kind of thing. It's that kind of stuff which kind of creeps in.
C
But it's a judgment.
B
Yeah, yeah, it's a judgment all the time. It's like, we want to move fast.
C
With quality, but you can also paralyze yourself. Yeah, too many, oh, I've got to get this to be 100 perfect. And I need to do this and you need to that and you just never move forward. And so, yeah, I mean, how do you find it rid on your projects? I mean, do you ever get paralyzed in wanting to do things 100 perfectly or.
A
The reason I asked was it's clear that you all, one, use the product, which is exceptionally important to get to a level of craft that you can be proud of. And then two, you're just, you're just fixing things. If you realize weeks after shipping something that it's not as good, oh, I could do this instead. Okay, you just fix it. You know, you don't have to get approval from anybody. You can just fix it, which I think is really cool. The danger then is if you take that same mentality and it slides into system refactors, because there's almost an endless amount of opportunity for that as well. I always deal with that temptation just because I naturally think in systems. Not only that, I enjoy thinking in systems. Like, I love it. It. And the variable that I guess makes it a little bit more unique for us is two of the three co founders are designers. I was the third co founder to join the other designer did all of the work upfront and we didn't actually have a handing over of the baton until we were months into trying to just do zero to one discovery. We already had made a big mess and I switched it from light mode to dark mode. So I blew up everything, basically all the components. And we're moving so quickly that I didn't really have time to refactor it. So it's funny that you asked that question because last night, I kid you not, at like 11pm last night was the very first time that I was like, you know what, I should probably make my button components now. And I did it in Figma and we're going to end recording and I'll probably open up cursor and make them encode after this. And we're like nine months into building.
B
If you don't feel your design is settled down because you keep on iterating, what's the point in having that kind of Figma file which is atomized and so forth? I think in our case, like, like, once we see like, hey, things aren't changing too much, like, let's take a step back. How can we reduce this? How can we like make this more systematized and more organized?
A
Is it.
B
What stuff can we take out? Like, there'll definitely be a place for that because I enjoy that as well. Well, not, not creating the Figma file, but actually being able to create UI and like, ah, I've got this component, I just have to pass some things in and it's just like, wow, it just comes out perfectly. And we're not that stage right now. It's like, yes, I can use a component, but I have to like do a few overrides to just get it right for this kind of like this. And that's, that's what happens when you kind of like, you don't have a big view of like how everything's going to be and you're just like iterating to that. But yeah, we'll get to that.
A
There's nuance though, right? Because like, it's not black and white necessarily. Because for instance, for someone who's working a little bit more in figma than maybe you are, if you didn't set up any color styles or color variables up front, I actually do think that that would slow you down.
B
The colors.
A
Okay.
B
I've seen some FIGMA files are just absolutely like crazy, right?
A
Yeah, yeah. So it's like, I don't, I don't want someone listening to be like, yeah, I, you know, David doesn't systematize anything. So like, we're not using this neutral 800 anymore because there's an element of like, you want to minimize the amount of knobs that you're turning to make future changes to.
B
Let's just say. Rick, I'm sure you would share. You would proudly share your Figma file. Hell no.
A
I've shared many Figma files. The inflight one would not be one that I would probably share. All right, well, we've covered a lot of ground. Before I let you go, I want to give you an opportunity to shine a light on a detail that you are particularly proud of that we have not talked about yet. So when you think about the different interactions in the product UI details. Maybe it's something that you've streamlined in processing Neil, whatever that looks like on your end. What's a detail that we can talk about and use that as a way to ride off into the sunset?
C
I mean we haven't talked much about the Mac app. Like we put on quite a lot of work into making that Mac app work in every scenario like with spaces. So when you move between spaces, all of these, it's quite hard to get some of that stuff right on the Mac and allow you to record easily like full screen or windows a selection of area.
A
That interaction, I meant I just want to call that out. That interaction was so good. Like that's like a pattern that everybody should use versus the little pop up where you have to like click on the window in the separate modal and it pulls you out of it. Like that little click in point was genius. Tip of the cap on that one.
B
In our team that was a debate, but yeah, clearly.
A
Right?
C
Well yeah, no, no, yeah from day one the whole point and click, I mean other apps do some of that stuff as well. So for me personally I always hate the idea of having to do a dropdown to select the inputs and so I can't stand that stuff. But the new version of the app, how it stands today with all of the little buttons and there was a lot of debate about what should happen when you hover and what you have when you click and how all that stuff should work. So yeah, I mean I think sometimes we kind of forget about the Mac up. There's a lot of stuff happening in there as well.
B
For me maybe just talk about the player which is, I mean there's just so many details in there. Just a labor of love and just to get it working at all different screen sizes and like the mobile version and so forth iterated on mobile version maybe three times like completely changed and just like trying to work within that small space to like make it feel like presentational but there's so many details there. But I maybe just point to one detail which is that I like which is. Well you, you talked about the loading screen, right? So we bring up your brand, color, we mask in your logo, we slide out the. Let's say it's like a curtain, right? We just slide it out and as it slides out the player actually moves forward a little bit forward like that. Like I remember adding that and thinking that just feels really nice. It's not just like feeling it, it's revealed with like it comes out at you. It's, it's just subtle. It's not like a big, like massive zoom. It's just a subtle zoom. So next time, you know the supercut, let me know if you, if, if you notice that. But yeah, that's, that's what?
C
One for me.
B
I mean there's, there's more things I'm sure.
A
David, Neil, thanks for coming on and this has been a heck of a lot of fun. Genuinely big fan of how you all approach the work and what you guys are doing and it's just an honor to get to hang and pick a brain a little bit. So I appreciate you making the time.
C
It's great.
B
It's great chatting to all this stuff. It's really cool.
C
Yeah. Thank you.
B
Thank you.
A
Before I let you go, I want to take just one minute to run you through my figure favorite products because I'm constantly asked what's in my stack. Framer is how I build websites. Genway is how I do research. Granola is how I take notes during crit. Jitter is how I animate my designs. Lovable is how I build my ideas in code. Mobin is how I find design inspiration. Paper is how I design like a creative. And Raycast is my shortcut every step of the way. Way. Now, I've hand selected these companies so that I can do these episodes full time. So by far the number one way to support the show is to check them out. You can find the full list at Dive Club Partners.
Host: Ridd
Guests: David & Neil (Co-founders of Supercut)
Date: October 17, 2025
This episode is a deep dive into the craft, decision-making, and iterative obsession behind Supercut—a rapidly rising design tool beloved by the host. Ridd interviews David and Neil, Supercut’s co-founders, about their philosophy of design excellence, balancing speed and polish, their aversion to process, simplification as a mantra, and their hands-on, builder-centric way of working. The conversation spans everything from micro-interactions to larger product decisions, the design/development pipeline, and their take on building small, highly productive teams.
“Less fuss” in Practice
Different User Personas
Anti-Process Culture
Continuous Iteration Over Perfection
Sweating the Last 2–3%
Polish and Iteration Go Hand in Hand
Design Philosophy & Tradeoffs
Using AI Thoughtfully
Advantages of Small, Generalist Teams
Building for Builders
Transparency about Code & Design Systems
On their core design obsession:
On the absence of process:
On balance between shipping and polish:
On resisting unnecessary features:
On dashboard design:
On team size and modern product teams:
On Figma, design systems, and technical debt:
On delight in details:
Supercut’s origin story & Typeform days:
[01:10]–[03:16]
Simplicity credo and sweating the details:
[04:43]–[08:28]
Process aversion & hands-on collaboration:
[10:13]–[12:25]
Iterating with speed vs. polish:
[15:02]–[17:54]
Design philosophy for "Auto Edit":
[20:55]–[24:35]
AI-powered features & decluttering:
[25:34]–[28:32]
Dashboard and notification panel design:
[32:56]–[37:42]
Code, components, handoffs & technical debt:
[45:04]–[50:23]
“Proud details” — Mac app and player polish:
[51:39]–[53:48]
Ridd closes by underscoring how the Supercut team’s obsessive approach, distaste for excessive process, and relentless hands-on iteration are setting the standard for small, effective, highly crafted software teams today. Both the conversation and Supercut itself reveal a philosophy where craft, simplicity, and builder-autonomy are elevated above all else.
Recommended for:
Designers who value craft and polish, founders aiming to build nimble product teams, and anyone interested in the design/development tradeoff between process, speed, and excellence.