Watch Duty Keeps it Simple to Save Lives

SE: Oh, awesome to have you guys here. Now we are talking about a topic that is interesting to people around the world because it’s about scale, it’s about safety. It’s about doing things on the smell of an oily rag, as we would say, doing things frugally and simply, but also things that are critical, and often people conflate criticality with expense. But often criticality breeds innovation. And so John, maybe let’s start at the start if we can, of what is watch duty and how did it emerge.

JM: Yeah, I mean, simply put, watch duty is an emergency alerting platform, similar to what the government rings your phone at, that very loud noise at random hours of the night. We’re an organization that is providing emergency alerts regarding wildfire, and it was born unfortunately out of fire. I live off the grid in Sonoma County, where we experienced this at a regular cadence. And after a couple of times, you start to realize like, who’s gonna tell me when danger is nearby, and at what interval level, and after a while of living through it, I just decided to do something about it.

WV: So who are your customers, John?

JM: Well, our customers really are everybody. It started out as an application for citizens because we assumed that the government themselves knew where everything was at all times, and as we’ve scaled, we found out that tanker pilots, dozer operators, emergency managers, firefighters, and everybody used it.

SE: So it was a classic case of you built something thinking it was gonna be used one way, but customers get a choice, don’t they? They choose what they like and what they wanna do with things and this went well beyond what you planned.

JM: Yeah, I mean, it definitely is used for the same use case, just a different user base than we imagined. We didn’t realize it was literally everybody.

WV: So, I understand it started off as a volunteer effort, it still is, to be honest.

JM: Yeah, Dave was a volunteer here, and so was I, right? But Dave and I were working on it for almost 18 months, Dave, I think, and then you came on board after that, but it’s still a lot of volunteers.

DM: Yeah, I was gonna say it was 2 full fire seasons, I think of them in fire season years, really, I guess it was less than 24 months. I mean, it was such an interesting start, because I’ve done hackathons and sort of for-good projects before, but this one so quickly caught momentum and so quickly had a fit in the market. You talk about customers and competition. The weirdest thing here is that it’s, it filled such a gap that there was no competition, like, no one else is doing this, and no one else. It’s not like we were an incremental improvement upon something that existed. It was OK, you can go on Twitter and Facebook and have 12 tabs open for your life and safety, or you can use a simple app where experts are synthesizing this for you. It was such a gap in the market that there really isn’t competition, like, in the classic sense. Well, I think,

SE: I think it’s interesting cos one of those use cases, cos we, of course, we don’t call them wildfires here, we call them bushfires in Australia and we’re very familiar with those. But it’s a classic seasonal thing that happens, and so for most applications, seasonality’s not a good business model, because, particularly when it’s seasonality of not, oh, it’s really busy cos it’s gift buying season now, it’s just normal buying, it’s fire, no fire, fire, no fire. And the no fire time is where people sort of lose attention. And like you say, when I look at your app and the capability of it, it’s like wow, how didn’t someone already have this? And it sounds like you were in that situation where you sat there, but you took that next step of action of saying, well, how does this not exist and how do we make it happen? What helped you make that jump? Like, what was it that, we can all sit here and go, well, someone should build that, but you built it.

JM: Yeah, I mean, again, after experiencing a bunch of fires, two of them being a quarter mile from my edge of my property, you start to realize that like, someone has to do something about it. Like, I live off the grid, so my nearest neighbor is about 1 mile away from me. The nearest fire department is 6 miles, I guess. And so, you start to realize when you make your own power, you make your own water, you live on your own infrastructure, like you’re on your own. And so, I could sit there and say, well, who’s gonna do this for me? Or I could start doing something about it. And luckily, Dave was crazy enough to join me early and help me architect this thing.

WV: So tell me a bit about — I mean, in Australia, Simon, tell me if I’m wrong, there is a user app where individuals can actually signal, oh, there’s a fire here, there’s a bushfire here or it’s starting here. But that’s not what you guys are doing. And Dave, this is much more of a — take professional information coming into the app.

JM: Yeah, it’s really more expert sourced than crowdsourced, right? So like you can go on Citizen Nextdoor Facebook and start screaming in the ether and tell someone that you see a fire, but is anyone going to hear it? For us it really starts with someone calling 911 and then We hear those dispatch signals. Our volunteers and some paid staff turn their radios on and start listening, so they know what to listen for. They know what these words and terms mean, and they’re really synthesizing this information on the fly to make sure it’s not literally the boy who cried wolf.

WV: So they are professionals or former professionals. They know how to interpret the signals that they’re hearing on the radios.

