[0:00:00] P: Hi Sohil. Welcome to Software Engineering Daily.

[0:00:03] SP: Hey, Pawel. Thank you for having me.

[0:00:05] P: It's great to have you here. Let's start with the first question. What is Tranch and what do you guys do?

[0:00:11] SP: Hey everyone. I'm Sohil Pandya. I'm head of engineering here at Tranch. We're a B2B payments platform and re-enable businesses to get paid faster and easier with our pay now and pay later checkouts. We tend to work in the services businesses, and this can range from anywhere from global law firms to marketing agencies. Yeah, that's what we do at Tranch.

[0:00:34] P: How did you, Sohil, get into the programming and what were your first steps in the software world?

[0:00:41] SP: Yeah. I probably have a slightly different background to some of the other guests that you may have on the podcast. I didn't go through the computer science background that you generally have to go through, do an edge down degree and then follow the path and the passion that you have. My passion was cricket, which is a sport and I tried to play that at the highest level. Unfortunately, I wasn't good enough to play at the highest level.

In the late 2000s, I basically started to explore what I wanted to do, what I enjoyed and I've always enjoyed tech as a subject, tinkering with things when I was young. Yeah, I looked into what options I had if I wanted to have a career in the software industry. Back in the day, it was the late 2000s. There weren't as many resources for people when they were just starting out. Free code camp didn't exist. People nowadays have a fantastic array of things they can do to try and upskill themselves. That wasn't there early on.

I remember doing the CS50 course back, I think in 2012 or something. It was the first one ever. I was just amazed by it and I loved every second of it. The one thing I really missed was the interaction, because when you do things online, everything is by yourself. You have to have the dedication and to just keep on going, a lot of online course is also quite repetitive. Sometimes the drive is missing. What I found here in London is a coding boot camp called the Founders and Coders, which back in the day when I did it in 2014, was a pretty new concept here in London. There were a few. A lot of them charging a lot of money, which I just didn't have.

I looked around, see what the best course of action was for me to try and get into the industry. That's how I broke into the industry. I did a boot camp back in 2014 and then started working as a freelancer. I did contracting. I worked in the charity sector, consultancy and tech for good sector. That was what was around there to grow my experience and engineering experience. I then moved on to Pizza Hut and worked there. I had a fantastic couple of years working with some excellent engineers and just the whole team was fantastic. It was the digital division of Pizza Hut and it was fantastic to work with some great minds.

Then I moved on to a mortgage startup called Trussle, which was later acquired by Better, which is an American version of that. Yeah, that's how started and developed myself and ended up here at Tranch.

[0:03:36] P: What's the story of you starting with Tranch? Where did the idea come from and how did the team form itself?

[0:03:44] SP: Well, I'd like to take all the credit for the idea. I actually met the two co-founders at my previous company, Trussle, which I already mentioned. Beau was my manager at Trussle and we worked closely on a lot of projects and features that were being shipped out at that company and that's where we build a good rapport and a relationship. Philip was a CFO at Trussle.

Although we didn't have as much of an interaction as me and Bo did, we definitely had a few conversations in our tenure there. That's where I first met them. When they both decided to start something, they were like, “Hey, Sohil. We've got this idea. Do you want to come and join us?” I was really excited by – I enjoyed working with both of them before. I snatched their hand off. That was back in 2021. The pandemic has got my years mixed up, so I have to be very careful with getting the right year. That's when we started. They started in October 2021. I was a first employee. I joined them very early on, and I have been there, you could say almost from day one.

Since then, we've built a product. We've gone through Y Combinator as well in the summer 2022 batch. That was a fantastic experience for us as well. We've launched our first product and we've continued launching and we're just growing from there, really.

[0:05:29] P: You're currently a head of engineering at Trang. I was wondering, what is your role as a head of engineering and how is it different than being a CTO?

