App development, bug reporting, and more in this GeekSpeak podcast with Bugsee

Back in early September, Lyle Troxell from GeekSpeak invited Dmitry and myself to his ad-hoc studio at Netflix in Los Gatos to record an episode for his podcast.

Interestingly enough, we didn’t realize we were actually going to do the recording then. We thought we were just meeting Lyle to discuss a future interview. Imagine our surprise, when we walked into a regular Netflix conference room and saw Lyle setting up his recording equipment.

We had a fantastic time chatting with Lyle. We covered a wide variety of topics. We started with the importance of titles in a startup, then went to talk about our early days working in embedded space with cameras, DVDs and phones. Then talked through our previous adventure and how it eventually, with a bit of help from Goldman Sachs, led us to the birth of Bugsee.

We covered a range of technical topics, such as recording video in production apps, its impact on UI and phone’s CPU, full network communication logging, why we use AWS and method swizzling in SWIFT.

We also touched upon some of the business challenges at the end.

Take a listen to what came out of it. There was another guest, Stu Sjouwerman from KnowBe4, on this episode, thus our part starts at minute 17:40.

Also, if you prefer to read through the interview instead, you can find a full transcript of our conversation below.

Thank you, Lyle!

PS: If you like GeekSpeak’s work, please consider supporting them.

 

Phishing for Bugs — Episode 45, Season 16 Full Transcript (from 17:40)

Lyle: I have Alex Fishman, he’s the CEO of Bugsee, a bug reporting tool. We’ll get into what it actually is. Alex, thank you so much for being here on GeekSpeak.

Alex: Thank you so much.

Lyle: And also, Dmitry Fink. And Dmitry, thank you very much for being here. Are you CTO?

Dmitry: Yes, I am a CTO.

Lyle: Are these titles because you’re more technical and you’re more businesslike? Or is it crucial that these titles are the way they are? I’m always curious about startups. How do you decide to name yourself?

Alex: I don’t think they are crucial. But yes, he is the smarter one.

Lyle: That’s how you define it?

Alex: Yes.

Lyle: And of course, he has his business smarts is very useful for you, Dmitry, right?

Dmitry: Yes.

Lyle: Well, thank you for joining me. I’m amazed at the timeline you’re dealing with in this company, so let’s get into it.

Alex: We started working together at a company in Israel called Zoran. We used to make chips for DVDs and digital cameras, before Netflix and iPhone killed both industries. I was working in digital camera industry and Dmitry was working on the DVD side. And that’s how both of us got here. Zoran relocated us, independently.

Lyle: And Dmitry, you have some Android developer experience, yes?

Dmitry: Not android application experience. After DVDs and DVD recorders, I was working at Palm, working on phones, WebOS. And I transitioned into Android as well. I was working at TI on Android phones, and I was working for Amazon. We were doing Kindles and FireTV. So mostly on the system level.

Lyle: So you guys both now are founders of Bugsee. And I guess you started in January of 2016. So it’s a relatively new company.

Alex: That’s correct.

Lyle: I know you have a third employee as well, who’s also doing developing or something of that nature?

Alex: More than that. We are eight people right now.

Lyle: Okay. Great. So let’s talk about the founding of a company together. Obviously, one thing to do is trust your partners. You guys trust each other, so that was an easy part. How’d you come up with wanting to be in the bug reporting and analysis space?

Alex: Well, we’ll have to take it even earlier than that. We actually cofounded a company together 2.5 years ago now. We raised a significant amount of money and built a team and revenue and customers and everything. Revenue was growing and luckily everything was going well. It just wasn’t going well enough, and at some point we realized that despite having a 17-people team and growing revenue, almost from day one, it just doesn’t look good.

Lyle: This is the menu company.

Alex: That’s correct. So the name of the company was Dishero, and we basically offered a way for restaurants to be very transparent with their customers, and for the customers to trust the menus in a way that’s not available today online because the user-generated content doesn’t necessarily do justice to the menu. And our customers, our restaurants, they paid us to be in the system. They were very happy with that. And the system started to grow and continued to grow from day one until the very end. But the growth was very painful and difficult to predict.

