Arisa Amano is the co-founder and CEO of Internal, an internal tools platform that allows anyone to create without code, reducing dependence on engineering and enabling businesses to do more with less. Previously, Arisa was the Chief Product Officer and co-founder at Harbor, a cryptocurrency firm, and the VP of Product at Zenefits, a healthcare startup. Prior to that, she held product and marketing leadership roles at Yammer, Microsoft, VMware and MTV Networks.

Bob Remeika is the co-founder and CTO of Internal, a no-code internal tools platform. As an engineering leader with over 20+ years of experience, he’s seen firsthand the difficulties in prioritizing and resourcing internal tools projects, which spurred him to co-found a company to address the issue. Previously, Bob was the co-founder and CTO at Harbor, a cryptocurrency firm, and the VP of Engineering at Zenefits, a healthcare startup. Prior to that, he held various architect and engineering roles at Yammer, Grockit, Razorfish and Yahoo.

In this episode, Ben, Bob and Arisa discuss...

• Why Internal helps solve a crucial problem that Bob and Arisa saw during their time at Zenefits.
• Why team tools don't typically get as much love, and how Internal can help.
• How no-code lends itself to help you understand more technical aspects of work.

Arisa & Bob - Internal - Spotlight Podcast

Tue, 9/1 10:47AM • 35:39

SUMMARY KEYWORDS

internal, tools, engineers, code, build, people, company, platform, engineering, customers, data, product, console, api, database, cases, non technical, engineering team, requested, bit

SPEAKERS

Bob, Arisa, Ben Tossell

Ben Tossell  00:00

Hey everybody, it's Ben here, founder of make fat, a platform teaching individuals and companies how to build custom software workflows and tools without writing code. This show explores the people behind the no code tools and the stories of folks using them to automate work and launch companies. here today with me, I have the founders of internal Welcome to the show. Thank you. Thank you.

Arisa  00:25

Anyway, give give a brief introduction about who you are and what internal is. Sure. So I'm a Risa. I am the co co founder of internal

Bob  00:39

Hi, again, I'm Barbara Mika CTO, co founder of internal and what internal is it's a no code, internal tools platform. We are designed for anybody in our company to be able to build tools whether or not you know SQL or code.

00:57

Awesome.

00:58

Yeah. And

Ben Tossell  01:00

yeah, go ahead. Okay. Um, yeah. So on on the on the page you mentioned, like the third word is engineers. So do you do class it as a no code tool for engineers? Is it more broad than that to try and like, target engineers first? What's, what's the back on there?

Arisa  01:20

We actually are designed so that you don't have to be an engineer. Our users range, we actually have a bunch of engineering teams, using internal as well. But actually, you don't. We have people that are in product management or operations, or just founders that aren't actually engineers and know how to code and they also use internal as well.

Ben Tossell  01:42

Awesome. So what's the what's the backstory of internal where did it come from? How long has it been around? Was it something else before it became internal?

Bob  01:52

Um, well, I mean, so internal and I heard recently I have been working at several companies together. There's actually a fourth company together. And yeah, one time ago, we started working at Yammer. And we, we sort of realized that every single company, we had built an internal tool. And they were always terrible. And so we started thinking about ways that the reasons why they're terrible, and ways that they couldn't be better. And so that was really the genesis of it. And more recently, a reason I started a company called harbor where we had built an admin console. And we realize we basically built the same thing that we built at every other company. And so there was definitely a pattern. And so we just started thinking about, you know, what would be a way for us to do this so that we never had to build a build a console game, because the issue was that we were always struggling with prioritizing engineering resources on our core product versus the internal tools. I mean, never really wanted to work on internal tools, we always want to work on a core product.

Ben Tossell  03:06

It's so Gee, do you use until two bit to run internal that is up to the same?

Arisa  03:14

Absolutely, yes. And what's been awesome is that, you know, I actually don't have an engineering background. And this is one of one of the reasons why we care so much about internals, because you know, as a product leader, we're always dependent, at least in the past on engineering and figuring out how to stuff engineering so that we can build these internal tools. But now, at our company, because we use internal, I'm building all the tools, and it's been awesome. I don't have to, you know, bother our engineers and pull them off of something else every time I need something. And that's been really a game changer for us.

Ben Tossell  03:52

