Mike Taber is the single founder of Bluetick.io, the SaaS which automates email follow-ups.  In this episode, we talk about his life as the single Dev, single Ops, single Marketing, and single everything else in his company.

Today's Guest
Mike Taber
Twitter: @SingleFounder
Bluetick: https://bluetick.io/
Founder Cafe: https://www.foundercafe.com/

Resources:
Startups for the Rest of Us Podcast
MicroConf

Transcript

Jonathan Hall: Ladies and gentlemen, The Tiny DevOps Guy.

[music]

Hello, everyone. Welcome to another episode of The Tiny DevOps podcast, where we believe you don't need a thousand engineers to do world-class DevOps. I'm your host, Jonathan Hall. Today I have with me a special guest, Mike Tabor, who is a solo founder, single founder of Bluetick, which we'll talk about in a moment. He's going to talk to us today about his experience as a solo DevOps programmer business person and wearing so many hats at once, we're going to just learn about his experience with that. Welcome, Mike, to the show. Thanks for coming. Why don't you do yourself a little more justice than I did and tell us a little bit more about who you are and maybe what Bluetick is?

Mike Tabor: Sure. I guess the long story would be I started my own business back in 2005 and ran a bunch of different things between then and now. Probably what I'm mostly known for is probably The Startups For the Rest of Us podcast, which I started with Rob Walling back in 2011, I believe. Then we started an online community for bootstrapped and self-funded entrepreneurs called FounderCafe, then MicroConf. That's a conference specifically for self-funded and small bootstrap software engineers.

Jonathan: Great. Of course, that's where you and I met for the first time in Croatia a few years ago when I was an attendee, but you've been working on, so you said since 2005, is that when Bluetick started or did that come a little bit later?

Mike: That came much, much later. I had ideas for it. For several years, I went through this idea validation process for it and decided that it was something that I wanted to build. It was a problem that I'd had with a previous product I was working on. If I had information that I wanted to get from somebody, I would send them an email and I would just get radio silence. These were people that I'd already had conversations with and they just weren't returning my emails. I found that there were certain things that I would tell them that would resonate and then suddenly they would want to talk to me again.

For example, I'd say, "Hey, we just came up with this new release and this is what it does." Sometimes I would immediately get an email back that says, "Hey, we'd love to talk to you about this and go over demo or what have you." What I realized was that there was a need for me to start using a product that would automate this outreach process because I was managing in a spreadsheet, and if you ever try to manage I'll say emails back and forth between you and more than five or six people at a time, it becomes a nightmare. Let's say on day one you send out five emails, three or four days later you have to send out a second email or a follow-up email if you don't get a response, but you want to make sure that you're only replying to those people that haven't talked to you yet. I needed a tool that would help me with that.

Jonathan: I think I can identify with that problem trying to email, for example, certain podcast guests. Not you, fortunately, you responded very quickly, but sometimes I tried to reach out to somebody about coming on the podcast and maybe they write back and say, "Yes, maybe. Get back to me in a couple of weeks." Then I have to remember to get back in a couple of weeks and maybe I do, but they don't respond, and then I need get back to them. It sounds like you found a real problem. How is that business going? You started it four or five years ago. How are things now? You've gotten some traction?

Mike: They're going okay. They could obviously be going-- I think anybody can say, "Oh, it could be going a lot better." Then there's just people who are on that hockey stick curve and up into the right and it's going great for them. Honestly, I have struggled quite a bit with Bluetick from a mental and emotional standpoint because Bluetick has a really good product and it does exactly what it's supposed to do.

The problem is the types of customers I attract are the ones that are doing lots of cold email and because it works so well, they don't necessarily do cold email well. They're looking for a tool that will just allow them to automate and scale up to like hundreds or thousands of emails on a daily or weekly basis. What I struggle with is, am I creating a tool that contributes to the greater good of society or not? Cold email I think is not necessarily a contribution to the greater good.

Jonathan: Let's talk about the technology behind Bluetick. Since we are a DevOps-focused show today, maybe just start at the beginning, what language is it written in? What technology did you choose to build your product?

Mike: The back end of everything is all written in .NET. I've been a .NET developer for a really long time and just kept up with it. I would say it's probably my go-to in terms of technology for most backend work. On the front end, it's all Angular. Actually, it's technically AngularJS, [laughs] I'm still on like the first version of Angular. I think Angular is up to, what? Version 10 or 11 right now. I still haven't upgraded that and that's a forklift upgrade.