And at some point, despite having 1.5 years to go on our existing funding, we didn’t see a path to either becoming profitable or being in the position to raise the next round. So we came back to our investors at the end of July of 2015, so it’s a year ago now, and told them that that’s the case and we think we should shut down. And after a brief deliberation between Dmitry and myself and the other cofounder (we had another cofounder at the time) and as well as our board — Manu Kumar, from K9 Ventures, who is the lead investor and a board member in the company — we decided to shut down.

Lyle: That must have been hard.

Alex: Oh, yeah. I actually wrote a blog post on Medium about that, and it actually got a lot of attention on the web, including Wall Street Journal.

Lyle: I mean, when to decide your baby, who you invested years in, and people are relying upon, to shut down.

Alex: Absolutely. And we even had revenue. It wasn’t big, but it was growing. But just we didn’t see it going anywhere, and we had to be honest with ourselves. We just didn’t want to end up running the business into the ground and just running out of money.

So when we came and offered that solution to the investors, they told us, you know what, keep the money. See what you can do with that.

Lyle: Okay. We want to be in the next round.

Alex: Exactly.

Lyle: So the investors liked you, and probably partially, even at the end of you saying we could run this out, but let’s not; let’s do this more intelligently. That’s probably something when an investor goes: “hey, I can respect this person and trust them.”

Alex: That’s a fair observation. So what happened in August 1st of 2015, which is a year ago now, we ended up with a team of cofounders willing to work together, tons of money in the bank and have no freaking idea what to do with that.

Lyle: That’s great. That’s a beautiful spot to be in.

Dmitry: You would think so.

Alex: You would think so. It’s actually not that easy. And I wrote another blog post last week about it and that’s quite akin to marrying somebody in 90 days. So basically, setting the goal of marrying somebody you’re going to spend the rest of your life together. You’re going to work through a lot of challenges. It may or may not work out. You’re going to need some blessing from your parents/investors, and you have to do it in 90 days.

Lyle: Yeah, that’s tight.

Alex: It’s difficult to find a boyfriend or girlfriend in 90 days, let alone getting married. So we had a deadline, January 1st 2016, so we had about 3.5 months to do that properly.

Lyle: How many different ideas did you spin around?

Alex: Dozens and dozens and dozens.

Lyle: What was the runner-up? If you hadn’t done Bugsee, what would you have done?

Alex: That’s a good question. I don’t remember now.

Dmitry: I don’t remember, either.

Lyle: Right. Because as soon as you made that commitment, it’s all in, right?

Alex: Yeah.

Dmitry: This is the one.

Alex: It was tough. We had two groups of ideas. Ones that we kind of conceived ourselves, and another group of ideas that we basically took from others. We met with a lot of people. Dmitry as the smarter one, he led the first group effort. And I, as the networking slut, actually took the lead on the second effort. We went through dozens and dozens of ideas. And eventually came up with Bugsee at the end of 2015, around December timeframe.

We did a quick prototype, did the research, obviously. Luckily for us, Atlassian, the maker of Jira, went IPO last year. So they filed their S1. So Goldman Sachs did their market research for us. It was very, very timely.

Lyle: Does the makers of Jira, do they have a product similar to yours?

Alex: No, their market is developers.

Lyle: Same market space.

Alex: Right. Same market.

Lyle : So when they did that IPO they got research on how…

Alex: How many developers are there, where it’s going, how it’s growing, and what are the challenges, as well as they disclosed all their financials.

Lyle: Right. But they didn’t do their competitive analysis. You guys must have done some competitive analysis.

Alex: Of course. Just for the sake of market research — in terms of how the size of the market or where it’s going. Goldman Sacks helped us a lot in making the decision. So once we decided that’s what we want to do and one of the reasons we made the decision is because we had similar challenges in building our previous companies. We can totally relate to the challenges of reporting bugs and explaining everything that we had to the developers who sometimes are in different time zones. So it’s not necessarily easy to report all the issues and then they come back with questions and it takes time.

