Learn more about Andreas Møller

Twitter: https://twitter.com/cullophid 

Linkedin: https://www.linkedin.com/in/andreas-m%C3%B8ller-bbb1a14/ 

YouTube: https://www.youtube.com/@toddledev 

Website: https://toddle.dev/ 

Chapters

00:29 - Introduction to Andreas and Toddle: An Overview of the No-Code Front-End Development Tool​​.

10:05 - The Inception of Toddle: From Idea to Founding a Company​​.

20:37 - Team Collaboration and Technical Challenges in No-Code Tools​​.

26:51 - Building for Speed: The Efficiency of Toddle in Software Development​​.

10:41 - Transitioning Careers and Prioritizing Features in Toddle's Development​​.

26:39 - Maintaining Product Velocity: Strategies for Rapid and Effective Feature Deployment​​.

‍

Transcript

Mike Mahlkow (00:29)

Hey everyone, welcome to the Happy Building podcast. Today we have Andreas from Toddle, a no-code front-end development tool. Andreas, how are you doing?

‍

Andreas Møller (00:40)

I am doing great. Thank you very much for having me. I've looked forward to this for quite some time now.

‍

Mike Mahlkow (00:47)

Great, yeah, it's a pleasure to have you and maybe to jump in. How would you describe Toddle, the company and product you're building, to someone who has never heard of it before?

‍

Andreas Møller (01:00)

So, Toddle is a platform for building web applications, and specifically the front end of web applications. So that's the part that runs in the browser, on the user's end. And it's built for creating very complex application, or at least potentially very complex application, without the need to write any code. And I think there's quite a lot of no-code tools out there. Toddle is sort of aimed at the more professional end of...

‍

of the spectrum. So our whole deal is that if you build an application in Toddle, you'll be able to stay with Toddle as your company and your product scales.

‍

Mike Mahlkow (01:39)

Nice. I like that. Like scalability is something that I think is very important and becomes increasingly important for people in the space. So what has led you to build Toddle and you just mentioned it, right? There's like lots of no code solutions out there. So if someone who doesn't know the space well looks at the market, they might think, well, it's well saturated. There's already so many solutions, but apparently you had a very different opinion.

‍

Andreas Møller (02:05)

Yeah, absolutely. And I think that's a fair point. There's a lot of no code tools out there. And I think from a distance, it might be hard to see what sets them apart. But my backstory was sort of I came from a very traditional development background as a programmer for like two decades. And I sort of over time rebuilding

‍

sometimes a lot of the same applications over and over again for different companies. I sort of started to get this feeling that we were spending a lot of time on stuff that wasn't really moving the product forward. And there was a certain bit, especially working with designers, I got a little bit of that sort of jealousy feeling of like a designer would go and build an interface in Figma and then...

‍

essentially come back to you and say, right, now that I've done this, can you go and redo the exact same thing, but in code, right? And I think especially for building UI, I think that's quite glaring that it's quite clear that surely the best way of building something visual is not with code. So, and at the same time, Webflow was out there showing the whole world that you absolutely don't need code to build HTML and CSS kind of applications, right?

‍

So the only bit that wasn't really clear is that can you also do the actual logic part, the data fetching, everything and data processing, can you also do that without code? And so that became a little bit of an obsession, something I started exploring. And I think I, that's almost five years ago now. And it was just me in my spare time.

‍

sort of trying to bash my head against the wall, figuring out how to crack this. Because there's a lot of bits, you know, if you need to handle every case, but you don't want like a million different ways of doing the same thing. So trying to figure out what's the right model that's powerful enough, but also simple enough is quite a difficult problem. And it took me a long time to come up with something I was happy with. And I think that one of the driving force against saying like,

‍

Andreas Møller (04:23)

You can see other tools that solve part of the problem. But also at the same time, I was working at a company that did a lot of 3D work, the 3D modeling, and they're sort of looking at game engines like Unity and et cetera, and seeing that actually somehow in 3D land, people can use NoCode tools a lot more. And apparently that works. But if we bring it down a dimension into 2D where the web is,

‍

somehow we don't have this kind of tools and that made no sense in my head. Right so it's like there's got to be at least we've got to be able to push it a bit further than what we're doing now.

‍

Mike Mahlkow (05:03)

I actually love the 3D to 2D comparison because one of my favorite hobbies is playing video games. And every now and then, in my spare time, I've just dabbled with building my own stuff. And I've thought about it in passing a couple of times how much easier it is to build a video game without coding than an actual web app. But I haven't really thought about it as deeply as you just said.

‍

Um, so I really liked that comparison. And so basically you said you had been obsessed with it for a while, right? And you tried out different ways of like potentially solving the issues that you saw. So lead me through the early days of actually founding Toddle, like it, because at some point it came from, it developed from an obsession and something that you tried on the side into an actual full time company that you're building.

‍

Andreas Møller (05:57)