I'm like, "I just really don't want to go in and have to do all that work in order to get it to a more recent version." I know I'll have to at some point but for the time being, it's just not risen to the top of the priority list because the application works like all the technology works and it's not any major security risks or holes that I'm aware of. I had a security audit done and they didn't see anything wrong with it. Everything's fine. It's just not the most up-to-date technology in the world.

Jonathan: How do you host the service? Do you have a server in your closet or are you using VM somewhere? How does that work? [laughs]

Mike: I've done that before. Not anymore. I haven't done that in years. I have everything hosted over in Microsoft's Azure platform and I think it runs on three different servers and then I have a fourth one that I use specifically for the build server. I don't run that at all times. I really just fired it up when I'm doing bills and when I check code in and it goes through tasks and creates everything and packages it all up, and then it allows me to deploy it out to the other servers. I have a server that's used specifically for all the front-end stuff. Then I have another server that's used specifically for all the backend stuff. Then I have one dedicated database server.

Jonathan: That's interesting. Each server serves a specific purpose. They're not like redundant servers in any sort of sense?

Mike: Yes, correct. That's an important distinction to make just because of the way environments can work as well, because you might think that, "Oh, he's got three servers, you've got three different environments, he's got one in one on each of those servers." That's not the case. It's like each of them has a specific role it fulfills, and it's doing a different amount of work.

Jonathan: Suppose one of those servers for some reason vanished, the disk got corrupted, or he decided to add a fourth one. What would be the steps involved in doing that? How much of that would be [unintelligible 00:06:58] and how much would be automated?

Mike: I have backups of everything and I maintain rolling backups for, I think, six months right now. That includes everything, including the database server and the databases on it. If anything goes down, I can recover it fairly easily. Obviously, I think most manual steps to do it, but it's not very difficult to do that. In terms of if I had to add another server for either the front end or back end infrastructure, it would really depend on which of those three servers I was trying to replicate. If it was the database server, I would probably do a lot more in terms of trying to optimize the code, then trying to scale that machine out to multiple servers. I've done clustering for SQL Server before, and it's not something I really want to do for this app if I don't have to. It becomes a nightmare.

If I had to scale up the three servers that I have, there's the front-end store which just does host the IIS websites for that. Those I could scale that up pretty easily, or I could just add more resources to it because it's literally just serving up HTML and CSS files and JavaScript files. That's really all that it does. There's no real need, I don't think, to scale that up other than if I wanted to add in some redundancy or something like that, for something like that, I'd probably just start migrating my names, my DNS over into the Azure services for Azure DNS, and then just do like round-robin distribution for centering the incoming request to those different servers. For the worker service, that's a lot more complicated. Every time somebody schedules an email inside of Bluetick, it ends up in that scheduler service.

There's this backend worker process that I have in place that runs as a windows service that gets installed when I do a deployment. What it does is every 10 minutes it will go out to every single one of my customers and log into their mail, see if there's any new mail, download it, and then compare the contents of that to see if it's a reply to an email that Bluetick sent. It does that for every single one of them every 10 minutes.

In addition to that, it's got all these scheduled jobs that run based on whatever schedule my customer set. If they say at 10:00 AM I want this particular step to trigger, Bluetick will go out and check it at 10:00 AM on whatever days they've specified. There are literally thousands of schedules that are there that are also being attracted in here too by that server.

Jonathan: How would you describe yourself as a programmer?

Mike: It depends on how far you go down the rabbit hole of technically correct. I'm a stickler when it comes to things like naming conventions and doing things, in the same way, each time because it makes it easier to modify the code. It makes it easier to look at something and just know what it's supposed to mean or what it's supposed to do. I'm a big proponent or fan of longer variable names and things like that. When it comes to those types of things, I want to be very exact.

When it comes to other stuff, sometimes I just hack things together, and in some cases, it's just because I'm doing research and development. Then I get to a certain point where it's holding me up to do it the correct way and I'll put something into place, and maybe it's not the way that it probably should be done, but that's the way that it is and it works, and then I immediately have to go off and do something else. Then I'm accumulating technical debt in some places. There's definitely places in the app where there's technical debt that I would love to get rid of, but it's not necessarily worth the time and effort to go do it. I'd say I'm probably somewhat pragmatic in that way, but my preference would be to have it be technically correct, if that makes sense.

