Ep. #10, The Happy Path with Avery Durrant of Dripos

Eden Full Goh: Hey, Avery. Thanks so much for joining me on the How It's Tested Podcast.

Avery Durrant: Hi. How are you doing? I'm excited to be here.

Eden: We've been friends and talking as founders for a few months now, ever since one of our mutual investors introduced us. It's always nice to have a chance to connect more deeply with a fellow founder, hear about your company, hear about Dripos, and what your team is building and would love to share more about Dripos with the audience today.

Avery: Yeah, sure. So I'm Avery, I started programming back... I think I was 11 when I started programming so it's been a while, and I started with I think what a lot of people start with, and that's game development. So I started with Minecraft development, I taught myself through YouTube videos, then stealing code online through GitHub, so what the best of us do. I'm not that proud of it.

But I kind of learned in my own, I'd say, abstract way of thinking about code and so I didn't learn in a book, I didn't learn through really any tutorial besides a guy who was probably the same age as me, 11 years old, just saying what he was typing out and not knowing what anything meant. So I learned really basic commands, then I didn't know what any of the syntax meant, I just knew what it looked like.

That's how I learned coding, and then two years later I was still working in Minecraft, I started reading Java books, I think I took Code Academy. I was really interested in what it actually meant, not like, "What's an array?" I'm like, "It holds stuff, but I don't know what an array is." So that's how I got into the coding space, I worked some full time jobs my freshman year of high school, I had OE because I was getting bad grades.

Then I went into full learning mode. At that point in my educational career, when you get very bad grades, apparently you can't get into good colleges. It's a weird scenario, but I couldn't get into any college I'd want to go to for coding so I found this coding boot camp school, named Make School which isn't around any more. But they were basically a two year alternative trade school that you could go to, they said that you would be able to get a whole CS career with applied... using and making things instead of theoretical.

So you weren't learning how discrete mathematics worked in the underlying systems of graphs and stuff, you were making those so that really intrigued me. I switched from, "All right, let's have fun in school," to during my free time I coded and contracted and tried to learn as much as possible. I downloaded like 30 apps, I had like 10 books on data design and different programming languages to try to get into the school, which I luckily did. But three months into it I actually left to work full time because they were like, "Hey, let's get you a job."

And I just happened to independently get myself a job during the first semester, so that was fun. I worked in big tech for a while, worked at a company named Deltech which made HR products, reporting, ERMs I think they call them. Then on the side, basically I'd work 9:00 to 5:00 or however many hours I'd work, then on the side me and my co founder Jack started Dripos.

I've always been dabbling in side projects and startups. The cool story about building Dripos is that our first two products didn't go anywhere. We just worked for two years trying to do dumb products, then we found this Dripos mold of like, "Hey, we were a coffee shop product, a Starbucks ordering app." Then we were like, "Hey, maybe we should get a product that there isn't 50 other competitors and we don't have any advantage."

So we interviewed all of our customers asking what do you want? They were like, "Hey, we want a solution that isn't 5-10 softwares tied together, it's made for coffee, and it actually does everything." That's kind of when we started our heads' down period of I would work my 9:00 to 5:00, Jack would be in the coffee shops being a barista, working with Dripos in the store, he'd get feedback.

I'd get off my 9:00 to 5:00, I'd work until 5:00 AM, we'd have a little sync, I'm like, "All right, here's what I did."He's like, "All right, that's cool. I'll bring it into the shop." I'd sleep for like 5:00 hours and then we'd do that again. We did that for awhile until we got into Y Combinator in S20 or actually I'd left my full time job March 1st, 2020.

Eden: Oh, man.

Avery: Which isn't the most ideal time to leave your comfortable job for a restaurant business. But we got into Y Combinator for S20 and we've been building ever since. We still have that really lean approach of just having a checklist, that's what we did, we just had a checklist that he would give me at the end of the day, I'd work on that, then we would reintroduce the checklist. We'd have that product management style. Yeah, so that's where we are now. We're an all in one solution for restaurants, we kind of do everything for our customers, and we love it.