JM: Yeah, it’s kind of a mixed bag, right? Some of them are kids who grew up with a scanner in their house because their dad was a firefighter and they’re literally worried, Is my dad going to come home or not? And then some of them are the dads who’ve been fighting fire for 45 years and now retired and they can’t turn the radio off. And so like once fire’s in your blood, these people can’t stop. It’s a life of service.

SE: So let’s talk briefly about, I guess what you reached for when you went to build this, and how big is the team building this piece of software.

DM: I reached for the pieces that I knew well. I went through the classic, all right, well let me draw up a diagram, let me write some things down, I wrote all these options for where we’re gonna host, what kind of database are we gonna use, and my mind drifted like any shiny object engineer to like, well it would be nice to learn a new thing. And then I thought about it a little more. And I realized that was a terrible idea. Maybe if it was my full time job, I would have had the time to invest in learning a new language or architecture or database or really anything new. So every decision ended up coming back down to things that I was really, really familiar with, and that generally were very, very simple. Boring choices. I think a lot of people agree now that like, you only get to spend so many innovation tokens, whatever you want to call it. You get to pick a couple things that are wild or innovative or novel. But in this case, it was like, well, everyone has a job. Everyone’s doing something else, we need to pick the absolute simplest things. So we’re gonna pick the technology stack I was using at my current job, and all the things that were already just the easiest path.

WV: At the beginning of it, you must have been thinking, this is a volunteer effort, but how much is this going to cost me out of pocket? Did that drive any of your early decisions as well?

JM: I was the only one who didn’t have a job at the time, so I was writing, this was my job. I was writing a lot of code, and so we picked Django, we picked Python, we picked React and things that we knew we could pick up off the street to find volunteers who could do this, rather than, to Dave’s point, the newest shiny whatever would be super cool, but like, guess what, it’s me in the woods by myself coding, while Dave and others are volunteering at the time, and so it wasn’t gonna work very well if we didn’t pick standard practice types of things, including architecture like AWS and others.

DM: And then just to go to the cost, it’s easy to look back now and say, wow, 9 million users in the first two weeks of January. Good thing we picked cost effective choices. We didn’t know at that time what it would look like, it was amazing how much pickup it had that first year, but we ended that first year with just shy of 100,000 downloads, I think. And that seemed crazy. Still not that expensive to serve in what we’re doing, mostly read heavy API traffic. But we didn’t even quite realize at the beginning what the scale of that cost might actually look like down the road. It was more like if we actually get there, we can fix it then.

SE: And this is often a classic case of, I’m building something to prove it works, and then I’m wildly successful. But often the timing of the wildly successful and the building it and then having the time to make it better doesn’t line up. And particularly in your case where, I mean this thing went ballistic in terms of adoption, I think it was one of the top, if not the top, downloaded app for a number of months. Again, some of the names you’d think would be the most typical ones that are always downloaded, so. You’re sitting in this situation where it’s a small team, and we need to get into the composition of your team cos I think that’s fascinating as well, but you’ve got this small team that suddenly, doesn’t wanna have to be in complete, dare I say it, firefighting mode on the app, you just need the app to run, so. Having the elasticity is, I mean that’s when it makes all the difference, doesn’t it?

DM: Yeah, and I think we did understand that we needed to be able to pull the slider to the right if we needed. And if we really needed to spend money, we could all just find the cost to do so. But again, I think we also knew that there would be time. So you can go back to the seasonality, normally a terrible thing in software businesses, but it was actually, especially in the first few years, kind of like the dream on the engineering side because you actually got periods of time where, well, we had no product organization, we had no sales, no one was breathing down our neck to do anything besides to improve the application. So you actually had these slow periods where you got to fix things, where you got to focus on performance, where you got to do that work that engineers fight so hard to like slot into the roadmap. And it was like, well, here’s a couple months where at the end of these months, all of our libraries should be upgraded, all of our performance hotspots should be dealt with, all of that technical debt that you naturally accrue with a small team with quick decisions. We actually had those periods of time to really focus on it. That’s slowly going away, but I still think we’re trying to keep it in our kind of approach and ethos because it really does help with long term stability.

WV: Now, in that sense, there’s a, well, I’m not saying it’s as explosive as yours is, but retail in some sense, if you think about Black Friday in the month before Christmas. January, February, March becomes a time to fix things. Yeah, but unfortunately in retail things never go back to where they were before. So you—

SE: —you’ve got a significant problem.

WV: Absolutely.

SE: Yeah, it’s not a good thing. Tell us a little bit about the team. How big is the team? What are some of the talents on the team that make this possible?