Yeah, I think that's one of the main things. One of the main benefits I see have no code of previous looking at previous companies saying Oh, I think at product time we had, there's a day every, every Friday for like any bug fixes or any, like requests for the developers so that you weren't, like annoying them in the week, right? And you'd always think we'd make friends with one or two of them just say, could you just like build this?

Arisa  04:19

thing? I mean, you You're always as a non engineer, you need these internal tools, right? And you're trying to figure out how to get engineers to squeeze it in. Because otherwise it's just not going to get that.

Bob  04:31

It's tough on engineering, too, because engineering didn't want to not help you. Yeah, I mean, engineers want to help. At least the ones I've been around, there's some dodgy dodgy engineers out there for sure. But, but generally, you know, people want to help and just slam you know, everybody's slammed. So what you're talking about is exactly the process. You know, it's, it's up to a non technical person, it might seem like you're just adding a form field or, you know, changing something really simple and it probably is. But the problem is that the engineering team and if you're if you're at a tech company, and you're doing it right, you're probably always blocked on engineering, right? It's just they don't have time to prioritize your chain, because every single thing requires some sort of code change code review, you know, deployment process, there's usually testing involved. And you know, it's actually a lot of work for somebody small changes, especially if you're gonna do something that's well thought through. So the problem with a lot of these tools is that they look terrible, because you don't typically have the same support that you would have on your customer facing product. Usually, on your customer facing product, you have something like, you have a designer, you have a product manager, you have an engineer, and maybe you have a team of engineers and we have a team of these people and bigger the project. internal tools just never get that love so so these things that are you know, really Small, they just become these breaking sign applications over time. And they're really hard to use broken. And it's typical, this process is very typical. So, you know, doing something that should be easy should be easy. And that's kind of one of the problems internal solves.

Ben Tossell  06:18

Yeah, I think, like you said, was for a non technical person to say, Oh, can you just have this form field? It's not just building that form field that you said, there's everything that is connected to every process that it's connected to? And yeah, I've seen, like admin tools that just very bare bones compared to what the front is. And yeah, I mean, no one's gonna prioritize that when the developer resources so like, needed on the important things on the front, I suppose.

06:50

A customer of ours I'm not gonna name names, but describe their admin console. As you know, MS DOS, it's just MS DOS, you know, it's that bad. They're all like that, though it's very common. So

Ben Tossell  07:03

which, so with a company who's already got, like this shitty looking admin panel come to internal and be able to just, like transfer stuff over? Or is it more of a, you got to start with internal or you just like transition over time? what's the what's the usual process that you've seen with customers,

Arisa  07:24

you start with internal, however, we make it really easy. So and depending on the customer, you know, they will hook up their database, they may hook up their business applications, they may want to hook up to their existing companies API's. But let's just take the database example. As soon as you hook up internal to your database, a bunch of different tables and queries are just generated for you. So you don't have to write any SQL. And all you have to do is dragon components, let's say, a table component and choose your data and you're done. And actually, beyond that internal actually spins up a bunch of these views for you as soon as you hook up to. So technically you could be up and running and viewing all your data in your database in a matter of minutes.

Ben Tossell  08:14

Okay, yeah, so that makes sense. So it's not necessarily like, Oh, you got to rebuild all your stuff from scratch. But in internal, it's more like, component based building and making it really quick. Yeah. What, um, what are some of the things that people have built? I mean, can people build stuff in internal and then you like, have those as reusable components for other teams? Is that how some of these things have come up that like, templates and things like that?

08:41

Yeah, I mean, customer says, you know, it's really a range, you know, I'm internals, a platform so you can kind of build anything. Now, the thing is, there are some internal tools that are pretty common. We've seen customers use it as sort of like a data entry type thing where you're mapping data from one system to another. We've seen people use it as, you know, something that edits users for user management. So things that we use internally for ourselves, we built a mini CRM that hooks up with Salesforce. And we kind of manage our lead process that way. And so the thing is, it's a flexible platform. So you can really build whatever you want. Part of one of the hard parts about internal is sometimes getting people to understand what they can do. And so I think it's good to be able to, you know, sort of give people sample application so you can show them what they can build. But the reality is they can really build anything that interacts with their data. That's kind of how we started.

Ben Tossell  09:42

Yeah, I think that's, that's sorry, that's, that's a very common thing and no code in general, that people don't know what they don't know. So, everyone I speak to you've got to solve say, you mentioned a few different things to just get their brain working and thinking Oh, wait, yeah, I could do that myself. But for slightly different thing. So people mentioned things like CRM, sales, marketing, stuff like that. A few