Lyle: All right. So let’s get down to what Bugsee actually is.

Lyle: How did you pitch this to the person who’s already given you money? Right, so now you’re just going to come and give your investor: “hey, this is what we’re going to do”. Give me your elevator pitch of what Bugsee was to be.

Alex: Just to clarify, the money was already in the bank. They had given us the money.

Lyle: You didn’t have to do anything.

Alex : The money was already in the bank. It’s a very, very different situation.

Bugsee is a bug reporting tool that every bug that gets reported using the Bugsee system includes a video recording of all the user actions leading up to the problem. All the touch events, all the network logs, all the console logs, and everything is being shown to you on a dashboard in a synchronized fashion. So you click a button, you see exactly what the user did, what was happening right before the problem. And you can see all the network and all the interaction with the server and see if it’s a server error or there was no network.

Lyle: Okay. And I took a look at it. It looks like you’re using CocoaPods, which makes it extremely easy for a developer to install this. You kind of tout in your intro video that it’s like one line of code to get this thing up and running, which is pretty great. We see a lot more of that kind of easy development feature set. Let’s describe for the general audience that’s not a developer.

When you say bug reporting, what you’re talking about building an app. I’ve got a little app that I’m making for a local bar in Santa Cruz. And it allows you to record what beers you’ve drank at the bar, and at the end of the cycle you get your name on the wall. So in that situation I have network connections, I have photos to be uploaded, and all these different things.

When I get it ready enough, I’m going to want to share it with a group of people that are kind of alpha testers. They’re not customers. They’re people that I trust to test it. And so I’ll deploy it out with maybe TestFlight. It’s an iOS app, so TestFlight allows you to push apps to people using the App Store methodology, but not to the general public.

At the end of that time, because they’re in this beta cycle, they have a special build of the app that allows them to report bugs to me. Sometimes you’ll see implementation you shake the app and it grabs a screenshot, and then kind of prompts you to type some stuff. And then what you get in the bug report is an email effectively, that says I ran into this — whatever they write. And of course, the knowledge that they can give you from using the app is pretty minimal; not network request connections; not what was leading up to it necessarily.

So the bug reporting tool you’re talking about allows me, as a developer, to very quickly produce a much better reporting on all the alpha testers I want to include. That they can report things that are really rich in detail. Is that kind of a good description?

Alex: That’s very correct. But it’s even broader than that. There’re three phases of development. There is internal development, and then there is beta testing, as like what you alluded to, as well as live in the app store. They’re very different phases, and you expect different kind of reports. So that’s one aspect.

The other aspect, there are two kinds of problems. One kind of problem that you see with your eyes, like a picture didn’t load, didn’t do what you expected, unintuitive UI or a misspelled text. Other kind of problem, the app just crashes. It just dies on you. No warning, no nothing, just boom, dies. So in all of these cases, Bugsee reports to you one minute of video that led up to the problem.

Lyle: Even an app-store production?

Alex: That’s correct. That one line of code that you talked about passes everything that Apple requires you to pass Apple’s certification. We pass Apple certification, and we have many customers live in the app store.

Lyle: So you have customers live in the app store where even if the user doesn’t report it, like a bug in the interface, if it crashed, what happens is, hopefully, the file system saved effectively, next time it boots it takes that payload and sends it off, and you get a user crash completely and video going up to that moment.

Alex: That’s very correct.

Lyle: Okay. That’s pretty cool. My day job is working at Netflix. I’m an engineer on the iOS app. We’re very conscious of privacy of the users. And in general, inspecting what they’re doing or looking over their shoulder without notifying them, would feel — something we’d definitely discuss, whether it would be a good idea to do that. Even though, of course, all the image assets and everything that they’re doing we’re delivering to them.

Some applications like a web browser that would do this kind of thing could have a lot of privacy concerns. That an end user might be looking at their email and it crashes. And all of a sudden you’ve got a picture of their email. So how to you decide on — do you have best practices for your developers?