Jonathan: I imagine there are times, maybe I'm wrong, but I imagine there are times when you think, "Oh, I'd love to fix this thing, it's bugging me for whatever reason, but it's not going to move the needle, it's not going to win more customers, so I'm going to focus on something else." How often are you faced with that?

Mike: I would say all the time. [chuckles] It's a tough spot to be in. I think if your back is against the wall and you need revenue, then it's easier to make that decision to just go focus on the things that are going to generate revenue and move the needle. If you're not, I'm not necessarily dependent upon the revenue for this, it's a lot easier for me to fall into that. I'll call it a trap, to be honest. Fall into that trap of, "Let me work on this over here because it'll make the product better." The customer may not see it, but it will allow me to do other things easier and allow me to sleep better at night because I won't be thinking about that.

Removing that mental overhead is extremely helpful for somebody like me because I've always got all these different details in my head or places of the app where I'm like, "Oh God, I don't want to go in there and touch that because it's a little bit fragile, or there's external dependencies and I don't know what's going to happen there, or I don't have enough code coverage in my unit tests or integration tests." Those types of things can bother me, so I have to do this delicate balancing act where sometimes it makes more sense to just put something out there knowing that it works, but it probably needs some work and tender care to fix things a little bit. At the end of the day, the customer doesn't actually see most of it.

There's definitely areas of the app where I've looked at it and said, "This is a bug and this should be fixed," but no customer has complained about it, literally ever. It's just I'm the only one who's seen it. Is there any value in actually fixing it? The answer is no, it doesn't matter. Usually, they're little things that a customer is just never going to run into, or an error message that just once in a lifetime pops up and a customer might get confused and it's easier for them to just email me. Half the time they're going to email me anyway, anytime they see an error message, so what difference does it make?

Jonathan: I want to ask the same question I did about, what type of program you are, but now when you apply that to infrastructure and operations.

Mike: I've done infrastructure work for a really long time. I used to do consulting for Symantec, and I would go in and I would deploy these massive systems using this technology called Alturas, where it would literally manage thousands or tens of thousands of machines. From an infrastructure standpoint, I didn't know exactly what I was doing in order to manage, you don't easily manage 50,000 machines unless you really know what you're doing. I would install the software and come in and do consulting work for customers to help them do this and help them manage their infrastructure.

In terms of infrastructure, I really would say I know a lot about what I'm doing there, but that said, for this particular infrastructure, I don't have Chef, I don't have Puppet. The only thing that I would say is really streamlined well is my deployment process and my backups and things that, because those are the only things that I need. If I had more than four machines, it might make sense for me to go down that road and be able to make everything completely redundant or click a couple of buttons and have everything spin up new servers and reimage them or what have you, but I don't. It's not really worth the time and effort to invest in that sort of thing.

Maybe for a recovery situation, sure, but I've had times where a service will go down and my customers don't notice. I've seen places where, I think there was a time where the service was down for probably two or three days, and it was just a backend Windows service, the front end of the application still worked, it just didn't do anything in the background. It was a couple of days before a customer said anything to me. I'm like, "Oh, okay."

It's because Bluetick operates in the background. It's not something you log into every day and see results, and you're not in it all the time. You go in, do your work and you leave. I have customers who haven't logged in for months, but they're still getting a lot of value out of it because they send things in through Zapier and they have it integrated into their marketing, their sales pipeline, and it just operates in the background for them. They don't even log in half the time.

Jonathan: Did that incident where you had a service down for a few days, did that prompt you to set up monitoring?

Mike: It prompted me to set up the service so that it will restart after a couple of minutes if it fails and it'll do that up to three times. After that, something else is probably wrong. No, I didn't actually do anything beyond that. [laughs]

Jonathan: If you don't mind, I'd be curious to hear how your product workflow goes, in the sense of you get maybe a feature request or a bug report, what are the steps you go through until the customer sees that and how long does that take?

Mike: That's a good question. It depends on whether it's a bug report or whether it's a feature request. If it's a feature request, what I tend to do is I'll look at the other feature requests that have come in, and until I can get a critical mass of people who have asked for that particular feature, then I'm probably not going to do anything about it other than just log it. That's for feature requests. If it's a bug, I tend to prioritize those quite a bit higher. Depending on what it is, I may drop what I'm doing and work on that or say, "Hey, I recognize this as a bug. I'll get to it after the current workflow that I'm in the middle of."

