40. Automating mobile app releases with Tramline founders

And I realized that there is so much manual work happening here. Everyone is running around and helping people at least get herding in doing wardrobe that is all the merch, conflicts and no one's sure what is shipped, what has not shipped etc. And I realized that this is a problem. Things aren't work like this. Hello and welcome to episode 40 of the Madagascar podcast.

This is Ilja and me talking about our journey in Madagascar setting up the company and sometimes we have guests in our show and today we have three folks from tram line. They'll tell us in a little bit about what they work on. We have Pratul, Nivedita and Akshai from tram line today. We're going to hear about their journey. If folks have been listening to our episodes like diligently then they know that we talked about tram line a little bit in previous episodes.

That's the CICD platform that we use. And I know Akshai and Nivedita from quite a few years ago when I worked with them for a few months at a dev agency called Nilensso in Bangalore. So yeah, here we go. Pratul, Akshai, Nivedita, welcome to the show. Do you want to introduce yourselves in tram line? Hey, so I'm Akshai. I've known Arna for quite a few years now. As Anna mentioned, we worked together for a bit at Nilensso. I think that was 2014 perhaps 15.

And I think recently too, I just noticed on LinkedIn that you changed your job to tram line. And I messaged you on like, hey, what's tram line? And you explain it. And I was like, that's exactly what we need right now because that week I was struggling setting up CICD for our app. So that was like another set of. So before we get into tram line, how about you quickly introduce yourselves? Because I don't think we've heard all of you so far. That's basically it for me.

So I mean, a little far back before I met you on a B-started Nilensso a year before that, then 13, Nivedita myself. And four other folks, I think originally kicked it off. I think you know most of them before that we also worked for another sort of very specialized Ruby on RealSish consultancy that was quite popular back in like a decade ago. That was what C42 or? It was called C42, yeah.

Yeah, and I found out about those folks through various internet channels like the IRC, which is also where Pratalan I met in 2008. Yeah, that's right. I've basically been programming since and when moving across these different agencies. This is our first foray into doing a product for real. Like a full-fledged product. Yeah, not a fake sort of is this a product or this is a hobby project type of situation? Yeah, it's not a hobby project. That's the main thing.

Thanks. I met Akshay at Nilensso before that C42. We both joined C42 around similar times like six months apart or something. And after C42 decided to close off its consulting thing, all of us at C42 decided to open Nilensso. That was how Nilensso was created. Basically, I worked and sort of ran Nilensso for the last few years for about nine years. Nilensso very recently celebrated its 10th anniversary. Wow, nice, yeah. Yeah, I'm surprised.

I mean, like back when we started, we didn't think it would last this long. So, I mean, we wanted it to. We didn't think it would. But so we were quite happy of the fact that it has lasted long and it's going strong. Actually, to be honest, I'm really happy about that. The reason I said a real product and not like a hobby product is because at Nilensso, we tried like a few other products apart from the cool thing that Arnaugurgdaan. We tried some wiki thing, some reranting matamos.

I think we tried like a few other products. Which we would treat as if it works out in the next three months. We will run this otherwise we'll kill it. So that was sort of like in our minds, hobby product or hobby project. You all were like big into dog fooding also, I think. Like everything that you built, you would use it internally and see if you'd like it or not. So that's a good way of developing things. Yeah, so, Tramline was all of ours first attempt into building a product as a business.

Actually, second for me. I should call pause. Okay, let's hear from Pratul also. Yeah, you're the only person I don't think I've worked with, right? That's for you, because I was not at Nilensso. Although Nilensso is timeline and why time that intersects so many times. Oh, yeah, quickly. Hey, everyone, I'm Pratul. Between the three of us, between Akshay and Amedita and me, I'm the one who actually built a lot of mobile first stuff and built a lot of apps.

I've been building Android applications in production since I think the first one was in 2010. Which was very, very early. Practically nobody had seen an Android phone. Because I remember for the longest time, a lot of people would ask what phone I have because they had never seen Android. And before that, I used to do a bunch of PXP and I used to do a bunch of open source work for Drupal. The content management platform.

I did some of the code with Drupal, which is around the same timeline that Akshay and I met online on IRC. Through some of the code, right? I think it was a some of the code channel. That's right. Yeah. I mean, we had a shared interest because I was working at Gnome and you were working for Drupal, I think. So for people who are not familiar with this, what is some of the code? So some of the code is this really fun.

And probably one of my favorite things that Google has ever done, which is a program for university students. So you have to be a student at a university, not in high school, where they get to work on an open source project. Like a specific part of an open source product. And Google pays them for it. So I think the timeline is something like three months. I think it's like the program is 10 or 12 weeks long. And you get paid, I don't actually have no idea how much money they get paid today.

But in 2009, which is where I did summer of code, which now sounds like a lifetime ago, I think I got paid $4,500. If I remember correctly. Something that I'll do. Yeah. I think they have regional pricing now. Was it 4500 for the whole summer or per month? No, no, for the whole summer. It's probably still going on. But in the beginning, it was very hard to get into also, right? Like you would apply for it and then Google will go through like a selection process and all that.

Yeah. And I distinctly remember this particular year, because the year that I did summer of code in 2009, I think is the first time they selected a hundred students from India. India was the second largest country in that year, after the US. And it was a hundred students, which is a quite a big deal because they didn't expect so many people from India to show. It was very, very nice. The program was very nice. My experience was great. It was very formative for me.

And I'm still friends with pretty much everyone who I'm at at that point. And this whole lot of people have gone on to do all sorts of crazy things. How old were you when you did this? 2019, 1920. So basically, like you were still a student. Cool. And I remember so these connections that you all created, because when I was working with you all at Nile Enso, there were a lot of other summer of code participants who showed up there. And these are like the best programmers in that university year.

So you were getting the like cream of cream to show up for Nile Enso at that time. Yeah. I remember at Nile Enso, at least. Obviously worked a little bit differently, but at Nile Enso. Wait, what's obvious? Sorry, obviously the company had brought to go founded and worked at. Let me close out my chapter. Yeah. Basically, I ended up moving to Bangalore from Delhi and starting my career as an Android engineer in 2011, September 2011.

And I worked on the very first app for this now very large medical software company called Prato. And I built their first app. I was one of the very early engineers there. And that was a fun experience, but I was very, very young. And so the founders, they're having the founders are only a year and a half older than me. I was 22, so they were 24. But you know what happened? You need to run a bunch of 22 and 24 year olds together and you asked them to build a business.

So it was fun for a while and then I realized that he had to want to do this. So I want to do something else. I want to do something of my own. And basically after that, I never did a job. I only did consulting. I only did freelancing after that. And we and a very close friend from school, who I knew back in Delhi, both of us were in Bangalore and we did a freelance thing for a bit. We built a bunch of things and we also tried and had a lot of building a bunch of products.

Actually, we built a game. We built a word game. We built a competitor to good reads back then. And a bunch of fun stuff. And we were kind of running out of money very quickly. And I got a chance. I think a bunch of people on Twitter were looking for an Android engineer. But rather, my former co-founder at Obvious Rahul Ghat Salvis. Rahul was looking for an Android engineer. And a bunch of people said, hey, if you're in Bangalore, you should talk to Prathal.

So a bunch of different people tell him about me. And he's like, who is this guy again? So Rahul and I ended up working on one of the earliest apps at Flipkart. That Flipkart I would built. In fact, in fact, this was yours before they built a retail app. And Avers and eBooks platform and an MP3 streaming platform. That's what we worked on. Because we'll flight FLYTE. And that was fun. The most fun thing that came out of it is that Rahul and I became pretty close friends.