Yeah, so I sort of got to a point where I realized that, okay, this could do something. And I could start building applications from this and it would be quite fast and easy to do. And also they seem to work really well and they perform quite well. But actually sort of the next step was to me to sort of realize, okay, am I gonna make this step? Am I gonna make this jump and trying to make it into a company?

‍

I had a startup before, I absolutely loved it. I knew I wanted to do it again, but I wasn't quite sure if this was the right product and this was the right, and I was at the right space. And so I needed a large application that I could build in Toddle to validate mostly just to myself, like also eventually to other people, mostly to myself that I haven't overlooked something really important that...

‍

Oh, actually, once you get a little bit down the line, you're gonna run into some issues you can't solve, right? So I needed something really big and complex. And the obvious choice here really was to build Toddle itself in Toddle. Because, and there was essentially two reasons for that. First of all, there's a long history of people writing program languages, eventually writing their own, either like compilers or interpreters in the language itself, like.

‍

Um, that's sort of a, a fairly well-established practice as a way of validating that the language works, right? Um, but the other bit, of course, I needed something, something fairly large. And the third part was I was building version one in react. And when you have like, when you begin to get into having the thousands of elements on the page at the same time, and the sort of couple of hundred components and an editor like this, like, like Toddle is a very complex application, right?

‍

So once you get into that space, you end up having to do a lot of work to keep React performant. And because Toddle is based on a different programming model, it's actually easier to keep that kind of application performing in Toddle than it is building in React. So there's a lot of good reasons to switch, and I sort of started rebuilding it. And once I sort of got back to saying, okay, now I'm kind of back to where I was in the code version, I sort of be like, okay, now at least

‍

Andreas Møller (08:17)

I've proven to myself that this is the tool, which was kind of the hardest person to convince, to be honest, so far. I've proven to myself that this works. And I mean, from now on, there's still a million problems to solve, but all the really hard ones I have an idea of how to solve. And from that, I kind of knew, okay, this needs to end up me in me starting a company. And almost at the exact same time, the company I currently worked for then got acquired.

‍

and merged with another big company. And that for me was sort of like, okay, now's the time, right? If the company you're working for get bought up, I felt like that was the perfect time to go out and try that. And I ended up getting a very nice deal with my former boss that I could actually stay on payroll for a little while after I finished and start working on Toddle.

‍

So the opportunities were all there. There was absolutely no excuses left. So I had to get started.

‍

Mike Mahlkow (09:23)

Interesting. So basically you removed your own doubts first, and then there was just like this massive external opportunity because like things change in your actual career And then you just couldn't justify it anymore to yourself to not at least like give it a shot and now we're here That makes sense

‍

Andreas Møller (09:38)

Yeah. And I met my co-founder, he's actually an old friend, but we hadn't really talked for a while and I kind of ran into him again. And he's a designer, which kind of works out really well in complementing each other. And he was in a similar situation where his current job was coming to an end and he needed something else. He was not so happy there.

‍

everything kind of commented and aligned at the right time. So it was very clear that, okay, we're doing this. Let's go out and see if we can raise some money and actually get started. So.

‍

Mike Mahlkow (10:15)

Nice, very interesting. And when was that? When did you actually get Toddle started for real?

‍

Andreas Møller (10:21)

So we founded the company in November last year. We raised money before we had a company. So it felt very weird going out and trying to sell shares of a company that didn't exist. It felt a little bit like scammy, but obviously we actually did found the company before we finished the whole agreement, right?

‍

Mike Mahlkow (10:25)

Got it.

‍

Mike Mahlkow (10:31)

Yeah.

‍

Mike Mahlkow (10:41)

Yeah. So you found it in November, 2022. Got it. Okay. Interesting. Okay. So you basically migrate from your full-time job to building Toddle. You raise some money, you find a co-founder and then you just like continue building and shipping. One of the main questions that you usually get if you're building, like let's call it like DevTools or like things that produce.

‍

Andreas Møller (10:44)

Yeah, exactly.

‍

Mike Mahlkow (11:09)

some kind of product for someone else who then uses it in return for their users. All these kinds of things. One of the most important questions is how do you prioritize which features to build? And you seem to have a very strong vision for parts of the stronger problems, and you had identified some of the issues before. But I bet, I could be wrong, that a lot of the conversations internally are which feature should we build next.

‍

How do you prioritize, especially given the fact, maybe for everyone who's listening, who hasn't worked in such a company before, usually what happens is you're being pulled in all those different directions by users. User A or user group A wants these features, and user group B wants very different features. And you have to be honest with yourself and just prioritize very strongly. So how are you thinking about feature prioritization internally?

‍

Andreas Møller (12:06)

That's a great question. And you're absolutely right. It's a very big one and comes up all the time. And I think it's also especially because I think every company feels like they have a thousand things they wanna do and nowhere near the bandwidth to do it.

‍