DM: Yeah, I mean, I don’t actually remember how many people helped volunteer. I would say in the order of 15 that first year. On the engineering side, 15 to 20 volunteers, varying levels of effort, maybe like 5 to 10, like really core contributors that first year on the volunteer side and that second year, probably the same group. And then it’s a very unique composition because we started out fully volunteer. For the first, let’s say 2 years, and then we switched to a model where, well, I joined full time, CTO1, quite the title, and then hired a contractor as I realized I needed a little extra help. And really that whole first year was just myself until we started hiring a little bit more that second year, and now we’re at 7 engineers. So still the two-pizza team. The nice thing for us right now is because we had such a strong Group of contributors, we’re able to recruit some really, really talented engineers from that group, which is quite the interview process — if you’ve worked with someone, you already know. In terms of how we’re composing our team right now, we still don’t really know all the things we want to do. So we’ve been just trying to hire, really, it’s an overused word, but full stack engineers that are really focused on problem solving. We don’t have a lot of novel technology that we’re building, but we are solving very, very concrete and real problems. So we’re trying to hire and get engineers that love to own a problem from the beginning to the end. There’s not going to be someone in product building out all these requirements and then a deep technical dive. It’s like, you need to be the person that loves seeing an issue and then seeing it all the way through. The nice thing is right now we have a really, really experienced team, a lot of talent and density, so we’re able to get a lot done with a really small team.

WV: How did originally your volunteers show up? Were they people you knew? Were they early users of an app? Were they, I mean, how did you manage to get 5 people on board to donate their time? It’s a problem that most nonprofits have where they only have 2 people that are maybe paid, but rely on a lot of volunteers. How do you find the people that are willing to donate their time to you?

JM: Yeah, I mean, we found them pretty early on through, mostly through our networks, through mine and Dave’s. I mean, a lot of the people that we brought on board were friends of ours. Dave and I worked together at multiple companies. I have a couple of other friends who I’ve worked with or known for a long time, who cared about this problem. We told a good story, we had a good product. I mean, our first draft took, I worked day and night for almost 80 days. I built probably 80% of it, and then Dave and others did the stuff either I couldn’t do or I had to sleep at some point, and then after a while it picked up, people started to see it, they knew what it was, they were using it, and it makes it much easier to then recruit people because unlike a lot of nonprofits, they often build things for other people that they have never experienced those problems, which I think is really hard.

DM: I’m just going to add in that John is very good at convincing people to help him. He’s selling himself a little short there.

SE: Well it’s interesting too that you often call yourselves sort of a tech first nonprofit, which is kind of a different profile than we’re used to. Help us, I guess, nailing onto that and what it means to have a CTO and a prior CTO running this thing. How does it affect the culture of the organization?

JM: Well, it really comes down to product, so it has nothing to do with the tech stack, right? That’s first and foremost, like, who cares if it’s peanut butter and jelly, duct tape and baling wire. Now, can I take 100,000 requests a second like ours just did with a tiny team. Fortunately, I could thanks to AWS and Heroku and other providers who allowed that to happen, but That said, I mean this is a really organic product that is made to solve a problem, and so its first revision is essentially a simple news feed with a geospatial map, right? None of this was all that complicated. So if you kind of like strip away everything you don’t need and just give it what it’s supposed to be, like, it’s a lot easier to get something off the ground, to think clearly and simply and realize we don’t need complex engineering to solve these problems, right? We need a very elegant solution to a very annoying problem. And the answer was actually using human radio operators to solve it. The tech came second, and so there’s a lot, quote unquote better products than ours out there in terms of I don’t know how I want to measure things better code or whatever it may be, but we have better outcomes, right? Outcomes are what matter. No one cares what it’s written in. And so it really comes down to first principled product. I

DM: I mean, I just wanna add on, I think you’re underselling our tech a little bit, John.

JM: early tech, early tech is pretty simple, man. You can see

SE: John’s become a CEO,

DM: I think, you look, everybody just like everybody in LA just downloaded Watch duty, and they got to see what Watch duty looked like after 4 years of revisions. I think that’s the big difference between a tech first nonprofit and a nonprofit that wants to do something like this, because we set ourselves up to iterate very quickly, to be able to take feedback from the SMEs, from our community, from ourselves. From everyone that has every single support ticket that’s ever come in, we’ve looked at and reviewed. We’ve probably, I don’t actually know the number on this, but we’ve probably released our mobile applications upwards of 50 times a year. That comes out to 200, 300 times we’ve released, we’re up in the thousands of PRs and all of our back end and front end repos. The ability to iterate quickly and have a world, I think a world class product on the tech side is that other difference because you can want an outcome, and you can, and that this is outside of the kind of scaling thing where 9 million people using your app doesn’t tank it. But I think even on the product side, we’ve been really focused on iterating and bringing, really, I think what a lot of people consider just normal product development in the startup and tech world to a user facing problem, a public facing problem that a nonprofit is the best suited to solve and provide. This wouldn’t work if we’re trying to charge people for this data. We, even if we didn’t believe that everyone should have it, I think we never would have gotten the traction if we were trying to profiteer off of people’s most panicked moments, maybe it would have gotten somewhere, but I think that’s the big difference.