And we decided, hey, you know what? We should do this consulting thing together. We shouldn't do this separately. And that's how Obvious happened. It wasn't initially called, obviously. It was initially called uncommon. But we started uncommon in Bangalore around the same time the Nelland source started. And we all knew each other all first pretty much. It was a very small community. And the next 9, 10 years overlap a lot for us.

Because we had, yeah, we'd like to throw each other leads all the time. We've worked on a bunch of projects together. It helped that we weren't competing with each other. I think now that I look back, I think. Yeah, because Nelland so specialized in doing backend services. And like all this fun stuff on the backend. And what Obvious specialized in was actually frontend stuff. So we were doing design and apps or building apps. And so it was a good compliment to each other.

Because every time we, every time someone asked us, I said, hey, do you guys know someone who can build this API for us? I'd be like, yeah, we know the best. We're actually, you should talk to these guys. Yeah. It lent itself well to being paired up together as well. So how did you all decide to start tram line? Is it like after 13 years of building Android apps, you finally got tired of automating the release process? That's, that's not very far off from the truth. Actually, that is the clear.

So the story of tram line, it's funny because I have been mulling tram line or something like tram line in some shape or form for many years now. Many years before tram line even started actually. And before I even moved out of office. And it was the first people who work came and spoke to. And this was in 2018. So in 2018, at obvious, we were consulting for Ola Caps and Ola Caps and Uber at that front were fighting T-Hard.

And so Ola got us in me and a couple of my colleagues we went in and we worked on performance stuff for their driver platform. So their driver, the app that their driver's used that was obviously running Android. And that platform was running Android. And it was built on top of Android. So we did a bunch of work for them. And I didn't actually write much code there. Because I had a couple of folks on my team at that point who were just doing this way faster than I was.

And I was one of the senior most engineers on the team who had that kind of experience. And so my job became looking at the operational stuff of the team. And so this was a large team. This was a team of 20 engineers that was shipping one of the most used Android platforms daily in India. And I realized that there is so much manual work happening here.

Everyone is running around, helping people are just cat-herding and doing war rooms and resolving merge conflicts and no one's sure what is shipped, what has not shipped, etc. And I realized that this is a problem. Things can't work like this. So I tried to help them out without building anything. Just as a process to kind of streamline their project management, streamline their Geras, streamline their merges and branching strategies and stuff.

I kind of helped them with that. I actually did training on Git and branching such stuff for them. But that was this first part where I realized that this is a problem. I think I spent the next year, by the time I came to Nelland. So I spent a year looking up who has done something like this. And I discovered Facebook in typical Facebook style, had written a research paper very accurately titled Continuous Delivery of Mobile Applications at Facebook. It's very straightforward.

And it's a 16 page log paper still available on the internet. Very, very well written, very well researched. It has folks like Kent Beck. I think Kent Beck is one of the authors on the paper version. And they talk about how they built this collection of tools and how they took the idea of a release train and how they took that build tooling around their project management system and their CI and their code to ship continuously or as continuously as they could.

Because Facebook is one of the first very, very large apps on the iPhone. And it shipped on the first iPhone. And then it has always been one of the largest apps in the world. They ran into this problem before anyone else did that, which was that all the learnings that they had for continuous deployment on their back-end and front-end teams are also super large-scale. They all fell flat. They all went away because the app store or the Play Store just don't allow that in.

So this is a very useful paper. And that paper was a landmark in my mind. I remember because I had it multiple times. I printed it out. I highlighted it and I was like, this is it. This has to exist somewhere. And I don't know what I did after that. I remember I did a whole bunch of very high-level thinking that this should happen. That's right. I took it to Nilan. So that, hey guys, this is really huge thing. I remember that thing was, oh, huge. It was so. It was a four-part vision.

It was a multi-year vision into what he wanted this product to be. Yeah. And that was what I thought was version one. So you went to Nilan. So with this and Nilan, so not decide to work on it. How did you all fork out of like pretty much? I remember the scenes after there was a general disinterest. Let me put it that way. And I think a lot of the reason was not just because it was perhaps too bloated, but also because I think none of us had really closely worked in the mobile space that much.

And none of the Nilan's are folks. I mean, we'd played around with the Closure script react natives and what have you. But not really released at large scale, maybe. Those teams were probably like four or five folks at max. So it didn't really hit us. I think if I remember correctly, it had a lot to do with a whole bunch of other stuff that hopefully trampling will incorporate in the future. But not enough to do with releases, per se.

And that time, I think most of the other stuff, like the feature flaggings and the observabilities of the world were things that the back-end folks were just using. It was just a normal sea, right? Like the centuries, the data dogs. There was also a lack of empathy that all of us at Nilan so would have around this, right? Like back-end folks, they're like, this thing is simple. Why aren't you just using the standards that exist already? Why are you trying to recreate the wheel in some ways?

That was the initial reaction a back-end team would have to this. And I think that I can totally understand that, I think, before starting with the mobile app building thing, because you do all of these things in the back-end, you're flexible because you can deploy smaller microservices independently and all that. It all works very seamlessly, I'd say.

Whereas I think when I started building the iOS app and the Android app, if you just follow their app store guidelines or Android Play Store, independently, you can make it work. But just getting everything to work in automated, like, build and deploy, especially from one set-up code base because we use Flutter, right? We kind of build both apps from the same code base. That was insane. So I think I'm glad that something like that exists. Who are some of the incumbents in this space?

There's BitRise, there's a few other places, right? So, Arjun, before we go, she can take a step back and maybe talk a bit about the customer problem here. What is the world without Tramline? Right. So the world without Tramline is effectively a part of your engineering team doing a bunch of coordination work and a bunch of hand holding across teams because you can't move fast enough, because you can't release fast enough on the app stores. So how do you release?

What is the process if you don't use a tool like this? Then there are scripts to deploy stuff. That's there. There are tools that will dump a build into test flight, which fast lane, fast lane, for example, very popular open source project is really the style for open source stuff in mobile specifically, actually, for around mobile apps. So there are things like that, but there's scripts.

And unfortunately, they cover a part of the release cycle and the problem comes into play when you're an organization that is trying to ship a product that you cannot ship fast enough. And therefore, you're artificially slowing down your release cycles. And if you're artificially slowing down your release cycles, the more you slow down, the more people stress. So there is only a couple of times in a month where a mobile first business is actually shipping an app.

And therefore, everyone else in the app is now worried about those two, three days. Because they know me as a product manager or me as an engineering manager, where my team might be working on a feature, I know that if I don't finish this and I don't get it merged by say 11th of October, I will have to wait till 21st of October now.

Because it'll take us 10 days to slowly roll out the build and that it's stable and it can go to 100% and we've monitored the users and crashes are fine, et cetera, it's a very, because things are slow. And things are slow because apps are not like on-premise software. Like apps get downloaded to our personal devices or our tablets and our phones. And the developers don't have any control about what happens to those apps once they're in the consumers' form.

So you can choose to never update the app. You can choose to cancel the update. You can just not open the app entirely, et cetera. So it's a lot more complexity and that complexity is much more similar to on-premise software than it is to actually backend software, backend services or say web front-ends, that's not all. And Ilia, let me try to also add a bit of color from my perspective.

When you say it's a script, let's say you have a team of like 15 developers and you're building an iOS app or an Android app or likely both at the same time. These scripts, you have to make them work exactly like fine-tune it for your app. But also somebody has to be in charge of coordinating all these releases, right? Because there's 15 people contributing code. You have to figure out which kind of feature is ready to go. Does it need to have feature toggling and all that stuff?