When you take on projects the size of Toddle, and the same is true with Fastgen, that is even more true, right? When you're building dev tools, usually your surface area, your user interface, the amount of things people want to do with that tool is pretty close to endless. So there are so many things. I think a big part of it is we're very clear on, first of all, the vision for the product.

‍

Like who are the people we want to build for primarily and what are the kind of problems they have and need solving, right? So and this is back to this idea that if you choose to go with Toddle and Toddle is not the easiest no code tool to get started with at all. There's a lot of tools if you want to build something very quickly and then kind of move on, like get on with your life after you build your app and spend like a week or so doing that.

‍

Toddle is completely the wrong tool for that, right? But if you wanna actually craft a product and spend some time making it just the way you want to, that's the kind of user page we're looking for. So being very clear on that, especially in the last sort of first six months, we focus very much on our existing users. And whenever they had issues where the platform would essentially prevent them from achieving something, that would be the highest.

‍

the highest problems, right? And right after that was all those issues they hadn't gotten yet, but we knew were coming, right? So in one of these many sort of restarts I had in the first couple of years I worked on Toddle, some of the things I realized was that you can't as a tool provider build all the features. It's just not all the features you usually need. It's just not possible. So from a very early stage, I built a lot of Toddle to be extendable.

‍

Andreas Møller (14:20)

And actually some of the core features of Toddle are built as extensions. You won't know as a user, but from an architecture point of view, it's quite important for us allowing users and third party to extend the platform with functionality we haven't built because there simply isn't possible to build everything we need to unblock our users from what they want to achieve. And so that has been a big priority. We shipped that earlier this year as sort of the final.

‍

the final piece of the puzzle says, now there really is no limit to what you can do with Toddle. There are things that are easier and things that are a little bit more difficult, but we never block you from achieving the feature you want. And so those were the sort of hard priorities, right? After that, we focused a lot on them. I mean, when we look at our user base, we get a lot of requests for saying,

‍

it would be really great if there was a really simple way to do this thing. And obviously people are right. It would be really great. But since that thing is possible today and just not as easy as it could be, when we contrast that with something that's not possible, usually the thing that's not possible, get priority, right? And we're getting through most of that. I like at this point, as I say, since you can extend total, there's really not many things, if any, you can't do anymore. But that's been our, that's been our sort of guiding star so far.

‍

Mike Mahlkow (15:45)

Yeah, it's always helpful to just have like some kind of framework, right? And in your case, it seems to be remove blockers for things that are not possible. If I like summarize it in one sentence and then listening to users. Like it's always very important if you, because like nowadays they are spending more time in your product than you are. Right. And that's something that I think people often forget.

‍

Andreas Møller (16:10)

Well, in our case, not quite. Since we pretty much work, yeah, we work full time in Toddle building Toddle. So I think we're, well, yeah.

‍

Mike Mahlkow (16:13)

because you're still building Toddle in Toddle?

‍

Mike Mahlkow (16:19)

Okay, that's actually a very helpful part, because I think that for most tools, and Fastgen included, that's not the case. Their users just spend so much time in the tool, and often it's not even possible to build your own DevTool with your DevTool. So that's a very special position that you're in. For example, in our case with Fastgen,

‍

It's literally not possible because of like some part of the underlying architecture and the way backend works. But, um, I actually, that's a major advantage as well. And one of the things that I first. Like thought when I entered your website is we literally build Toddle in Toddle. I, I remember telling my co-founders, this is one of the coolest sentences I've heard in a very long time. And at first I thought it was just marketing, right? And then we started talking and then I realized it's not. Um, then let me rephrase.

‍

Yes, yes, exactly. And then let me rephrase the question a bit. And I want to talk about something that I would summarize as modularity. You said extendability, but having plugins or enabling people to use external services. This is a bit of a break from how no code has worked for some time. Many of the enterprise tools, the big ones, and also some of the like...

‍

very successful no code companies like Bubble, for example, they are like this very closed system. They do have like some external exposure, but the original assumption was we have this like one place, you built everything, but there seems to be like a newer generation of no code slash low code tools that are thinking about it more as being a tool in a stack. And that seems to be what you're doing as well. So can you elaborate a little on why that was your decision?

‍

Andreas Møller (18:15)

Yeah, yeah, absolutely. I think there's kind of two, what's two initial reasons. The first one very simply that to this day, I'm not aware of any code framework that's really succeeded in doing a full stack framework. You could definitely argue Rails in the older days and then somewhat still today, of course, but that's largely because the front end wasn't.

‍

the same thing we're seeing in applications today, right? We just didn't build applications as complex back then. There was a one called Media for a while that got very popular, but fundamentally died almost as fast as it came out. And it just is a difficult thing to do because there's a lot of split focus. And the other part is you really don't get that much from it because half of your application is running on a user's machine.

‍

The other half, it's not necessarily half, but the other half is running on a server somewhere. So it isn't the same application. It's two different applications and they have very strict protocols for how they communicate. And so you don't really get a full integration anyway. You still have that transport and that one protocol you have to go through. So we folks said, well, if we can get really good at...