Jonathan: Then once you decide you're going to tackle that bug or that feature, you set aside some time, you start coding. What happens next?

Mike: Sure. Because I'm the only person working on the code, I tend to do the tests afterwards. I do a lot of, I'll say experimentation, you call it R&D work, to try and figure out what's the best way to put this in, how should these different classes and code modules work together? Because for this one app, I have, I think, 12 to 15 different projects inside a visual studio that actually do everything.

I figure out what needs to be done, how it needs to be done, and then I'll write some basic tests that verify that functionality. I don't write them in every single case, I definitely don't have 100% code coverage, especially when it comes to the third-party libraries, because I'm accessing external services or HTTPS. It's just harder to test those types of things, so I don't bother.

Once those things are done, I'll check it in and my build server will go through, make sure everything's right. I typically will run all of the unit tests locally first, and then after that, assuming the build server works and creates the packages, then I deploy them onto the development environment. Then I'll test things manually there depending on what it is. Then after that, it's go out to staging. If there's any database migrations that need to be done, that make sure that it's going to work against the production database. Then once that's done, I'll schedule a time to push it out into production.

Jonathan: When you decide to push to production, you said schedule a time, what does that entail? Is that just telling customers the servers will be down for 20 minutes on Thursday?

Mike: I typically just hit the button and just let it go. [laughs] The thing is, the types of updates I do are typically very small in terms of scope and scale. One of the issues I have is that because it's a SaaS product, anybody can be using it at any given time. I don't necessarily know who's logged in at any given time or exactly what they're doing. I could find out, I could write some tools that find that information out. For example, Saturday night on any given week would probably be a great time to push it out. That said, I also know that I have customers who are in Australia. Their daytime is my nighttime.

And at the end of the day, it doesn't matter. If there's a couple of hiccups here and there, not a big deal, but generally speaking, customers don't tend to have issues with me pushing things out in the middle of the day, because I'm not normally deleting stuff or deleting application endpoints, I'm always adding. When I'm adding things in, it's not a big deal. If it's something where I'm deleting the database column or something that, that could be an issue because then front-end code, if it doesn't match the back-end code, you're trying to tell it to do something, I have no idea what this field is, it doesn't exist, and then they get an error.

I try to avoid those things in the middle of the week, but usually what I'll do is I'll add the things in, deprecate it, and then go in and start deleting those things a few weeks later. That tends to avoid those types of issues, but I don't typically have problems with needing to bring the application down for days or I guess minutes or hours at a time. Usually, everything is pretty much updated in place and it's not a big deal.

Jonathan: How much time do you spend these days on coding versus, say, business development or marketing or other aspects of your business?

Mike: I'd probably say I spend more time coding than I do on like the marketing side of things. It's gotten probably closer to 50/50 at this point. In the early days, you're doing way more programming and development than you are on anything else. Most of what I'm doing right now is looking to see where the application needs to be refactored and what things will make it a little bit more bulletproof.

I always try as hard as I can to make sure that the application is bulletproof because I don't want to field support calls about, "Oh, this is busted." Or, "My data looks like it's corrupted." That's the worst-case scenario in every situation. You never want to have that happen. That said, there's always the fiascos that will happen. I think that recently there was a thread on Twitter about the dear intern, I don't know if you saw those from HBO.

Jonathan: No.

Mike: HBO apparently sent out-- Somebody internally was running some tests, and they had it connected to a production database of some kind. Probably thousands or maybe tens, or hundreds of thousands of people got an email that said, integration test number one. That's literally all it said, and it came from HBO. I saw it and I was like, "Oh, that's funny." Of course, they did blame it on the intern. They said, "It was an intern. Yes, we're working with him to help him get through this." Then there was a dear intern hashtag on Twitter that was trending for a while of people sharing their stories about all the different things that had just gone completely wrong, and there're no jobs and they're just like, "Yes, don't worry about it, buddy."

[laughter]

I try to make sure that my code is as bulletproof as possible so that I don't have to go back and deal with those types of things. I think that has helped me a lot in terms of staying away from doing too much support. That said, there's a lot of other things in the app that probably should be done that are more, I'll say, user-friendly. The onboarding, for example, definitely needs a lot of work. The marketing engine needs a lot of work. I know how to do it, I just haven't dedicated the time to it.