[0:05:40] SP: Really good question. We sorted out quite early on. Like I've already mentioned, I was there from probably day one. When you're there from day one, you have to sell, you have to code, you have to mentor, you have to architect some code, you have to work on the roadmap and strategy, you have to evaluate what partnerships you want to make strategically. Everything you can imagine under the sun, I have been involved in from day one.

For some people, that's quite daunting. For me, it's really exciting. You don't really get an opportunity to do a lot of those things when you're working in a big corporate, or even a slightly bigger scale up, because all of those things have already been – they're already there. You just have to go in. You can get involved, but maybe not to the same standard that you can at a very early stage startup. It's very exciting to get to do all of these things.

Primarily, obviously, I'm hired to build a product. We started with zero lines of code. Coming up with a vision is quite a daunting task. We've got to set out the technical strategy, we've got to have some coding standards that we want to follow whilst we're building and then focus on execution. Our goal is execute, execute, execute and make sure that we're delivering the best product that we can. We grew the engineering team to five people. You've got to do all of the execution and building, but then you've also got to grow the team, mentor the team, both technically and culturally, because it's very important to do both.

I'm very proud of the team that we have right now. Like I've mentioned already, I don't think you've heard me say execution. It's very important for us. Even if you go to tranch.com, you will see some really intricate containers. I'm proud to say that all of the CSS has been it's just pure CSS. It's all responsive. I wish I could tell you that I coded all of that. I didn't. My team members did and I'm very proud of that. We have this ethos and we just want to try and make sure that everyone on the team is able to do what they want to do and deliver.

[0:08:04] P: As the head of engineering, you'll be also more involved, for example, in hiring those and then a CTO and more into the standards direction maybe. 

[0:08:14] SP: Yeah. I think me and Beau, my CTO, work very closely together. One of the things that YC always tries to – one of their ethos for startups is that the founders really should be involved in the day-to-day issues. If you have an engineering background, you should really be coding. Beau really takes that at the heart, and he's involved in all the daily decisions and we tend to make decisions together, whether it's a technical decision, it's a hiring decision, or it's a partnership decision. Whatever it is that we need to do in order to grow the business, we tend to do together, which is great for me, because I have someone who has more experience in me, making sure that we're making the right decisions. It's always good to have someone you can talk to about these things as well. That's how I see it.

[0:09:13] P: As an engineer going through the Y Combinator program, I was wondering, how did Y Combinator, apart from obviously affecting the business model a lot, most probably, how did they affect the technical decision anyway? How did it all work together?

[0:09:27] SP: Let's focus just on the engineering side. I think we aimed to deliver features, or products on a weekly basis. Shipping was key. Getting things in front of customers is key. Then whether it fails is all depending on the end customer. The idea is to get things out in front of people, so that they're the ones who make decisions. Not you and I, because sometimes engineers aren't known for making the best decision for their customers. That's the ethos, not just for the business side, for the engineering side as well, but you've got to work your butt off. Excuse my language. You've got to work your butt off. Make sure you're delivering features, or product that people really want to actually interact with and use. Hopefully, that makes you money.

[0:10:22] P: If you're in front of the view of the features that you decide to build which, and how do you decide which features you're going to build next? With collaboration with the business, how did you agree on the technical world map?

[0:10:37] SP: The roadmap, usually we have a coarsely missing between the heads of and me and Beau and Philip would get together. We have a good idea of what direction the product needs to go in. Like I've said already, our vision is to become the best pay now and pay later check out. The vision is to provide the best experience to everyone. That's always at the top of our mind. That's always our goal. We want to achieve that. We try and break it down into what can we get out in front of customers at every stage?

Whether it's a feature like, give you an example, pay now. It's a feature where we'll enable customers to be able to pay their invoices straight away. That's something that is in addition to our existing pay later pipeline as well. That's a new feature that we've got to build. Technically, there's a lot of work involved. You've got to think about, okay, how are we going to figure out whether the person who's entered the bank details are correct? How do we verify those? How are we going to make the payments? Are we going to integrate with a third-party payments platform? Who's then going to make that?