WV: So can we, so we talked about customers which in essence to users, but if you normally would build a product, you would work from your customer backwards, like you say you care about the outcomes, but there’s a massive input stream here as well, because without the input of the volunteers that are actually putting things into your system, this wouldn’t work. Yeah, so do you consider them to be another set of customers? What do they need? What do we need to give them to be able to get this accurate stream into the application?

JM: So I think stepping back is, when we found these radio operators, they were using Facebook and Twitter, right? So they were using a very lackluster product to solve a very complex problem that was involving life and death, and so, the bar was very low, right? So obviously 4 years later, we build all sorts of advanced tooling and signals to noise processing, whether it’s AI bots, and whatever it was, but like, we were immediately better than what happened before them, right? And so, we had leaps and bounds, better ideas about how they should be doing their job, like, for example, they didn’t even really communicate with each other. They’d kind of message each other in DM and Facebook or whatever it may be, but they’d kind of be running their own independent Facebook pages or Twitter pages, and they’d kind of know each other and like follow each other, but they never talked in real time and Slack. So imagine like 4 people covering one fire or like the Palisades fire, for example, which was like 6 to 10 people at a time. They’re all collaborating in real time. So just the fact that we put them together in one place and gave them a community to talk and collaborate, which was a huge leg up, let alone all the systems that we built on top of it. And so, again, boiling it down to like how things were versus how things are going to be, it was not as challenging as you may think. Now that said, as Dave’s going to chime in, we spent a lot of time building tools, right? But ultimately, it was so much better than it was that it became much easier to get them enticed in this and asking for features and ways for them to work better and faster.

DM: Yeah, I mean, it’s a unique organization. It is very much in one side a product facing tech solution, but it would be nothing without that input stream you’re talking about, and it’s incredibly important. It’s the secret sauce of what makes watch duty so compelling to everybody. And they are very much our customers in the other sense, because there’s only so many of them. It’s hard to find these people, it’s a very specific domain expert that wants to spend their time and energy and really it’s a passion for most of them. So we’re trying to give them the absolute best tools that they can have. We had some volunteers that were also reporters on the engineering side. They were incredibly motivated to help fix these problems. We have advocates within their side that tell us, hey, this is busted. This we waste time with. Sometimes we just watch what the reporters do and say, you’ve been doing it that way for how many months? That’s a lot of time wasted. There’s an anecdote last year where we found out that all the reporters had to refresh Facebook and Twitter pages all the time to find out how to report on more kind of like the end, the tail end of fires, you know, because that’s unfortunately where a lot of public information is posted right now. So they just had like a panel of 2030 tabs, and they’d go every 10 minutes, they’d go refresh every single one. And it was like, what you’re doing is super valuable, but that is not valuable. We can help solve that problem. So give us a couple months. Next spring, you won’t have to deal with that anymore, because that is definitely the hardest part of our scaling is the reporters and the contributors and that human element. Which is I think.

WV: The quality of data really relies on them. Much more than anything else. But by the way, can we do one little sidestep because I’m actually just curious that you mentioned geospatial. What I find over time traveling the world and going to many different places is that commercial maps are not that terribly accurate when it comes outside of cities. And organizations like humanitarian OpenStreetMap and or and the OpenStreetMap Group and things like that. What kind of mapping technology are you guys actually using? Because this is mostly off the grid, as you mentioned, John. Yeah,

JM: it’s a good question. I mean, we’ve, God, we’ve done so much experimentation with different tile sets from Esri, Mapbox, OpenStreetMaps, and honestly, we still struggle with it. You’re hitting the nail on the head. It’s like, So out in the wildlands, as we call them, like there’s oftentimes like satellite passes that are 2 years old, and you’re like that house burned down, that water tank is not there, like, that’s a dirt road that’s now closed off. Someone bought that land and it’s gated and they have no idea, and so we still struggle with that, honestly, and we’re trying to find answers to those problems, and we’re definitely not doing cool streetcars ourselves or helping OpenStreetMaps, although we wish we could, we have no way of doing that. And so we’re trying to think of other clever ways of doing that, whether it’s buying satellite imagery and partnering with those organizations, but there’s a lot, there’s a lot to be gleaned by the Earth observation community, which still hasn’t seemed to solve this problem either. And I scratched my head living out here. I’m like, how did I just get here, and I’m seeing all these issues, and we’ve been able to open the can of worms and solve a bunch of them, but there’s more underneath them, and this is a big one that we don’t have a clear answer to yet.

