 Cool. Before I start, can I get a show of hands? Does anyone here work at startups? Does anybody here own startups? Like, are you guys founders? OK, cool. Nice. So I think, so I'm Vish. So I am the co-founder and CTO of Split. We are a travel financing startup, which means we let you pay for your trips in installments. So how we do this is we become a payment platform. We become a place where we get integrated on travel websites at the checkout page. And you can choose to pay in Split and split it in installments. But what I'm here to talk about is a problem that's very personal to me. So I've worked across multiple startups in many countries, in India and the US, Malaysia, and now in Singapore as well. And I worked in small companies and rather large companies as well. Small instance at less than 10 employees. I was one of the first few employees. And then in all the startups, there are 200-plus employees spread across multiple countries. But one problem remains constant, and this is also personal to me, is firefighting. And I'm sure you must have heard this term or faced it yourself. There are more often times where you feel like, why am I doing the same thing? Why am I just not growing? Why am I lagging behind? And you know when you're firefighting, when your product team is asking you to build features at such a fast rate, maybe one release a week. And then you have a huge backlog of bugs that you need to fix. Or if you're always trying to figure out hacky solutions for problems, just fix it really fast. Let's get it out and then do it later. I guess this sort of a mindset in startups has been sort of vicious in a way that things don't get built properly. But on the other hand, we see startups like, I mean, X startups like Airbnb, WhatsApp, they always seem to be way ahead of the curve. They're always building amazing features that works across platform, across communities, across countries as well. How do they do it? So what I'm here to do is actually go through my experience of why firefighting happens and how we can sort of avoid it in the first place. And then again, as me running a startup of my own, I do not want to deal with any of these problems. So firefighting, how do we stop it? I think the first question to ask is, do we firefight at Split? That's your, we don't so far. Yeah, so far. And the way we are able to do it is by two core philosophies that we have. First one is be lean, very unlike the lunch that I had today, but yes, be lean. Be lean in two ways, be lean in your code and be lean in hiring. Let's talk about code. Whenever we write anything at Split or build anything in Split, we do not ever want it to come and bite our ass ever as much as we try. I wanna engineer things that autopilot's on its own. An example I'd like to share is actually WhatsApp. So just before that acquisition, WhatsApp had 16 employees, that is it. And they were probably in the top 10 of every app store in every country for a long, long time. How is it that they're able to achieve something like this with such a small team, right? So that leads me into hiring, right? It is actually very easy for startups. Like, look, you've got in your seat around the same million dollars or so. Boom, you get an office here in WeWork. You hire 10 engineers who are just onboarded and then, and you're expecting things to grow really fast and really like explosively, right? But that's actually not gonna happen. So as founders, you've done your due diligence and figuring out what the product and what the experience is going to be. You get one person onboard and it probably takes them about a month to kind of get their mindset tuning and work as one single unit. Imagine getting 10 people in one shot. How are you gonna convince them of your vision? Yes, maybe they convince an overall scale, but can you work together as a unit is the question. Something to think about. It's easier said than done, but that's something that we try really hard at split to do, making sure that you're on the same page. We're all thinking as one unit rather than having like confused conversation, meeting after meeting. That's never gonna happen, right? And the second thing is, I know this is gonna be a very cliche topic. Stay true to your vision of your company and never find shortcuts. Now, again, when I said easier said than done, your vision, for example, split vision is no travel will be made impossible because of the upfront cost, right? If $1,000 is a huge upfront cost for you, we wanna stop that for you to be able to travel, right? This is our actual vision. Now, the motivations of a startup could be very different. So let's say you find out that there's a company in the US that's doing something and you feel like, hey, the same product could be applied in Singapore and there's a huge market, right? So your motivations could probably be that, I wanna make that money, I wanna make that exit. Now, if you go with this mindset, you're never gonna be building a very customer-focused product. You're never gonna know what the actual problems are. Sure, you can do your user research, hire five product managers to do it, but then your measure of success is always gonna be GMV, right? So that's bad. So the key is always stay true to your vision of whatever that might be in your case, right? And second, never find shortcuts. Shortcuts always bite your back in the ass. I don't wanna elaborate more on this, this makes sense, right? So yeah, anyway, speaking of hiring, we are hiring at Split, if you would be interested. You can come talk to me later. But enough of me, I'm gonna pass on Mike to Marsha. He's a full-stack engineer at Split, and he's gonna talk to you about experience of working at Split, working at startups, and how it means to be here. Just a minute. Hi, my name is Marsha. So maybe some self-introduction. So I'm a full-site developer for about three years of working experience. So for my development experience, I've been bouncing between startups, working for a deaf house, projects after projects. Then I got an opportunity to work in a big MNC, German MNC called SAP. So I experienced startups and MNC structured and unstructured, or less structured companies before. So I'm trying to convince you guys why you should join startups, rather than a structured company like the banks, big companies. I know they pay well. Full-site developer, you got now $5,000 a month, no problem. But why you should join a startup? So the main g-source of it is there's costs for everything. So first there's costs on monetary gains. Second is growth and opportunity. Working for big MNC, they are structured, got rules and regulations, very little room for creativity. But working for a startup, you got more room to explore your ideas, to grow, to be creative. And in some sense, for split, there's no office politics in some sense. So yeah, split adopts 80% to 20% room. 80% of the time we do what we are hired to do. 30% of the time we can do whatever you want to do. So for me, my 20% of the time, I choose to do business development. So I was part of developing a pet project for loans for our travel agents, like people's puppet. So ongoing project. It's fun. I'm a full-site developer, but I care to be a mini-PM below BD. That's cool, man. You can't get the kind of opportunity in MNCs. So this is it. So yeah. Yeah, we are. So we need to reiterate split hiring. We are all Node.js days. So I will be at the corner talking about Node.js. If any of you guys are Node.js, you're the first come talk to me. I will be great to learn from you guys. So check with me later. Thank you. Yes. So the question was, what do you guys do in a day-to-day basis that reduces the rush in development, right? So we've been active for about a year. And the one thing that, again, back to core principles is that we follow the general principle of sprints, making sure everything is clean before it goes out. We use a test. The golden rule is number six. Talk to six people for majority likes it. Go adopt these product principles. But at the core, if even one person says that, hey, this is not something that I'd use and not a widespread experience, we'll not use it. For example, a couple of days ago, we needed to push a release out, which does a lot of new things. But it was a little bit slow. It took a two-second delay. And we took a conscious choice. We will not push it until we figure out why there's this delay. So the end consumer matters the most. Like, if you look at companies like Apple, for example, hopefully they have been doing stuff, start-up-y. But then more often than not, when they release a product, it is generally widespread and it works. They do a lot of testing. They do a lot of research. And then they take their time to do it. So that's the thing, right? So our product has evolved over a year. It is not what it is before, but we also don't follow the move fast and break things principle. We don't want to break things. We want to just move fast. Any other questions? So when you say that you don't fire five, right, it's kind of magic. Okay, so in any project, there's always this trifecta or whatever you want to call it like feature, scope, quality and time. And there's a natural tension. So at different points, whether it's your own fault or not, one goes into a crunch mode. And then you wind up by fighting. That's what happens. So how do you bring the balance back? That's the only way, right? Absolutely. I think we are fortunate at this time that most of the things that we want to do already is perfected in some way. For example, right? An API call, making an API call or a queue, your queue stack. Three years ago, like RabbitMQ was not as good, right? Today it's really good. Making an API is super easy. Let's say things like a server crash, for example. It used to be a thing of the past. You have auto scaling, you're easy to go down. But now put everything on Lambda and it works fine. So I think adopting scalable technologies is what I'd recommend. And there is this core reason why this happens because, again, staying lean, we are a three-member team right now. Now, if we do something that could potentially break, I don't want to wake up at 2 a.m. and then fix something, right? So there is a sort of need to make sure we cover our track wherever we go and make sure this doesn't happen. I don't know if I'm expressing this correctly, is that when in your mind you feel like things are gonna break and this is gonna happen, it kind of reinforces your brain to figure out what could possibly go wrong and fix it. But having said that, it is quite possible that things will break and you will have to firefight at certain points. But let's say if you're mostly not firefighting, that's a very good thing. Does that make sense? I think I would add doctor and we don't rise oil for it. So if there's a problem, we say doctor put an image, you're done, you can go to sleep. And automate that process. So you don't even wake up, huh? Yeah. Good. All right. Yeah.