Eden: Yeah. I think what's really awesome about your background, and it's quite similar to mine in a way too because, yeah, I went to Full Stack Academy which is a 12 week boot camp and learned how to build a basic web app and that was how I built the original prototype for Mobot, was using those skills that I had learned. But then how did I get the idea for Mobot? It was from actually working at a real job.

It's not so much about going through traditional schooling, traditional education in order to get that experience. I think, yeah, what's really inspiring about your knowledge is that it really shows that if you have the skillset that you can learn on your own, and you're actually solving a real problem for a real market... The nice thing about being an entrepreneur, being a founder, is that it's basically open to anyone. You just kind of have to have the hustle.

Avery: Yeah. I think that's what's really true about this day and age, is that I think software and a lot of... It's more trade jobs in this field, you can kind of learn a lot of it on your own. I think the hardest part is to get your first foot in the door, so I think I was lucky that I had a lot of relevant work experience that I could use to get my first job. That's what's really helpful. But I think you can learn anything online nowadays. It's just what you do with that knowledge, I guess.

Eden: Yeah. So would be great actually for maybe you to give us an introduction to what is Dripos. You mentioned you and Jack were working and Dripos was a side hustle initially and Jack was literally a barista. Was he a barista before you guys started Dripos? I'm just very curious about the whole story.

Avery: It's a very funny story. Our first product we had built together was in 2017, 2018 and that was a subscription service to bars. It was like movie pass but for bars. We encouraged people to become alcoholics because, hey, every day you get a free drink. So I think you could assume it's not the best area to be in. It was hard to get customers, working with bars isn't the easiest, so we kind of pivoted to the first version of Drip, before we were using Assist for Drip, which was a mobile ordering app.

We wanted to bring like the Starbucks or the Dunkin' Donuts app to local coffee shops, so we had that app for like a year. Then like I said, we realized the space was too big, or I guess the competition was too big, the space was too small. We felt like we were just an addon instead of... People didn't actually want us. It was just like, "Oh, we need to do this to be competitive."

So we sat down and we like to say we reviewed film, we went to like 10 of our customers, not just coffee shops but pizza places, ice cream places. Any type of restaurant you could think, we kind of went to and interviewed. Jack pretended that he was a student at Wisconsin doing a project so we just recorded people, recorded customers, potential customers, and we'd just ask them questions like, "What are your pain points every day? What software are you using? What would you do if you could do anything? What would your dream product be?"

Everybody kept saying, "Hey, it's really hard to have 5-10 services to tie your company together, it's really clunky, it's very expensive, it's very hard." They want a product that's really made for them. Some of our competitors are made for sit down, they're made for retail, they're made for coffee, they're made for everything.

So we had a genius idea of replacing 10 different companies as two kids that I was probably 20 and Jack was like 23, 24, and we were like, "Hey, we're going to do 10 companies worth of work together."

That's where we went into this heads' down mode of Jack would be a barista, he didn't actually work as a barista, but at that time the solution would just go down half the day and there were so many bugs. Our first product was like a ticketing service. It's like a subscription service, a very simple subscription service, we built on Stripe and we built on a software named Memberfull.

We had a React Native app and we had a very bare bones website, which was just raw HTML, no themes or anything, and so we built on top of that to actually have, "All right, we need an order system. All right, we have an order system, now we have a ticketing system. All right, ticketing system. We now have to have online ordering, then mobile ordering, then scheduling, then payroll, then ingredient management.

So one by one Jack and I would have these sprints of he would be in the shop, he would be sitting with the customer and getting feedback. We were able to build this product right next to our customers which we think had a big advantage of, hey, we listen to our customers. Each customer we gained, we basically had a whole new experience that we could build around and each customer had a different feature set that they would want or different products that they used and we could get the feedback they had on these products to meld into our product.

There was a long time of just at the end of every day, like I said, we had a check list that Jack would give me, that, "Hey, here's the feedback, here's the bugs."I'd spend the night getting all those done and go to sleep. Eventually when I left my full time job that just became, instead of overnight, that was the whole day and the whole night. So same amount of sleep on both of our sides because Jack would actually be the designer at that point.