DM: I mean, it’s a big challenge, but I think part of the challenge and constraints that we have is we can’t bite off all these problems. We get a lot of user reports around — this street is named wrong, this street isn’t there. This satellite pass is old and like it takes a lot of discipline to be like, we’re not going to build a middle layer where we start overriding OSM data. It’s like we have to be really focused on our core competency and sometimes just be like, well, you know, I wish that our product could be a little better on this aspect. I wish we could do it, but like, We’re a team of 1, we’re a team of 3, we’re a team of 5. Like, it’s enough. We could work all day and night and just distract ourselves from the actual mission. It’s frustrating to have the street behind you mislabeled, but it’s more frustrating to not have the product that we brought you.

WV: It’s mostly because it is a massive problem. I mean, India is a really great example where many of the roads are not either not, you can’t drive a big truck over it or a Google Street map van or whatever. So there’s this one app that actually is for truck drivers to connect you with a truck driver and they in general go out into the woods. So, this app now also actually tracks that data. Yeah, where did the doctor go? So now we kind of know that there is a path to do that, which brings me back to actually another question for you guys. You collect a lot of data, you get a lot of input signals from all these professionals. Is there something that you do, let’s say with the data after the fire? Yeah, because this must be an extremely important data set. That is also for firefighters very important.

JM: It’s really useful for after action reports, which is what the fire department will do after the dust is settled and the last engine leaves, but a lot of our data, like, believe it or not, is publicly available, right? Like what’s really unique about us is our news feed, which is the radio reports, but again, when it’s all said and done, that’s all public as well. This is all FOIAable public information, so a lot of it can be had. We just have kind of a common API or endpoint to get some of that data, but I found that like, for example, we don’t know that like this part of the fire was crowning, meaning the canopy was on fire, right? We don’t know that this was the hot spot, this was the cold spot, and like the little subtle details that people wanna know, like we don’t know either. We might have one of the better data sets in the world, but you’d be surprised how finite it actually is, and I remind people that like, although we may be the best, quote unquote. We still don’t have what we need because we don’t know where the perimeter is as the fire is moving. It’s throwing spots or embers half a mile, 1 mile ahead of itself, lighting fires ahead of it, pushing the fire with the wind, like, we don’t know that. No one knows that, right? And so it’s really — knowing what I know now, there’s still so much more that we don’t know, and it’s really quite interesting how challenging this problem is, and until we get really high resolution satellites doing 1 m resolution at very, very sensitive heat detections, we’re not gonna know all that information, to be honest with you.

SE: Do you see a world where things like drones that are, I guess, dedicated to seeking out fires and changing our fires and telemetry back and sort of AI driven, trending, etc. like what’s the future looking like as you sort of start to reach into what could be versus what you’ve achieved so far?

JM: Yeah, I mean, I think it’s interesting to think about. We like to think about skate to where the puck is going, right, and think about the future. And so there’s certain like there’s ways to cut this and really think about it. So for example, let’s use the Palisades fire. The Palisades fire was a hurricane with fire inside of it. So, if we found it two seconds earlier, Not much we can do about it, right? Unfortunately, like the reality is, and people don’t want to hear this, is that like when you’re fighting a wind-driven fire throwing embers across the head of the fire at that kind of speed, at that rate, there’s not enough AI and drones in the world to stop it, right? That’s the reality. Now, where the AI and the drones come in handy, and let’s call it, I forget AI. I don’t think that’s irrelevant for this conversation, like detection, right, is really what we’re discussing. Like there are great examples. like the fire that happened to me, that got me in this business, there was a lightning strike 12 hours earlier, that was a smoldering tree, that didn’t matter until 12 hours later and the wind picked up, set those embers flying. Next thing you know there’s a 50,000 acre fire. That would have made a difference. If we had known that was there, that tree was on fire, we absolutely could have stopped a mega fire from happening. And so, being able to detect this stuff and respond to it, whether you’re having drones dropping water, or whatever it may be, and suppress these things in the middle of nowhere, that is definitely something that will stop some fires, sadly, not all, and so it’s kind of a, let’s throw everything we have at it, but realizing that like 100% never gonna happen again, it’s just not a reality we live in.