And somebody needs to manually run those scripts. And you need to ensure that they're doing it correctly. And that's what I think all this process automation and tooling helps with. Is you take all of that out of like these 15 people, there's no need to coordinate anymore. You just, when you're ready, you ship your changes to or you get your code changes reviewed, merge it into a branch and then tram line will take it from there and figure out how to deploy it.

A good analogy that I think we often like to use. It's a runbook of your perhaps manual release process, perhaps script-based process, but either way. It's a runbook that always executes the same way every single time you run it. And one of the cool things that have just emerged perhaps are now when yourself have seen it also.

Now, because all this work is happening on tram line, when aren't there triggers something or earlier you trigger something, we have a full audit log of every single thing that a person did that pertains to her release. That is all captured as a part of release data. If you made a faulty decision perhaps or a decision that was unwanted. It lives on forever now. Thanks. Yeah, I live on. It's a tram line blame. Yeah. Yeah. I'm reading the Elon Musk book right now by Walter Azixon.

So he says there that Musk will demand dates that next to every single thing that's being done whatever, like a part specification or a release, like for that matter, there would be a name. So that there is someone to blame for the things go wrong. That's very musky. That's one usage of it. Another use of it would be to learn, like, OK, this was the mistake we did. We can learn from it and not do the same mistake in the next release. But just that visibility, right?

Like if you're running it using a script, let's say from my machine, you have no idea who ran the last release, who deployed it to Android. And if you have a question, you don't know who to go to ask. And on top of that, once the app is built, you don't know what commits got into it, what commits did not get into it. So somebody has to sit around and document all this, might as well be a process and a tool around it. Yeah, at the end of the day, it's a binary, right?

We don't have the same sort of visibility. Because in backhand, you usually just like small chunks of work go, perhaps like two or three weeks of words going together. And there are times actually where release is run in parallel. Like if you're going back to Prattles Facebook paper that he mentioned, most releases, they actually run in parallel in big teams, where if a release has gone past the testing mode and is currently in sort of a release mode, they're released slowly, of course.

There is another release already, which has gone into testing mode, while the upcoming release is in release mode. So there can be sometimes up to three releases, which are getting prepared simultaneously. So you don't have to just remember what's going on in this release. You have to remember or you have to know what is going on in all the three parallel releases that are getting prepped.

And in most companies that we have talked to, there is usually one or two people who are like, I know exactly what to do in this release. If those people go away, the rest of the team has no idea. They're like, I don't know, I don't know how to release this app anymore. These are the two or three people who were responsible for it. So the best factor is just really, really low in most mobile teams. So Tramline plans to eliminate that. We have codified your release.

Like, as Akshay said, this is a runbook. This is exactly the steps you need to follow to make this release. And even if the person responsible or the one person who knows it by heart is no longer there, anyone can take the runbook and just run with it. See, if I'm not there, Ilya can run it now. Yeah, because there's one button to click. It's guardrails. We don't even have a button to click anymore, because that's what I was telling Akshay, that I don't want buttons to click.

I wanted to go out automatically on every night, yeah, which is great. There's a useful addendum here that is probably worth calling out. It isn't to say that this stuff doesn't happen on the back end. That would be unfair, because the designers and the compliance folks, the regulatory stuff, all the stuff that slows a release down is still there. That's not changing.

The important distinction here to make, I think, is the level, the abstraction that you're working with in terms of the deployment of the software artifact is entirely different. I think that's where the stakeholders were a part of this process. They have a sense that there's sort of more scrutiny there, because on the web world, even though these folks are participating in this release process, this scrutiny is much less because A, you can deploy more frequently.

So the unit of work is much smaller. And B, you can take it back if something goes wrong. Obviously, you don't want to keep rolling back also on the back end. That's a terrible waste of time. So you should still avoid doing that. But you have the optionality to do so is still there, which is why the process, although not entirely distinct from the other side, is more important on the mobile side.

Yeah, I think like Pratul says, it's very much like you're shipping your code to be run in somebody else's computer, which because that is what it is. So it's hard to change after you've shipped it. You don't have any control over what's going to happen to it after. Yeah, it's shooting a football out in the air, type of situation. So who are the incumbents in this space? What do you do differently? I think one of the ways that I like to think about this is direct incumbents and indirect.

Like direct competition and indirect competition. And direct competition is, of course, folks who are building products that overlap in many ways with transactions. So three examples that come to mind. Immediately are Microsoft App Center, Betrace, and Runway. And all of them do things a little bit, a little bit differently. Some of them prioritize a very wide variety of features. So App Center, for example, is very comprehensive. It has a CI pipeline.

It has this internal beta build distribution. And it has stuff for React Native folks. It has over the air updates for React Native apps and stuff. Betrace is just CI CD. They were one of the first very well done CI platforms that focused on iOS and Android. That's their thing. Runway, I think, is the closest to what tram ride doesn't the sense that it is a nice, codified, release process, which gives you those guardrails that you can use. So there's a point about direct competition.

And I think this probably is true for most of the market. Our fight is less towards direct competition and more towards indirect competition. And that is confluence and Google Sheeps and Notion. It's not possible that teams aren't solving this all gradually. So everyone needs a release process. No one just does this at all. If you're even marginally serious about your app, you have a release process. It's just that the first thing that they'll end up doing is just write it in a Google Doc.

And at some point, it gets upgraded because someone's maintaining it. And then at bigger companies, we've seen five, six-page-wrong confluence documentation, which is maintained by a whole bunch of people that do this and do this and let this person this function for this part and so on. And that is really hard to get rid of because that is lured. It sounds like it's true.

And I've often found in our customer conversations, and even in our research, which we've done, it was harder for us to convince people to give up their documentation and move to a system that can do the execution. That's an interesting thing to call out the direct and direct competition. Why is it hard for them? What stops them? I think because they're not used to a process at all. They are used to completely manual stuff. So they have bare-bones CI pipelines. It'll just make a remote built.

Like all they want is a build on a CI server. But they don't do anything with it. They don't send that. They haven't scripted their pipeline to deposit the build into test flight, or to play store, or whatever. So what the pipeline does is it basically compiles the code. And then a person steps in. They download the binary files and it was like, or a 4.2, somewhere. It's very manually driven. It's a person's job to read that runbook. And then, of course, maintain that runbook.

And they have to remember that this has to be updated because otherwise something will fail. What tends to happen with manual processes is you start to change things over time. You see, oh, there's a better way to do this small thing. And there's a different way to do this. And you change those things. And now every company who's doing this ends up with their own customized version of their own workflows.

And you don't want to go to a tool because it maybe doesn't do five of the 25 things that you want, that you want to specifically control. This actually goes back to something that I was talking to Akshay maybe a few months back is how are you thinking about acquiring customers?

Because established companies that have their own CIICD very, very specific document that this is what we do step after step will find it hard to move to something that is streamlined because it might not do a few of the things that they want versus maybe smaller places that don't have an established process. They're just looking to get started. Kind of like Ruby on Rails back when you started. It's very opinionated. But you know exactly what you're getting. And you don't have to think about it.

I think one of the ways we are planning to, we think where we can work with this is we ask people, we model the release process in timeline as you would do it in your company. It's not, timeline is not opinionated in how you should run your release. It's not actually opinionated that way at all. What it is opinionated about is like whatever you do, you need to put that down. You need to put that down as a step in the release process.

So that is I think where we differ from some of the incumbents as well. We will model your release process, whatever you follow because one of the other things is mobile doesn't have standards around this. Mobile teams do not have any kind of conventions or standards around how to run. I mean, I'm not saying any kind. There are some standards, but everyone has their own way of doing this, which is not true.