‍

working through that protocol and integrating with that, actually we can integrate with everything, right? And I think the other half was that we realized that fairly early on, that in order to achieve this vision of Toddle as being a tool built for professionals, and being a tool that's scalable, and scalable here is one of those tech words that has 17 different meanings. Scalable means how many users are using it.

‍

It can mean how big is the applications you build in it, and it can be how big is the team that is building the application. And especially that bit is not something No-Code Tools historically have been very good at, right? But if we wanna build something, like the teams I came from, we were somewhere between five or 20 people, sometimes even more, building on the same application. So you needed a version control system that allowed multiple people to work on the same platform at the same time.

‍

Andreas Møller (20:37)

without stepping on each other's toes. And so we had to build that, right? We also knew that we needed a hosting platform because we needed to optimize that performance. We needed to crank it as much as we could and that requires us to own both the hosting platform and the editor. And so we were sort of looking at, we're sort of a neck deep in building three or four different SaaS products right now.

‍

there really was no reason to add more on top of that, right? If we were also to do a backend or a database, something else had to give. And that's also what we're seeing from all, or from the other NoCode tools, like the ones that chose to go the full stack route, generally are really, really good in the early days of getting started. And as long as your application and team stays relatively small, I think they're a really good solution. Once you start scaling out of that, you start realizing that actually version control...

‍

and sort of a Git-inspired version controllers, which is the tool you use in the code world, right, is a really key component. You can't really do without that as you start having many developers working on the same product at the same time.

‍

Mike Mahlkow (21:49)

Yeah, many, many things there that I can actually second. So the very, very early days of Fastgen, like let's call first four to six weeks, we still had the idea of adding like front-end components as well to like make it just faster overall. And then very quickly realized that...

‍

for a couple reasons, it doesn't make sense. Some of them you already mentioned, you want to be really good at what you're doing, I think. And then extendability is actually better, even for the overall experience of your users, because they can then choose the best tool for each part of the job. So yeah, I think what you say makes a lot of sense to me there. And I think it's something that especially people who...

‍

are coming more from the no code scene and are not like coming from the traditional code scene, like you and me, like they have to think about it a bit differently usually, because for us using Git or like version control and having like a tech stack is very normal, but this like tech stack idea, it's slowly like growing and like growing very fast in the no code, low code space. But it was something that originally wasn't really a thing. So I think we're getting there.

‍

One of the other... go ahead.

‍

Andreas Møller (23:07)

But I think, oh, I wanted to add that there was an added benefit that we actually only discovered much later, which was that there's all these other companies that are in the same boat as we are. And Fastgen is one of them, right? Of saying you are providing half of a solution or maybe even less, depending on how complex the setup is, right? You are providing part of a stack. But that also means you get to work with other companies providing other parts of that stack.

‍

And from a user point of view, we have a lot of new users coming in saying, well, then I have to learn two tools. Yes, you do, but that's also true otherwise, because front ends for building UI and databases are not the same. So whether you're learning two completely different parts of the same tool or learning two tools, it's pretty much the same amount of learning. And now we can sort of say, well, if this is the kind of problem you have.

‍

go over to Fastgen and check out their documentation, check all the content they've done on, and you're focusing exclusively on teaching people how do you do this part of the application, right? So it's a massive amount of work we would have to do, and we would never be able to do it as well. We would just not be able to do it as well with the split focus. So it sort of quickly become a massive benefit to not do it because we were lucky enough.

‍

to see this explosion of other tools coming out. Gotta say there was a period of about six months right up to fundraising where a lot of these tools were not quite like you hadn't launched yet. So we were not aware that you existed. We go, oh, are we about to launch a NoCode tool when there really is no obvious other tools? Like Xano existed, it was great. There's like one is not quite enough to...

‍

to sell this, to explain the story of why it's important. And luckily, we are now seeing a lot of really great tools to fill out that stack, right? So I think it's very quickly become a huge benefit for us that we're not trying to do everything. There are other really good companies that can fill out their part of the stack.

‍

Mike Mahlkow (25:18)

Yeah, I agree. And that's how we think about it as well. Like these partnerships and also just offloading some of the teaching content, et cetera, work to like the other tools in the stack makes a lot of sense. And that's similar to how you would do it as a normal developer. And then especially if teams grow, there's someone who might like focus on the backend and someone else focused on the front end, and then you can just like focus on the interaction between the two systems. So I think there's a lot of stuff.

‍

that will happen, but we'll talk about the future of no-code, low-code a little bit later. I want to focus on two other things before. One of the things, and I think I know part of your answer already, one of the buzzwords that people throw around, especially to measure the likelihood of success for an early stage company is product velocity, right? How do you ship new stuff fast? And...

‍

I would love to hear how you think about product velocity internally. And let's exclude for now building the right features. You can ship really fast and then you ship the wrong stuff. That's usually worse than shipping slowly and shipping the right features. But we already talked about feature prioritization. So let's assume you're shipping the right features. How do you make sure at total that you can keep up the pace and just deliver on a constant basis?