Are we going to do that here in the UK or US? We're primarily a US – we are a US company. Majority of our clients are in the US. It should be focused in the US, or the UK. These are all, I guess, questions that lead us down building something, which we eventually get down in front of the users. You've got to try and narrow the scope down, so that you can try and get a fully end-to-end feature delivered in as short an amount of time as possible, so that you have a quicker feedback loop. Because if the users are – if we get it in front of the users, they're going to be able to use it. If they use it, we’ll be able to collect feedback. If they don't use it, we can then question why they're not using it. There's always the lifecycle of the product.

[0:12:46] P: You try to keep the feedback loop.

[0:12:49] SP: Absolutely. 100%.

[0:12:51] P: Does it also makes you much faster with making any decisions that you need to make quickly? As a startup, obviously, those decisions, the earlier you take them, the better it is, especially if you're led by user feedback. Let's speak a little bit about your tech stack. How did you build Tranch? What technology are you using and what's behind the entire system?

[0:13:12] SP: We are primarily a TypeScript house. We are a full stack JavaScript platform, where we use – React is something that we use in the front end. Then we use Node in the back-end. We use Fastify as a wrapper on top of Node. In terms of all of it, again, TypeScript. We've got PostgreSQL DB, so we've got a user relational database. On top of all of this, it's all Dockerized, so that if let's say, you were to join us, Pawel, for the role that we're hiring, we can get you set up on your laptop within five minutes, because it's just a Docker compose. Thank you very much. You're up and running on your machine very quickly.

That's, I guess, the platform in terms of our infrastructure. We use DigitalOcean's app platform. We're using DigitalOcean for our single-page React app. We have a server running for our API, and then we have a couple of different servers running, actually. it's technically a mono-repo, which houses all of the code. Then we just deploy all of that to DigitalOcean. We also have a one-to-one staging production. We believe in our engineers owning the code end-to-end. That's from the moment they pick it up to deliver it. It is within their remit to make sure everything is as expected, because as soon as they click merge on GitHub, it's going to go to production.

It can be daunting for some people, but it also means that we have the right attitude towards testing and whether it's actually testing the code, or manual testing, either way. We make sure that we build that into our engineers.

[0:15:08] P: You mentioned that you are using within your infrastructure as your cloud provider, you use DigitalOcean. Could you speak a little bit more about how did you choose the DigitalOcean? What are the reasons? Because it's obviously not the largest cloud provider. I'm personally a fan, but what led you to using the DigitalOcean? What was your decision process?

[0:15:31] SP: In the world of startup, speed is key. As a very small team, it is very important for us to not spend a lot of time on the infrastructure side of things. We want to use a platform that makes it pretty easy for us to get up and running, whilst also provide us the scale that we might need to grow for the next couple of years. We all know that DigitalOcean isn't where we'll end up in the long run. We'll probably use AWS. The cost of actually using AWS from day one is a distraction, because every day, or every hour that we'd be spending doing infrastructure, we’re not doing building product. At the earlier stage, in order to find a product market fit, you've got to have a product. I'd rather everyone in the engineering team is focused on building something valuable to the end user.

[0:16:31] P: How did you find working with the DigitalOcean app platform?

[0:16:37] SP: Actually, it's been pretty good for us. In terms of the cost, it's pretty reasonable. It has coverage across the US market and the EU market, which is the two markets that we're – UK market, I should clarify that we're in. We can deploy our platforms in both of those locations. The platform, the GUI is pretty straightforward and pretty intuitive to use. I find that pretty good and valuable, because it means that even if we're training up our junior engineers, we can actually get them onto the platform and actually show them how we get a database up and running, how we get the servers going, or the single page React app up on the apps platform. Whereas, I wouldn’t in a 100 years want my junior engineer to go onto AWS, because that can cause all sorts of trouble. We just don't want that.

[0:17:38] P: Yeah, it makes some sense. I was wondering from the point of view of any specific technology choices, or architectural choices, did you do any interesting architectural, or technology choices with Trang that you would like to highlight?