SE: Nature is nature and nature is awesome in the good way and the bad way, but it’s interesting, that lightning example is a great one where, it’s a very small incident and I’m sure there’s hundreds of lightning strikes during certain times of the season around the area and it was just that one, but it caused a disaster. It can be that little, which is, I think the other interesting part of all the data you’re bringing in, so you’ve got open data sets, you’ve got input from volunteers, from reporters, etc. like, this is not just sort of structured and unstructured data, this is data of all kinds of dimension here. How do you unpack that in your brain? How do you, David, how do you sort of tackle that from a data modeling standpoint at least?

DM: I mean, I think right now our best answer is that it’s not that the reporters are an input stream, is that we’re giving the input streams to the reporters. So our best solution right now is to give them the subject matter experts, the cleanest, fastest information, and to reduce all the other friction that they would normally encounter when trying to do this reporting. They’re able to do a great job of synthesizing, because there’s a lot of details that they hear on the radio about the real-time firefighting efforts. Not all of that is relevant to the end user. And their job, one of their jobs, is to make sure that what they’re reporting is the most relevant information. You don’t want to get your phone pinging you every 2 minutes saying like one more engine got added, 2 more engines got added, it doesn’t, it’s not meaningful. It’s not actionable. I think what they do such a good job at is finding that balance between giving people information that is actionable and not leaving them scratching their heads saying like, oh God, what’s happening? I haven’t heard anything in 6 hours, and I live 2 miles from this fire. So we really view it as what are the best systems that we can give these ex-human experts, they’re going to do the synthesis and analysis, and then out comes actionable information for the public.

WV: Human AI, which works a lot better. It works a lot better than — I mean, the creativity and — and absolutely not.

DM: I mean even when we do have automation, even when we do have automation, it’s always human in the loop. I think that is really overlooked a lot in terms of like the value of where AI and automation and technology can go because you can get so far by just giving people a review but, as opposed to making them do all the work or being OK with failures or error. And in our situation, we’re very conservative in terms of ensuring that the accuracy of the data is very, very high going out.

SE: I was gonna say, I think that philosophy of needing to be right. And valuing the correctness versus the speed is such a fundamental tenet in a safety critical world that’s often overlooked.

JM: Yeah, there’s a signal that I wanna tell you guys about since this is a geeky podcast and Dave’s probably gonna know what it’s gonna be, but this has gotta be my all-time favorite thing that we do. So, fires are fought with radios, right? Shovels, sweat, and radio is how fires are fought, and there’s a lot of intelligence on those analog radio channels, right? It’s 150-ish megahertz depending on where you are. And so what’s really interesting about the fire service and actually all emergency services is they put digital signals on an analog radio network. And so what you’ll hear by listening to the first responders is you’ll hear DTMF tones, right? The same thing that your phone used to produce or the fake ones that the iPhone produces, that doesn’t do anything anymore, right? That sound is something that they actually use to communicate with each other, and it goes extraordinarily deep. So here’s what happens. There’s someone at the dispatch office who’s gonna order an engine and they say, hey, I need someone who can go investigate a fire. Someone called in a fire at 123 Main Street. They hang up the phone. Some dispatcher will radio in, and they’ll often use CAD systems and whomever, but anyway, what will happen is they will tone out is what it’s called a firehouse. And so let’s say that tone is 1234. So on that radio frequency, you’re gonna hear beep beep beep beep, there’s a number, right? That number means something in that county, but two counties over, that might be a bulldozer or that might be a battalion chief. Well, our team are those types of people who decided to listen to all of them and begin to categorize them all. And so now we do DTMF tone demodulation, and we built the Yellow Pages out of the analog network to turn into a digital signal, to then drop it into Slack to say that someone ordered 3 bulldozers in this general area. So that’s the lengths that we’ve gone to solve a complex problem.

SE: When we say diving deep, that’s diving deep. I love it. I love it.

WV: Given that it’s also called the Frugal podcast. So let’s go back to money a little bit. You were just a bunch of geeks building something that you thought was going to be extremely useful for yourself. That at some moment you’ll be, you understand that you need finance for this and you made the decision to become a nonprofit organization. So that means you start relying on donations or and at some moment also you have subscription. So how does that, first of all, how does the process work for you?