‍

Andreas Møller (26:39)

Yeah, another great question. But I actually think the answer to how we do it fast and how we pick the right features so far has been the same answer, mostly. So there's a couple of parts to it. So probably the biggest and most obvious one is the fact that our whole reason for Toddle to exist is to help people ship and build like building ship software faster, right?

‍

So we build the whole system we're working in every single day around the ability to do this faster. And there's a couple of reasons why that's possible. One of them is that usually when you work in code, you end up doing a lot of work that isn't technically building product features. That's just kinda doing work around that, around your deployment pipeline, around your setup, around your testing, around your integrations, et cetera. And since all that is built into Toddle,

‍

That's just a bunch of problems you don't need to worry about. And obviously, that also means that there's fewer ways. Like, Toddle is a hosted platform. Everything runs on Toddle. So we don't have to work with 10 different hosting providers to some way to make that work. And therefore, you don't need to worry about that either. You can just focus on shipping your product. So that's a really big part. And actually, I think, I'm not sure if it was actually a record today, but we had in the case today,

‍

where we had a seven minute feature. And I'm measuring from the time it was requested by a user till it was live in production. And I mean, it's a special case. It was one of those that really obviously made sense. It was easy to implement, right? It was because we knew exactly, okay, obviously we should have this and it's not gonna be very hard for us to implement. But I've never worked anywhere where you ship software in seven minutes. I mean, that's just not.

‍

It's not our... it's only our record for feature. We fixed box in less than one minute from reported to go live in production, right? I don't want our user to expect that to be every feature. But that's sort of the velocity. Yeah, just so we...

‍

Mike Mahlkow (28:49)

Yeah, I had a very similar conversation recently where we added a feature, not quite in seven minutes, but I think it took us like 35 minutes for something that was requested in our community space. And then immediately I got three additional feature requests. One of them was like a huge feature, like nothing that you can build in like half an hour whatsoever. So

‍

Andreas Møller (29:10)

Yeah, while you're fixing things, I have this printer. Yeah, exactly. But I mean, the fact that we build a whole platform around that is a big part. We also, the other part is that because Toddle is accessible to people who are not developers, I mean, eventually if you use Toddle enough, you naturally become a developer, right? So we don't really make that distinction very much. But because it's accessible to people who don't have a coding background.

‍

Mike Mahlkow (29:14)

Exactly. Yeah. But yeah, go ahead.

‍

Andreas Møller (29:38)

It means my co-founder who's a designer by trade is spending his day building in total and he's focusing more on the aesthetics and the visuals, but he's not just designing it. He's implementing it. Right. So that's not an extra task that me or one of the developers have to do afterwards. We just hired a head of marketing who led, who just released a video about how he's building our partnership program platform.

‍

how he's setting that up running off of Contentful as a backend, right? And he built all of it. We haven't, nobody else has touched any part of that yet, right? Because that part is really easy to do in Toddle. There's a lot of simple things are really easy to do in Toddle. And they are really hard to do in code, right? I mean, if you wanted to change the color of a button in a React app, you need to know how React works. And that's like a big barrier of entry. So not having...

‍

not having all those blockers and having to run everything to a ticketing system. It's like, if someone has, I need to do this, this is on my to-do list, I don't need to book time off the engineering team or anything. I can literally just go and do it, right? So that means you can ship so much faster. And often, just like we saw with the seven minute feature, often you can pretty much implement simple things almost as fast as you can write a Jira ticket for it, right? So that just gives a lot of velocity.

‍

I want to say the other part is, especially here in the early days, we've hired people we know very well, that we know are incredibly good engineers and incredibly good people, that when working in any case ship incredibly quickly and quality software. So I've been very adamant about who we hired as the first team. And I also don't have a very strict prioritization of what they should be working on.

‍

We have a prioritized roadmap. We have a list of priorities. My guess is about 30% of things they do aren't from the top of that. Sometimes it's not on the list. Sometimes it's not from the top of the list. And I very much trust them to go and say, either this is something I actually think I need to fix now is not gonna take too long, or sometimes it's just, this is gonna be really fun to do and I think it adds value. It's not necessarily more important than everything else.

‍

Andreas Møller (31:58)

But if people are in the zone and have the right mindset to solve that problem right now, it's very often the right time to do it. I mean, obviously there's an upper limit of like, if it's gonna take three months, that's not really a thing. But if that's something you can do within a couple of hours and you're right now in the mood for that, time might be better spent doing that than something else that happened to be higher on a priority list we agreed on in a meeting.

‍

So I let the team do most of those high, like the final decision making, they tend to do themselves. I provide and we work together providing a prioritization list. We align on what we wanna achieve this month, et cetera. But they have a lot of freedom to go and pick what they wanna work on now. And I think that adds a lot of, well, it makes it more fun. It adds a lot of velocity in the end as well.