Alex: Absolutely. So first of all, Bugsee automatically removes every secure field from the system. So whether it’s a password, whether it’s a credit card, whether it’s the picture from the camera from the phone, whatever is considered to be secure — is automatically removed. That’s all within this one line of code integration.

Lyle: Okay. Right. So you’ve made sure that some of the things you can detect are private, just turn it off.

Alex: Yes.

Lyle: That way it won’t log it. I don’t really care what it is anyway, because that’s not going to solve the problem.

Alex: Exactly. And it doesn’t even leave the phone. So it’s not like it goes to our servers and there we process it. It doesn’t even leave the phone. So it’s very, very secure on that front. And on top of that, we offer you APIs where you know that certain screens should not be recorded, and you preemptively can disable Bugsee in certain screens.

Lyle: So if you have a web browser screen, you’d do that. So from that perspective it makes sense. Are you always the middleman? Do these crash reports and log reports go to your services or do they go to the individual developer or is there different — it depends on the partnership?

Alex: I’m not sure I understand the question?

Lyle: So when, let’s say I take my beer app, and it crashes and I’ve used your system. Are the images, the last minute of video, and all that log report, when it boots back up, sent to me or does it send it to your service?

Alex: It’s uploaded to our server. And then you get an email and it goes to your Jira or your Slack.

Lyle: Okay. So you’ve integrated with Jira and Slack.

Alex: Yeah, we’ve integrated with like 15 different bug tracker and calibration tools.

Lyle: To be clear when you talked about Jira, Jira is a really well-known bug tracking tool made by Atlassian. We use it here at Netflix.

Alex: So do we.

Lyle: Yeah, it’s a great app.

Alex: It’s a great tool.

Lyle: And they have APIs, of course, for integrating other things into it. So when one of these bugs occurs in your system, you have a tab, an extension, if you will, to Jira’s system. And it actually logs it right into Jira. So from a developer’s perspective, if you’re used to using Jira, perfect, it’s right there for you.

Alex: It just shows up there. Right.

Lyle: Okay. So cool. So you’ve got some security concern issues because the developer has to trust that. Of course, all developers have to deal with this privacy issue, right? So it makes sense to me that they’ve got to be the one to decide what’s something that’s valid and what’s not.

I can imagine my little buzzing in my engineer brain is saying you’re recording video all the time and tossing it all the time. Isn’t that a bit of processor time and a bit of memory and a bit of disc space? I mean how are you doing that efficiently enough to always be running a ten-second video? Dmitry?

Dmitry: When it comes to space we are talking about one minute video, so it’s couple of megabytes. It shouldn’t be a concern. Obviously, CPU is being consumed, but we’ve spent a lot of time fine-tuning and optimizing our solution. We actually have some know-how in the area.

Lyle: That’s good.

Dmitry: We’ve achieved a solution that doesn’t visibly slow the UI. You would not know it. It’s not noticeable.

Lyle: Lots of times in bug reporting kinds of things you actually want to do a sample. You don’t want to do a full 100% of everybody’s crashes. You want to do a 2% of all issues. And in that way you’re not overloading yourself with errors. Do you guys support that?

Dmitry: For crashes, we have a solution. First of all, we detect similar crashes. We combine them into one report on our end. But we also don’t collect all of them. If you have a popular app and you have thousands or millions of similar crashes, we collect some amount; let’s say like 10 first ones. And then when the similar crash happens, we actually instruct the device, no need to send us that, we already have enough.

Lyle: Right.

Dmitry: As a developer, if you don’t think that it is enough and you need some more sample data, you can come to our web interface and just click a button. I need some more for this issue.

Lyle: Nice.

Dmitry: All right. So we will collect ten more.

Lyle: Even if you don’t get all the reporting like you were sampling of the actual reporting, do you still get a count of how many times that’s happening?

Dmitry: Yeah. Yeah. So we still gather all the statistics and we show you all the graphs, which devices it happens on, which build, and so on.

Lyle: Okay. I’m sold. It sounds really intriguing. I think I will throw this into my toy app. What’s your model for making revenue? Are you advertising base? Are you sharing the data? Are you just straight-up charging the developers?