When I was coding at night, he was designing the screens and then he'd get a little sleep here, I'd get a little sleep there. That's what enabled us to build a product that when we first tried to get investors in 2020 or 2019, we were laughed at because they were like, "You're not going to compete with Coast or Square because these are massive companies that have hundreds if not thousands of engineers. How are two kids from..."

I lived in my mom's basement and Jack lived in a car. He drove around in a car around the country launching people. I'm sure I can send a picture later on, but he literally converted a Sedan into a bed and he would go to I think Planet Fitnesses to shower and change. It was really gritty, startup, mom's basement and a broken down car that would break down every other mile, but it was fun.

It was a fun experience and it got us to where we are, eventually got a little more serious, got some funds after YC, got an office in Manhattan. A little more strict and a little more sleep we get nowadays than we used to, you could say.

Eden: And so in the early days it was the both of you writing code and building the product, but how did that then transition to hiring additional engineers and... Yeah, I'm curious, you mentioned in the early days there were all these bugs and it was down half the time. How do you get to that to the stability that you have today?

Avery: Yeah. A lot of it is, I guess, maturing. I'm the technical founder, Jack, he tried to code once or twice by... He'd go into GitHub and change... I'm dyslexic so he'd change all my spelling mistakes. When we started out it was just my knowledge I'd gained from... I'd always play in full stack development, not just servers. I used to love designing good schemas and doing apps and websites, so we had a good architectural backing just from what I learned through failed startups and projects as a kid.

But the maturing really came into, hey, I need to actually figure out does this scale or not? I didn't have any mentors and at my past company, it's not like I was building these massive systems that had to be taking tens if not hundreds of thousands of orders a day so it really took time too. When Jack and I raised our first amount of money after YC, we didn't hire an engineer until I think eight months later because we literally didn't have time.

Hiring takes a lot of time, you wouldn't think. You're just like, "Oh, someone want to come join us?" But when you're the only engineer, you know what's going on, you know what everything means but bringing someone in and being like, "Oh, they need to be able to understand my code and understand where to add things." We didn't even have a system. We just had a checklist, and so we did daily deployments.

That was where a lot of the bugs came from and we didn't have any good testing process. There was a testing process when we started out. It would just be every night I would push an update at 5:00 AM through code push, and we had no pipelines, we had no software that was helping. I would just compile the server code, drag it into Elastic Beanstalk and then I would code push update, so like an over the air update of our React Native apps.

A funny thing that Jack and I used to have was that I'd go to sleep at five o'clock, I'd tell Jack what I had pushed, then at six o'clock he would... We lived together, he'd knock on my door, he's like, "Avery, it's all down. Everything is down." Our early customers were kind of guinea pigs, I'm sorry. You don't want to say that. But a lot of them were. You're able to work so much faster there, it's more about how much throughput can you have of code in the early stage.

You want to validate it. I forget who said it at YC but they were like, "You want to break things to know if customers are actually using it, and breaking is good because that means you're evolving," I guess. Which when we started getting more customers and bigger customers, being down for 10, 20 minutes randomly throughout the day wasn't a good idea. So we just started to create actual systems.

We had a massive codebase, there was no way I'm going to write unit tests for this many lines of code, so we first had what are the users cases of how they... The most critical systems and how do people use it, so we were like, "All right." We also moved to releases once a week, we were like, "Once a week is better than every day so let's try to do once a week." We had these really easy user stories that we would test and that did a good amount of, I guess, common sense testing of, "All right, this looks good."

But you really didn't get all the use cases and all the different scenarios that customers would go through, so we eventually just kept on... We called them happy paths. Basically we'd create really detailed testing protocols, I guess you could say, for each feature and every sub feature and what customers might use. Since we have a product that spans not just software, we have hardware, we have things like four apps, we have three websites, we have apps on those hardware, we have multiple servers.

For us it was really hard to make really standardized and deep automated tests and unit tests, so we went more for a, "Hey, we're going to test this as a company." So currently every Monday night we have our release and we do a release from 11 o'clock to 1:00 AM in which we have like 200 user stories, or we call them happy paths. But like I said, everybody in the company, doesn't matter if you're in sales, if you're in success, if you're in operations, Jack and I, we all just test.