[0:17:56] SP: I think, I would like to probably – I think I've already mentioned the CSS shapes. I would really recommend people go to trang.com and look at the containers we have, because – and actually look at it and maybe ask yourself the question, how would you go about designing that in CSS? People don't give CSS enough credit, or how hard it can be when you're trying to deliver something that your branding team has come up with. I want to start right from there.

Something that we're really proud of is the data model. Me and Beau invested a lot of time in the data model, both for the pay now and the pay later businesses, especially to start it from scratch. This is the one thing we really wanted to invest the time in, because we want to feel that this data model that we have will grow with the business, rather than any year's time, feel like, “Oh, shoot. We've made some critical errors in our model. Let's start again.” That's something people, business doesn't really like to hear. That's one of the other things. I would say, data model. We're really proud of our data model and invested a lot of time in that. The third thing is open banking has been quite a, I would say, an interesting challenge to solve, because – can we go a little bit more into I guess, open banking?

[0:19:19] P: Yeah, sure. Absolutely. Because that was actually the next question I was about to ask about open bank.

[0:19:24] SP: Yeah. You have to remember that we are a UK and a US business. Open banking, it basically allows businesses to access consumer, or business data, so that those businesses can make a decision, whether it's giving you a better loan, or whether it's giving you a discount on a product, whatever it may be. They can collect this data. It's a read-only stream, so that, for example, you've heard of Monto. You can give me access to your Monto, and I can then, based off of your data, deduce whether I want to give you a specific product offering.

That's, I guess, at the top level, what open banking does. It opens out the ability for businesses to provide exciting products, or whatever it may be. Or even give you services, like an idea of how much you're spending on things that you might not want to spend, right? It really opens up a great host of possibilities. It's been around in the UK for a while. The standard’s been set. It's really straightforward to implement here in the UK.

If you talk about open banking in the US, sometimes it can be the Wild West. When we are thinking about implementing open banking, we can't just pick, “Hey, listen. I want to implement this for a specific bank.” Because as a business, our customers are not just going to have a Chase bank account, or a NatWest bank account, right? We might have 20 customers, all with 20 different bank accounts. At this point, we have to really look at what options are out there for us to integrate with in order to provide our customers, I guess, the best experience for connecting their banking accounts.

Again, going back to being a UK and a US business, there are some fantastic UK providers, but they don't exist in the US. That can create a problem in terms of the engineering side, because then you're like, “Okay, are we going to implement something just for the UK and then have something else for the US?” Now, you're putting the cognizant load on me as an engineer and like, oh, my God. I'm going to have to integrate, first of all, two different services. Then depending on whether my user is a UK, or a US user, I'm going to have to then implement that differently in my data model.

It can get scary, right? That is why we decided to go with a platform called Plaid, which is available both here in the UK and US and has a great coverage across both sides of the pond That is basically the best way for us to provide our customers with the ability to connect their banking accounts.

[0:22:31] P: Just coming back a little bit. Step back. About open banking itself. As we speak about open banking, you can receive the data about your bank. What kind of data can you get via open banking and how do you use it? Is there any specific part of a data that you are interested much more in? Is there any part that you don't use that much and you are still able to use it?

[0:22:54] SP: It's a great question. It's basically a statement of your spendings in the most basic way, if you want to think about it. It's the same thing that you might be able to see if you open up your banking app and you see all of the list of items that you've literally spent the money on. What we would be getting is a similar data, but with attributes attached to it. For example, if you bought something at a print, a coffee, then it would be labeled as a specific category. If you ate some food, it might be a different category. If you purchased a suit, it might be a different category, right?

We get a lot more attributes and metadata alongside getting the individual payments and what you – basically, the payment amounts, etc. Then what we can do is we would be able to take that into our data model, ingest all of that data and then figure out whether or not you're a worthy person to lend to. Because we'd get your balances as well, of course, right? We'll know how much money you have in your account, how much outgoing you have every month. If I can see, and this is obviously talking on a consumer level, this also applies to the business side as well. If I can have a look at your data and see that you have £10,000 incoming every month and you spend £9,000 every month, we can then make certain judgments around your spending behavior and then offer you products based on that.