‍

Mike Mahlkow (32:51)

Got it. Yeah, I think I understand. There's a difference between spending five days of adding this animation on a screen that no one will ever look at, but it's fun, and then actually building things that have some unique value to the user. And one of the, go ahead.

‍

Andreas Møller (32:08)

I mean, the feature requests we got today was not very high on any priority list. If we had to prioritize it, we might not have done it this month. But someone could do it in seven minutes and they just did it, right? And that mentality and that culture does a lot, right?

‍

Mike Mahlkow (33:20)

Yeah, if it's fast, yeah. Yeah, I agree. Um, one of, one of the other things that is talked about like quite a lot in the, in the no code space or like local space and extension is a vendor lock-in, right? You probably hear that a lot. And, um, I would love to hear just like how you think about it and what you tell people that are worried about vendor lock-in with Toddle.

‍

Andreas Møller (33:51)

Yes, first off, vendor login sucks. As a developer and engineer, for the last 20 years, it sucks. It's not a good thing, nobody likes it. It is, however, a reality. And I've come to realize that it is a reality in almost all of software. Oftentimes, the vendor is not necessarily a vendor in the traditional sense, but I've been part of migrating projects from an Angular code base to a React code base.

‍

We were never paying Google for Angular, but the costs, we still paid for migrating off it. We were still paying for using it in terms of the engineering team, we ended up having actually much preferred React and was more efficient at it. So while they didn't get any of our money, we were still paying for it, right? Even in open source software, you have vendor lock-in, even when people are not trying to lock you in. And I think...

‍

in the vast majority of cases, people are not trying to lock in. There are definitely cases, there's stories of companies that have a lot of practices around how we can, you know, be sticky, I think is the, is the corporate term. Um, but most of the games that's not really the goal. Um, and, uh, especially not in our case, I think, uh, the same thing that means we have some level, like just to be clear, like there, if you build your application in Toddle, it runs on the Toddle platform.

‍

And you can move off Toddle again. We even have a guide how to do it. We've all worked on projects where we had to migrate technologies. We know the only way to do that properly is gradually. So you need to do that part of your app at a time. This doing one big, like export your code, run somewhere else, is just not a solution I've ever seen work, unless you.

‍

Mike Mahlkow (35:43)

No, it might work for like small landing pages, or like very simple things, but once you reach a certain level of complexity, it usually doesn't work.

‍

Andreas Møller (35:52)

And I think especially in no code world, like even if your tool created the most beautiful readable code in the world, and we can create readable code, but it's gonna be readable code based on how we build apps in Toddle, which might not be how the dev team you wanna hire in the future do it, right? They're probably gonna choose a major framework and wanna use that, right? So in the end, this, I think this idea of you

‍

exporting your code and then continue working on it as code. I will be very impressed if someone manages to do that efficiently, but I don't really see any anywhere where that's possible. I think that's you can run it, but then if you need to change something about that code after you exported it, well, then there's your problem. So in our case, that's we very much have it. It's not

‍

at design, I reckon there'll be at least a few users that won't take me on my word for that, and that's fair enough. But it isn't, we don't really have any big interest in vendor lock-in. What we did wanna do is build a platform where we could do a lot of the heavy lifting when it comes to performance and optimization. And for us to do that, that requires a hosting platform that understands every part of our Toddle application works.

‍

and requires an editor that are integrated to that. Like a lot of the benefits that we give is because we're building those parts of the system together. And if you remove one or more of them, then that kind of falls apart and you don't get those benefits, right? So it is a product of the way we chose to build the system because of what we prioritize.

‍

Mike Mahlkow (37:40)

Yeah, yeah, that makes sense. And I agree with your statements on basically every kind of software having some degree of lock-in, even if you just use an open source language or whatever you're using. And then the other part to it is that I think the best kind of lock-in you can have is literally just providing as much value as possible to the user.

‍

If you just extend the capabilities of what they are able to do in total, then literally lock-in is not an issue. Where usually lock-in can be an issue is, especially in the no-code world or somewhere else, if you just reach barriers and then there's no way of breaking through the barriers. And that's usually the worry I tend to hear from traditional engineers, I just call them, who are considering to move to no-code, low-code tools.

‍

just because they know that like in code, theoretically they can like encounter every issue and then solve it. But especially with some of the traditional solutions in the no code space, it's just not a thing. But yeah.

‍

Andreas Møller (38:47)

Yeah, I wanna add to this that I think both for Fastgen and Toddle, because there's a lot of, I've worked on a lot of different SaaS products and I've also worked on some where lock-in was something that the management team was very serious about and more or less designed for, right? But they were not in the dev tool space because one of the things that's quite

‍

not necessarily unique, but definitely characteristic of this space is that our users work in our tools every day for hours, right? Obviously, we have hobbyists as well, but when you use a tool every day for hours, if you don't like this tool, if you don't choose this tool, if you don't want to work with it, you're just going to start building up resentment. There's no business in that.