Alex: Great question. First of all, thank you very much for considering using Bugsee. That’s first of all. Second, we’re not sharing data, and we’re not planning to share data. So just to be very clear about that. As for charging, we are right now in a free mode because let’s roll back. We started working on it in January of this year. We rolled out our beta at the end of April. So we’re talking about we are 4 months old.

Lyle: Wow.

Alex: We just started. Bugsee offering is entirely free right now while we’re figuring our shit out. And we plan to rollout our pricing in probably October timeframe. And we still experimenting with different charging models, but it’s going to be per usage of some kind.

Lyle: That makes sense. You’re wanna be in a situation where the price point makes sense for the developer.

Alex: Right. Right. We’re still experimenting. And we’re talking to our customers and asking them what makes sense to them, what would they pay. A lot of customers reply to us with phenomenally positive feedback. And that’s a beautiful opportunity to ask you what would you pay for that? And we collect all that information.

Lyle: You talked about the three different phases of development; the internal, the beta, which is pseudo-public, and then the total public. And you operate in all those situations. I can imagine that having this running all the time as developing would be extremely convenient. Because even though I’d probably always ignore it, because I’m rapidly developing, I’m crashing regularly, I’m debugging code, sometimes a situation can happen that afterwards I go: “wait a second, what actually happened there?” And to be able to have a video real quick of that moment would be very useful.

Alex: That is very correct. Obviously crash report includes the stack trace. And often enough it’s sufficient, but sometimes you don’t know why that pointer was null to begin with. You see it’s dividing by zero, but why you’re doing that, you don’t know. So that’s why the video and the network trace and all this information that led to the problem is sometimes crucial to understand what had happened.

Lyle: I can imagine the network log could be relatively large. Are you doing any kind of compression on that? Are you saving the entire session at network log or only the last couple minutes?

Dmitry: Currently, we are just setting a limit on that. So we just record packets that are no larger than 5KB and so on. And just xml, json or some other text.

Lyle: No images and things.

Dmitry: Yeah, no images.

Lyle: But if I launch the app with your system and run it for a day checking my email and then it crashed at the end of the day, in your log, we’re not going to see all that network traffic?

Dmitry: No, we are talking just about the last minute.

Lyle: Last minute or so. Okay. All right. And is that flexible on what the duration is?

Dmitry: Yes.

Lyle: Okay.

Dmitry: It’s fully configurable. You can make it larger or smaller.

Lyle: So since you’ve been rapidly developing so quickly in this, you’re just started in January, and your customers happen to be developers. Do you get a lot of feedback on what stuff people want? Is it driven partially by your user base giving you feedback?

Alex: Absolutely. We get a lot of feedback from our customers, by just saying thank you and it helped them to save a lot of time. Both on the QA side, as well as on the developer trying to debug the issue. But they also come and say we want this particular functionality or we ask them what would you like to see? And those conversations lead to a lot of good outcomes.

Lyle: So you’re definitely not in need of things to do, I would imagine. You’re extremely busy.

Alex: That’s for sure. And we still have a relatively small team. So it’s not easy.

Lyle: So how big is your team right now? Did you say seven people?

Alex: So we have two cofounders. We have one iOS guy, one android guy, one web guy, and two designers.

Lyle: And your web system is in beta and your iOS system is in beta, android is still being developed, yeah?

Alex: So iOS is fully deployed. We have many customers live in the app store. So I wouldn’t call it beta anymore. We’re just not charging for it yet. So we probably should at this point. Android is definitely in beta. We started it later, and it turned out to be slightly more difficult than we originally expected.

Lyle: What? Why is that? What kind of technical problems emerged?

Dmitry: So usually when you’re talking about Android people think that it’s an open system. Actually, it was much harder than iOS, because on iOS we could achieve a lot of things by instrumenting the stuff in real time using swizzling.

Lyle: Using what?

Dmitry: Swizzling.

Lyle: What’s that?

Dmitry: When you can replace a method of a class.