[0:24:26] P: From the point of view of the metadata that you said that is associated, let's say, with the statements and the elements, the rows within the statement, are those categories, are they coming straight from the bank as the data, or is it the third party and the provider that attaches them into the data itself?

[0:24:45] SP: That's a great question again. Plaid helps us categorize these things, and so that you can then have just get me the category where you spend all the money on your food. Get a list of that. That's where Plaid really comes in its own and really makes our lives easier.

[0:25:06] P: If you would be to integrate, for example, yourself with all those different types of banks, what do you think would be the biggest differences? Are there any differences within the data model that the banks provide and how strong the open banking is in terms of applying rigor into how the data looks like that you receive?

[0:25:25] SP: I think the standard here in the UK is pretty good. Using, or trying to do that individually, I don't recommend to anyone. There are fantastic platforms out there that help you do this and really take away that risk of doing that, because you'd not only have to – not only do you have the risk, but you also have to have compliance around that as well. Don't forget, it's not just that, “Hey, how many do you need? I want to connect with Monzo. Can I just do it?” No. There are layers and layers of complexity, not just on the engineering side, but on the compliance side that you have to deal with as well, which a lot of these third-party applications really take away from your hands and make it a lot easier for you to do. Not to say that you don't need to have compliance on your side. You, of course, need that.

Going back to your question, the UK is a more mature market on the open banking side of things. It would feel much more comfortable in the UK. Some US banks don't really provide, then really have an API. How are you doing that? Are you screen scraping? I know companies that have done that in the past in the US. It’s really dodgy territory. Then imagine your screen scraping, and then one day the HTML changes, because they've added one more thing. Oh, my God. I'm going to have to go back, redo that, figure out whether they've done any other changes as well. It can get really complicated really quickly.

[0:26:50] P: Do you think that those banks that are – or not providing the APIs, or just creating a lot of issues in very outdated ways of getting data from them, do you think that they have any incentive to start working on that and provide those APIs and go through that technological, well, not even innovation, it's more of a catch up?

[0:27:12] SP: I'm probably not the right person to answer that, but I can tell you that in the UK, the standard's been set since 2017 and has been complied by most of the UK banks. It's fantastic to see, makes it easier for fintechs to actually do what they're doing and build amazing products, right? Whereas the US, the standard is still being set. There isn't anything finalized. When that does happen, I'm sure everyone will have to comply to that. At the moment, it isn't there yet.

[0:27:44] P: from the point of view of, let's speak a little bit about security. Because obviously, you work with financial data. What kind of security measure do you take on the side of Tranch within both your infrastructure and the way that you work to protect the user data and to make sure that everything is compliant?

[0:28:04] SP: Yeah. Again, fantastic question. At a high level, we are a product for a specific type of consumer, right? There's data involved. Whenever there's data involved, there's always a risk. For us, everything is encrypted in transit and at rest. Fortunately, the infrastructure provider that we have helps us do – takes a lot of the load off in that sense. The one thing that I will mention is we take additional steps and use encryption standard to encrypt the open banking data that we get, so that we're not just really nearly exposing that information. Again, fortunately, Node has a crypto module baked in, which really helps us build the encryption – bake it in, really. They're the couple of things that I'll mention.

[0:29:01] P: Could you speak a little bit more about the crypto part of the node? At which point do you encrypt the data? Do you encrypt it at the point when you receive it straight from the provider before you save it in the database? What is the data flow and at which point it is encrypted? At which point it is not anymore to present?

[0:29:17] SP: As soon as we get the data back from Plaid, we encrypt it and then we store in the database. Of course, the database is at rest encrypted as well, so there's a double layer on that. Even if, let's say, I was to leave my laptop open, which I'm not going to do, don't worry. With that specific database, a row on my screen, people are not going to be able to do anything with it. We do encrypt it before storing it. Then every time we have to access that information, we would then have to decrypt that as well. Absolutely.