And back in I have noticed there is a certain amount of the DevOps sort of guidelines that exist. Yeah, the types of deployments you can do canary, you can do blue green and all that. But like how to get to that is a very straightforward. It's very standard. So if you actually go back maybe eight to 10 years, there was a whole type of role called release engineers and release management. And so you would have your dev team who was building it.

There's a support team, there's a DevOps team, and then there's a release team. All they do is figure out like what branches to merge, how to merge them, merge them, resolve the conflicts and go through these steps. And that today, that's gone, right? Like that role doesn't exist pretty much, except for maybe some very, very older companies who haven't changed their processes because it's all automated now. And that's what you're trying to do for the mobile world essentially.

I mean, it helps to bear in mind that mobile is very, very new. Like the App Store 14 years, I think 13 or 14 years is the App Store's age. It's very new. And a lot of the very large mobile first companies that people associate, when people think of an app, some of the largest successful companies are very, very new. Say, Swicky, Go Jack. Or even like Uber, Facebook, they're not that old, compared. Yeah, Uber is I think 2012. I think it's like just over 10 years old.

So it's not surprising that the first generation of companies that became very, very large and we've had done our research on this. It's not surprising that the Uber's and the lifts, you know, and the Spotify and Shopify and stuff, all of them built tools like Tramline internally. They faced the problem very, very fast. They were hitting huge scale on this app that they were shipping.

And now that we're in the second generation, the second decade of the App Store, like it's kind of ridiculous to expect now that the next Uber that happens, or like the next large scale mobile first business that gets built, they will also have to solve the same problem internally. It's kind of ridiculous. It's time to democratize some of those ideas that we've understood that are good ideas. I'm kind of surprised that none of those companies open source something.

And then AWS will just pick it up and do the service out of this. A few of them have, I believe, Shopify's ship it is open source and it's already written in a plug-in-based way where you can write one thing on top of it. You can write your own plugins to make your own process on it. But of course, writing that plugin is expensive. It's non-trivial to do. Yeah, no one open source their platform. People have open source parts of their tool.

People have written about it extensively, even if they haven't open source it, there's a lot of writing. And we have learned a lot from that writing. We've in fact spoken to some of the people who've done that writing and understood what they were thinking and like how things were. We really hunted the internet for some of these videos around like five years ago, 10 years ago with people talking about these things.

In fact, a lot of the UI that you see on Ramline is just directly lifted off of the few screenshots that you can find from the internal tools that these people have built it's based. So the stuff we just realized, this is great, they already figured this out. Has this to this? So talking about open source, you offer a Ramline, like it's fully open source also, right? So tell us like what led you to go down that path, how it's working out?

I mean, when Pratil and I were speaking about this originally, which was when we were both in our previous jobs. And when we were speaking about this, I think it was very clear to us that this would have to be open source. There are reasons for it to be open source that make sort of longevity sense. And then there are reasons for it to be open source, which are derived from the fact that there is no reason for it to not be. So it's like that kind of lens as well.

Of course, the second one is philosophical in nature. You have to buy into it, you have to believe in it. And I'm sure everyone knows the folks that I'm talking about here, started the open source evangelists of the world would say this. And I think we roughly fall into those camps as well. There was no reason for Ramline to not be open source in the sense that there was nothing much to lose here.

Of course, when you're such in such an early stage, you can argue about it like what if the AWS is of the world coming and take your software and launch a service and all of that. I mean, we would be humbled to if they did so. Please take our software and launch our service if you're watching this. But it isn't really just about that. In a similar way, Fastlane has forever been open source.

It makes sense for this kind of software, which is trying to build a standard to operate how things are done. It is essential for everyone to know what we're up to at all times. In a way, you're trying to get collaboration, but also with a community, you want to define the standards because there is an standard, right? And one way to do that is open source code. So if they don't like something, they can contribute a different way of doing it.

Is it part of the calculus that also, if you have kind of critical mass, then you can also influence Apple and Google Play to modify their APIs, do stuff like that? Yeah, that would be great. Actually, there's a whole bunch of stuff that's missing as of today, which disallows us from giving you all a better experience, right? Like there's just APIs are lacking. Documentation is very often lacking around a lot of this stuff. Yeah, Erna is well aware.

I don't think that's an active goal, but we hope that this does change some stuff because it's so visible that, hey, okay, these folks are trying to solve this problem here. It seems like we're not providing them enough information to make it better. We must do something about it. It's hopefully an emotion or... Enough of an influence to infancy big companies. Good luck.

We have comments on Google Issue Tracker around their APIs, which all these companies that we mentioned, Shopify, Etsy, every one of those people who have built a platform like this, there's a comment there saying, please fix this. All the incumbents who have come have actually gone there and written a comment and we're like, okay, yeah, we see it. These are the people who are building these, or these are the people who are actually to platform here.

Yeah, I'm surprised that Google hasn't done anything in this space because they've got a bunch of Android and iOS app. I don't know how many, probably like over 50 different apps. They have their own platform internally. We know this. Yeah, they probably have a really good platform internally. Exactly, yeah, but why don't they externalize it as a GCP service? And see, I think this is where one of those differences with Amazon would come in.

If Amazon had produced 50 apps internally and had built a platform, I'm sure we would have seen like an AWS service about it already. Whereas Google probably likes to do excellent things, but it's not enough to get promoted. Right. Right. They haven't seen the opportunity to like make a thing about it yet. Or if they build it, they'll kill it after five years. One year. Yes, that too.

But I feel like the folks are using the developer console on Google at the very least upload a binary and then roll it out. I think that solves most of the use cases for most of the people that platform. And I feel like that is enough in their heads, perhaps. I mean, this is all conjecture. It feels like this is good enough today. Of course, when we are talking about online, we're talking about the 90th percentile, right?

Like we're talking about folks who are at the top of their game, essentially the top of the top mobile first companies. Like us. Yeah, you're pretty much here. Exactly. Or who is crucial, like whose business is mobile critical? Their business would stop if the mobile apps are not shipped on time. It's kind of interesting because you need some experience and expertise to actually even realize you have this problem.

Because if you take like a student doing a pet project, it's not a big deal to upload something to the web console, right? They may not even think about it. But then what we are realizing now, we are a very small startup. And we save a lot of time, but also a lot of energy, but not having to do all the mental work. So actually startups probably get to benefit from this a lot. They just don't know. Maybe they don't think about this.

I think you folks are definitely, I would use the word over-engineered in a slightly good sense. I mean, it's all good. I told you, Arnav. I told you. I told you. No, but you're absolutely right.

Arnav, to your previous question, if there is like a Ruby on Rails version of tram line, this is definitely something we think about pretty much every week, breaking through the barriers of existing work that people have put in, and then not necessarily swapping it, but augmenting it with the more streamlined experience is initial work, which of course, we also had to spend a day together to do this. That's true.

The slice that requires this to be a Ruby on Rails experience requires tram line to be a Ruby on Rails experience, which is basically the one-engineered framework, they want they like to call it, which essentially means it's a full stack framework, which means they do everything from top to bottom, you're vertically integrating all the sorts of stuff that you do in a release in one single place. And that's definitely something that's on the cards, but not a high priority at the moment.

But yeah, it is, I think, valuable to both enterprises, just to draw this analogy out even further, Ruby on Rails is used by us, and Ruby on Rails is used by Shopify's, and the intercoms of the world also. It works for everyone. You just have to scale it differently. So it's been about a year now, right? And you're three people who does what, how are you like distributing, deciding who works on which sides and all that?

Akshay and I take care of all of engineering, product, and engineering, related writing, support, in fact, some amount of sales as well, Pratulitex care of sales and product as well. So right now, I think we're such a small company that it doesn't need to have very clear divisions, like you do only this and you do only that. I was actually having this conversation with Akshay yesterday. It's sort of like this week or this next two weeks, needs to be completely focused on just this problem.