Arisa  10:06

other examples, you know, onboarding tools, that that's a common use case, if you're onboarding a customer, and you need to be able to, you know, update their information in the backend in order to get them going. That's a common use case. Another interesting use cases like data cleansing and data mapping. So if you have, you know, data and multiple different databases even, and you need to kind of bring them together and make connections between the two. That's another interesting use case, wherever, where you are manipulating data. So there's a lot of different types of use cases.

Ben Tossell  10:44

Yeah. Awesome. Yeah, I just think of just there's just so many things. I think most of these tools, do offer. I mean, do like lots of things. How did you find because people always say when you're doing a company to focus on the one thing is just, I suppose there's so many use cases here is just the one thing, having people build internal tools is that like, the one thing but internal tools is very broad, I suppose, isn't it?

11:15

It is Brian.

11:17

But

11:19

you got it.

11:20

Alright. So the I mean that you're right. It's, it's, you know, the there's like kind of two ways you can go about building a company is you can focus on that sort of like that initial use case in that wedge and then you can also go broad and, you know, I think for a platform you actually have to go for on now, there is something to be said for having that starting point. Right. So, you know, what is your your niche So, you know, is it maybe building a sort of like a switch management tool or something like that for your, your system? That's certainly possible with internal um, Generally, though, we are a platform so you can build whatever you want.

Arisa  12:05

And the reason why we're tackling this is because Bob and I have felt this pain and have experienced this pain over and over and over again at so many companies. And so we want to figure out a way to solve this problem where internal tools are always just on your engineering team. And it's always blocked in engineering and non technical teams can't do anything about it. And so that's why we're going with this platform approach.

12:32

Yeah, I mean, just a little bit of backstory on this too. You know, I mean, I recently I both worked at a company called zenefits. And, you know, that's where we saw the need for internal tooling, because zenefits grew so quickly, you know, grew from like, I think I was employee 400 or something like that to 1800 and like, you know, I don't know, two days or something like that. So, um, so anyway, we had a we had an Internal tool we call the console. And, and, you know, it just didn't scale as fast as a company did. And, you know, it was it was a constant tug of war between whether or not we could allocate resources on internal tools because we had a really large operations team versus build our core product. And they were always at odds with each other. And unfortunately, the internal tools always suffered. At one point, we had to really address the problem. And because the tool was just falling over, so we reallocated a ton of resources. I think at our height zenefits had an engineering team of like 200 plus engineers, and we took like, let's call it at least 10% of those engineers and allocated them towards internal tools. What could those engineers have been building in the meantime? You know, what kind of forward looking opportunities could we have attacked in the meantime, you know, Because the cost of not the cost of building the internal tool probably cost us exponentially in actual growth and company opportunities. So that was sort of like one of the big aha moments, I'd say the other aha moment was with, you know, harbor and we just realized we had to build this, this deep console so that we could have, you know, remain compliant Harbor was a financial services company that interoperate with the blockchain. So we had this big compliance team that had to go in and review documents all the time and sort of make updates and we actually had to work with outside contractors, but we never wanted to get data access to these contractors to our internal console. So we had all these issues with building our own console. And, and honestly, I didn't think it was all that unique. You know, the console that we built in house was sort of like allowed you to sort of navigate through your database, we had some custom tools, and we had some the ability for people to go in and sort of manage their tasks. And, and that's kind of where we saw this pattern. We also had this need to allow people externally to see our data. But of course, we didn't want them to see all the data. And so that was really hard. And we had to jump through a lot of hoops to get that done. And so we took all this experience that we had, from, you know, I think, I've been in this industry, you know, technology 20 plus years at this point, and resubmit it for a really long time as well. Um, I, we just kind of put our heads together and brainstorm what would a really good console look like? What does it actually have to do? And how can we put some controls in place so that, you know, you didn't have this problem with you know, everybody having access to all the data All at once.

Ben Tossell  16:02

Yeah. Well, it seems like it's quite an easy picture to paint for a company to say. I mean, I even said it earlier saying, Oh, well go developer, just like you've squeezed this project in this week to help me do x. That must be like, Do you find that it's quite easy to split here, I suppose sell it to a company and just say like, have you ever been in this situation? Every company says yes. And they say, well, isn't gentle.