‍

from our point of view in saying, in trying to keep anyone on our platform that doesn't wanna be there. It's not, I don't think it'll work out even financially in our favor to do that. So we very much focus on saying the lock-in should be that people keep choosing us every single day, right? We need to go for that. If we're not doing that, our company doesn't have a future.

‍

Mike Mahlkow (40:04)

Yeah, I wholeheartedly agree with that one. Let's like, we have a couple of minutes left. Let's talk a little bit about some non-product related questions. Number one, you're producing a lot of YouTube videos. And it has been, or it seems to be like part of your Toddle either like go to market or education strategy. So tell me more about like, why is YouTube such a big deal with total?

‍

Andreas Møller (40:32)

I mean, so I used to say when people comment on, I just recently got our neon logo behind me as well. And I've got a custom design, it's cut out of frame here, but that's my nephew's built that for me. Yeah, it's very fancy. I'm very happy. It cost me a PlayStation 4, but worth it. Easily worth it.

‍

Mike Mahlkow (40:45)

Oh, oh, okay. Yeah, props to your nephews. That looks great. Well, a deal I would take any day. I would definitely take that, yeah.

‍

Andreas Møller (40:58)

But I do get asked sometimes like, why do you have this setup? And I mean, the answer is safe. If you build a complicated product, you end up having to spend a lot of time teaching people how to use it, right? And I mean, obviously, Toddle is as simple as we can make it, or at least have been able to make it so far. But you are still learning to program. A lot of people have never done that before. Right. So, yeah, if you're a traditional engineer, it's fast. Otherwise, it takes some learning. And therefore, we need to produce a lot of content to get.

‍

uh, people, um, on board. And so most of our content is educational. Um, but also, I mean, especially YouTube is just a great platform for content. Uh, we, we spent, um, our early days focusing on Twitter. And the thing is it's with Twitter, when you've done a tweet, you can tie kind of take a breath and then it's gone. And now you have to go and produce more content and then you have to produce them more.

‍

and the quality suffers, right? Obviously it's text content, but nonetheless, like it kind of disappears when you're done. And so YouTube has been our platform because some of the videos we made six months or maybe even almost a year ago now, people are still watching them and getting value from them, right? So I think for that, we've very much focused on that. I will say that we're trying to produce a lot of content. We're almost getting overtaken by our users and our community now.

‍

So we have more than one YouTuber who's like building a lot of Toddle content at the moment. So we sort of, we use it internally saying, okay, they just released another video this week. We gotta step it up. We can't be outdone by a community that have other jobs. We gotta...

‍

Mike Mahlkow (42:45)

I think you will have to be outdone by your community at some point though, just because it will grow and grow, right? Yeah. Some of my favorite Fastgen users are some of the content creators. And then I sometimes just look at their videos and like, well, that's, that's better than my last video. And then, and then you need to step up the game of how good your videos actually are. So some of the, some of the community members are like really good content creators and getting them excited is.

‍

great just because they are producing this educational content. But then that also shows that people really care about your product, because they're taking their time, especially for the ones that have day jobs and are not full-time content creators. They're taking the time out of their busy day and invested into talking about your product, which is one of the best signs that you can get that they really like it. One question about the videos before we move on.

‍

You said that people rewatch a lot of the videos that you recorded like 10 months ago, but I assume Toddle is also changing over time, right? So like, how do you work with like Toddle being like very different now because you've shipped so many things and like keeping videos up to date? I think you know where I'm coming from, right?

‍

Andreas Møller (44:02)

Yeah, yeah. And I mean, again, we haven't removed any, we haven't really replaced any videos, we just, we add more, right? But yeah, we have a lot of that. And when you watch the earliest videos, I don't have this set up, I'm sitting in my living room with a webcam instead and recording videos, right? And so there's also quite a clear difference. I mean, I think the most glaring example is we have some features that literally shifted to the other side of the screen.

‍

So I keep sitting there saying, and in the right panel, you'll see, but actually it's at the left panel or in the left panel is, oh, it's actually on the right. It haven't actually been that much of a problem. Like the product has changed, but it's kind of based on some fundamental ideas that don't change, uh, all the really key, uh, ideas of how total is built. We haven't really invented. We kind of went and said, what are the, what is the model that all the big frameworks have?

‍

landed on because they all actually work more the same way in JavaScript land, right? And then we go, how do we translate that into a no code context and then solve this out? So none of the very key ideas about how the platform works has changed. A lot of the visuals have changed, but generally people then figure out, okay, the word variables is now on a different part of the screen. I'll figure it out, right?

‍

So so yeah, it I mean eventually with a content team We might sit and go and sort all that out, but it hasn't been too much of a problem yet sometimes people ask and then you know, we add a comment or And it and then them to do the video right, but it hasn't been a big issue But there has been a lot of changes for sure

‍

Mike Mahlkow (45:46)