Jonathan: Looking back, what have been some of the biggest surprises, maybe in your Bluetick journey?

Mike: I would say that there's a big difference between what I think is important and what customers think is important. Some of it is educational. Some people think, "Oh, I really want to be able to send out these cold emails. I want to embed these images in it. I want to do this and that." I'm like, "A, You don't want to do that, and here's all the different reasons why." Then they realize, "Oh, that's probably not a good idea. Great, thanks."

Then there's other times where somebody will say, "Hey, I'd really like to do this." We have a conversation about why they want to do it and then I realize, "Oh, that's something I just never even thought of or had considered why you would want to do something like that." There's usually just a discrepancy or a gap between what you think is important versus what your customers think is important.

Jonathan: What would you do differently if you could? If you could go back and start over, what would you do differently?

Mike: Oh, geez. I'd probably think a little bit harder about how to position the product. Or how to plug it into somebody's sales and marketing engine in such a way that it is not causing more problems than-- More harm than good, I'll say, in the cold email market. Like I said, it's a great tool. It does exactly what it's supposed to do and it works really well. I just wish I had a better story to tell about different places you could plug it in because the low-hanging fruit that most people have or that you can point to is pretty well taken care of by most of the types of tools that are already out there.

For example, the calendar link. If you want to schedule a meeting with somebody, you send him a calendar link and it will follow up with them to let them know that they've scheduled a meeting. It doesn't necessarily follow up with them to say, "Hey, we still need to get on this call. Here's a reminder that we need to get on this call." It won't do things like that. Again, you could automate that through a number of different tools. That's a huge use case for cold email, which again, I said, I want to try and avoid that if possible. Maybe I say the heck with it and join the bad guys and take the money out. I don't know.

[laughter]

Jonathan: I'm impressed that the answer to both of those questions had nothing to do with the technology that you've chosen. It sounds like the technology for you as a tool is serving its purpose and other than that, it's not a big deal. I think a lot of listeners, myself included, at least in certain roles in the past have been so focused on technology that if somebody asked me what was the biggest surprise, I would think, "Oh, my gosh. That one time the database server exploded." Or something like that.

You focus on the business, and the technology is serving your business successfully so far as we expect. I like that perspective because it's a perspective, I think many, many developers and engineers forget that our jobs are there to serve a business need, and you've got it lined up. It's serving your needs. The places where you wish things were better are all related to business, not to technology, as I understand.

Mike: Yes. Well, the way that you phrase the questions like what's the biggest surprises there? For the most part, I don't find anything that's technology-related to be a surprise. Is it a surprise that something was broken in an older version of library? No, of course, not. If your database server goes down and you lose data, and you should have had backups, it's not a surprise. That's why I would say nothing that's technology-related should really be a surprise for most developers. The surprises are really where you're making assumptions about what should be happening. Or what users are going to see or what they're going to do with your product because you really don't know.

Jonathan: Are there any tradeoffs that maybe you wish you hadn't had to make?

Mike: I'd say there's a handful of things. Some of them are technology-related and some of them are not. The technology-related things, I would-- For the scheduler, for example, I use an in-memory database right now. What happens is that when I restart the service, it reruns and basically downloads everything out of the database that is supposed to be scheduled, keeps it in memory. Then while that service is running, it just manages all the scheduled tasks and jobs. What that means is there's-- The side effect of that is that every time the scheduler starts up, it has no knowledge of anything that happened before.

Let's say that I restart the service in the middle of the day. I'll say, like 9:59 AM. I say that specifically, because the default schedule for new emails or sequences that are going out is at 10:00 AM. If I restart it at 9:59 AM and then it doesn't start back up again until 10:03 AM, any of those schedules that were in there are probably going to be missed. There's nothing there because it doesn't have the ability to see, "Oh, this should have run today at 10:00 AM, but it didn't so I'm going to run now." It just basically missed that timeframe.

That's something I would like to have fixed. I'd like to convert it over into storing all those things directly in the database so that if there is a failure of any kind or the service restarts, and it looks at that and says, "Oh, I should have run this at 10:00 AM and I didn't, so I'll run it now." That stuff would be taken care of. That would also contribute to the uptime and the resiliency of the system.