So you go do that and why I take care of everything else. The other side is like, okay, this week, we don't have a lot of engineering work. So let's just, you also focus on sales, you also work focus on marketing. It is a bit of flexible roles right now, but yeah, Pratulitex, this is the kind of division we have right now is you. There are some baseline roles. That's what you need in a start. Yeah, that window is all the engineering. This window does no engineering. That's a big difference.

But all three of you like code, all three of you do sales whenever needed, all three of you do. No, I barely written any code. I've done a bunch of UI work early on. I did a bunch of UI work. So there are some baseline roles, I would say, sort of initial roles. And then there is some minor overlap here and there because of from an engineering point of view, since both need and myself are there, it's slightly more engineering heavy happens to be engineering heavy at the moment.

So we tend to balance out the whole equation of the sales marketing engineering support, the whole loop. It's possible that like sometimes the both of us spend more time on non-engineering work to balance out the work Pratulitex putting in. But yeah, we do have some baseline responsibilities and we are there weeks where like Pratulitex, you can get rid of sales, which we have with a couple of potential customers. And I am the one only doing engineering. I mean, right now I'm doing fundraising.

And I've only been doing fundraising for three weeks now, I think. You look exhausted, man. Yeah, I don't think I've spoken to bigz many people in three weeks, F-Burge. I met so many new people. Tell us about that side of it. Like how's the money flowing in? How did you get your first few customers? How's that all going? What are you looking to do with fundraising and all that? So the first few customers, we just threatened all of them. Have you went and threatened all our clients?

Effectively told them, hey, we are doing this thing and you have to listen to us. Clients from consulting time, OK? Yeah, clients from consulting. And all of them were like, yeah, I can do something. And we'll talk to you. I was a very, very slow person. I think personally from me, theoretically, and in all manner, understood that the early sales process is very, very slow. Like it takes a very long time. But I was still constantly surprised at how long it took, OK? I've heard it.

It was such a drain. It was such a slog and just understand. At some point, I have to write a blog first about this. Like my personal experience of understanding the meaning of living through what the word positioning means. It's very easy to say, oh, your product positioning is not right. That doesn't mean anything to me. But to feel it, once you've spoken to 100 people, like 100 different companies, and then you realize, oh, they're just not getting it. Like, what am I saying wrongly?

I'm not saying this the right way. So that it was a challenge, of course. But I thought it was very exciting. I get excited still when someone tells me about a thing from their personal background, which theoretically I understand. I guess you're retically no enterprise sales cycles are long. I sure, retically know that these things, I've never done it, but I sure, I technically know this is what's going to happen.

But when someone tells me a person anecdotes about something from there, here, you're like, I meet someone and they'll tell me, yeah, 10 years ago, I did this. It's very fascinating to me that, wow, it's almost identical. There is no difference in this stuff at all. It's very first principles the way that this happens. So for us, our first users are all friends, like for everyone else.

I've had a lot of friends who obviously have been mobile engineers, and our mobile engineers, they're building site projects, hobby projects. Some of them are building new businesses. Like you guys happen to be in that category. So those folks definitely became our earliest users. And some of those folks became early customers. They can work to customers. And correct me if I'm wrong, I think it took us seven months to get to the first user, right? Six, seven months. Yeah, I would say so.

So is it seven months after we've already had the product, or is it seven months, including building the product? No, including building the product. Seven months of going from zero to, basically, zero to one where one is a production release. Or rather, someone made a production release to the app store. I think it was a place to actually be to the place or using traps.

It was the place to, that was basically our benchmark because you can do all sorts of releases to test flights in the Firebase app distribution to the world. But the serious test of the platform is shipping it to the users. And so that's where we measured the benchmark. OK, this is how we counter-release. Everything else is sub-release. What's interesting is actually add to this. Is that from Jan, it took us six more months to get our first big enterprise customer.

So it took us like a nearly a full year, even though we're in a market where we definitely, we're given that we're talking we're in Bangalore. And like the three of us have been done engineering in Bangalore for more than a decade. And we have access to so many of these companies, even then. And we did speak to a lot of these companies. But the value of land to love to get them to understand the value and for them to agree that, yes, we will try this. Yeah, a year of work.

So if you were to say this on LinkedIn, you would say like you leveraged your robust network of previous connections cultivated during your consulting times. It created synergy. I will record it. Listen to this recording. And I will make that a positive. You could call this red flags or whatever you will, right? But this product is quite complicated to build.

This is a non-trivial thing to ship in two months, which is like the general thumb rule of you ship three months or whatever to your first user. This was literally impossible. It would be basically Frankenstein project if we had shipped it like that. It would be dysfunctional. And so because it's such an integration heavy sort of thing, and it requires so much domain context to do, it doesn't make sense piecemeal until a whole bunch of things come together.

There is obviously, I mean, looking back, perhaps there is some stuff we could have definitely left out, but it wouldn't have gone from like eight months to three months. It would have still been like five months or six months. Yeah, so you call it what you will, but I think that time elapsed was necessary. And of course, this is roughly the first time for us, right? Also trying to sell this. And so those cycles are also longer.

And not just that, it's just this sort of stuff isn't out there in the wild. This isn't generated way, and this isn't a version control system, and this is into Jenkins. It's an entirely new subsystem. It sort of comes in the purview of wild DevOps, which has become sort of famous over the last five years, four years. But again, there was nothing to compare it to that this is like X of mobile engineering. There was no analogy we could draw when we were selling it to people.

So we had to almost start from scratch. We would have to say, OK, this is how you do things now. And this is how you do things with tram line. And by the way, we have learned how to sell this by failing at it for so long. I wouldn't say we've learned it yet. I think we're starting to learn. We're still always moving. Yeah, I don't. I'm saying we've learned it in the sense that we've done one sale, big sale. So in that way, I'm going to give ourselves some credit.

But I think this learning process is going to continue because none of us had actually sold a software. We were always on the other end. We were always the buyers. Actually, that's the point. Remember, we were discussing this today or yesterday that even as buyers, I don't remember ever paying $100,000 for a software. Not this bigger software, yeah. Exactly. So the three of us have also both of you, like you know, you win at AWS and Google.

And you've actually had that experience of how large companies think of buying software and using it and deploying it. So you've probably seen six-figure contracts, seven-figure contracts, or your career. We've never done that. None of us have ever seen that happen. Or at least it's familiar to you in your vicinity if not in direct contact. It's a bit different, I think, in Amazon. There's a thing called NIH, not invented here.

It's almost like a negative thing right now because Amazon would almost never go by some off-the-shelf thing or pay hundreds of thousands of dollars. They would instead like take two years to kind of figure it out and build it internally. And eventually they'll release it as a AWS product. But that's for like, infrastructure products, right? But things like the use exchange for Microsoft, the use Slack, oh, I'm pretty sure some, you know, conqueror for expenses.

All that kind of non-core business stuff. And I'm pretty sure like this Slack contract is probably an emilians, given this scale of Amazon. I think Amazon is slacks if I remember the biggest installation because think about the number or employees Amazon has. I don't think there's any other. I'm pretty sure Amazon is a large, just imploring. Wouldn't be surprised, yeah. Well, Microsoft will come close, but they would use Teams. Yeah. I think it's about positioning, I think, is very interesting.

My larger team at Google had this experience where they were selling Cloud Run, which is a container of the service. And they would come to customers and customers would be like, is it like AWS Lambda? Or is it like AWS Fargate? And the team would be like, it's neither. And then the customers would be like, it's just hard to explain. If there is a box in their architecture and just say, okay, so you just unplug that thing, plug our thing instead, it's just so much easier.