We just take them, we do our deployments, we'll have a testing environment that we'll go through that will basically use the cloned production environment, we'll do testing on there. Once that's good product, we'll deploy it to production. So we evolved from the every day, Avery just pushing whatever code he wants, to more like, "All right." We have PRs, we have a system named Buddy that does CICD, and it's a lot more mature, but we still try to keep it lean and fast, I guess.

Eden: That's awesome. You mentioned that, okay, you have four apps, two websites, hardware. How does the management and versioning of the hardware work? Are you testing every new deploy? Are you guys still releasing daily? Are you doing over the air updates to the actual hardware and you make sure when you run the protocol it has to be done on the actual hardware that is sent to customers? How does that process and controlling work?

Avery: Yeah. I guess the systems we use for hardware is we're on Stripe and we use Stripe readers, and we have most of our hardware, our card readers, we have some other Bluetooth random stuff like printers and scanners and stuff. But our main hardware that we care about that actually changes a lot is our card readers. Whenever we do testing, we do a regression test and we do our current server test so we'll deploy our server first, everybody will test on the old version of our app on the reader and then we'll do a deployment.

When I say deployment, it's usually a code push deployment so an over the air deployment of our JavaScript bundles, and so usually that's what needs to happen because we don't really change a lot of Native stuff. So if you need to actually do a Native app update, that would be a different testing protocol of, all right, go send to beta mode and beta mode is done throughout the week instead of during our weekly law.

But it is definitely hard to have a good system set up and we're still always evolving our system. Code push has definitely helped us be able to allow some flexibility on what we're pushing and how we're pushing it. I think we're really grateful for that, but my least favorite thing I guess is the Native app updates, having to go through iOS, having to go through Stripe's deployment process.

We don't really have a standardized process, I guess if we had an automated test, a testing suite, that would be a lot easier because you don't have to manually do it with humans. But I think for our product and for our team size, a lot of that work has to be done manually. I guess it's just we try to do regression with the old version, then the new version we have some type of updating the app solution. If that's a code push or if that's a Native update, we kind of have to I guess work on those differently.

Eden: Yeah. I guess given that there are some third party dependencies that you guys have, whether it is Stripe, whether it is literally the Stripe SDK or maybe it's the firmware on the Stripe Bluetooth readers, or your own Native app or the code push EPI or anything like that. Where do you see when bugs do happen, are they happening on your own features or do they happen more when you're trying to interface with these external systems?

Avery: Yeah. That's a really good question. I think bugs come a lot of the time from features that we're pushing, a lot less on core features that we've been building on for like five years now, like our order system. More from the new features coming in. The fun, new thing we're working with is regression bugs. Sometimes we'll add a new feature and it will break a feature somewhere else, and it's just like, "What? How can an order system change break scheduling?"

It's just interesting things that you'd really not think about with different sizes of products, but it is really hard to make a product that's reliable because we have a lot of third party vendors under the hood that do payroll, that do accounting, that do banking, that do text message, all these things. Stripe. So trying to make a software that is reliable in the sense of if one of our vendors are down, that we can mitigate that, having offline modes, having systems that can still act and log certain things.

If your payment processor is down, Stripe's been down a few times this year, we have to somehow still get those payments because that's our job to our customers. They shouldn't know that Stripe is in the background. It's kind of like an ebb and flow of there has been bugs that we've had to report to Stripe, there are a lot of bugs with integrations changing from different...

We've had integration problems that they update stuff on their side but they didn't tell us, and so we have to reactively... Now I guess we're working with a lot more mature companies so that hasn't happened as much, but it's happened to the point that you're just like, "Wow." It's hard to prevent. But the bugs on our side are a lot easier to deal with, and I'd say the majority are coming from weird new integrations or features that we're building that we need to make sure stay stable.

But we have different environments, we have some customers we push features to sooner, we have a beta environment, so we make sure that the features that are a little less stable don't go out to all the customers.

Eden: Okay. That makes a lot of sense. It sounds like you guys are building out a pretty robust process to make sure that you cover some of these integrations when you do your weekly regression sweep every week, and everyone on the team is taking ownership of that and hopefully I guess the goal is that if you are testing and covering all these integrations, you should be able to catch any breaking API changes before they actually roll out to production.