[0:29:53] P: You'll be surprised how many people leave unlocked laptops on the tables and co-workings and other places. It's incredible. Obviously, as your business model, you allow your users to pay back for a larger payment and to split it into different parts. I was wondering, how do you deal with deferred payments? How do you deal with people that say, “I’m not paying back”?

[0:30:14] SP: You should have had Philip on this call. You've got the wrong person on the call. Yeah. Listen, in an ideal world, this situation wouldn't happen. Like you mentioned, the business like ours has to deal with this at some point. Be it fortunate enough that our team has processes in place to deal with companies who may want to defer payments. Yeah, that's what I'm going to mention about that.

[0:30:41] P: Tell me a little bit about your team and how do you work together? Do you have any lessons about the ways that you work that worked for you and anything that they worked for you? I was curious, do you work remotely? Do you work hybrid? Or are you maybe every day in the office?

[0:30:58] SP: Yeah. We started out every day in the office when it was just me and Philip and Beau. The three of us were in the office four days a week, actually. As a team group, we are now four engineers. We're hiring a fifth one. Even a few months ago, we were five engineers as well. We expanded that to two working days from home. We decided that the Wednesdays and the Fridays would be work from home. The Fridays always work from home for us, but the Wednesdays are a little bit more flexible. If the team is like, “Hey, listen. Let's work from home Thursday,” we'd all work from home on Thursdays. There's some flexibility on that second work from home day.

Technically, you can call us a hybrid model. We focus very much on being in house. We're in person three days a week. All of us really believe that is the best way to grow a very early-stage startup.

[0:32:03] P: You think that this would be more important for companies that work within the fintech area specifically, or is it just more in general?

[0:32:11] SP: I don't think the field really matters. If you're starting out, you'd really need to be working very closely with people, whether it's on product idea, business ideas, whatever, selling. You should be in touching distance of the person next to you, because that's how you can get the business moving forward quicker, build the product quicker, and also, build a culture as well. It's very important for us to all be in-house, to build a relationship. I think something that we've really forgotten during the pandemic is that those relationships that you build when you're in person, the impromptu going for some food, for lunch, for dinner, staying later together, trying to solve problems together on one computer is like everything from engineering to social side of things culturally has been missed. All of us are really aware of that and we really want to build a really good culture across the entire division. It's really important for all of us to be in house and grow the business that way.

[0:33:19] P: You also said that you are currently hiring. I was wondering, what position are you hiring for? How does your recruitment process look like? How do you assess engineers for Tranch?

[0:33:29] SP: We’re hiring for a senior engineer at the moment, a full-stack senior engineer. Again, for them to join us in-house here in London. Our offices are here in Moorgate. We have a fantastic office, lots of space, and a lot of space for collaboration. I don't know if I'm selling it well. But the process, the interview process is a very good one. We've all been through interview processes, where sometimes they've been great, sometimes they've just not been good. But lately, a lot of times, people are being given tech tests to take home and are being potentially told to spend two hours on something, which really, they can spend two days on, or two weeks on, right? They're being judged on that.

That was something we were really aware of and we didn't really want to give people a take-home test in an ideal scenario, because that's just – we just don't think that's fair on them to really work on something for a prolonged period of time. Our process is pretty straightforward. We have an intro call with someone for half an hour. We find out whether that person has any GitHub repositories, where we can maybe look at some of the code that they have that they can maybe share and talk about. We look at the experience they have. If you are good with that first stage, you come in, you spend some time with me and Beau. We go on ideas.ai.

Ideas.ai is a platform that generates an idea for you. We sit down as a group of three and the way we collaborate on this is we say, YC has invested some money in us and we need to build the MVP. Let's pick one of these ideas and let's wide board that out. How would we go about building it? From product requirements, and then we take a little deeper dive on how you'd go about building the infrastructure, what the front-end might look like, what your data model might look like, what your restful endpoints, or graph, whatever you want. However, you want to take us on the journey and build this product that we're going to eventually make millions on.