But then if you say like, oh, you unplug half of that thing, one third of that thing, and also half of that thing. And then you like rewire the whole thing, it just becomes a much harder self. Too much changes for companies to take in all at once, yeah. I actually wouldn't be able to tell you the difference between Lambda and Fargate itself, even though I've used both of those. Because I think a lot of those AWS products and this is not disparaging, I think.

They have, at the surface level, fairly subtle differences. You could lump them in roughly the same category. But like when you dig in, oh, okay, actually, this is a pass, but it's not localized. Or this is a pass, but it's not on Kubernetes or whatever, right, like that kind of thing. But it's still in the rough category of that, but it's slightly different. This is serverless, but still for deployment, really. It gets harder to remember the subtle changes that these products have.

I feel like there's one more on AWS that does this thing. That's not Fargate and that's not Lambda. It's like Heroku, but on AWS. Oh, yeah, open chef. The team in Germany that ran it, oops, works. Oops, that's correct. Yeah, there's actually another one, which we don't need to get into. But I think there's a few of those out there. I think what tends to happen in AWS is also, teams are very independent. So initially Lambda and Fargate were very different products.

But over the years, as they grow and get bigger, Lambda is introducing ways for you to bring your own containers and stuff. And Fargate is getting closer and closer to the serverless thing. So I think if you were to start today, there's like, yeah, they're almost very similar things. There are differences, but yeah. And Google is like in the typical Google factions. You all doing serverless wrong. Here's called run. So yeah. Yeah. This is the best way to run this.

That's actually in one of our positioning conversations, which we may perhaps revive when our shot, we used to call ourselves like a Heroku for mobile, which doesn't really land that well. We call it a word cell of mobile. I'm sorry. That's what we used to call it. Similar things. My personality was circle siya of mobile. Yeah, that's correct. Yeah. So how did you like during the long build process, right? And you're starting to get your first enterprise customers now. How did you fund yourself?

And where are you? What are you trying to do with raising funds? And what's the next step? So I raised right before I actually joined. I actually not I had a couple of months before that. I joined this accelerator program called on deck. They have a very cool founder fellowship. It's called on deck founder fellowship. It's like a eight week or 12 week long fellowship program for founders.

They basically have programming around getting founders into groups like discussing stuff and like sharing their problems, et cetera, et cetera. It's almost like every month's group terrapizing each other, all these founders. And it is everyone who usually joins the on deck founder fellowship program, they're all very earned. So they're all usually at an idea stage. So that experience of me was super fun because I got to talk to all sorts of people who had all sorts of ideas.

And they were all very excited about these ideas, but they had no idea what to do or like how to build this into a business. But they all were excited about this thing. And so that was very useful for me personally. And coincidentally, the on deck program also that year offered some founders the option to raise money from them. So that was that pre-seed round. So I did the program. I agreed to take on their pre-seed thing, which is $125,000. And that's the raise that in July last year.

For what percentage of equity? It was standard 125K, some percent, pretty standard thing. OK, so like the Y-combinator or the standard deal thing? Yeah, like the older Y-combinator thing, basically. And right after that, actually, it's been taken to break for a bit and it came back. And he joined up full time as this thing. And then joined us in January, yeah, early January.

So we're very careful about how we use the money, where aware that we have taken venture funding, even if it's low friction gap, it's accelerated money. So it's a little of friction. But we are aware of the fact that if we get on to the way that the valley likes to call it the VC train, then it kind of forces you to go in a certain direction at a certain pace in a certain time. Towards a certain goal? Yeah, exactly towards a certain goal. And both of you know this very well.

You've been talking about the senior podcast over and over. And I don't think that venture capital is a bad idea. I think that the way Silicon Valley has done when you're capital over the past 10, 20 years or whatever, post 2008 perhaps, I don't know. That has taken a lot of what could have become sustainable businesses and made them become unfortunately unsustainable, right?

Because once you've taken 10, 20 million dollars in funding, at that point, you have to become like a multi-hundred million dollar business. When so many of those businesses could have been very well run, 20 million dollar smaller businesses with a small team and they would already very happy. The founders would be happy. The early angels would be happy. The early investors. So I'm not against venture capital, but I think the slow and cheap capital, like slow VC mode is the way to do this.

Some of those businesses would not have been able to actually reach that point of sustainability without the funding. But some of those could have. But they instead chose to take the money and then they basically shackled themselves into. Some of those the ones that could have ended up in the hype cycle anyway, where they could have avoided it, perhaps. So we're cautious about that, the three of us. Yeah, we want slow living, slow VC mode. What is slow VC? I mean, that is basically what I said.

Like I'm not against the idea of venture capital. I don't think the three of us are against the idea of venture capital. It's just that be very, very, very mindful that you're taking somebody else's money, which means that the only reason they're giving you this money is because they want to make more money off. Then that's not right. Exactly. So you want to be very mindful of what that X is.

If you end up taking 20 million dollars when you barely have anything, how are you going to return to 200 million dollars? Like you're going to make it somebody else's problem at some point. You're going to be like, oh, that's been six years doing this. I'm going to make somebody else see you. I'm going to leave figures. And we've seen this over and over again, every month, how can you somebody will write a story that this destroyed my business? I could have done this differently.

Anyway, at the moment we're raising around, we like to think of it as a bridge, kind of like a middle ground between before we get to the point where we decide if we want to raise seed. We're very consciously avoiding venture capital, like basically avoiding VC funds in this round. And we're only raising from angels. So are you like looking for smaller angels?

OK. Yes. Only from angels, engineering leaders, leaders who have experience in DevOps platforms, or people who've spent a lot of time at very large mobile first companies. So some of those, a lot of the angels right now, people who have experiences like that. And so of course, they're also looking for a return. I mean, I'm not saying they're not looking for money. But their individual capital is very limited.

And the reason that they're investing in us is because they, either they really enjoy us as a team. So they know, as personally, and they just want to support someone who they know is doing something. Or they truly believe that this problem is real. And they want to try and help us. Or if some of our angels have been very, very proactive about offering support that closes round out. And then let's talk late October or November.

And I want to understand how I can help you shape your US GTM, for example. And that helps. That's the kind of support that you want. It's very specific. It's very focused because these angels are unscended. I'll do this, this, this, this. I've done this for 10 years really well. And I can help you do this thing really well. And I really like what you do. It's nice. So how are you going about finding these angels? Is it the same robust, what did I say earlier?

Like leveraging your robust network of? Correct. I'm leveraging by a robust network of professional connections and then asking them to leverage their more robust networks. So you're like directly reaching out to people one on one. And are you looking at angel networks and things like that? Or you're doing like literally one to one reaching out to people? I have looked at some engine networks where I knew an engine personally. So some of those have happened.

The first set of like, I think 50 people, like 30 people that are each are two. I knew everyone personally. And then they, they're some of them who agreed and then some of them who didn't agree because of whatever reason. They ended up connecting us to other people. And now this happens on a daily basis. And daily basis, somebody will say, yes or no. And they're like, you know what? You should also talk to this person. And this person, this person is really good at this.

What are the months I'm talking about this stage? Like third person. Par angel. It's like 10 to 50 K. It's usually the jacks I say 10 to 50 K. But you're also not just looking for that, but you're looking for people who are established in this space who can advise you on it. Yeah, some align me. Correct. I'm wrong. I don't think we're spoken to anyone like completely. Yeah, that's the, I guess, the value of going through the robust network.