JM: Well, the interesting part is we were a nonprofit from the beginning, and I actually formed a nonprofit before watch duty, and the nonprofit’s mission statement is solving obvious problems for underserved communities. So, I got that paperwork approval in April of 21. We started to formulate the idea earlier than that. We started building code on May 17th of 2021. And so we actually have always been a nonprofit. We’re still a bunch of geeks trying to change the world, but that hasn’t changed, and neither has the nonprofit status. So it’s always been that way. And then ultimately, to Dave’s point, like the end of our first year we were like 100,000 users. It’s like a drop in the bucket. And so we got donations from Amazon and Heroku early on, we didn’t really have any bills, right? So we published a lot of this publicly, you could see it on our annual report, but like, we spent no money the first year at all. It was just human intelligence for the entire first rendition of this project.

DM: I mean, and it’s also easy to spend no money when you have 5 engineers giving them time. I mean, yeah, like that was the output that was, that was the input was like, we had donations from some cloud providers and people donated their time. I think the transition from a full volunteer to the paid staff and like, all right, we’re really growing up here. That was where we started to figure out, all right, well, what is our business model going to be? How are we going to run this? We don’t want to throw galas. We don’t want to do the traditional nonprofit grant funding cycle where we’re beholden to all this. So we kind of went to what we knew, which was treated like a startup, most of it’s going to be salaries. How do we get enough money to kick that off? And then, It was never going to be a problem about user growth, it seemed like, or engagement. We, I think what was our NPS the first time we measured it like 92, like paid

JM: was in the 90s, yeah, yeah it was 86.

WV: climate change, your application area is probably only going to grow over time.

DM: sadly, a growth industry, yes.

JM: So, I think after the 1st 18 months is when I put a first a million dollars into the company, and that’s when I was able to call Dave and say, hey man, remember that thing we’re doing? Well, this is a real job now, and so I kickstarted it with a million dollars. We hired Dave and some other help at the time. I can’t remember the years blending together. There is no fire season anymore, it’s just fire all the time, but anywho, we were able to then hire top tier talent. It wasn’t just volunteers anymore, it was volunteer supported operations, like any nonprofit, they have volunteers and they have staff, right? And so we were able to kick that off and get that running, and then to Dave’s point, like we knew that we could make a self-sustaining business. As a nonprofit, and it actually took me at least a year or so to figure this out, because every lawyer, CPA, nonprofit I talked to told me, I can’t do what I’m doing. And then I started to dig in deeper. I was like, well, what about AARP? They’re a $1.5 billion a year nonprofit, and they sell services, i.e. a magazine, to the elderly, and then they get discounts at Safeway. And turns out then the lawyers are like, oh well, you can do that, and I’m like, well, what’s the difference of what I was telling you, right? They’re like, well, the answer is they’re not paid to think that way, right? And so it took a lot of like thinking about this problem, like unlock it, we’re like, wait a second, museums and the AARP work the same. Same with NPR who sends you a tote bag for donating, right? We just give you extra features in the app. And so the beauty is of nonprofit is that As long as you’re selling services that are part of your program, which is what the money goes to, then the proceeds coming off of that are nonprofit dollars, non-tax deductible, do not get taxed on revenue, and now we operate like any other of these nonprofits does, and that was the big unlock for us to figure out how we make an actual business out of this thing.

WV: So if you think about the architecture side of it, when you started offering, let’s say, for-pay features, did that change the way that you thought about your architecture because now suddenly you have a reliable income stream.

DM: Yeah, I mean, I think the marginal cost of all of those was really quite low. So it didn’t have a huge impact on like the spend, it started out as a very small percentage of our users. So it wasn’t, and the percentage of users that donate and become members is still under 2.5%. So we’re giving away this data and we always will for the life and safety stuff. But that’s to 97% of the people using the application. So it’s like we always had to build for the scale of people that are not going to pay us anything. So as always, how can we make sure that this is going to be done efficiently? We need to be able to have buffers. We need to be able to When it was really more about like, what does it look like when it doubles, triples, 10x on the cost side, and then we’ll find out how the income will get to us. Now, in terms of, I would say the biggest difference about having a more reliable income stream is they’re able to hire. It was like, we had a lot of confidence that this was a market fit, that this was incredibly useful, but we can’t, there wasn’t a VC fund that was going to continue to funnel us money until that finally panned out. So we need to make sure that we were hiring responsibly and effectively for kind of like, I guess a bit more conservatively than I think a traditional for-profit business would have. So it really helped us understand how we could grow that team out.

WV: You’re really, I mean, your origin and your focus is really and also of course, the emergency of the past, let’s say 6 months at least is fires. Fires in California. Yeah, but I can imagine that this application will be equally useful for hurricanes in the south of the US or other type of flare up emergencies like there are. Do you guys see interest into that? Not necessarily from you, but do you get contacted by other people saying, hey, we would like to use it for this particular application area?