Lyle: Yes. That you can do an Objective-C.

Dmitry: Yeah. You can do it in Objective-C, you cannot do it in android.

Lyle: You can’t also do it in Swift, can’t you?

Dmitry: Swift is currently using Objective-C system classes. So we are okay for now. Until they rewrite the whole foundation.

Lyle: So from that perspective, because you can inject yourself in the language core, it’s relatively easy to do this in an Objective-C base system. And android not so much.

Dmitry: So tasks that took us few hours on iOS, sometimes we’ve spent weeks on Android.

Lyle: Oh, really. Interesting.

Dmitry: Yeah, like intercepting touches, for example.

Lyle: Yeah. I mean part of this is that you don’t want to be a pre-compile step that you kind of inject yourself in the app. You’re not interested in doing that, right?

Dmitry: We wanted to be a one-line integration. We don’t want to mess with your build system too much or make you go through hoops.

Lyle: Yeah. Because, of course, you could tackle it very differently if you did a build time — just routing all the methods and calls into yours.

Dmitry: Yeah. And maybe with android we could do that in the future when we could integrate easily as a plugin into the gradle system. But we haven’t looked at it yet. We’re planning to.

Lyle: Apple is slowly moving towards Swift. And as you know, their next WWDC they’re going to talk about more of their fundamental part of the UIKit, slowly shifting such that the core methodology is Swift implementations. And then you will have a problem with the way you’re doing it. Yeah?

Dmitry: I think that we’ll still have the solution for that. We haven’t looked at that phase yet. Currently we are working fine with Swift.

Lyle: Yeah, that’s important. Right. So with Apple and their sensitivity to anything that they’re not expecting you to do with the development, the whole app store review process there’s tons of stories when they release a new iOS version, that a developer has done something clever with an API, and they go oh, no, that wasn’t intentional. And they deny their app being deployed. How sensitive are you guys to that and how do you know that your pattern of what you’re planning on doing will fit nicely with Apple. Is that a risk that you have?

Dmitry: There is probably some risk, always. For now, we haven’t seen any problems with the way we do things.

Lyle: And the more customers you have using it effectively, the less likely Apple will have a problem with it, which is really interesting.

Dmitry: I hope so.

Lyle: You’ll get to a certain point where it’s a core feature that everybody wants, then you’re good.

Alex: Yep.

Lyle: Okay. So let’s talk about a competitor. I know that other companies are actually doing video recording, because when I was doing some research I noticed a list of them that are doing this. What differentiates you or is the space just large enough you’re not concerned about? From a business perspective what are your concerns or issues for that?

Alex: Well, obviously, we’re familiar with the space, and there’re other players in the space. So from what we know there are no player out there that delivers the quality of video that we do without slowing down the UI and passing app store certification. Basically, there are 3 ways to record video in iOS. One is using undocumented APIs, which will work, but you won’t be able to ship the app to the app store. That’s way number one. Number two would be to use the legitimate APIs, but they will slow down the app beyond usability. You won’t be able to ship the app or even use it in the beta. It just becomes unusable.

Lyle: Can I guess what the next one is? You pseudo-render all your content yourself in your own space.

Alex: No.

Lyle: Okay. What’s the third way?

Alex: And the third way is to use the documented APIs, but in a background thread as opposed to main thread, which will work, but will crash the app on occasion. Because UIKit is simply not thread safe. It’s just not designed to be thread safe. So it will work for a while, until you do something it doesn’t like, and it will eventually crash. So those are the three ways. And those are the three ways available on the market, and then we have —

Lyle: Your way.

Alex: — Dmitry’s way.

Lyle: The fourth say. Which you don’t have to talk about if you don’t want to.

Dmitry: We won’t.

Alex: We won’t. We worked really hard to develop a fourth way, which is basically doesn’t slow down the UI, passes Apple certification, uses only legitimate APIs, and totally, totally usable. And we have many customers in the app store using that.

Lyle: Oh, that’s fantastic. So you do have a bit of an edge, then, from your competitors.

Alex: That’s very correct.