Arisa  16:31

I mean, every company has experienced this issue. If they're an existing or larger team, if they are a startup, they just feel this pain all the time because they're just trying to get their product out. And they're customer facing product out. They don't want to spend any engineering resources on any internal tools. And that's something you know, I work at our company, so we use internal and you know, one of the things that, you know, is a big challenge for us all the time is a company is prioritizing, and you know, getting as much moving as fast as possible and getting as many features out to our customers as possible. And if we had to also squeeze in all the internal tools that, you know, I needed and our you know, business side needs, that would definitely take up a lot more of the engineering resourcing.

Ben Tossell  17:22

Be finding that as you're onboarding more customers, and using internal, internally, that you're seeing ways to add things yourself and think, oh, that would be like, I wish this was added in our internal tool, but let's add this as a feature or add this as a component. You sort of dogfooding in a very big way, I suppose.

Arisa  17:44

Yeah, absolutely. I mean, that's, that's one of the great benefits of dogfooding is, you know, when you're using our own product, and you're you're one of the customers, you're always finding things, Oh, I wish I this this happened or like I wish that this you know, feature did this right and then Add that to the roadmap. roadmap is massive.

Ben Tossell  18:04

What are some of the most recent features and things that customers have requested? And you've, you've shipped?

Arisa  18:17

The one of the most recent ones that we shipped, I would say is the being able to filter the data that is in your application based off of the logged in user. That's something that we've we've been requested, or that's been requested a lot. So what that means is, okay, you have an app, and you know, Bob, the engineer logs in and looks at the app. What is it? What does he see versus like me, the product manager, what do I see in the in the app, and you'll be able to actually control that and this, the use case is actually more relevant to let's say, like sales teams or account managers. So Usually you have like, accounts for or a customer's assigned to you, right? And so if you log into an app, you can just see the list of customers that you're assigned to so that you don't have to see the full list.

Ben Tossell  19:11

Yeah. Can you? Have you seen anyone using this from all fronts facing apps? Like thinking of that example, you could you have, like membership members seeing certain types of data and then everyone else not seeing like specific levels of that or, or similar.

Arisa  19:36

We do get a lot of requests actually, to use internal more as a customer facing app or partner facing app. That is something that you could do, but it's not something that we have optimized or focused on so far. Yeah, we're like pretty focused on the internal tools use case and making sure that that is successful. You

Ben Tossell  20:00

Yeah, I mean, yeah, talking about it and seeing seeing the products and stuff makes me Just think, especially for building something with no code. And actually, this could solve so much of the, like, logged in dashboard side of things where no code doesn't really solve that for for a lot of people right now. Right? The obviously, is this one thing at a time, I guess,

Arisa  20:24

one thing at a time?

Ben Tossell  20:26

And did you purposely choose this, like, no code route? Was it were you doing? Do you call yourself no code? Or do you just happen to call yourself no good.

Arisa  20:39

We, our mentality is no code first. And that's really important to us. So you know, background again, like we feel that, you know, the core problem with internal tools is that it's always on engineering. And nobody else can actually build or maintain your internal tools. And that's the problem that we're trying to solve. So We want to make sure that the platform is something where a non technical person who doesn't know code maybe doesn't even know SQL can come in and actually build or fix tools or do what they need to do. With that said, and I'm sure Bob can chime in more about this, but companies engineering teams, need robust capabilities need to be able to hook into their existing API's, for example, on their existing business logic. And so we of course, support that aspect too. So we like to think of ourselves as no code first, but with all the capabilities of other more other powerful platforms.

21:42

It The other thing I think I just add to that is it there is like this no code movement, and we started before that, you know, though the whole thing. But But core to our value prop has always been offloading the work of engineering onto teams that can Do the work, they can basically maintain their applications themselves that has been from day one, where we saw value, right? So like, It is one thing to help accelerate engineers to do their job faster, they have one thing. But I think that doesn't really solve the whole problem. The whole problem is that you need to be able to remove engineering from that process. You have to remove engineering completely, and we'd be naive to think that you could, right because at the end of the day, you still have you know, API's gotta hook up you've still got you know, database and so many things are technical and you just unavoidable you have dropping the code. When you have to do that with internal you can but it's not what we lead with. Like I said, it's it's what we're what we present to somebody is not like an ID, but we present to somebody it's something that's friendly and approachable and helps you feel like you're not going to mess things up. That's kind of like the approach that we've always had from the beginning. And it's great that there's no code thing is happening, because I see that the tools are getting better across the board, you know, and people are having more options. And at the end of the day, that's going to translate to, I can just do my job as an educator, which I always feel like, people come to some sort of company, they want to work on a core product, they don't want to build internal tools, you usually get back to the intern or something like that, you know, so. So that's where we see the value. Do you think it's been