What that really gives us at an early stage, we're really looking for people that we can collaborate with on a day-to-day basis. We've already said that we're in-person a lot of the time. We're looking for a person who we can really reliably talk to all the time and have a back and forth. Of course, they need to be good on a technical level. If we can get that on an exercise, then that's fantastic for us. That's the second stage. You meet Philip in the third stage. If you're all good, it's pretty straightforward.

As a whole, I think the process takes maximum half a day, from including that first half an hour call. We've tried to really streamline it because, again, one of the things we try to do is if we're going to hire, we're going to make sure that we're focusing on it and get it done as quickly as possible, so that we're not – the time isn't bleeding into my coding time, or both planning time, or my mentoring time. We try and make sure that we're really hyper-focused in getting this done as quickly as possible.

[0:36:41] P: Yeah, and this is definitely us at the same time interviewing engineers and potential candidates for a company. It takes a lot of time, but also, it takes a lot of energy, I found, when I was interviewing. Because we want to both present the company in the best light. You want to make sure that a candidate has an opportunity to present him or herself in the best light as well.

[0:37:04] SP: Yeah. Absolutely.

[0:37:07] P: The interview that you do, it sounds more like a systems design interview.

[0:37:10] SP: Absolutely. That's what most people would officially technically refer to it as. We just try to make sure that it's more a collaborative environment. We don't want it to be, “Hey, there you go. There's a pen. Go and draw something on a whiteboard for me,” and ask questions. It's more, “Hey, this is a problem. Let's try and solve it together.” I'm always there to help, or Beau’s always there to help, but let's try and make sure that we try and deliver an MVP of a product, which looks reasonable technically. Yeah.

[0:37:41] P: Do you think that this is a good method of also seeing how the candidates perform when they are presented with more open-ended question? Than an, for example, algorithmic question where the main aim is optimized and provide the most problem solution. There might be just a way to do it that has been discovered that you need to remember, to actually apply it within the problem.

[0:38:03] SP: Listen, the algorithmic questions have a time and place. Certainly, when you're hiring at certain companies, you need to weed out. When you have a 1,000 applications and you just need to weed certain group of people out, I think that can do a job for you. I'm neither for or against that method. I just believe that the method that we have is going to provide us the best result, because in a small, early-stage startup, of course, we need someone who's hardworking and can code, but also someone who can closely work with.

[0:38:42] P: I was wondering, looking into the future, what is on your plate for the next around 12 to 18 months with Tranch? Are you working on any new features? Are there any new technologies that you would like to use, or try within Tranch? What are your plans, if you could share?

[0:38:59] SP: As mentioned before, we want to provide the best checkout experience for businesses, so that their customers can easily pay now, or pay later. We want to provide the best checkout experience. That is always our overarching goal. Whether it's in 12 months' time, or when we do our next podcast in 18 months' time, I hope that I say the same thing to you. That's always at the top of our mind.

At this particular point in time, we're delivering the pay now feature for some of our clients where they can offer pay now to their customers on top of already offering the flexible payment to their customers. That's a pretty big piece of work. I think it can be daunting at times, because you're building something that A, doesn't exist in your data model sometimes it doesn't exist. There's no UI for it. The whole team has to really get together, collaborate and try to deliver something in a very short space of time. Again, we're running this quite lean and trying to deliver something in a very short space of time. This particular feature, we have a sprint for this one. It isn't two weeks sprint, like you would, but then that would be a real obvious one.

We have a month-long sprint. We're running really hard to try and deliver something at the end of the month. Outside of that, we have a Kanban board as well, which we try and then work off continuously. But when we have features that we really need to focus in on, we would then take a step away from Kanban and build something specific. In this case, a board, specifically a sprint that we can run for four weeks and try and deliver something at the end of it.