Yeah, that makes a lot of sense. And I'm definitely encountering similar issues when we are making videos. The cool thing, similar to what you said, the core structure is the same. Like the logic and like the base of how Fastgen works hasn't really changed. And we are also very careful, like ever touching like core structure of how it works. Because we put a lot of effort into this and like test it very hard. So we're pretty sure that there's...

‍

that that's correct and works well. But we ship it a lot of additional features that you can use it for, and we ship improvements around it, like additional extensions, new functionality. But the basic way of how it works stays the same. And then, as you just mentioned, people can usually make this one step, or the second step. There's one more question that I think is great to just close the conversation off since we are...

‍

I'm running out of time almost. And I could probably do this for like two, three more hours. But I know that it's late where you are. Yes, we should definitely do an update at a later time. But for now, let's look a couple years ahead, right? And there seems to be a lot of momentum in the no code, low code space right now. There's like great products being built and I would include Toddle among that list, like definitely. And there's like...

‍

movements in all different areas. They have movements in the workflow area, the backend area, the front end area. There's like easier ways to like host databases or even database adjacent tools. Right. It doesn't have to be like a full database. So basically the summaries, there's a lot of stuff happening, but where do you see the space a couple of years from now? What do you think has to happen for it to become, let's call it like really mainstream?

‍

Andreas Møller (47:38)

Yeah, I think it's a great question. And I also, I am not shy of saying, I don't think no code is mainstream, at least not when you compare it to the amount of software being done in code, right? And especially when you even include like the amount of software that could have been done in no code, because there's also obviously software being written that there is no code alternative for, right?

‍

But I think we're sitting on a very, very small percentage of the market now as no code tools. It's a really good question because I think I've heard a lot of people say that there's no reason why you wouldn't use no code for this and that and this and that. And I think that's becoming true. I definitely don't think that was true a year ago. I think as a coming as an engineer.

‍

and as an engineer who fully buy into no code. Like it should be purely clear, I'm quite committed at this point, right? But the reality is that while there was incredible tools, there was also very clear limitations. And I think coming from an engineer background, you can say, well, that's great, but you're not gonna build this kind of application that I just came from building in that, right? So I think we're beginning to see that. And I think it's within the last two years,

‍

that we've seen what I think are gonna be the tools that have a potential to go full mainstream. Because there are some requirements of like, what happens when you take this concept of no code and scale that up to someone building enterprise scale SaaS products, right? That is, there are some different problems you reach there and there's some issues around scale that just needs to be handled, right? And again,

‍

scale here can be any one of those definitions, whether it's number of users requests, team size, or even complexity of your application, right? For any one of those types of scale, that's not what no code for a long time have been focusing on, and it shouldn't be, right? It was incredible at doing what it is, but I think potentially there is a potential with the new generation of tools to take that to a whole new level. And I'm at a point where...

‍

I was asked this, I actually get asked quite a lot, is there anything you wouldn't build in NoCode? And there's tons of things I wouldn't build in NoCode, but they are almost all of them things where there are no, there's not really that much of a NoCode tool for, right? There's a lot of things you can build in the 3D game world with NoCode, but you couldn't build like AAA games in a NoCode setup today, right? So they are still.

‍

There's a lot of places where no code hasn't gone yet, for sure, right? Systems engineering is not a no code space at all today, right? But when we talk about web apps, I don't see any areas, I don't really see any specific use case where I would say that would make sense to choose code. There might still be, like today, you might still be able to make that argument pretty strong. I think that's gonna be a hard thing to reason or to argue for.

‍

in as soon as a year or two. I think it's still gonna take longer for mass adoption, like to really get a hold right, it just takes long time to get, like people already build their apps, they don't really wanna start over. So adoption is gonna take time, but I think we're getting into a point where that argument is very hard to stand up against very soon, I say that no code just is a choice that it's hard to get around.

‍

Mike Mahlkow (51:22)

Yeah, I think there was a great closing statement. Um, I don't have much to add to that other than the fun fact that whenever someone asks me is fast and scalable, I asked them, what do you mean by scalable? Because everyone, everyone means something very different by it. So I totally like, usually I use the same triple scalable definition that you just use, I just use different words. So very much second that. And also very much think that.

‍

There's definitely some momentum in the space. It hasn't been there before. And while you might not be able to build like high frequency trading apps for like wall street in no code or like some like very sophisticated fringe things. Maybe you can. Um, I think we might take longer than a year or two, like basically for any web and also most mobile apps, I don't think that there is a reason in one or two years. So I totally agree with that. It was a.

‍

Great pleasure to have you on. Thanks for sharing all your insights. Everyone who wants to take a look at Toddle, it's Toddle.dev, and you have a great Discord community that's very active, and a YouTube channel, and then also still a Twitter account that is posting some good memes every now and then, even though it's not part of the core strategy anymore. So everyone who's looking into building a new web app and wants it to scale, check it out. And with that, have a good rest of your day, and as always, Happy Building!