Ben Tossell  23:35

a slower adoption from engineers in this whole no code movement? You think? I mean, I've seen some sides of it, where it's like, people think you got to take sides, or it's one or the other. But I think something like internal and even, there's plenty of tools out there that aren't no code. There may be no code first, even by by accident. They just happen to not have to use code. can eventually. So there's a lot of like gray area here as well, I think that that's, I think good for this whole movement in general. But I wonder if you've seen engineers be a bit more standoffish with with no code.

24:17

I mean, I probably say like 10 years ago, I would have been like that, you know, um, I think that the, there there is a healthy skepticism from engineering because as an engineer, you kind of understand how these things are all put together. And you you, you know, you kind of think like, well, how could one, you know, GUI wiziwig type tool accommodate all these edge cases? And I think that skepticism is is right. I think the thing is, though, is that you don't need to handle those. Something you don't need to hell those but those patterns are established so when something is easy to build, and kind of Well known, you shouldn't need to need a programming language to build that you shouldn't need an engineer to build that. Those are the cases that we handle really well in our platform. But of course, of course, there's going to be times where you drop into code and chorus is going to be times when you need customize, you need to go a little bit further than what a tool can reasonably support. And that's a big part of internal as well. And we have, you know, these pieces of the product where you can drop into code, but we don't we with that, and that's, and that's kind of the point.

Ben Tossell  25:37

Yeah, I think a lot of I see that happening a lot where people are using the product, and maybe pushing the limits or like just getting really advanced and relying on it a lot. And then seeing all these smaller things. It's like just need a little bit more but then because they're so used to how the product works, they actually can understand or recognize that's the database there or that's the end API like I can. I now can almost touch and do stuff with API's that I would never have known before using something like Zapier, for example. So, right, it's, it's sort of the no code pushes you into, okay, here's the basics that you, like can recognize with drag and drop and clicking things around. And then, yeah, when you get into that more advanced level, you can dip your toe in a bit and then maybe mess up a few few times before it gets right. But

26:30

now, I think it's good. I think, I think one of the things that engineers tend to underestimate is just really simple things like syntax syntax for people that don't write code on a, you know, daily basis is actually really hard. And, and it's not that the thinking about the problem is I mean, thinking about the problem is hard. I think sometimes you have to have like a technical mind, but there's just a barriers to entry along the way syntax compiling Building, deploying, you know, all these things that people, your engineers, I think kind of take for granted, because it's just baked into their daily workflow. But these are all things that that people that aren't programmers would need to learn if they wanted to build tools with code. And so what we've done is we've just taken all of that away, basically, for somebody that doesn't isn't a programmer on a daily basis, maybe they're technical, maybe they are a spreadsheet wizard or something like that. For people on that internals, a great platform, because you don't have to worry about all this barrier to entry stuff. You can just come in and start working. And everything just kind of works, how you would expect. I'm now on the engineering side. You know, I think engineers are skeptical, but what I'm seeing is engineer starting to come around. You know, I think engineers themselves are realizing, oh my gosh, it's so great that I don't actually have to worry about that. It's no stupid admin console anymore that I hate working on, because it's slow and it looks like crap, you know. And I can just rely on this platform. It lets me get in where I need to, but it takes away all the things I hate doing. Building UI thinking it through, you know, hooking, you know, writing

28:24

Glue Code,

28:27

you understand, trying to write, write code that understands the relationship of your database. And it's just, it's just boilerplate. I mean, it really is, it's just let's get rid of the boilerplate, but give you the areas that you really need to focus on as an engineer, which is like, Okay, I'm going to I'm going to define an input. And that's going to hook up into my API here, and I'm out. And that's all I do. That's the way we use internal internally. So you know, Risa, what I tend to do is we have an API or something that you know, maybe modifies you To record. And so I'll just configure that. And then from that point on, I'm out of it. The Risa is building the tool herself. And so that's kind of how internal works. It's really based on how you I think, these, these applications should be built. You shouldn't be blocked on engineering for adding something like a form field. This is ridiculous.