Avery: Yeah. And we do have a good test, PR process, so you use that, should, as the first line of protection. Our weekly release time at 11:00 PM on Mondays are more like let's make sure everything is working as it's intended. Developers can only spend X amount of time testing every single feature for one of their changes, and so the full testing with the whole company is really helpful to make sure that we get those weird changes that might have broken something in another part of the product, as well as making sure that the features that are out of our control like a Stripe SDK or Check, payroll... All those are working like they need to.

Eden: I guess I'm curious. If you could go back and do this again and build the app from scratch, telling yourself, going back in time a few years ago, would you still use code push, for example? Because I've heard pros and cons. I'm curious, would you build Natively? Would you continue to use React Native? Curious what you think.

Avery: Yeah. I've heard a lot of discussion on this, from a lot of different sides. What I personally believe is that the biggest thing for startups is talking to your customers and getting your product out as fast as possible. So yes, there are advantages to building natively or building with different, more stable products. Yes. But I don't think they outweigh getting your product built faster. I think a full JavaScript stack is the fastest stack you can use to deploy, to build in, to write in, it's easier.

We have a lot of behind the scenes packages that we use across every one of our products so it's really good code sharing. React Native, while code push does go down a lot, there are some weird bugs, there's no better alternative. Would we want to hot fix something immediately or do we want to wait for Apple's random, for some reason, rejects your app that you've deployed the same amount of times because they have a new rule?

So I think React Native, React, I think those are by far the best stacks to build your product in. I don't think we're going to be moving off that for any time soon. In Node, in JavaScript, I think you just can't go wrong with a full JavaScript stack. The most important thing is building and getting things out as fast as possible and just keep iterating on your product. Maybe if you're Facebook or you're Google and you have to write lower languages, Native apps at that scale.

But a lot of big companies do still write in React Native, do use code push, do use Node so I think it's a lot less scary. When I started, it was a lot more scary, a lot of these solutions weren't as stable but I think they've gotten a lot more stable, a lot more reliable, and still they allow us to deploy fastest, communicate with our customers fastest, to have the best solution we can and just make sure we're constantly growing.

Eden: Yeah. I think what I find really interesting is you guys move very quickly, you're a very scrappy startup. But there's also this physical component, right? Where you have to physically ship hardware to the stores, or Jack is working as a barista. How do you make sure that you guys are getting timely customer feedback in the moment? When something goes down or if someone is using your point of sale system and they have an idea for how they want to improve it, do they just pick up the phone and call you? It's a little different than a normal SaaS platform, right?

Avery: Yeah. I think we're lucky. We don't have the volume of customers that like a Facebook or an Instagram, or any of these big social media tech companies have. If we had 10,000 customers, we're a billion dollar company. So we're able to work more closely with our partners, we have a 24/7 support line, we have every other week meetings with our biggest customers, we have all these...

What's important for us? Like we said before, Jack used to live in these shops. We would have instant feedback from these customers, so we built our whole... We call it the success engine of our team, the success team, to make sure that we can have that feedback and have that transparency. We can have any communication we need with these customers, and that's something that our customers really love.

They love to be able to call us up at any time of the night, text us any time of the night and someone is going to pick up the phone and those people are actually Dripos staff. They're not offsite, somewhere in a call center. They're Dripos staff, they know what your problem can be and they're going to fix that problem at that same moment. If you have feedback, that feedback goes directly into our...

Like I said before, we still have a big list, we call it the hit list of things that we need to work on. There's a little more method to the madness than in the past. We don't ever think of ideas ourselves. We get all of our feedback from our customers through those meetings, through our support line, through our email line, and that's the driving force of innovation at our company.

They know better than me, I've never worked in a coffee shop. Well, Jack has. He's not been a tenured employee at a coffee shop, so we try to make it as easy as possible to communicate with our customers because they're the life force of our company.

Eden: Have you seen your product being used in different ways? Because I know there's pizza shops, coffee shops, fast casual restaurants, the fancier ones. I don't know what you call those. Are there differences in the way that those different types of restaurants are using your platform? And how do you inform your product roadmap or regression testing protocol to account for those differences, if there are any?