JM: Yeah, I mean, just like, we started as a nonprofit, we also didn’t put fire in the name of the company on purpose, right? So, First of all, we’re in 22 states, not just one, right? So California happens to have 38 million people, which is like most of the population of the West, but we’ve been covering fires in many other states, for quite some time, and now we’re all the way up to the Mississippi River minus Louisiana. So, we’re already pushing eastward. And then we’re now launching our investigation and some new features out soon-ish, we’re trying to figure that out regarding water issues, right? Now water happens to show up in very funny ways. It can show up in a tsunami, it can show up in a river, it can show up in a hurricane, and water kills more people than fire, actually, right? People run from fires, but they drive their Prius into the river thinking they can ford it, right? And it’s a strange human phenomenon, right, of like kind of a misnomer of how powerful water actually is, so, It’s a great question, and we’re going to continue to explore what that looks like and how we deal with these other disasters that are geospatial in nature, that are temporal, and unfortunately, we’ve seen many issues and other problems, right? We just had a tsunami warning that went out to a lot of the American West on the coast, and that warning said run to higher ground. Now some counties in areas went to extremes, like I have friends in Berkeley that all packed their Subarus and drove up the hill, and they found out that 25 minutes later, there was no tsunami, it was not going to make its way under the Golden Gate Bridge, and it was not going to wipe out Berkeley. Meanwhile, they’re panicking for 25 minutes while a tiny little swell, perfect for surfing, went under the Golden Gate Bridge and did nothing, right? And so this problem exists everywhere because we don’t think about borders and boundaries, right? Like we look at things from 80,000 ft down and say like, what do the people need to do in response to this geospatial problem and how do we stop pretending that these jurisdictions actually make any sense, because they don’t, right? These disasters take from us all equally and everyone deserves equal information and so we try and think about it from a much broader perspective than just fire, just this county, just this area or just this disaster.

WV: Yeah, here in Europe, the biggest deal is indeed floods. There are the big rivers like the Rhine and the Meuse and others are all, more and more the dikes haven’t been built as high as they should have been 20 years ago, and it’s a massive problem here as well and a lot of reporting is inaccurate around that at the moment. So yeah, I can see many different areas where you guys could be successful.

SE: Definitely more work to be done.

DM: Just to add on there, I mean, I think what we’ve seen is that, I don’t think this takes anyone by surprise, but the government is not the best at building agile software. Best of intentions, but it’s just not their strong suit, and there needs to be these really high class, well thought through product-driven solutions to really pressing problems, and they’re not being built. I don’t think what we’re doing with wildfire is going to be the solution for a hurricane. There’s some really unique characteristics about the temporality, as John said, with wildfire. It’s probably closer to a tornado than anything else, except tornado is more just like hunker down, get in the basement. There’s not a lot of other action you get to do. So we’re not sure what it looks like in everywhere else, but we do know that there’s this big gap. The gap is high quality products delivered for free to the public across jurisdictions and boundaries and borders. And I think that that there, like you said, there’s a lot of room to grow there, but we really have to figure out where we fit in. What we’re doing for fire may not be the product fit, the market fit in every disaster, but it’s going to be there and we’re working and investigating what capabilities we can add to our platform to fill those gaps. Sounds

SE: like there’s plenty to get on with, which is fantastic. John and David, thanks so much for joining us today on the podcast.

WV: It’s a brilliant product and an absolutely essential service.

SE: Absolutely, and Werner, as always, I think this kind of story again emphasizes that frugality in all its forms is an important thing for architects to think about. It’s not just money, it’s time, it’s effort, it’s problem fit. There’s a lot to unpack here.

WV: Well, and team size, for example, indeed, I remember Dave said at the beginning, your tech stack is mostly also determined by who’s willing to come on board. And indeed if you pick Django and Python, you will be able to find a lot more engineers that are able to contribute. Yeah, we actually in the early days of AWS built one or two products on the perfect programming language, Erlang. Don’t, don’t, don’t even get me started. It’s not my idea. It’s not my idea. However, what that team pretty quickly figured out is that they couldn’t move anywhere else in the organization because that’s what you can do within AWS. You work for two years on that particular database, you move, you go, you want to do something robotics, you go to the other side. Nobody could leave on that team because he couldn’t hire new Erlang programmers. So, course of action after 2 years was to rewrite it in Java. Not because I was the better choice in terms of technology, but there are so many more aspects to development than just is this the absolute best new, best particular technology for this particular thing if you can’t hire the people for it. It remains a people problem.

SE: The right tool for the right job. Thanks everyone, and thanks everyone for listening. And until next time, keep on building.