Ben Tossell  29:23

Yeah, no, exactly. Yes. I mean, that's the point that we try and make a lot of time is sorry, everyone wants to just get rid of the repetitive stuff, or stuff that you have to like, redo every time in the same way. That's not the interesting pieces. It's like let's get to the more interesting things faster. That way. What, what do you think you'd both be doing or working on what what would be a different company if internally existed today, and you too, had to do something. It seems like you've done with quite a Few things already. So

30:03

what's on the list? Would it

30:09

be like mining cryptocurrency?

30:14

So what was the question? What were we doing?

Bob  30:17

Well we be doing if internal RNA existed, so we wouldn't have to build internal tools anymore.

30:24

Oh, um, I mean, personally, I probably would have been a lot more productive.

30:31

I bet that you know, I mean, I think

30:36

Yeah, I, I never liked working on consoles. It's just kind of ironic. That is my full time job now. Um, but you know, I think that the approach is a little bit different because we're trying to build a console. So you don't ever have to build a console before and that feels like somewhat of a normal quest. But the whole thing would I be doing if I I don't know. I just have a lot more time. I probably My kids more

31:02

sure about uresa

Arisa  31:05

i don't know i mean there's so much to build with internal that it's just I haven't really thought about that. I have to get back to it

Ben Tossell  31:15

Yeah, I guess feeling like building something like internal then probably makes you feel like you can you're building smaller tools within internal all the time right so it's a scratch in that building edge probably over and over and over every week.

Arisa  31:31

Yeah, I'm tweaking or building new tools all the time. Yeah.

Ben Tossell  31:37

Awesome. What do you guys both think of where no code is going and where internal also might be going with like with the rise of this whole no growth movement?

Arisa  31:51

I think it's it's so I think it's still so early. That I don't exactly know where we're no code is is going you know, it's very clear that there are an increasing number of, you know, platforms that are popping up that really give non technical teams more and more power to do a lot of things. So we don't know. But when it comes to no code for internal tools, obviously we we believe that that is something that, you know, in the coming years, more and more companies are just not going to choose to build their internal tools. They are going to pass on that responsibility mostly to their non technical teams and fully embrace it.

Ben Tossell  32:38

What do you think the barrier is today with getting the non technical team to like, start taking this on as something that they they can do themselves? Because a lot of it seems to be education of you can do this.

32:53

Yeah, that's fine.

Arisa  32:54

Yeah, it's just Yeah. I think a lot of times because in the past internal tools It's always been something that, you know, engineering, it's on the engineering side and during builds internal tools. The non technical teams think that they have no ability to build these things. And so it's really about educating them to say, hey, actually, there are platforms out there that will allow you to build these internal tools yourself and maintain it. So it's, it's really an educational thing.

Ben Tossell  33:28

Yeah, I agree. Anything else you have thoughts on in the no code space? Otherwise, we can wrap it up there.

33:37

Have you got anything?

33:39

Um,

33:41

I mean, I guess what I would say is, I encourage people to take a look. You know, maybe you were, maybe you're not an engineer. Maybe you're semi technical or technical but not an engineer. You looked at some of these tools and you went on Don't get it, or, like, the the tool is, it looks like it's for programmers and I don't understand. And I think I would encourage people to take another look at this stuff, because it's getting better all the time. And our platform is, in particular is it's always improving. So, you know, I would just encourage people to, to, maybe if you've looked at it and been intimidated, don't be intimidated. You know, and then also, in for internal in particular, we're always happy to talk to people and sort of walk them through and get them comfortable with, with the tool. And so the support is really there. You know, I think it's great actually, that people are starting to pick up these, these no code tools and and I think, you know, it's just better for for everything. So take a look at it. I would say check out internal for sure. And and we're happy to talk to you and walk you through it.

Ben Tossell  35:06

Awesome. Well, I really appreciate you both coming on when you let the folks know where they can find you and internal.

Arisa  35:15

Just go to internal.io and you'll find us.

Ben Tossell  35:19

Awesome. Well, thanks so much for coming on.

35:21

Thank you. Thank you. Right. Thanks, man.

Ben Tossell  35:24

Thanks so much for listening. You can find us online at maker pad.co or on Twitter at make that we'd love to hear if you enjoyed this episode, and what we should do next.