Avery: Yeah. Right now Dripos is really focused on coffee, but when Jack and I started our company name was actually Frostbite Technologies. When we started Frostbite we really focused on making a product that could be modularized out and could be used in different verticals because eventually we don't want to just be coffee. We want to go to sit down, we want to go to X, Y, Z, but for us what's really important is having this specific product for our vertical.

Once we go fully to have a pizza product, it's not going to be called Dripos. It's going to be called Pizza-os or something like that. We built all of our code under the hood in our modules to basically be turn on, turn off. Once we have another product, it's the same app, same everything, we just turn a few dials and levers and that's how we deploy.

So when we're testing we're basically testing those modules, and when we're enabling customers, we're enabling those modules and so if we have a different app that has a different look and a different brand, it's still the same code and the same underlying features. It's just we're turning some things on, some things off, so being able to build with that intention from day one has really helped not need to add new complex systems because we haven't really needed to change how we test or talk to customers.

It is hard because we have a smaller team, we have five engineers right now and so trying to prioritize what's more important if we have a pizza client. Are they more important than a core customer in coffee? A lot of it's just around, all right, what's going to grow our product? What's going to make the product better? What's really important? If there was like a step one thing that needs to be done because a customer can't launch because of it, yeah, we're going to focus on that.

But we have a thing at Dripos that we try to do one or two features for every onboarding customer, which in the past it was very big things because we didn't have this product that we have now. But now it's all right, and we can do that now. It creates that relationship that we want because our customers love us because we are helpful to them and we talk to them.

We've had one or two outages in the last year and every time we have a system that we contact them, we make sure they're okay. It's just really about being close to our customers and I think knowing what their priorities are and having a level of communication that they know our priorities as well. Like, "Hey, this isn't that big for us currently.

We have it in our roadmap, we hear you, but we're going to let you know it's done." So every release we have, we contact our customers and we say, "Here is your things that we have from you, here's what we're working on, here's what's been released." Communication is key, I think in every aspect of any company. Internally, externally so that's what we try to do.

Eden: That's awesome. I guess looking at the six to twelve months, what is the future of Dripos? What are the features that you're excited about next or verticals you're planning on launching? Even beyond the next six to twelve months, what is your technical vision for the company?

Avery: Yeah. I think the grand goal is to have that protocol specific product that we can turn on and off features. We have it built that way, but scaling that and figuring out how that's done because engineering-wise, that's easier than marketing that, building up teams to sell that product, how do you support those products. Those are the grand visions, I think, more like two to three years down the line.

Right now we're really just focused on finishing our grand vision of what is Dripos and what would any feature that people would need for Dripos, which is also going to be needed for a pizza product or a sit down product or an eCommerce product. Right now we're really working on inventory management, having an inventory marketplace, having banking, having accounting, all massive features.

Building in a banking integration is a lot of work, but these are things that customers want because they want to be able to manage their bank accounts, they want to be able to have purchase orders that can come from their bank account. They have all the sales data, employee data and payroll data that they do with Dripos, they want to be able to do accounting with us because we have all the data.

Then, using that, we want to be able to basically give them health of their company, what they can do to make more money, how sales are doing, predict sales costs, predict labor cost. All these things are very important to us and being able to accumulate all this data by being this all in one solution has been super helpful and we're just excited to finish the grand vision and then be able to start looking at where we can bring this, besides coffee.

Eden: Yeah. I'm really excited to continue to keep tabs on the startup and what you guys are building. I hear great things about you guys all the time. I guess one more question for you is now that you've gone through these early stages of building a company and you've made some recommendations about the right tech stack earlier, and just focusing on prioritizing customers, being as close to them as possible. Any other words of wisdom, either about testing, release management, mobile development that you'd like to share with our audience?

Avery: I think the core tenets of building a company is just being able to move fast, being able to work really close with your customers and being able to iterate fast. I think that's some things that people aren't as good at, and when you start a company it's going to look very different, when you start your first product it's going to look very different than where your product is a month from then, two months, a year, 10 years. It's going to look very differently.