I mean, you'll end up finding folks who've kind of done this. And I think the folks who haven't generally just tend to kind of say, no, anyway, or like they're too far away from the problem, they'll be like, I can't form a thesis on this or whatever. I can perhaps connect you to folks who have. And then that's how the network grows. It kind of just end up it is. It ends up, it's not that we're actively looking out for the folks. It's just by design, it happens to be that way.

How does structurally devol the paperwork? By the way, where are you guys incorporating this? At the beginning? Oh, it's Delaware. Where are Delaware's you call? And this is, this round is an angelist, RUV. It's a roller vehicle, which is a really fun product that angelist has. If you're not aware of it, RUV is still a safe note, like you're raising on a safe note. But what it does is angelist will create a special purpose vehicle.

And everyone who invests money, they all become founders or whatever shareholders in that SPV. And then that SPV itself, that roller vehicle itself, is just one line item on your captivity. So it maintains a very clean, captivity instead of having all of these people who have little, little, little, little amounts. So investing in an RUV itself is also super easy. Like, angelist has really made the process butter smooth. And that's what we're raising using an angelist RUV.

So basically, if you find the friend, then you just send them to angelist to put them on you there. Yes, yeah, we just send them a link. And angelist just guide them through the process. Angelist will give them all the details in it, because I've given them details of our previous round and all of that and are linked to the tech and like risks and this close and standard stuff. But it's a very neat platform. And how about like board seats and all that? None of that exists in an RUV.

It's none of that matters. That's what happened when you end up taking a direct investment. Get to VC. Yeah, even a microphone which you'll want to cut like a 100k check, like a 200k check, they will start to make a little little noises about that. You know, like we want preferential shares or like we want to have what like, can we change this, amend this thing? When an RUV, when they're angels, it's literally a duplicate of the by-combinators they've document on by-combinator.com.

They're like, I know that it doesn't matter. And it's at the same percentage, the same kind of deal percentage is based on the amount that they're putting in. Yes. And what are you planning to do? Like what's the future for a timeline? What are you planning to do with these funds? I mean, we have a whole bunch of experiments that lined up, some are experiments, some are where mostly convinced our features worth building.

There is obviously the default catchup that Tramline has to play, which is to be open for as many people as possible, which is trying more integrations in on a consistent basis as people need them. So we have a certain lot today, but a few other client would come around tomorrow and they will need to certain other lot of integrations. So that process is forever ongoing.

Obviously it'll reach point of closure when the most important ones have reached our system because there's only so much diversity in the integrations that we play with. So perhaps it's like a couple, and now it might become like six in the next year or so. That's about it, it'll probably stop there.

This is sort of a thing that Tramline is inherently has as a platform, which is integrations, but there's of course a lot of other stuff that it can do to make it more Ruby on Railsesque if we wanna call it like that. There is of course the part where we build your apps as well. And I think now we've also spoken about this before.

So to be clear right now when you use Tramline, it's basically the runbook for building and deploying and releasing your app, but the actual build is happening somewhere else. Like in GitHub or in our case, we use bitrises for actually building it in a container. So you want to provide like a mechanism which will make it even smoother, I think the UX, because as we were figuring out there's so many moving parts, certificates and all that to pass around.

There is a level after which you can't really do anything. Again, the platform sort of is at the end of the day first shipping mobile apps to the stores from the Googles and the apples. So you have to abide by their rules and you have to abide by their APIs. So we're restricted by that, but definitely having a lot of those baked into the platform is a huge load of people's tests, like trying to integrate stuff in other places and then integrating Mac here. It's a much simpler experience overall.

That's kind of like the distribution or the building part of things, the CI CD part of things, let's call it. Yeah, a bunch of stuff on sales. One of our big plans is also to actively start focusing on the US and Europe market. Right now it's a focus, obviously because of the geography we're based in, has been India, Southeast Asia, but also with this race, we're going to actively start looking at North America and Europe as well.

And I think finally we'll try to wrap it up quickly, but it would be a crime to let you all go without talking about like the dev agency stuff because all three of you worked in some of the best boutique consulting dev agencies in India. Tell us a bit about how that goes. Where do you see startups looking to use their agencies? How do they go about selecting them and all that?

This is really funny because I think once or once a week somebody asks me this, still it's been two and a half years after moving out of an agency business, I am still approached once a week by somebody that, hey, I have this idea and I want to build this app which will do this and that and that. So what should I do? Who should I talk to? And it's an issue because most people don't really have the kind of budgets to afford a good agency.

And in a good agency in India, even in India, will cost you $60 in our minimum. And like, of course, going up to lip probably 100. And the vast majority of the people don't know how to even find these agencies. I think that's a very big challenge because these agencies are getting the work from word of mouth so they don't bother much advertising themselves anyway.

So the bigger challenge that I see with startups is how do you sift through their $20 in our work or the $30 in our work, which is almost all of the work that you can call one of the kind of agencies that you see and figure out who to pick there. That is what it's like. I've actually helped a couple of folks who have met and like friends who are doing something new in helping them do this.

And usually I tell them that if you like the leadership team, if you think that the founders or the team that is running, the team that you're working with, like the leads or whoever is running this team, if you like them and if you think they like your idea, at least that should be okay. But if you think that when you're talking to them and they're like, yeah, whatever, we'll build everything. You want to say, yeah, absolutely. That at that point, I see that as a very big red flag.

Like you want a mass market agency at a low price point, you want them to care. And you know you're not going to get the best work and they know they don't can't produce best work. That's fine. Everyone already knows that. No one needs to speak that out loud. My advice to most people is that if you meet someone, if you meet an agency where you felt like this person I was talking to, this team lead, they cared about kind of cared about what I was building. I think that's good enough. Just stay.

Go ahead. What kind of projects do you think it works really well in? Would you say this is for design? Essentially you're outsourcing some parts of it, right? Like how about developing your core application itself? Is that something? I mean, that is something that we have done. All three of us have done, right? Building someone else's core, whether that was backend or front end, core business application. And you get a consultancy usually or you get someone with an expertise.

They don't just build this thing for you. That's how we have usually done. They'll teach people in your team and they'll mentor people in your team on how to build good software and how to build a scale, a software at this level. And that's what you wanna look for a little bit. Not just someone who will come, build this and just leave, but also someone who will come, mentor your team and who will build your team a little bit for you. Because yes, there won't be around forever. That's a thing.

Both obviously in the lens, I did like one year, two year contracts. It was not a three months contract ever. They were all long term contracts. But what the most of the time spent there was not just building the product, but also building the team. I remember from early days at Gojek, the entire lens or team helped build their closure expertise, which was basically the central allocation service that did allocating of drivers to all their bookings.

Like there was one central service that did that. That was written in closure and we didn't just build the service, but build the entire team around it. And now the team grew into like a 30% person team and like still going strong. So that is kind of what you would want to look for. It is not about solving one particular problem. Like you won't probably get someone to solve because you are the domain experts. You won't actually get someone to solve a particular domain problem.

As a customer, you are the domain experts. You won't find like someone comes all this logistics problem for me. You have to gain your own expertise in that domain. What you would get, but is people who know how to build and scale software at the scale that you are at and help your team? Because most of these startups, most of these companies, even if they're not startups, they have a very young team. And it's hard for them to hire senior engineers.

That's actually one of the big reasons why a lot of the times, at least Nilla and Sogot hired, just to get experience talent in play. Boots trapping their own companies. Boots trapping their own, yeah, pretty much. Because a lot of these companies kind of hire en masse and punch junior folks at the same time. Now what do you do with them?

You don't have enough people to train them or not just train in sort of like a boot campy way, but like show them the ways of how a product is developed or like an engineering artifact is shipped. But again, I think the bare minimum qualities actually just track record. It's as simple as that, as with anything, right? If you've done this before, you're probably gonna be good. If you've done this before well, and that's not very hard to find out.