Lyle: Okay. That’s cool. Because of Dmitry here.

Alex: That’s very correct.

Lyle: It’s good to have partners then, I guess.

Alex: Yeah.

Lyle: Okay. So it’s interesting because when I was taking my notes on what to ask you guys, I was going to talk about bug reports versus crash reports. But in a lot of ways you’re not really differentiating them. From my mind a bug report is actually initiated by a user. And a crash report is — or some other kind of logging port is done because of a detectable stace. But in your pattern, it looks like, in a lot of ways, there’s not a differentiation.

Alex: The only one difference in our case that you will have a stack trace in the crash case.

Lyle: Right.

Alex: And everything else is the same. You get the video and the logs and the network and all the traces and tons of other information. It’s identical. Actually, there is a third issue where it doesn’t crash, it’s not user reported, but rather in the code you decide that you’re not supposed to be there.

Lyle: I want to know about this.

Alex: Obviously, that cannot be done with one line of code. But then we have APIs to say I want detect that case and report me everything we normally report if you ever get to that condition. So we have that as well.

Lyle: And you also have a lighter touch where it doesn’t report everything just kind of lets you know?

Alex: No, that reports everything because it’s light enough.

Lyle: Okay. Let me ask you this then. I come along an app, we’ll use the beer example app, because I’m in the middle of doing this in my sideline. So I’ve taken a picture of the beer that I’m drinking to log that I actually had that beer. And there’s a weird typo in the interface. So I’m a beta program so I shake the phone or take a screen capture. What do you guys use as a trigger event?

Dmitry: We have both.

Lyle: Both. Okay. So shake the camera, or shake the device, and it tells me the bug report, and I say confirm, and I send it. Then within a minute now the app crashes. The second video, will the two videos that I get from that incident, the one the user reported and the crash one overlap each other?

Dmitry: No. The moment you clicked a submit button the first time, we start a new recording.

Lyle: Yeah. Okay. That makes sense, because why have duplicates. I’m just curious about your little subtle implementations. Was there anything else you guys wanted to talk about with your business? Did you have anything else you wanted to cover that we haven’t actually touched upon? Are you hiring right now?

Alex: No. We’re all set right now.

Lyle: But you are looking for developers? As customers.

Alex: As customers, yes. Obviously.

Lyle: And so you recently met Brian at a meetup about iOS development.

Alex: Brian Young.

Lyle: Yes, Brian Young, who is on the show regularly, and you guys started talking about coding and such. You were going to those meetups basically, to get customers.

Alex: That’s correct. Yes. There’s a lot of meetups here in Bay Area. We live in an amazing place here. I live in San Jose, so it’s very easy to just decide that one evening I’m free. And my wife is happy with me leaving the kids with her, so I just pop out and see where I can hang out with the potential crowd that could be potentially our customers. And just we have friendly conversations over coffee or beer, and that’s how I randomly ran into Brian. We had phenomenal chat and he then he said, you know what? I’ll introduce you to Lyle. And that’s how we got here.

Lyle: Can you talk about some of your sample customers you actually have or is that private?

Alex: Well, obviously it’s private. I cannot disclose our customer names, but what I can say that we have a wide variety of customers from small individual shops to huge companies, from private companies to large public companies.

Lyle: How about how many app starts you have or any kind of statistics to talk about the scale you’re currently running at? Nothing public yet?

Alex: Well, sure. You’ll be the one to disclose that. How about that?

Lyle: Okay. Sounds good.

Alex: So we’re talking September 2nd today? Right?

Lyle: Yes.

Alex: So and we rolled out in end of April. So we’re talking about 4.5 months, and we have 797 customers signed up with pushing about 1,000 developers, and about a quarter of them use it in past 30 days.

Lyle: Nice. So that feels good.

Alex: Yes.

Lyle: Yeah. Yeah. Your service integration, are you running on somebody else’s cloud infrastructure? Where are you running?

Dmitry: AWS.

Lyle: AWS, who else.

Alex: You should know.

Lyle: Everybody does. So you didn’t get sucked in with Microsoft trying to pitch you a good.