I think a lot of people start their testing process very, "All right, you need unit tests, you need X, Y, Z."But start out with all those things, unless you're a company that really needs those, you can have other ways to test that won't double your code cost and once you're at a point that it's like, "Our vision isn't to build right now." There's different stages of your company, "We need to build as fast as possible and bugs can be acceptable."

But then you have to evolve not just your codebase but also your testing practices. We used to not have testing processes, you had to add those in. But it's all about your early stage is code turnaround and idea turnaround as well. We pivoted so many times that you need to be able to... A lot of people don't like tipping, just shooting their firstborn child, it's a kind of morbid way to say that, but you have to kill some of the things that you really spent a lot of time with.

So it takes a lot of growth and iterative processes which is at the core of what Dripos is. We make sure that we have retros every week on every team to make sure that we're not complacent and that all of our systems are the most sufficient for where we are, and so that came hand in hand with making sure that our testing is as robust as it can be at this stage. Like I said, it's all about resource allocation.

If you're early on you don't really have time to write all these tests and you don't have all this time to make sure that every feature is fully 100%. Push a half made feature, you can look at DoorDash, they didn't even have a first product. They just had a website that said, "Hey, call us up and we'll get your order." I forget who it was but I think one of the founders called in the middle of the day and they were like, "Hey, this is what I ordered."

And they went out of their class at Stanford and drove to the restaurant and dropped it off. That's how you validate. You have to validate. You have to build fast and that was what made us the company that we are because we took that to heart and built that way, and that's core to us. So iterate, make sure you're not complacent, and have fun. I love coding so I think this would be a lot different of a company if I didn't enjoy what I was doing and did it for my free time in junior high and high school. I'm having a lot of fun and I think that's what matters.

Eden: Yeah. I think a lot of what you said I really resonate with and I spend a lot of time thinking about this because, yeah, you guys have an impressive platform. But the reason you got to this point was because you weren't writing perfect detox tests with your five engineers. You guys were out shipping and revising features, and what is the point of writing a detox test for your React Native app if you're just going to change the feature again tomorrow or you're turning that module on or off tomorrow?

So yeah, I totally get it. I think one of the things I'm trying to do on our side at Mobot is how do we build tools that make it so that teams can ship faster without... I think there is a time and place, like you said, for when it makes sense to have that kind of infrastructure. But I think the story that you're sharing here of just the early founding days, I feel like there needs to be more awareness around what it actually truly takes to start a company, so thank you so much for sharing.

Avery: Yeah.

I think you hit the nail on the head, of sometimes people see the best practices and they're like, "I need to do all of that." But it's like you need to make sure your company is alive in six months, and so making sure you can get customers and you're building for them.

I see it on Reddit all the time, they're like, "You're not doing 30,000 test unit integration?" Manual? You don't have time for that in the beginning, it's just do what you need to do for your stage of your company. Now we have a lot more tests, let's just say that. We can't do that anymore.

Eden: When do you think you guys will begin to invest in an actual full time testing engineer or a DevOps or someone? Because it sounds like your five engineers on the team right now, they're all writing features, right?

Avery: Yeah. Yeah, that's a really good question. We've been working on changing our whole testing fleet, and we think at the core of our company is making sure that everybody has context on the entire product. Not just the product team, but sales, operations and success so we don't actually have plans for when we're going to bring in full time X, Y, Z. We have plans of how are we going to make it that we don't test at 11 o'clock on a Monday?

So we do it over the weekend and have different environments, and easier, less work for everybody. We just try to do what's best for us and give the context to our employees and make sure that we're not allocating resources to teams that at our stage, every engineer is more valuable than having to bring someone in to test because that's however many Dev hours that could be building new things to get more customers.

That's a big question for us, but we like to... We have a value, it's build for now. So right now we want to build what's going to make it easier to do these processes we have now and there's no end in sight for when we're going to have to hire our first QA or QE, but it's coming. I'm not saying it's never coming, it's going to come. The day will come. But like I said, we're just building for now.

Eden: Yeah. I'm excited for what's to come and I'll definitely be checking in with you because I want to know how things turn out. Thank you so much, Avery, for joining me on the podcast. I really loved this episode, I think you shared a lot about the founder journey but also your tech stack, recommendations for other technical founders. I hope our audience really gets a lot of great insights from this episode.