At the same time, when I restart that service, it's never down for more than a minute or two. I just avoid 10:00 AM. [laughs] Like afternoons, evenings. Perfect time to do it because nobody notices. Other things I can think of. I do wish a lot of times I had a business partner who was working with me on various things so that I had more of a sounding board. I have a mastermind group, I talked to them quite a bit. They're very helpful, very great to us.

However, having a mastermind group that you meet with once a week or once every two weeks is very different than having somebody who's also actively working on your business and in it and talking directly to customers and onboarding them, and answering questions and coming up with ideas about how to solve different problems in the business. How to market it, how to do more things for your customers.

I would say that's probably the biggest thing that I wish that I had. At the same time, it's been so hard to find somebody who fits the mold or that I'd have that history with I would trust to bring into the business. I'm not opposed to it, still not opposed to it but it's just hard to find somebody who fits all the criteria or ticks off all the boxes and also figure out a way for it to actually work in terms of equity split or profit-sharing, or what have you.

Jonathan: What advice can you offer to anybody who is in a similar situation? Maybe they're trying to start their own business or they have started their own business and they're struggling to balance the demands of business and technology, and development and operations and all this stuff. Any advice you can offer to them.

Mike: I would say focus more on talking to the customers and finding out if there's ways that you can create shortcuts. I've found that when you get customers who ask for certain things, and I fail to come up with an idea off the top my head, but if they could say, "Hey, I wish I could do this in your software. I would like a checkbox that does this or a dropdown. Something along those lines, something else on the screen." You always want to ask why. Why is it so you want to do that? Because sometimes there's a workaround, that information may already be available to them, or there may be a different way to do it, and they just didn't know that it existed. If you don't ask the question you don't know, and now you're blindly implementing things that either, A, don't make sense for your product or, B, are redundant, because it's an education issue, and the customer just didn't know that that was there. Having that conversation with them tells you that and then you can ask yourself the question, "Why didn't they know that this thing already existed over here?"

Those things can help you to avoid doing, I'll say, busy work or doing work that didn't need to be done, to begin with. It's a huge time-saver, especially when you just ask, "Why is that important to you?" The other thing I would say is when you are having those conversations with questions, or with customers, and they ask you if your software can do something, turn it around on them and ask them, "Is that important to you?" Because I've had people ask me for something before and again, I can't remember the exact situation, they said, "Can you do this with your software?" I said, "Well, is that important to you?" "No, I was just wondering."

The way that they phrased it, it seemed like it was important to them, and that was a deciding factor for them to sign on to the software and buy it. I also knew that, hey, that's probably two or three months' worth of work. That's a huge, huge effort. "Is that important to you?" "No, I was just curious." Oh, geez, I just saved myself two or three months of work by asking that question. You can really get into some bad situations where you're either committing things to the customer that don't make sense at all or committing yourself to implementing all these things that it's just a ton of extra work and effort that don't need to be done. It's just a delicate balancing act.

Jonathan: I made it through my list of questions. Mike, is there anything else you'd like to add?

Mike: I don't think so. I think you've pretty much covered everything that I would possibly have talked about-

Jonathan: [laughs]

Mike: -in terms of development and operations. I think it's an interesting topic. I don't think that most developers pay attention enough to DevOps when they're building a product because you really want to make sure that it's always up and available, and you're able to deploy and deliver things to customers on a timely basis. I think it's just not something that's typically taught in school to people and they're not exposed to it until they get out and start actually building and shipping products. It's difficult to find information about that. I think it's a great service that you're offering for this podcast to help fill people in on those gaps.

Jonathan: Great. Well, thank you. Mike, if people are interested in following up with you, how can they get in touch with you?

Mike: Sure. I used to be fairly active on Twitter, with my single founder handle. I'm not as much anymore, but still, I'm pretty active in the FounderCafe community, which you can find on foundercafe.com. I'm usually available through email and you can always find me over at Bluetick.io. Those are probably the three main places they would look.

Jonathan: Wonderful. Thanks so much, Mike, for coming on. Best of luck as you continue to advance with Bluetick.

Mike: Thank you very much, I appreciate it.

[music]

Jonathan: This episode is Copyright 2021 by Jonathan Hall. All rights reserved. Find me online at jhall.io. The music is performed by [unintelligible 00:33:21].

[00:33:24] [END OF AUDIO]