[0:40:40] P: I was wondering as well, connected with the future thinking part. With the current rise in popularity of the large language models, and a lot of startups that are just jumping on the wagon and they're trying, or to enrich the current functionality that they have, and they're offering with large language models, or they're trying to build something completely from scratch. I was wondering, are you looking into utilizing any of these in Tranch in the future maybe, or what do you think about it?

[0:41:07] SP: Excellent question. We have investigated it. It's a very early-stage investigation. Again, we can't afford to spend a lot of time on it. What I will say is that in getting financial institution data, which isn't open, it is not very easy to get a large language model to ingest something, or come up with the result. If I was to, let's say, take your data and say, “Hey, is Pawel going to pay me back all the money?” Now, it's very difficult for it to build that without having a lot of data to churn through prior to that.

Because it's a very secure space and data isn't freely available, that's quite the challenge of making sure, how do you get the right result at the end of it? There's a lot of training you have to do. But in order to do the training, you've got to have the right data as well. The data, it’s just not there. I think there is a little bit of a, I guess, a larger data model set out there for a data set out there for the consumer side of things. On the business side of things, everyone's still just exploring.

[0:42:25] P: As the last question, would you have any advice for any founders, or engineers getting into the fintech space within the next 12 months? Are there any trends that you see that would be good to investigate, or any obstacles that potentially can create issues?

[0:42:46] SP: Economically, it’s quite a tough time that we're going through. I think everyone is aware of that. For founders, you've got to hire a great head of engineering. It's very important. To follow up from that, I'll say team, team, team. It's very important at an early stage, founders, to make sure that they have the right team. It's very important. Then on top of that, make it in person. The benefits of having an in-person team vastly outweigh the cost, honestly.

Focus on delivering great products, right? You've got to keep that cycle short. Try and get something in front of your customers, so that they can decide whether they want it or not. You're in no position sometimes to answer that question, but your users are. Try and deliver it as soon as possible. Make sure you're getting it out in front of people. Make sure if you're a non-technical founder, you're selling the product before it's ready, so that your co-founder who has an engineering background is tearing his hair out, because they have to build it in a very short amount of time because you've already sold something, a vision. Those are all the things that I’ll kind of – that's my advice, I think, for people who are looking in the space.

[0:44:04] P: I think the last thing you said about the non-technical founder to prepare something beforehand and sell the product before even he gets into the engineering part, I think this is very good. Because very often, I was approached by people that wanted to start something as a software engineer myself. A majority of the work would have to be done, but the non-technical founder has an idea, but didn't exactly validate it beforehand. It just must build it straight off.

[0:44:32] SP: Yeah. I think validation. You said it, right? It's key. Validation is key. If someone is paying for something before you even have it, you definitely can say you have something going for you.

[0:44:45] P: Any advice for engineers within the space?

[0:44:49] SP: Yeah. I think, again, the market's been pretty tough. There have been a lot of layoffs, but there are still lots of jobs out there. You can break this up into three. Junior engineers really have to just get out there and build some products, whether it's for themselves, or ideas that are out there. Just try and build something, so that you can showcase that when you're going out there for interviews. For mid-level and senior engineers, I think there are plenty of opportunities. Opportunities are plentiful. There are lots of job opportunities out there.

I think for mid-level engineers, if you want to grow to the next level, my advice would be to try and find something that's in-person, because the mentorship and working with a senior engineer, or even helping junior engineers is much easy. It's easily done in an in-person environment. Of course, there are companies who are remote first and have a fantastic ethos around that. DuckDuckGo being one of them and GitLab, but they're a remote first company.

A lot of companies, post-pandemic, have turned down the route of being remote, but really don't have processes in place to help their engineers, or grow their engineers. Be selfish is what I'm going to tell the engineers. When you go and get a job, be selfish and make sure that you're getting the right help to grow yourself and your career.

[0:46:13] P: Thank you so much for your time. It was great talking, Sohil.

[0:46:16] SP: Thank you so much, Pawel. See you later.

[0:46:18] P: See you.

[END]