$1M Later and Conduit is STILL Rocking Convex

Yeah, I think we looked at a lot of other providers early on and was just like, hey, we should make some conscious like decisions on architecture. We were like, you know what, like Convex is working. Let's just continue with it. And I think the thing that really convinced me was the real-time updates. That [music] was like almost like an immediate Eureka moment where it was like, okay, this is something that can let us build so much faster [music] because we don't have to refresh every single time and see the the UI state change. Convex just automatically updated that. And I think I've had a lot of YC companies, even non YC companies now that shoot me DM and ask me like whether they should pick Convex. [music] And usually I would, you know, try to understand like what their actual application is, but for the most part, like most applications actually will benefit quite a lot from getting on convex. In terms of developer experience, it kind of just makes sense. Hello. Hello. Hello, Mike. Oh, nice to meet you. Nice to meet you. Hey, good seeing you. The uh the office. This is the spot. This is where the magic happens. straight from uh yeah from tree hacks all the way to here. Yeah, that's right. We were just talking about that. Like how did you guys find this spot? We just toured it with uh with one of our um agents like Yeah, we really really like the location. So nice. I love the logo. Yeah, that's cool. Yeah, that's very cool. Instagram guy, but he like does like light signs on Instagram. Who is this? It's like it's like a guy who like the guy in China who like produces light signs like does memes about him like gone super famous and say we just order this from him. So uh we were just talking in the car actually about and you mentioned we're coming up in the elevator like I was I was thinking back to tree hacks [laughter] because so tree hacks this is where we were at with tree hacks is like convex wasn't even 1.0 yet. And like we had no idea how the product was going to go. And so um Tree Hacks was actually a pretty great opportunity to just like show it to a bunch of people, show it to a bunch of students and like just look over people's shoulders and just discover like what's working, what's really confusing about the product, what does anybody like? So the product was like this kind of when you guys like at least at least when you first used the product, right? Way back in 2023. 2023, right? Yeah. So I actually am curious even way back then like how come like how come at the at tree hacks you decided to use Convex? Was that the first time you That was the first time. Yeah. I mean honestly that was like the first time I used a kind of like a more managed backend um platform where you know before that it was just all kind of raw like on the rail stuff. Um, and at Tree Hacks, we saw I mean, of course, there are like sponsored prizes and, you know, the different things that you would combine together, whether it's a convex plus another tool to build something and then hopefully like win and take home those two prizes. Um, and so we're just exploring what we wanted to build. And at the time I was like, okay, it's like, you know, 48 hours or something before we have to demo this thing. We didn't really have an idea and I had a team that I went there with already. And so we saw Convex and we were like, "Hey, it seems to be something that we could use to build stuff quicker." Um, and I think the thing that really convinced me was the real-time updates. And that was like almost like an immediate Eureka moment where it was like, "Okay, this is something that can let us build so much faster because we don't have to refresh every single time and see the the UI state change." Um, Convex just automatically updated that with the with the websockets. And so we decided to go with Convex and as we were building out our product, I mean, I just like loved the developer experience of just being able to like edit the fields in the table and then just like immediately seeing the change on the UI. Um, and this was like all preAI, right? So it was it was kind of manual like to actually build all these things out. So we built out this tool for essentially like property managers to be able to manage all of their uh lease payments. Um, and so Convex was just the back end powering that. And so we actually ended up winning the the best fintech prize. We we took that track down. We were kind of bummed that we didn't get the Convex like most complex hack prize. Um I think it was it wasn't my fault. I don't remember who judged it. That's a it was somebody else who like did some cool stuff with convex frankly where it was just like ingesting data super super fast but then like it was real-time updating on the screen. Um so that was pretty cool. And then since then I mean I think we did tree hacks around like April. I think that was like usually when they hosted it. Um and after that I just went back to school um and started hacking on stuff but loved the Convex developer experience so much that I just continued using Convex for literally all my projects. Yeah. So and so you started off with realizing that okay convex can help us build faster. Um, what was it? What part of Convex was it? That's do you just do did you just keep going forwards with it and just cuz you already built so much tech on top of it or did you continue looking at other technologies and just decide that comics are still the best for your situation? Yeah, I think we looked at a lot of other providers um early on and was just like, hey, we should make some conscious like decisions on on architecture. Um but I think the fact that we were a chat app uh and you know there were lots of conversations going on all the time um and and notifications and triggers uh from Postgress for example would have had to you know been been pretty pretty frequent. Uh we were like you know what like convex is working like let's just continue with it. Um and generally speaking it was almost always the developer experience that kept us on convex. Uh it just made us ship so much faster. uh we were you know basically deploying every hour um on like new features, new new new new bug reports that we had to patch. Um and I think that wouldn't have been possible otherwise. Yeah. Yeah. There's the the what's really funny um but also like really awesome about working with you guys is you guys adopted like so early. There were a lot of things we ran into that you all would be like how do you do X on Convex? and we'd be like, I don't know cuz you guys are the first ones to try. Like there was a lot. So, and it's kind of funny cuz now the product is like it was sort of the assemblage of best practices and stuff like that are so much better understood. But like I think a lot of the the first time someone tried X, Y, or Z, it was like a lot of times it was like your guys' team that was trying some of that stuff. So like that was super fun to do together. I'm sure sometimes for you guys it was like you guys running into some friction like how how should we do this guys? are like, I don't know, let's talk it through together, right? Cuz like uh yeah, we were trying to do a lot of like crypto stuff early on and just like the fact that we had to do a lot of like, you know, environment hopping, cross crossing like that node chasm um from the V8 that was that was something that was like a little bit painful initially. Um but I mean right now like we're we've kind of also developed some uh best practices within the team to kind of like make that make that delineation a little simpler. What was your experience when you did enter these edge cases, use cases working with convex as a team? Did you find it like good response from them or was it annoying or I think it was it was super fun because I'm not sure if Ian was at tree hacks that that year. I think he was right. Yeah. So, so the funny thing internally is that me and some of the engineers like we we we chat with Ian a lot through the convex slack and we always call Ian like the teacher um because we would we would have an issue, we would have a question, we would just ping the Slack and then Ian would always be on there and just like he just answers every single question with like full depth and then you know obviously we'll hop on a call when needed. Um but he he was extremely helpful with helping us get through all those edge cases. Yeah. Yeah. Fantastic. And for me when I because I started off as just as an enthusiast and it was the discord and it was having team members directly respond to my messages in Discord. Jamie CEO was like how many of the startups do you know that when a CEO responds to you in Discord? Yeah. It's uh I I used to have a rule that no message anywhere on the internet would go unanswered. [laughter] I I regret to say I can't keep up with that anymore. But I think that's changed. [laughter] I I tried until the point where I almost never slept and then eventually I was like I think the machinery is going to outrun me a little bit but for a long time and uh I yeah and like even that right now like I don't love it. I I actually still want to figure out how to answer every single thing but but yeah but it's because it's a lot of fun. It's awesome when you make something new and other people are excited about what you made. Like you you know it's doesn't feel like a job. It feels like a privilege. You're like, "That's sweet. I love that you're excited about what we did." Like, you want to talk about people. It was super exciting, too, cuz like early on we were discussing all these edge cases and how we would handle like different kinds of workloads and we would just jump to the convex office, sit in the the conference room for a little bit. Everyone would like jump on a Zoom and we would just like figure out and whiteboard together like how to actually make this thing work. And then now obviously all these things have like become abstractions on components and um the workpools was was was huge. Um, but I think initially, you know, the the very hands-on approach was super helpful for us. Yeah. I want to come back to your story again in a minute. But, um, do you, if you were to do it again, we roll the dice knowing what you now know, would you have gone through it again, starting with a small team like Convex and scaling as Convex scales up, would you do the same again or would you go with a more established big brand name? Yeah, that's that's a really good question because I think a lot of it's like super path dependent, right? It's it's like since we built so much on convex and we were trying to move extremely quickly, we had a bias to stick with Convex. But I would say I would say depending on the application that we would, you know, redo this thing with. Um I would still stay stay with Convex just because of what I mentioned uh in both the developer experience and depending on the app um the reactiveness and and the live updates. I feel like those are extremely huge for for an application like ours. Um, I also think at the kind of user interface layer, having things be so reactive is something that like most apps just don't have. Like we know multi-billion dollar companies that have apps where you know your inbox still needs to be reloaded. Oh, so frustrating. Every time every time they encounter that, go just use Convex, please. Exactly. That's exactly it. And I think it really depends on the app, but for us, you know, using Convex as kind of like the client layer that's serving all that data real time to to customers, I think I'll do it again like 10,000 times over. Is there any instances where you say you shouldn't go for YC or should you always go for YC? Yeah, I'm extremely biased here, but I think for first-time founders, there's almost like no better experience than YC. It's extremely beneficial, I think, in in in in two regards. The first being the community. Like there's no other place in the world, especially being in in the Bay Area in San Francisco, where you're able to be surrounded by so many smart and not just smart, but super ambitious folks that want to build the future of whether it's AI or whether it's something more traditional like logistics to manufacturing. Um there's no other place where there's that much density. And so just being surrounded by this community pushes you a lot more. Like you would go to dinner and you know, you come back extremely energized to do more um than what you were already doing before. So, I think that's huge. But really, the second component is they will just help you make fewer mistakes as a first-time founder. They've seen so many companies go through the batches that, you know, they actually have like statistics that they were able to extrapolate of, you know, like if you do these sets of things um you're actually higher uh or there's a higher likelihood that you will actually succeed as a business like use Condex like use. Of course. Exactly. I'm sure that's in the standard curriculum now. Yeah. So, he deserves that holy grail status is what I'm hearing. I think no matter how large YC gets or how large the batches get, I think the the YC method um and the the the way that they take companies from, you know, idea phase to all the way to fundraising and and and post fundraising and actually support them throughout their journey. I think there's no other place uh better than that. How are you finding Convex growing with you? Does the convex developer experience grow with the team like organically or is it hard for new people to on board on convex versus something else maybe? I think initially it was a little tougher because we didn't really know kind of the best practices to onboard new folks and like there wasn't a way to like easily share like environment variables um and things like that. But as I think convex has grown uh in the past you know several months like we've brought on four new engineers and they've gotten 0 to one basically in two hours. All right. like they just sign in with convex and make an account and they get their dev environment and I think really the nuance of the onboarding is understanding all the concepts uh within convex. So things like you know pagionation and how do you write queries that are maybe slightly different from how you would do so on postgress. Um but then I think in terms of de developer experience it kind of just made sense um like you don't really have to educate them that much about you know you have your dev environment and you have your product environment. just shows you on the dashboard and so they don't have to go back and forth so much with with maybe the core engineering team. But we do have best practice docs for you know convex engineering. I'd love to read those. One of the interesting things with convex is the the limitations that we initially thought were limited with convex where maybe you know you can't count all the documents and collect them all um to just show as a counter actually forced us to build a lot more efficient ways of quering our data. um such that you know if we if we did it on post code for example we'd be writing just super inefficient queries all around right and so I think that actually was something that has taught us about how to how to do backend engineering the right way um and so yeah so in in terms of that that was that was that was super helpful but when when we're talking about AI I think I mean even in the last month like our workflows and the engineering team has changed so much um with yeah it's a I mean 4.5 sonnet yeah opus now Um but in terms of the the coordination with convex, I think the patterns uh in our codebase that we've built out has allowed us to be a lot more hands-off with all the nuances of convex because they're coded in so many places in the codebase now that whenever we ask the AI to build something, it actually builds it with the best practices of products in mind. And when it does that again, it it all compounds, right? like the best practices um that are in the codebase kind of forced by the convex pattern has allowed us to have those best practices be translated in all this new AI generated code whereas you can imagine like a a huge query would have been repeated 20 times because AI is just pattern mashing in a bad um and bad practices of the codebase. So, it's nice to hear some of those things working out cuz there's a million subtle little biases I built into this context that are that are based on these kinds of things like success. Yeah. Yeah. And just especially as teams grow and things like OC versus pessim pessimistic patterns because you always want failures to be localized and the thing that's just changed is the thing that's highest risk. And if that thing can have non-local effects then as your team grows your productivity drops in a super linear way. And like so long as you keep things localized including failures because failures will happen. those tend to be the thing where you can kind of bring new people in and have them fail locally in a way that doesn't. And so open-ended queries is a great example of that, right? So this it's why almost every big team ends up moving away from completely open queries is because otherwise it it's almost like this combinatorial problem where you need n people or n constantly gets bigger to all stay like completely uh tenacious and consistent and also to even know that they should do that. Yeah. Um and so things which you know are Yeah. So there's a lot of biases into the design so that that the hope is over time all of these things will happen and you will keep the kind of compositional power that the individual person stays pretty productive because the system because of those early limits even though I know those are often annoying at first. People are like what the hell not longer than a second and it's like I know but um but yeah so it's nice to hear that. Now having said that we haven't like delivered all of the pieces of that yet. For example, things like incremental compilation on components and stuff like that. So there are things right now about both code bases and team sizes that do hurt you more as you get bigger. I think you guys are suffering from some of those things and we still have to fix those. But but at least a few of the the early ones that we knew would be difficult to take back if we didn't get them in early. It's nice to see those start to work for teams. So yeah, I think just like one one other thing to comment on that is that you know kind of the horizontal platform and and um uh componentized nature of of convex like really reminds us of like our own product where we are building something that is fully horizontal and can build essentially any conversational workflow but we also want to encode some of those best practices uh as constraints so that when folks uh that again are not as technical and don't understand AI as well, are able to just come in without breaking everything and potentially creating like a behemoth that would require a lot of maintenance. So, there's a lot of parallels with kind of the way Convex has built their platform um with the way we're thinking about things that we're we're still trying to figure out, but I think we're trying to take some some of those uh guidances of of being more opinionated than being kind of, you know, fully flexible, right, Jim? than the other. Well, I could go down the nerdy asking you lots of technical questions through here cuz I will also say we're not done talking to them. I think it's just the phase of people talking on camera. You know, I got lots of technical questions, but um maybe we save that for another video. Thank you very much, Pun, for talking to us today. Yeah, thanks. It's been good. Yeah, appreciate it. Cool.