Dmitry: They did pitch us. We have some credit from Google as well, but yeah. We did AWS because with previous startup.

Lyle: Once you get good at it, why go anywhere else, really?

Dmitry: Yeah. We already had the preexisting setup so we just reuse our knowledge.

Lyle: Because you’ve done that, your ability to scale with multiple customers or a giant customer coming online with millions of launches a day, wouldn’t really be a problem. You’d have to figure out the revenue at that point.

Alex: Yes.

Lyle: Probably.

Alex: Yes. It’s a tricky one, though.

Lyle: Yeah. So are you going to go for another round of funding or are you going to go public or are you just, at this point, looking to become stable financially through revenue when you set it? What’s your plan?

Alex: Our immediate goal is to figure out revenue so it will basically, allow us to grow. And then we’ll see. We’ll see. It’s going to be very interesting how that turns out. That’s an experiment we haven’t ran yet. There’re a few ideas that we have how we’re going to run that experiment. And then once we do it, we’ll figure out what’s going to be the next step.

Lyle: Are you seeing a difference in your last company versus this one? Because you guys just did this, and closed it. At this timeframe from the menu company, six months out, how different are they?

Alex: Oh, it’s a very, very different. We have something to compare it to. So we see our customers signing up. We see customers signing up because their friends told them because they use Bugsee and they want them to use it as well. Obviously, it’s free, so that makes it even easier at this point.

Lyle: It’s a little easier to say yes. Right.

Alex: Right, right, right, right.

Lyle: That’s for sure.

Alex: So I’ll be honest about that. And then we’ve been live, as I said, for 4.5 months, and we have a lot of customers with big names trying to use us right now.

Lyle: That’s great.

Alex: That’s very, very impressive. So we were nowhere near in the same position in the previous company. And we had to invest way more into sales and marketing. While here we do invest a bit in marketing, but generally speaking it’s all coming out from organic.

Lyle: What percentage of marketing spend versus salary and AWS cost? Like general cost versus marketing cost; what kind of percentage are we talking about?

Alex: I’m running marketing, and I’m not a marketeer in any shape or form. So I do an occasional experiment here and there with the sponsor starting in newsletters or podcasts and see how that works out. So we still experiment with that. I don’t have necessarily a strict answer.

Lyle: Okay. Cool. Fantastic. Thank you so much for speaking with me. It’s been really fun. I look forward to loading this into my toy app and trying it out and seeing what it’s like. And if I like it, I’ll definitely spread the word here at Netflix, too.

Alex: Thank you for having us, Lyle.

Lyle: Certainly.

Dmitry: Thank you.

Lyle: Alex, Dmitry, thank you both very much.

Alex: Thank you.

Lyle: Oh, and of course, it’s Bugsee dot —

Alex: Com.

Lyle: Com. Wow, that’s pretty good. Do you spend some money on that?

Alex: Yes, we did.

Lyle: It’s also Bugsee, B-U-G-S-E-E.

Alex: As in see the bug.

Lyle: See your bug.

Alex: Right, right. That’s the whole concept, right. Well, it’s all work of our multifaceted Dmitry Fink as well as the logo, which is the anteater, which supposedly eats bugs. Also a conceived and drawn by our Dmitry.

Lyle: Dmitry.

Alex: Yes. Yes. Yes. I’m useless.

Lyle: I bet he doesn’t feel that way.

Dmitry: I don’t. I don’t. He does the talking, and he’s running the business pretty much all the other aspects.

Lyle: Right. You just make sure everything works.

Dmitry: Yeah. I just do the technical stuff.

Lyle: Yeah. Great. Well, Bugsee.com to learn more about it. And if you’re a developer for iOS, web or — can you sign up for the Android beta program right now?

Alex: Yes. We don’t advertise it, but if you sign up it’s available there and it says it’s in beta.

Lyle: Cool. Great. So give it a shot if you’re a developer, and thank you both for being here on GeekSpeak.

Alex: Thanks for having us.

Dmitry: Thank you, again.