Of course, as Prattal said, like we've never really marketed ourselves, because we've never needed to, because the demand has always been in surplus against what we can actually supply to the folks coming into us. A lot of the time it was about rejection and not. Yeah, it was about, they want to hire someone. Is there a team willing to get someone in? Is not just the CTO who's deciding that they need an expertise, but is the team actually willing to like make the change?

Because one person deciding, or maybe even if it is a leader deciding that the engineering process or the engineering culture needs to change doesn't really affect it. Unless the team is involved. There is a very similar conversation that I was having with another friend of mine recently, and we were just talking about, I don't know if this was true a decade ago, roughly when we all started.

It's just perhaps more so true before that, but what we've realized lately is that there is definitely a shortage of agencies lately who perform sort of very high level in areas that are hard to do. So a lot of sort of like this low latency, high throughput work. Those are hard computer science problems. Data pipelines. Data pipeline work. Large swaths of data handling, stuff like that.

There's very few folks, at least from CarPurview, I might be wrong on this and I don't have enough data on this, but just looking back 10 years, the folks who are around looking at folks around now, I see a general lack of this. And perhaps that's because it is a talent that requires more skill in hands. It's harder to do, but I also think a lot of those folks who could have done this have just been swept up by the fangs of the world and the big companies of the world.

Or they just get tired of this. Also that, yeah. Or they just retire. They also retire, yeah. I don't know if it's sad, but it's an opportunity if anything. But of course you have to buy into that sort of business building, which is kind of linear. And slow. Take time. Okay. So I think we're well over what we had initially told you will record for. So let's wrap this up. What's a book or a podcast that you're listening to recently or something you would recommend?

Very weirdly, I just finished reading this. It's all top of mind. I have a terrible fear of flying. My fear of flying is so bad that I recently made a trip to Rajee and I fainted on the way down and then I had to take a train back. I was so bad. I remember because you and I were going to meet for something and then you said, I'm sorry I can't meet today. I was like, that's totally cool. And then later on, I'm talking to you like I fainted on the flight and I'm stuck in a ranch. It was not great.

I mean, yeah, I've tried a bunch of things that doesn't work. It's been really not eye opening because I think these arguments that people make about flying. I know them all factually, right? Like it's all obvious. But it's just a lens in which was presented. This is a book called The Easy Way of Flying by the guy who wrote the book to quit smoking, which is Alan Carr.

It's quite a popular book at this point, but I think the flying book is in that popular because I FOF isn't that big of an affliction as the grid smoking is. That book has a fantastic lens that as you're about to read it, feels like it's easily challengeable by the person who is already afraid of flying. But by the end of it, it's impossible to challenge it. So that lens shift was quite fascinating to me. And it helped, I think, quite a lot. When are you taking your next flight?

I'm taking it very soon. And I'm all ready for it. So I get afraid like weeks in advance, right? And not this time. Good luck to that next flight, yeah. Yeah, need Pratulia, go ahead. I have actually not read anything. You know, why like what I was reading last was the memory police by forget her name. Yoko Okaza, I think. Yeah, the famous, I mean, I want to read some Japanese authors. And I like sci-fi, so I was reading memory police.

And I really enjoyed the very almost poetic way of the stories written. I really enjoyed that kind. It's a very, I'm not going to say Murakami-esque, but it sort of touches that. It's not as dark, but yeah, that is what I was reading last. And I really enjoyed it. And you have been learning Japanese, or both of you have been learning Japanese for a while. Well, you follow me on Doolingos, and you know it happens very often. Yeah. Well, I don't know what language you do.

I just see progress updates and all, yeah. I mean, we haven't officially cleared the N5. There's like a leveling system in Japanese. But I think we're roughly around that level. You'll be like ready to fly to Japan, and no Japanese at the same time. I think we can buy bread and milk pretty easily, and rent a flat out here. I mean, you're done. That's all we need. House and bread and milk. And your computer, yeah. And internet, of course. And yeah, Pratul.

I've actually been reading this fantastic fiction series called The Locked Tomb by this author called Townsend Murge. It's a trilogy, and you know, I mean, I've read a lot of science fiction and fantasy, but this is unlike anything else I've ever read. It's incredible. It's the front page of the book. The blurb just says, let's be in necromancers in space. That's it. And the book is so incredibly well-drained. Like, it is nothing.

I think this is one of those books that is going to definitely go down as, if you enjoy fantasy, you have to do this. It's super, super fun to do. I mean, what's finishing the tradition? And podcasts, we listen to Barakast. Chris, yeah. Yeah, actually, that's true. I have actually every once in a while on LinkedIn, it'll pop up and I'll go, I have also been listening, yeah. I know this is a super popular thing, but I did finally give the Hoobeman Lab a shot.

And I kind of got it and crossed into it for a while, for many months, actually. And I would like, listen through the whole, they're really long and really like almost tiring, right? Because it's just, it's just log area, right? Like, it's just bunch of words being thrown at you, constantly for four hours. It was a bit tiring. Also, what's it, no, no, it's important. Most of the words you don't know. So it's, it's very dense.

I did read a bunch of criticisms on his techniques in which he parses, because a lot of it is him parsing papers and sort of making them accessible. It's basically just a giant, like, I will read 20 white papers this week and I will condense them down into a four hour podcast. That's essentially what I think he does. It's like papers we love in that case. It's paper, paper, we love in podcasts. I'm a single person.

But I've been reading a lot of criticism about how he parses them and there are some discrepancies in the outcomes derived from it. So like, I started to hold back a little bit because of those, not that most of what he's doing is that. I think there are some holes here and there, which is expected. I mean, you can't read a thousand papers in a few months and expect not to have any errors. I was consuming that quite intensely for many months, like a lot of it. Blue Mibreins out.

I've only tried one of his episodes where he talks about stuff. I think it was something about dopamine. After 20 minutes, I'm like, I don't understand. I'm just losing track of it. It's like just to dense. But his interview is actually pretty good. Like, his interview with Mark Andreessen was really, really good. But Mark Andreessen also, he like, his picks at like, I don't know, I know what the normal rate of species he speaks three times, right? It's impossible to parse him.

I recently just downloaded a book by another person he interviewed. His name is Peter R. T. He's like, I think he's a doctor. Who just kind of generally talks about, like, muscle building and health type stuff. And that interview I found was quite interesting. It had a lot of weird correlations that he drew from it, which you wouldn't really draw naturally. There is a very strong correlation, for example, between grip strength and longevity. It doesn't compute, right?

When you first hear about it, but it's like good data to back it up. So yeah, this stuff like that's interesting. Right. OK, it was wonderful to have you all finally, like tell us where people can find you and where they can find tram line. Twitter and link it and tramline.com. What are your handles on Twitter and LinkedIn? My handle on Twitter is PRXTL. And I'm LinkedIn. I'm just fine. You can find me back. I've already got it. Shabnay is actually tramline HQ on Twitter.

Yeah, I'm mid 90 everywhere. I am. It's a little hard to pronounce. I guess this settle sit now, right? My nickname is pronounced as Catalis. It's not Catalis or something else. It's Catalis. It's K-I-T-A-W-L-L-I-S. I'm pretty much that everywhere on the internet. What's the origin of that nickname? Oh, that's a long, that's another podcast. Yeah, it's a podcast episode. It's not great. It's like 80% cringe and 20% interesting, I think. You'll have to take it in 30 seconds. We can't live here.

This opens us up to another, like, an episode hopefully in the future where we start off with this. Origin story. Great. Yeah. It was awesome having you. Thanks, folks.