The Changelog: Software Development, Open Source - The Web Development Engine (Interview)

Episode Date: May 30, 2025

We're joined by Andreas Møller, Co-founder of Nordcraft — the team behind Nordcraft Engine, a powerful new platform designed to give web developers what gaming developers have had for years. Andreas shares what inspired them to build Nordcraft Engine, why they believe the web is overdue for a shift in how we approach designing and building for the web, ee explore how the platform works, how you can get started, and what's next for Nordcraft.

What's up friends, this is the change while we feature the hackers, the leaders and those building the future of the web. On today's show, we're talking to Andreas Moller, co-founder of Norcraft, the team behind Norcraft engine, a powerful new platform designed to give web devs what game devs have had for years. Andreas shares what inspired them to build Nordcraft engine, why they believe the web is overdue for a shift, and how we approach designing and building for the web.

We explore how the platform works, how you can get started, and what's to come for Nordcraft. A massive thank you to our friends and our partners over at fly.io. That is the home of changelog.com and a bunch of robots too. Learn more at fly.io. That is the home of changelog.com and a bunch of robots too.

Learn more at fly.io. Okay, let's talk web dev. Well, friends, you know, I'm excited about the next generation of Heroku. Who isn't? Well, I'm here with Chris Peterson, Senior director of product management for Heroku at Salesforce. Chris, tell me why should developers be excited to the firm platform? What does that mean to you as a Heroku developer? It means a few things.

One, it means that we're going to be working on investing in our ecosystem. One of the standards we're adopting open telemetry is a big step up over the way Heroku's done metrics traditionally. We had a piece of technology called L2Met that converted logs into something that kind of approximated open telemetry metrics but now there's like a real standard there's like a real toolkit and there's a whole ecosystem around OTEL and so being able to have open telemetry dashboards out of the box and our partners that tap into all of your Heroku telemetry so that you don't have to go build a dashboard and you're not necessarily constrained to what we provide on our dashboard is exactly the

type of value we're seeing out of this. So it's tapping into the ecosystem effect. Similarly, cloud-native build packs. One of the features that I'm excited about is supply chain security that we're gonna be working on later this year but that was an open source contribution to the C&B project itself. Bloomberg actually contributed support for software build materials generation. And so the things that I'm excited about are the things that developers are excited about, which is we're not going it alone. We're not building a proprietary solution.

We're using the same tools and technologies as other superstars in the industry are. And we get to play into that ecosystem effect. A huge part of Heroku's value has always been the Elements marketplace, being able to bring in databases and key value stores and telemetry and observability tools. And so renewing our investment in open standards lets us renew our investment in our ecosystem and our marketplace. Very cool. So how is this next generation

and what is coming changing the game for you and the product team. To me, on the product team, let's be put out a roadmap that's way more ambitious than what I could do if we were trying to build some of the primitives ourselves. Kubernetes has really established networking technology. That means our roadmap has a lot of networking features that our customers have been asking for for a while that we're going to be a lot slower to build

on the Cedar stack than they are on the first stack. And so you should be excited about the open standards and the modernization there on day one. But the thing that I'm excited about is what we can do by the end of the year in terms of roadmap and features, not just getting to parity on some of the more nuanced features that we have on Cedar, but also the new things that we can build taking advantage of AWS VPC endpoints, which is something that the Salesforce customers have wanted for a while. There's a huge number of these features that just wouldn't be possible

to get done this year otherwise. And that's where I'm excited. Very cool. I love that. Well, friends, the next generation of Heroku. I'm excited about it. I hope you're excited about it. I know a lot of people who have been really, really looking forward to the next thing from Heroku. To learn more, go to heroku.com slash changelog podcast and get excited about what's to come

for Heroku. Once again, heroku.com slash changelog podcast. Today we're joined by Andreas Mahler from Nordcraft. Welcome to the show. Thank you very much. Happy to have you. I first found you from this blog post called They Lied to You. Building software is really hard. I found this to be very relatable.

And one of the things that you said in that post, I'd love for you to expand on for us, is that you said, if you're looking for one trick that lets you get ahead and jumpstart your career, your advice to the reader is don't choose the path of least resistance. Can you unpack that for us? Why, why not?

What does it mean? Yeah, absolutely. So I think, I mean, a little bit of context, obviously if you have a job and you've been tasked with building something, you don't always have to go the hardest possible way of doing everything, but I think there's something to be set

for leaning into the challenges when they present themselves. So if you're always, if your solution to every problem is their library that does that, without looking into how to actually solve the problem. Or if you're the kind of person who likes to hang around, stack overflow and see if there's an existing solution

to everything, like it's good to look it up, but it's, I always would say, give it a try first, right? And sort of throughout my career, especially with a lot of junior developers, there's this sort of attitude that like, oh, I'll go and look here, I'll go and find it here. And a lot of the times, the part where you really learn something is when you sit down and take your time. Right? So actually leaning into saying, this is a hard problem, it's gonna be difficult to solve,

but I'm gonna try and figure it out. And I'm not gonna look for the solution until I've at least analyzed the problem and feel like I have a good idea. And you're here now today building a thing called Nordcraft. How did you find yourself here? And you talked about your experience. What does your experience look like? How did you find yourself here? And you talked about your experience. What does your experience look like?

How did you begin building this, et cetera? So Nordcraft sort of came about a little bit out of frustration. I've been a software developer for a little over 20 years now. Almost always, almost my whole career focusing on web development, because I really like the web. I think it's the

greatest application platform ever built. And I really enjoyed building anything from like small websites to massive SaaS platforms. And and through my career, I've sort of gotten to see like, we've gone from there were no frameworks to gone through a few a few of them. Like React has stuck around for a long, long time. And now we're sort of seeing the new generation of framework coming out and improving on React. But things aren't like there's a lot of talk about how things change every every six months in web development.

And yes, something changed. Sure. month in web development. And yes, something changed. Sure, if you're looking for it, but on the whole for the last 10 years, things really hasn't changed that much like react has been the dominant framework. There's a little bit of modification like a lot of the details, but overall, the way we build apps are very much the same. And so one of the things I noticed was this process when you're sitting in a product team, where a designer will like usually a product manager will come and say like, we need this kind of feature because for some reason, a designer will go and do a layout or design of what that needs to look like.

And then you get a handoff to the developer, right? This was me. And the handoff is something along the line of like, here's a picture of what you need to do. Please do it like exactly the same way. Like we usually call it pixel perfect, right? And pixel perfect means don't add anything of yourself into this task whatsoever, right?

Just do the exact thing that's been shown you, but in code, right? And I been shown you, but in code. Right? And I like my job, but that particular part was like the least favorite part, because that's the bit where I don't really matter. I just need to repeat the task someone else did, right? My opinions don't really factor into this.

Now in actuality, they do because the design is never complete, but I always felt that part was kind of pointless. Like, if the designer already built it, why are we doing it twice? And so I wanted to play around with this idea of saying, well, why do we duplicate this step? And I've seen tools like Webflow.

You can build visual tools for building websites, but there wasn't anything built for applications. There's sort of a limit. for building websites, but there wasn't anything built for applications. There's sort of a limit and like the second you get above a certain complexity or you need some flexibility, some dynamic content, then we're going back to everything is done in code. And so I wanted to figure out why is that? If the UI can be done visually, why can't we build something like this that would work for the kind of application I'm building? Which was mainly SaaS applications. That sounds an awful lot like Drew Wilson's thing

he's working on, Adam. I just listened to your conversation with Drew Wilson and he mentioned he's working on something similar where kind of the design manifests in DOM nodes or something. The design tool is actually producing the DOM. That's the big thing he wants to work on. Yeah. I don't know if I know, what is it called?

It's not named, I don't believe. I don't think it has a name yet. I think he said something. It's like opacity or something like this. Anyways, it's not like out there yet. So, you know, you're way ahead of him, Andreas. Don't worry about it. But he is a formidable opponent.

He is a formidable opponent that is for sure. There are a lot of tools like in the sort of broader space of sort of trying to make programming visible, visible, visual. There's a lot of tools. What I thought was really interesting was that like, this sort of idea is not new at all, right? Like the broad idea of visual programming is very old. The oldest thing I know of is like 1967. So before we had personal computers, someone

was drawing with a light pen on like an old, uh, like what's called the RAM tablet. And they were drawing those together and programming like by drawing on a, on a, like a, I mean a tablet is what they called it. It was a very large monitor sitting and take you up. And it's been tried a lot of times before, but it never like, and like visual basic worked and took off a bit, but then it hasn't really, it hasn't really taken off, right? It's always died down again, except in one industry, which is gaming. And I thought that is the weirdest thing in the whole world. So if you're building a

triple A game that takes 10 years and take some of the brightest minds of our engineering industry, right? Then you can use a visual tool to build most of the game. But if you do it in 2D and it's just a website, then that doesn't work. And I'm like, that doesn't make any sense. There must be something I'm missing here, right? There must be something I'm not seeing. But why it is that that's the only industry where not only is it possible, it is an absolute necessity. Without those tools, you cannot compete. Yeah that that's the only industry where not only is it possible, it is an absolute necessity without those tools.

You cannot compete. Right. Yeah, that is interesting. I've never developed a game before, so I don't know that for sure how it works, but that does make sense. I mean, it as a designer, so I'm a I came up in design, came up in user experience, design, product management. I was like a product owner for the company leading.

And that was that I was that person that was for the company leading and that was that, I was that person that was between the business itself and the engineering to make sure the business goals were met and the engineer was able to accomplish the goal. A lot my life. And I would say on the flip side, it was a struggle as a designer to have to do all this in this pixel perfect way in pixels, literally,

and not in the web, and not have the tooling available. Sure you can HTML code it and you can use CSS, but it was just, you could make more progress more efficiently and higher fidelity inside of the oldest of day Photoshop, lately Figma, or even Sketch if you're not a Figma person, it was always a challenge to design something like that,

to go through all the process, to go through the customer and the user stories and talk to people and talk to customers and gather all that feedback to then create an artifact that is static and attempt to hand it over. And hope, if it looks like that. And honestly, because you'd done all that work,

because you'd done all the thinking behind it, you're like, don't change anything, okay? This is a brittle thing I'm handing you. Please don't change anything because we've gotten sign-up from here, we've gotten business concern handled there, we've got colors established here. Hopefully it was that thought through.

But for the most part, it was pretty good and thought through, don't change a please, and please, can we make this happen? And so I've been on that side, and it's tough for both sides really. I think we all want better tools. It really is, and the interesting thing is my co-founder, his name's Casper, he is a designer.

And his motivation for joining, like when I showed him this the first time, he almost to the word told me the same thing. As saying like the frustration, because it's not just that it's limiting, but it's also the frustration and then seeing what you've done interpreted through someone who thinks blue is blue. Right. And there is white and I'm not sure what eggshell is, right? It's just white, isn't it?

And then see someone like that take your design and then say, look, I made it. And then, no, no, that's not what I did. And having to wait and then come back and then we have to do a whole iteration again. I have to go back, critique all the things and lastly say, that's the color, right? And yeah, it's super weird.

And it, um, and I think like I've, I've, I'm a big fan of all the, the JavaScript frameworks, actually all of them. I think they're, they're, they're all great to be honest. And, and in many ways we move forward, um, because we were able to build more complex things. But one thing we really lost is to kind of put the final nail in the coffin of should designers code right? Before then there were designers who worked in HTML and CSS. That's more or less not possible

today, right? Because it's not just that you need to know HTML and CSS, you need to know VEET. You need to know how to install that NPM module that never wants to work or figure out whatever happened to the build system since last when we cloned things from GitHub. Like the complexity of our builds, of the setup around building an app means that before you get to touch anything design related, you're like three or four days in. So we really sort of, with the technology stacks we use today, we've moved even further away from the idea of a designer contributing anything directly into the application.

I think that's probably the worst thing that happened with modern frameworks. Yeah, that does make it tough. I'm curious about perhaps a pivot that I'm sniffing out here because when I first linked to you, which was March 27th, it was on toddle.dev, T-O-D-D-L-E.dev.

Now it's Nordcraft. I remember toddle talking about a game engine for the web or something like this. And Nordcraft itself is the web development engine for web apps that delight your users. You talk about creating web experiences. A game, a web game, a web experience. These things are very similar things.

So I can see it being just as maybe a pivot of sorts or perhaps just a rebrand. Can you tell the story of NORDCraft? We were kind of branding nerds. We think about naming, we rename things. And so it's more just intellectual curiosity there than anything else. It is a rebrand. It's not a pivot. But it's it's a quite thorough rebrand. Yeah. The product we always kind of knew what that was going to be. Like there was never much discussion on that. We I invented, I, I invented this for myself.

My co-founder coming in knew what he wanted to use it for. Right. And, and, and the point was to build something for professional product teams. What we looked at and saw that was this whole no code community and no code tools are generally, they're somewhat similar, but the big difference is that they're focused on people who don't come from a developer background. And generally don't want to be developers in like, they don't want to spend time learning to code. They are not interested in getting too deep into the technical part of software development. They kind of want

a tool that takes care of most of it for them. A lot of them are very interested in vibe coding right now for the same reasons, right? It's about getting a product out, but they don't, the process of building is less interesting. Well, a lot of developers often are actually drawn sometimes even more to the process than to the final product. And the way that happens in no code is you try and simplify, you try and figure out how can we take a process and something that's very complex and how can we simplify it down to a point where people can get started earlier. And that generally just happens

by creating high level abstractions, right? What we would normally as developers call massively over abstracting, right? It's just like, that's what you're building. And that comes with a certain set of limitations, right? You can build this kind of table component, but you can't build that kind of table component, right? You can make it behave like that. You can't quite make it behave like that. And as long as you're okay with those, as long as you're saying like, I'm solving a business goal, the specific

details of what it looks and feels like aren't important as long as the business goal is solved. Those tools are really great, right? But that's not what we wanted to build. We thought there was a space for us in that market of saying, well, we can be in the professional segment of that. Once you hit a certain limit with those tools, we're right there for you to move up. And what we didn't quite realize was that's not that interesting for people again, because most of them either already moved up and like hit the limit and then their next step is learning code or they are just not interested in taking that extra step. And at the same time, I think we underestimated just how much a lot of software developers

do not like no code, both as a term and as an industry, right? Like NoSQL. Yeah, almost as much as they dislike NoSQL. Right, I mean that was a bigger shuffle back then too. Oh, for sure. Yes. And in many ways, honestly, it's not that unlike the whole Mongo story of like,

look, we don't need SQL because look how simple this is. And then you're like, now you need a transaction. And then you go, now I have to invent transactions. Right. So yeah, for sure. There are there are certainly similarities, right. And to some degree, that's what the blog post is about, right? Like when you always seek the simplest and the the easiest solution to every problem. What you end up doing a lot of times is you put yourself into a corner where it's really hard to get out of. So I've done that.

I've chosen Mongo for a project that really needed a transactional and relational database and then gotten to a point where I need to figure out how we kind of build our own transactions. We could roll back at the application layer, right? And I think we see the same thing in the no code space a lot of time. And I think a lot of developers will have experienced that. Sure.

And all the Vibe Coders will certainly experience that assuming that their idea is good and they get past that first phase, which is, I think it's great for getting that proof of concept, you know, something to show somebody, get your idea out on paper, but extreme limitations, at least at this phase, the current state of the art.

So, Toddle to Nordcraft, this was just a rebrand. What was Toddle holding back that Nordcraft unleashes? So like the name itself was a bit problematic, right? Because Toddle is sort of a relation to toddlers and toddling. Which was actually like a joke name my wife came up with in the very early phases because when I started working with this, I had no idea if it even could work, right? There was a part of me that thought since we don't have these kind of tools, there's probably a really good reason why, and I just don't know what it is.

But I had to try and figure out, so I kept working on it, right? And to some degree, like when it came up, I'm like, that's kind of what I'm doing. Like right now, I'm trying something and then I'm falling over and then I'm trying something else. I'm like, it's, yeah, okay, let's call it that. And then, you know, as it started working and we kept referring it to a total, we kept going eventually like then VC investors came in and then we had to talk to all of those and that was a bad time to change the name.

And then like there was never a time to change it after that. We're not going to sit down and come up with the best name because it's like, it was fine. Right. And it was more on, and there's a certain truth to the fact that a name is whatever meaning you give it eventually. Right. So, had we kept the name, eventually, total will just mean our app and it wouldn't matter because that would be the ideas people had. But we could feel it was holding us back a bit from sort of anecdotes from customers. And at the same time, we couldn't get a dot com. It's hard to search for because we get so many other results. So there's a lot of sort of small things about the name that wasn't so good.

So when we realized that we needed to sort of make a branding pivot away from being a no codecode tool and like a more professional tool for beginners kind of thing, right? Which is also a weird phrase to say out loud. We said, well, let's take the name away as well, because that at least everything will still redirect to the new site. But when people say things like this is what I think about like Tottle versus this tool that you really have no reason to compare us to because we're in completely different like we serve completely different sets of users, right? A lot of that is sort of

existing conversations we could actually a little bit leave behind. And that was very intentional. So we wanted a brand that sort of highlighted that this is meant for be to be for professional teams. It's meant to be for for developers who know what they're doing. Well, Adam seems to like it. I think I heard you say it's beautiful. Is that what you said, Adam? I think Andreas missed it. The rebrand looks beautiful. I mean, the application looks beautiful too. And I was only able to find it because thankfully you're able to clone an application. So I'm hanging out at toddle.dev slash projects slash a bunch of slugs.

Nordcraft is the next one after that. And so I'm actually like hanging out in the UI. It's all beautiful. It looks really nice. Thank you. Thank you. That's my, that's my, my co-founder who's the biggest. Well, I mean, it's not just him anymore.

Right now we have a whole team. We have designers that are looking at that, but, but that's, that's not, that's the biggest, well, I mean, it's not just him anymore. Right now we have a whole team, we have designers that are looking at that. But, but that's, that's not, that's not my fault. There are old version pictures of the first versions that looks very much not like it does today, but yeah, I'm really, I'm really happy about the, the work they put in there. I think it looks great. And again, the new design has a certain, like it has a little bit more gravitas to it, right?

It looks a bit more serious. The other problem we sort of ran into is that we are not very serious people, my co-founder and I. And we love this part of startup life when you can do ridiculous things for attention grabbing and like send out content that are, it's ridiculously silly and people enjoy it. But when you stack that on top of a child is brand name and everything being bright, child is called us like it becomes too much.

So when we have a serious branch brand actually being a little bit silly as founders isn't the problem. Um, so I think, I think that all aligns quite well with what we're trying to do. And actually I heard about Tottle by way of a friend through friends, I would say some alum, Naila, I'm sure you know her. Yes. Uh, amazing DevRel, amazing all the things. I admire her so much. She's so good at speaking and so good at

demoing and Just thinking how users feel and like that intersection there. She's really just a star So I'm sure you're glad to have her but I was like man Tata sounds pretty cool, but the name didn't really Make me feel like oh I should you know, I don't know. I just it didn't didn't it didn't really make me feel like, oh, I should, you know, I don't know. I just, it didn't, it didn't, it didn't spark my interest. Let's just say it doesn't make you go, Oh, I need to use that for the next tool that I maybe focus my career around. It seemed like a toy.

It seemed like whatever it is, it's cool. It's it's groundbreaking, but it's almost silly just by name. That's it. Application, obviously different scenario. Now, if I'm being honest, though, Nordcraft is almost as ambiguous, almost. Oh, yeah. But that's that's that's kind on purpose. Like we don't we don't want it to mean anything, really. Well, I mean, Nordcraft sounds like buildings.

Nordcraft? Yeah. I mean, the crafting part makes me feel like this is for crafters, right? This is for, you know, builders. Maybe. I also think of Minecraft, of course, because it's such a strong brand in the crafting space. Sure. So there's a bit of fun there.

Nord, I wonder what it is. It sounds cold, Nordic, I don't know. I've been to the website, so I've seen some of the trees and stuff. So you do have like the forest thing going on. I like it, I think it's better than Tottle. I don't, I agree that it leaves. If you just said Nordcraft to me,

I wouldn't know what it is, but you know, back when you first said Google, I didn't know what it was because I didn't know what a Googleplex was back then. One of the things we found was that trying to explain what it is was extremely difficult because everyone has like, especially when you're doing marketing content, right? People have a desperate need to find a bucket and put you in it. Yeah. And if you don't give them one, they'll take one. Right. So I, I once had an entire, uh, 20 minute conversation with a investor that

never understood that we were not like air table, even though we do not have a backend or any database associated directly with it whatsoever, right. But he just couldn't, he couldn't let go of that idea because once he sort of tried to represent our, what it was, it was locked. Right. Um, and, and when we say visual editor, like if you think it's kind of like web flow, it's technically not wrong, but it doesn't quite communicate the important part, which is this is actually a tool that teams will use to build very complex applications.

And Webflow is for building mostly marketing sites and it's predominantly not used by developers. So even though there's a lot of similarities, it doesn't quite capture the point. And what we found is actually we think the best thing we've come to yet is this idea of a web development engine. It's essentially like, what if we had game engines but designed for building web apps? Not web games, but that same idea, that same concept of tooling that you have in the game world,

how would that look if we built that for the web? So go ahead, explain the tech to us. You know, exactly what it is, how it works. We're all developers here. So hopefully you don't get completely locked into something that it's not. No. So I mean, probably the simplest way of, again, we use a lot this, this analogy to the game engine, right? Where a game engine is a sort of big box of a lot of different things. It has rendering engines, physics engines, audio engines, animations engines, all these things.

And then that's all tied into a central framework for building games. That sort of powers the game loop and everything. And then on top of that, they have this suite of visual tools. And most of the people working with them are like a mix of some developers, a lot of designers, but they're all working with the same tools. And these tools essentially program the engine, right? And we're not just talking like building characters, right?

It's not just that they're using visual tooling for like 3D modeling, etc. Most of the game logic is built in visual scripting. So in Unity, it's called Blueprint. In Unity, it's called, I think it's just called Visual Scripting. In Unreal Engine, it's called Blueprint. And I didn't realize this at the time when we started, but actually, the AAA games today, most of the game logic

is built with visual programming, which for me was such a mind-blowing moment because we just rejected this concept in every other industry. We're going, okay, that's cute. That's for sketch. That's for children. But when we look at these big, massive games we play, they've been built this way. There is a lot of code involved.

There's a lot of really talented engineers working there. But a lot of the logic is built using these visual tools. And so the basic idea was what if we build web apps the same way? So the best way of describing it on a technical level is probably that it is in effect a programming language with a building framework. But the biggest difference between like, if you're familiar with Elm, that's actually a really good analogy as a programming language. So Elm was this programming language with a building framework. Its architecture was the inspiration, the Elm architecture was the inspiration for Redux when that came out.

But it was a whole language built just around the idea of building front-end apps. And Nordcraft is actually the same, but instead of the code part, normally when you have a programming language, you have the code that gets passed into an AST, which is this abstract representation of your program. And then that gets compiled to either code or JavaScript or whatever it is, the, the, the engine needs to run it in. Right. And all we did is we sort of cut off the code part and they're saying, what if we just design the big syntax tree of what our program is going to be? And then we store that in a database and then we build an editor for manipulating that tree.

And what that means is a lot of the things, and that editor is where normally a visual program is like a big board of like a million nodes. We have some of that too, but what we've done is saying different problems have different needs in terms of how you build tooling for it. So if you're building UI, obviously the editor is going to look like a UI editor. You're going to drag a some elements and you're going to click them, you're going to apply styling.

And because we wanted to build for professionals very early on, we set on this path of saying, we're not going to try and reinvent new abstractions here. Because that's really hard and usually takes a long time. And there's a reason why we haven't seen new abstractions since probably React or Angular time, right? We all, all the new frameworks are the same abstraction. So we're not going to try and invent a new abstraction. We are just going to create a very nice UI

for working with the web platform, like HTML, CSS, everything you set in our style panel, maps to a CSS property. And we even in our tooltip show you what the CSS property is and what the CSS is going to be rendered is right. Because we want you to have full control. So the HTML you see inside Nordcraft's visual editor is going to be the HTML we render for every component in every page. The CSS you see is the CSS we render, right? We do have some class names, but that's about as...

Other than that, you basically see exactly what it is, right? And then different problems have different solutions. And we have like a workflow editor for like when I click a button, what do I actually want to happen? That becomes almost a flowchart. And it turns out that, and we sort of separated, we made a distinction between like what we call actions, which is I do something that's like I call an API, I update and variable, I trigger an event, those kind of things, right? Things that we in functional programming say have side effects, right? And pure functions. So pure

computation, we call that formula, anything that has a side effects and action. And those are actually two different editors. And that allows us to sort of visually separate the two, which turns out it's really nice because you get the high level structure of what is it this thing does. And then you can dive into the details much easier. So it became it becomes a naturally nice way to organize your code of saying take all the computations and actually hide them initially and just show me what are the steps. And then if I want to dive into why you did that step or why you did that other step, right? Then I can go into that.

And I think that it's not far from how people often organize code anyway, right? But each of those kind of have their own UI. They're a separate problem. Like the editor for doing like pure formulas, like pure computation looks very different than the editor for like doing a flow chart, right? And completely different from any of the UI stuff, right?

When I'm poking around the UI, I see the option to add formulas and variables. Is that what you're talking about when you say flow charts and stuff like that? Like that's pretty interesting because you've got like different types and integers and data coming from different places that connect via nodes. Is that what you're talking about?

So when I say flow charts, I obviously it's a bit abstract concept to apply directly, but I'm mainly referring to what we call the workflows. So if you go, if you select an element, there's like an event tab. So you can say, and there you can, you can click on the click event, for example, right. And that sort of shows up this this dialogue that says, Okay, what do you want to happen when when someone clicks this element, right? And there you can add nodes. And, and that's a different UI looks kind of a little bit like the formula UI, but it's actually tipped on a different axis, to sort of make it distinct. And so we separate like, what is, what do you want to happen when I click, right? Okay, so I want to update this variable, right?

But the value you set on the variable, right, that's probably something you compute most of the time, right? And that computation is a formula. So from in that you open the formula. And by having those two separate, you actually, you get to a point where it's very easy to get a high level overview of what's going on and very easy to then dive in to exactly the point you want. And one of the benefits we see with that is also that when you're working in the same tool, both engineers and designers, designers can sort of opt into how much they want to get into. So like when my co-founder joined the project, he only touched the UI, right?

He didn't touch any of the logic, none of the data fetching, none of that, right? I'm only looking at the UI, I'm styling it, and he was super happy about it, right? And it worked really well because effectively we worked twice as fast as we would normally do because we weren't doing all the UI work twice, right? He would just design directly in Allcraft. I would just actually wire up the functionality. A lot of times I would build it first and not style it at all. Just add like the minimum amount of UI to make it functionally work.

And then he would take over afterwards and actually one shipping it. But as a designer, you can choose, do I care about how the formulas work? Do I care about the workflow? Do I need to know? And initially the answer is probably no. And over time, what we often see is that you can sort of get a high level idea.

Okay, so this is the thing that, you know, this is where it updates the variable. This is the button that eventually fetches the makes us fetch the data from the server, right? That kind of thing. Or you can if you want to go really into like, why is it that decision? Why did it do exactly that thing? Why was this the value that was set? Right. But if you're not a programmer, and you're just coming into this, right, you sort of have

the option of saying like, I don't't really need to deal with that yet. But still get an idea. Well, I also know how the editor opened and I'm clicking around as we talk. It's very interesting. It reminds me of, well, like Pixelmator or Figma with more things in there for like actions, for instance. Is it baked? I mean, is this thing rated rock? more things in there for like actions, for instance.

Is it baked? I mean, is this thing ready to rock? Are people using it? Is it, how long you been working on it? And is it, nothing's done, but is it like the 1.0? Is it ready? It is super ready. We've been, we launched a year and a half ago. And we've got quite a few, like,

obviously we don't have any like massive enterprises that build the whole stack in Nordcraft yet. Right. Because a year and a half is not quite enough for people to discover a tool and then build on it for several years. But we have some really interesting projects that's built in Nordcraft. One of my personal favorites is a guy in Malaysia who built, like he calls it, was essentially a competitor to Shopify. It's not feature complete like Shopify, but in Malaysia, apparently the way Shopify does

card payments means that it's almost impossible to use. So he built like an e-commerce store platform like Shopify in Nordcraft. And it has its own visual editor where you can build your shop, which has a nice sort of inception concept to it. And I think he's already processed like orders for over $10 million in that one stop, like in that project. And I think like on the first day he launched, within the first three days,

he just like processed the first $10,000. So like immediately successful, and he's done a ton with that, right? And we have a couple of projects like that that's really successful. A lot of people are building like hobby projects and interesting things, things for fun to try it out, right? Most of our users are like always on the freemium plan

and just building interesting things. And of course the biggest project, like the whole editor that you're using right now, we're building in Nordcraft as well, right? Gotcha, so it's like self-hosted in that way. What's the language? I mean, you said you created a language and a framework together.

Do you know? I mean, does the, do I, when I learn the language as I build things or what I not have to know? So language in this case, there's not, we haven't given it a name. Okay. Because we don't really refer to it in that way. Okay.

Like it's just the thing underneath that powers the whole thing, right? But you never have to poke on the cover. No, there's no, there's no, we haven't invented a syntax for it. Like the whole thing is just stored as ASTs and JSONs, right? So what about when I'm hooking up my actions?

You know, when you click on this, here's what I wanna do, go hit this API, get the results back, display them in a table. Am I coding in the language then? Or am I clicking on things? What am I doing? I think that's almost a philosophical question, isn't it? Almost is, yeah.

Because especially, I used to say that it's not coding, but it's programming, just because coding for me was like code. Sure. But people use the word code a lot to refer to what they've done in Nordcraft. Yeah. And I mean, I'm not sure it's wrong, right?

But there is no textual representation of it, right? Okay, so I am clicking on things and hooking them together. Yeah. I'm never gonna be like- But so like, again, if you were writing a JavaScript function, right, that says like add two numbers together, right? Yeah What the browser actually does when it sees that initially right it starts passing the actual text and

Then it builds up this tree structure in memory and like the first node is gonna say This is a function node and then it's gonna have some attribute that noted that says the name of it function node. And then it's going to have some attribute that node that says the name of it. Probably whether it's async, I can't remember what the standard AST for JavaScript looks like, but something like that. And then it's going to say, and there's some parameters or argument that's going to be an array. And if you have like numbers as input, it's going to show that you have parameter A that's of type number and parameter B of type number. And then it's going to say, and there's a block, right? So it basically takes your code line for line or like bit for bit and try and represent

as a large tree structure. And every compiler does this. Like that's the passing part, right? And then if you're using Babel, what Babel does is it just applies a bunch of vision transforms on this AST, right? you're using Babel, what Babel does is it just applies a bunch of vision transforms on this AST. If you're doing TypeScript, that's again, TypeScript runs type checking on this data structure so that you can run all these different processes against it.

And then the final bit of that is if your language is a compiled language, it turns that into a bunch of ones and zeros where complex process that I feel like we can leave out of the scope. Also, I don't really know anything about it because I've never built a compiler. Or if it's an interpreter language like this, there's literally a program that goes through that tree and then performs all the different actions that matches what that is. So if you're saying, okay, this node is a function call and this is the name of the function, it's going to go, well, I need to go look at my function stack and find that function and apply it, right? And that's the same thing that we do, right? So the only difference between, like, in this case, Nordcraft, as conceptual as a language,

and any other one, is that we don't start out with text, we cut that off. And this AST that the parser normally generates is actually our source of truth. And that's what we store on our database. And the editor loads that in and has that model in memory when you're working with it. And whenever you edit anything, it goes directly into that AST and say, I'm going to change this property, right? So if you rename a function, it's going to go find that ST and say I'm gonna change the name property so when you're building a formula you are clicking you are saying add an if condition here's a type of variable it's a boolean you're like connecting things together and so

it's very visual even when you're building formula. Formulae, formulas. I'm not sure. Yeah formulas. Or maybe we should do formulae. I think formulae might be the formal way of saying it. I know that because it wasn't homebrew, they have formulae I think. Oh.

I always thought that. Maybe we should stop saying that. Yeah it's kinda cool. Anyways, I do find there's a button down there cause I'm building a formula, a test formula right now. And as a software developer, this is cool, but like at a certain point you're like, I don't wanna click and drag and do stuff necessarily.

And there's a button convert to custom code. And now I'm looking at a JavaScript editor with a function, a JavaScript function. Is this kind of your solution for that situation where you're like, yeah, this thing's limiting me. I need to do something outside of the ordinary and I can bypass the editor. Tell me what's going on here

when I click this convert to custom code. Cause there is a asterisk there about server-side rendering. Yeah. So the whole idea of custom code, we call them custom actions, custom formulas. It's basically that like whenever you're, if you're building a new language, you are missing a lot no matter what you're doing, right?

Like there's a lot of things you can do in Nordcraft without ever touching any code, but not everything. I often use the example of like, I wanted to build something. I often use the example of like, uh, I wanted to, I wanted to build something that I could use, uh, I wanted to tie the Bluetooth API, right? And so I made an, uh, a simple example where I could use a PlayStation controller to browse a website. And I, that Bluetooth was not very high on our priority list of things that

Northcraft needed to do because I've never actually used before in my 20 years. To be fair, it hasn't been there for 20 years, right? But it's not the most used web API, right? But you might still need it for your app, right? It might be that the thing you're building needs Bluetooth connectivity, right? And so there always has to be a way to solve your problems. And the way every programming language ever, I think, has done this is through a foreign function interface. So like, when Node came out, it could do a lot of things, but like most of the libraries were just bindings to C, right? It was just here is the JavaScript interface, I'm actually calling some C code underneath, right? And for a long time, over time, it kind of changed and a lot of things actually got written in JavaScript and it stayed within

the same ecosystem. But initially, it was all a different language and it was just an interface for it. And that's the same thing we've done here saying, well, if you want to like add an API, add, do something that NordCraft can't do yet, right? You can create this custom action and it's essentially a foreign interface. You go and say, well, the action is going to take this kind of input. It can emit some events back and whatever it does in between, that's entirely up to you. You can write whatever code you want.

And it allows you to say, it allows us to fix to say there is no limit like even if you hit a really weird edge case that your app needs to do well that's possible right if you want to bring in a third-party library that does like a weird graph rendering things because someone made that and you you want to use that or if like if you really want to use AG grid right you can use AG grid right you just go and say I'm gonna define in Nordcraft and saying this div is where Nordcraft, just like you were doing React, right? This is the div where Nordcraft stops

touching the content inside, and then I'm gonna use JavaScript to render the rest, right? And that's perfectly possible, right? And you just build an interface so that you can work with that inside of Nordcraft. Like, and this is not us coming up with something fantastically new. This is the same thing React does whenever you're like opting out of React for rendering.

Right. And it's the same thing every program's language has done for like for an interface. There are also cases where it's just like we ran into an example. The other day was like a markdown parser. Well, like, yeah, I mean, just, just, just use the JavaScript one. And we had an engineer who definitely felt like he wanted to build it natively into Nordcraft. Um, but it's like, yeah, it's not a great tool for building like a markdown parser.

That's not the point, right? It that's JavaScript can do that just fine. But when you're building Nordcraft with Nordcraft, do you find yourself ejecting often the way that you guys have set this up or not very often? Ironically, almost never. Almost never? Like if you look at the project,

and we're in the process of taking it open source, so in the coming weeks, we're gonna open up the editor project so anyone can dive in and see how we build it. And at the end of the day, there's a lot of custom code, but almost all of it is because we made it before, like in, in like maybe a couple of years ago before North craft could actually do that thing. Right.

Um, so there's, there's really not a lot, um, of times it's quite rare. We go in and do that. Like, um, the most recent example I had is like with, we rebuilt our whole style panel. And because we want to support like the full CSS spec. So even if we don't have a UI for a specific type of style, you can still pop into this CSS panel on the side where you can go and look the actual CSS, right? And you can write CSS in there.

And we want to support you doing that, right? Whatever it is. But that also means we actually have to pass all that CSS so we can figure out how to properly render it in the style panel. And so we had to sort of build one, sort of half open source, half build ourself, pass. And that was like a classic example of like, yeah, you can definitely do that better on code, right? Um, that's, that's not what an old craft is built for at all, but it is quite rare, most things it just, it's just easier and works better to build it directly in old craft.

It's interesting to build inside of itself. How does it work? Like it's, um, I mean, it's a nice experience now, but, um, I started doing that before we had version control. That meant if you made a mistake, you broke the tool you're going to use to fix it. So I had a few times where I had to like check out Jason from a big Jason tree from the database and trans so it trying to figure out what did I do? How do I fix this?

Right. So you're literally building the engine inside of Nordcraft. Is that what I'm hearing? What part are you building? Inside the editors, just the editors. So the visual UI, all the UI you see is being built with Nordcraft. Yeah. Okay.

So the, the runtime, as we call it, the one that actually executes and renders like HTML and CSS into the browser, that is built in TypeScript. And that is all open sourcing. You can see it on our GitHub repo. And you're in the process of open sourcing more things, or everything, more things?

So the, yes. So we of open sourcing more things or everything, more things. So the, yes. So we've open sourced the runtime and a bunch of sort of utility functions and a few examples that basically allows you to run your whole application. Like anything you build in Northcliff, you can run it by yourself on your own infrastructure, right? And when you do that, all our code is like, what is the GPO? And your investors like this?

They were actually fine with it. They didn't have a problem. I mean, obviously I had built a story before I went to them. What was the story? Tell us the story. So the basic story was saying like, there is no... Like we're not going to... We never thought we were going to build a big company

out of the no code community, right? Because first of all, it's not nearly as big as the developer community. And it's per definition never going to be big enterprise customers, right? Because that's the big one. So if we want to take this thing where we think we can go, we need to get developers on board, right? Cause that's, that's the big one. So if we want to take this thing where we, where we think we can go, we need to get developers on board, right? And we had some and they were interested in all of them were asking. So is this going to be open source?

Right. And basically saying if we, if we want companies to trust us with the kind of projects they're building in that size, we got to show them something, right? We got to say, well, actually, we're not going to like rock pull you halfway through and say, ah-ha, surprise. Now it's going to be twice as expensive. Lock-in is something that we're all

thinking about and if you want to build something serious on top of there, even your, your user in Malaysia, who's got now a platform that he's making money off of and he needs some assurances that that's not going to dramatically change or somehow lock him out or whatever it happens. Having open source is peace of mind, right?

Exactly, right. And I mean, personally, I'm not sure I would, like I would have that in mind. I would never, there's a limit to what I would build in a platform that literally, cause it's not just that like it's some of it, there's a limit to what I would build in a platform that literally, because it's not just that like it's some of it, it's like all of it, right? Because literally you hold up that you're building. So if you don't have options, right, that would worry me. And I think it worries other people in the same way.

But we didn't build like that from day one, mainly because, well, my experience and my understanding was that open source doesn't necessarily make you go faster. No, not necessarily. And especially the early days we wanted to go fast. So we didn't want open source there. We already had in mind that this was going to be something we would do. It wasn't something that came up a lot in the early days from users. So therefore we was like, okay, we're going to keep it close and we're going to keep going.

And now there's a bit of a process in sort of separating first what is the platform code? That's our hosting code and that part of the platform that's related to our hosting service and the actual editor. Right. So we need to separate those two apart. And we also need to sort of have a open source backend for it. Right. And that's not going to be a hundred percent the same as the one we have that's custom

built for Cloudflare at the moment. Right. That all makes sense. It's for web apps. Is it bad for websites or just not built with that in mind? Is it just as good of a choice or is web flow the way to go? I think the, the, I mean, almost every time when people ask what should I use it for, I say that the answer is the same as you would say for React.

I think that for websites, we might have a little bit of a leg up because like it's quite easy to build a website. Like React is a lot overkill and so is Nordcraft. But you don't really get, you don't experience the overkill. Like the extra stuff in Nordcraft, you're building a website, right? It's kind of like building a web flow. So it totally works for websites, but you have options. Like there's a lot of other tools that can do websites. As well as Oswain.

Where it begins to change and where we really sort of land as being There's a lot of other tools that can do websites as well as us. Where it begins to change and where we really sort of land as being our sweet spot is when you start pulling in data from different data sources or backends, start making it more like interactive and dynamic. Well friends, it's all about faster builds. Teams with faster builds ship faster and win over the competition. It's just science. And I'm here with Kyle Galbraith, co-founder and CEO of Depot. Okay, so Kyle, based on the premise that most teams want faster builds, that's probably

a truth. If they're using CI providers for their stock configuration or GitHub actions, are they wrong? Are they not getting the fastest builds possible? I would take it a step further and say if you're using any CI provider with just the basic things that they give you, which is if you think about a CI provider, it is in essence a lowest common denominator generic VM. And then you're left to your own devices to essentially configure that VM and configure your build pipeline.

Effectively pushing down to you, the developer, the responsibility of optimizing and making those builds fast. Making them fast, making them secure, making them cost effective, like all pushed down to you. The problem with modern day CI providers is there's still a set of features and a set of capabilities that a CI provider could give a developer that makes their builds more performant out of the box, makes their builds more cost effective out of the box and more secure out of the box.

I think a lot of folks adopt GitHub Actions for its ease of implementation and being close to where their source code already lives inside of GitHub. And they do care about build performance and they do put in the work to optimize those builds. But fundamentally, CI providers today don't prioritize performance.

Performance is not a top-level entity inside of generic CI providers. Yes. Okay, okay friends. Save your time, get faster builds with Depot, Docker builds, faster GitHub action runners, and distributed remote caching for Bazel, Go, Gradle, Turbo repo, and more. Depot is on a mission to give you back your dev time and help you get faster build times with a one line code change. Learn more at depot.dev.

Get started with a seven day free trial. No credit card required. Again, depot.dev. What about things like authentication, you know, authorization, when you get into this and you're like, how does, I know it's an editor at this point, it's a visual interface to it,

but how do you, is that simply just part of the programmatic ways it has behind the scenes? You can enable that. How do you work that kind of stuff in? So because most of authentication is a backend issue, we don't handle most of it. We don't have a backend. We just work with whatever your backend is, whether you coded your own or whether you use like super base directly as a backend or whatever

you're going. There's also some like Sano is one that more low code, no code style backend works really well with that as well. So I mean, from our point of view, again, we're front end. So we're just doing HTTP requests to a server, right? And so what we've done around authentication is what matters for us is how we store the token in essence. Whatever strategy you have authentication is possible.

What we sort of nudge people towards is storing your token in a HTTP-only cookie right? Because that's generally the most secure way of handling it. And what we've done is we have a API proxy. So whenever you have an API from the front end, if you run it through our proxy, we can actually authenticate that request. So if you, let's say you need to send an authorization header with your user token to an API.

That's the most common approach, right? Well, you can actually set up, well, that's what I want to send. And you don't actually have the token on the client because that's stored in ACP only cookie from when you authenticated. But we actually put that token in before that request goes to the server.

And that way, even if you have some script injection attacks, et cetera, they can't actually steal your token, right? That's not gonna fit for everyone. Sometimes if you wanna do like, especially if you're doing like real time web sockets and stuff, that's not always an option. And you do need to have the token on the client. So there are like, you can,

whatever your authentication strategy is, is possible. And it sort of speaks to the general approach. whatever your authentication strategy is, is possible. And that sort of speaks to the general approach. I sometimes say we didn't really invent that much. And by that I mean, almost everything works the way you would expect it if you stop looking at it as a visual tool and start looking at it as a JavaScript framework. So when people ask, how do you do

authentication react? It's sort of almost a half abstract question, right. Because it's like, well, however you like. And similar, like how do you, how do you, how do you store things on the client? Well, there's local stores, there's session stores, there's indexedDB. There's all these options. It, it, cause it's the web browser, right? And we are a framework and we just build visual tools on top of that. But we didn't invent whole new abstracts, right? The web's pretty good, like the HTML, CSS, it's the best we've come up with yet, I think. So we're not reinventing it. Obviously, it's not running JavaScript, but it's very much stealing everything it can in terms of function names and making sure that everything is very familiar to someone

coming from that world. And again, all the browser APIs, they're the same. No need to install modules and bundles and things like that. Well, there's always a question of like, how much do you want to build yourself and how much do you want to use other people's code? Right? So we have packages is what we call them. Um, and you can install them and basically, so, so by default, when you open Nordcraft, like, um,

I think people are often surprised that there's nothing there in terms of like pre-built stuff for you, right? Like, so, so if you open it up, like what can you add to your page? Well, you can add a header tag or a H1, or you can add a button or links. All those great HTML elements you can add. But there's no tabs. There's no complex media player or carousel. You can install those as packages, just like you would do in any any framework, right? But that's not a built-in feature, right? You can build them yourself or you can use something made from the community, right? What is deployment like then? I suppose if it's the visual side like is it it's not host

I'm still trying to figure out like it what exactly Where it lives I suppose, you know like what? Tell me more. I don't know how to ask this question, but like, are you deploying something? Is it living somewhere? I know you said you mentioned ASTs in your database, but how does this application, how do you say deploy this,

whatever this is, or is it always deployed? It is always deployed. So you're live in production when you're, when you're building or staging. So how, how, how detailed do you want to go? As deep as you want. Okay. So, so there's basically two, I would say if a developer is thinking like, okay,

I get it, Adam doesn't, but I get it. React, but different. Take us there. Like what would a developer want? Okay. Well, we're dipping a bit into the developer space then. Take us there. Like what would a developer want? Okay. Well, we're dipping a bit into the developer space then. Um, so the, we build this, uh, our version, our hosting platform on top of CloudFlare because CloudFlare kind of uniquely has a bunch of

services that are very interesting for us. Um, one of them is something called durable objects. And what a durable object is, is essentially a serverless worker with state. And so you can basically save things in memory and it'll still be there next time you ask it. And it has this weird prophecy where there can only be one instance of it deployed worldwide at the same time. And that is for most things really bad, right? Because it doesn't scale.

But it is essentially how we kind of treat it like a shared file system. So whenever you create a branch and we have version control, that's, that's, it's not technically good, but like it's, we copied this as much as we could. So whenever you create a new branch, each branch has its own be good. So whenever you create a new branch, each branch has its own durable object associated with it. And the way these work, which is quite cool, is that they are always close to you. So if I connect to a branch, that durable object is going to be in a data center near me, whatever closest to me. From Cloudflare has like 250 or something like that. If you connect to the same branch, it's gonna, or if you connect to the same branch later,

it's gonna move that instance closer to you to make sure you have better read-write performance. But there's always gonna be only one. So whenever I'm working on a branch and I'm updating my data and sending that to the doable object, that instance always has the latest version of my project for that branch. So whenever I go and say, actually, I want to preview this one. I want to see what it is live. Whenever I open that, it connects to the same instance when you're on a branch when

it's not deployed. So in real time, you can always see what is there, right? Because the second I make a change that actually gets sent takes about seven to 16 milliseconds, right? And then that's saved and then your application will see that. So like branch deployment, those live free environments, that is with below 100 milliseconds from iMegaSaved to UCLive. For the actual main, we don't do this because it's actually a good thing to have a lot of different instances all over the world for that. So there we are, we are just, we have the main version of that project and that we use as their cache infrastructure to make sure that every single data center has a version of that. And we are rendering like whenever you make a request to a page, we are rendering that whole page based on our code. And we actually looked into caching. And the funny thing is, it didn't do much because it renders really quickly on this worker. So

actually caching the final page for a static page didn't make it faster. Maybe on average, like for a static page didn't make it faster. Maybe on average like three or four milliseconds, but it really didn't change much. When you start adding data, then like when that page needs data in order to render, obviously there's a different question. Right. Does that answer it? Does that make sense?

It does. Yeah. But even our deployment is just saying, like all we're really doing is saying this version that we have, It does, yeah. But even our deployment, even our deployment is just saying, like all we're really doing is saying, this version that we have in our, that we have in the database, that is now the live version.

So we are moving a pointer for when we're deploying. So like deployments happen really fast as well. How are you approaching education? We hired a really great person for education, common friend I believe, to help us with that. Salma, hello Naila. That's her role. Yeah. Okay.

Is our head of education. So education is a big part of this, right? Because even though a lot of this is actually familiar to developers, once you get past the interface, right, right, you kind of have like there is a little bit where it has to click. We've seen a lot of people where they have like, how do I submit a form? And like, it's a form, right? You, you know, how to submit a form, you just have to see that because the visual interface, you thought there was all sorts of other things, but it's, it's the same way you think,

right? There's a button inside, click the button, submit the form. Right. So there's, there's those kind of things that that that people often a little bit have to get over. But after that, it actually is very familiar. If you've used the framework before, right. But that being said, education is still a big part of it because it is conceptually a new thing. Even the tools it looks like, it isn't quite that and you want to think about it a little bit different.

So it's something we put a lot of focus on and effort into, both as a sort of how do we how do we approach it. We just worked with an agency with this. It's a Nordcraft only agency, they only work in Nordcraft, because they're kind of picky. And like we don't want to do projects that are in Nordcraft. So they're very focused on it. We just work with them. And they actually helped us rebuild our whole documentation side and as well as a lot of the technical documentation because they are incredibly good at it.

Like they really understand the platform. Right. Um, and, and I think that it's, if you're looking into Nord Graph, go and check out the documentation. It's, it's some of the best I've seen, uh, as a high level attention detail. They did a fantastic job on this one. But also a lot of video content, a lot of sort of trying to, how do we, how do we try different medias figure out what people learn? We also have these challenges we added when you first sign

up and the basic idea is I kind of hate these like step-by-step tutorial where it's just move the mouse to the right and click the button. Okay Yeah Right. So we wanted something a little bit more fun But that still kind of held your hand and so our approach is challenges where it kind of sets your challenge like you're gonna build a weather app and you need to add an API fetch some weather data and you need to add all that data to your UI and this and this and this, right? And it kind of has, it shows you the steps.

There's always a chance of it showing you, but it kind of like lets you try first and saying, you know, give it a shot. And then if you're not sure, come back. Right. So we're trying a lot of different things to sort of figure out what is it that kind of gets people to get it the fastest. I noticed in your welcome email, you allow people to book a personalized onboarding session, which reminded me of, I think, Paul Graham's essay, Do Things That Don't Scale, something

in this one's not going gonna scale as you get popular. Is that with yourself, is that with Salma, is that with your co-founder? No, it's literally with me, and the thing is, the worst thing is, I think it might scale. Because no one clicks it or what? Because I don't get a lot. And it's one of my favorite things,

obviously at some point we can't do that, and it's probably not that far away. Like it is, but I think I have two a week of like 15 minute calls. It's not that bad. And it's not because there aren't people, it's just, I think just this idea of like, for some people it's a little bit, I don't know, right. Developers aren't booking calls for new tools, right? That's, that's similar.

So, so we had it in because if someone want to do that, generally it's been a good thing. Right. But actually it's not like, yeah, we don't get a lot of people doing it. Most people very much prefer learning on their own. We have a Discord server. We really recommend everyone going there because it's such a great place to get help. And it's a fantastic community. But there's also a lot of people who don't want to join a Discord server for a new tool, right? They want to see it first and figure it out and then we'll see

about community afterwards, right? That's fair enough. Well, it's a cool tool. I mean, I'm impressed. Very polished. It seems like you've thought through a lot of the things that would stop me as a developer from using something like this, such as a way of ejecting, such as a way of self-hosting. You're obviously getting there in case, you know, Andreas and Co. no longer exist or get sold or whatever, and things change. Or get really greedy.

I mean, there's always options to say, we just want more money, right? So. Yeah, or you get greedy. Yeah. Yeah, what's the cost right now right now how does it work what's the pricing look like today so we think it's very reasonable you can build like a lot for free the only time we really start charging you is well so by default we call it the open source plan and basis if you're doing a public project that anyone can see and clone then you don't have to

pay for it. As long as we have some traffic limits, etc. If you want a custom domain for your application because you're starting to brand it, or if you want it to be a private app that other people can't see because maybe you don't want to build an open source product, right? That's fine. Then you need to go on a paid plan. And they start at 36 for monthly, dollars per month per developer.

And then once you move up to a scale up plan, which is either when you sort of move past the traffic limitations or lower, or you get more than three seats, then it's a $100 per seat. And is that like collaborative? I guess we didn't talk about collaboration at all, but I assume those seats are like as multiplayer,

like you can be in the same thing, doing different stuff, seeing each other move around. You can do that. I would say that generally doesn't work as well as people think, because being in the same branch, like it's kind of like being in the same branch in GitHub, right? It's rare that really that's how you want to work. You generally want to work in separate branches.

So you can, you can absolutely say in the way this works, like if you go into the same branch, you'll see the update someone else makes almost as fast as they do, right? As long as assuming you're in a similar location. But most of the time people work async, right? So we just like in Git, we check out our own branch. That's what we're working on. When we're done doing what we're doing, we will commit that branch and publish it.

If someone else did that, since we are merging their changes and our changes. We can see what we're doing. And again, the workflow is exactly like if you're working in a code base with Git. The big difference is that the way we actually diff the projects, because there's no code, therefore there's technically no Git because that's file-based. So we had to change some of the implementation details, but the process and the workflows are the same Cool stuff Adam any other questions for Andreas before we let him go. I don't think so. I don't think so. I'm excited about it. I think You're on something good here. Don't stop. We want we are we are gonna keep going because Excitement only building we've got some really cool things coming. One thing I'm really excited about is that one of our engineers has been working on

an animation editor. I've always felt like animations on the web, we really technically had the tools for doing great animations for like a decade. right? Like keyframe animations, you can do a lot just with keyframe animations and transitions. They're quite powerful. But if you go and look at people's like web apps, especially SaaS apps, they're all super static, right? They're all kind of boring. And part of it is that while we've had the tools

like finally adjusting a keyframe animations in CSS, it's pretty painful, right? I guess I have to go and say, oh, actually, the timing is a bit off, so now I need to go and move keyframe number three. Am I gonna move that 2% or 3%? Let's see, and then I go back and then, you know, I'm waiting for live reload.

Like that kind of work, like adjusting animation to feel nice, that is fine tuning work. And code is not great for that because the feedback cycles are slow, right? So one of the really nice things is that once you have a visual tool with a fast upload, you can start actually building like an animation key frame editor

and you can visualize your keyframes like as in the good old Flash stage, right? We lost something with that when the wait, we also gained something. But like you can start adding in those kind of keyframes and actually really animate every aspect of something and adjust them and fine tune them. And that, I mean, it's the same thing we're seeing now, just something like a gradient in it. It's just having a gradient in it means that you will actually use gradients because right. Nobody knows how to type gradients into CSS. You forget it the second you've done it, right? Totally. Having a tool for those kind of things means that you actually use them. And it

means that the results, the output actually gets like more interesting and more sort of delightful. I think it's the worst that comes. So I'm really excited about the animation. It's a, I, I, he's done such an incredible job and, uh, we're going to have a ton of content and tutorials and stuff coming out when that launches. How do you know you're on the right track? Like what is the feedback loop?

I know you mentioned, um, the, the other project, how they're doing some cool stuff. I didn't hear a big name yet necessarily. How do you know you're approaching or near product market fit? What is that for you? So product, the hardest part of the product market fit is actually for us, because I think we have what we call a product customer fit. Our customers really love it. They go and make videos about how much they enjoy this. They go and talk about it. Sometimes, like ad nauseam to other people and we get complained about people

going like, look, we get it. He likes your tool, but like, you know, can we talk about something else sometimes, right? So I had a call with someone from an agency that's like, I kind of just took this because he wouldn't shut up about it. Okay, fair enough. Maybe they'll try it, maybe they'll like it, right? So we have a very strong fit. The number one guiding thing for me is that

we are working in this tool every single day, like the whole team. Obviously, some of our engineers are working on the backend and different aspects and we write code as well as part of it. But the vast majority of the work we do every day in the whole team is inside this tool. Because we're still a small team, we're only 10 people at the moment, right, building this thing. Because we're a small team, it's a very advanced, very experienced team. These are people who've been building, I think our most junior has been doing it for 10 years. Most juniors, the wrong way of phrasing it. But these are people

who've been doing this for like a long time and they know how to build these things. They are exactly the style of users we're looking for as well. And like, we know how this works. We dogfood, as you say, every single day. And once you get to that bit where it clicks and you start working with other people and you figure out how all these things work, that dynamic of designer and developer working together, the idea of letting go of that afterwards, that feels awful. The idea of me going back to having a design handoff with a Figma design that I had to go and replicate. I mean, that feels so backwards right now. And personally, for me, like I have like a couple of hundred

apps now of projects I've built in Nordcraft because every time I have a new idea, that's always going to be my go-to. Not just because I start a company, but because it's just so much easier to get started. It's so much easier to get your ideas out. It's so much easier to build UI visually than it is to sit and write code. A lot of the other bit, I find that most people I talk to, because it is a big sell, it is a big difference, a big shift compared to what people are used to. It is quite a radical idea. Even though, again, when you think of the development like gaming and stuff, it probably shouldn't be so radical,

but it is a big shift. And it took me two years to convince myself it was a good idea. Like I didn't believe in it for the longest time. I've been the hardest one to convince because why wasn't it done? What was I missing? What was the thing like, okay, it looks fine now, but what about six months down the line, right? Is it still

going to be good? And that was the motivation for starting to rebuild the editor in itself is because I needed a project that was big enough that I got that feel of like, what is it like at scale? And now understanding obviously 10 people you can defy, you can debate whether that's scale, right? But it's enough to give you the right idea. And now building this tool, like, if we did that in anything else, like I think doing that in React would slow us down a lot. Like that we wouldn't be able to move at the same speed at all because like just the fact that two of our two out of our 10 team members wouldn't be contributing directly, but just feeding in designs, right?

Well, that's like a lot already. So I mean, our whole team, we're using it, we're building all sorts of stuff in it, we're constantly jumping. We also know all the bad parts, all the things that aren't as good. Like there's always, this thing is not as good as I want it to be. Or this thing annoys me. But, you know, we'll see when we get to fix it. We also get to feel all the bad parts way earlier than anybody else. Right.

But like really being inside the project, having it be your daily driver for everything you do, it gives you a very good idea of what it's capable of. I'm thinking I'm just kind of camping out on like this transitional period. So you got this, you know, very uphill battle when it comes to marketing. Like that's what Jared asked about education, because he's like, how do you know, how do you, how do you convince people they should make this change that they have a problem? We all know there's a

we just defined the problem, like your co founder had the problem, I had the problem, you've had the problem in the past of like designers and developers working in the same tool and not double working or having this scenario. But I'm just thinking like how, not an hour, I'm certainly not an hour today, but who are you, like who was coming into this thing initially?

Is it developers? Cause you've spoken about this allergy of no code and things like that so who is it that's coming in or seeing the the the light so to speak this aha moment that You know is the early adopter. It's a good question and this is split like there's not a one clear Good question. And this is split. There's not a one clear. Most people come in, like when we ask them, what do you identify as? Are you a developer, designer or something else? Right? Most say developer. And then that's like half around, around half. And then there's a 50-50 split between designer and none of the above. One of the things that's

really interesting is that I think there's more to win as a designer early on, right? Because as a developer, what we're basically saying is this is a slightly nicer way of working and you probably work a little bit faster, right? And also if you, like again, a big part of the value prop is the fact that building UI is very valuable in a visual environment. I think the logic itself, the reason why that's visual programming is not necessarily because

there's anything wrong with code. It's just because context switching quickly gets annoying. My initial draft, all the logic was done with code and only the UI was built visually. And then I sort of realized that like, okay, but if I'm just like binding a value to an attribute here, it's kind of annoying having to switch to coded it's to do that. Why can't I just do it right there? And then over time that kind of kept growing into a point where saying, actually, I kind of want the full power of a program language without having

to context switch out of the app to a code block somewhere. But that wasn't really the point. The point was building UI. And that's where I think most of the value still is. And for that reason, as a designer, you go from, I make a Figma design, or maybe I can make a Webflow site, to I can actually build an app. I can make a web flow site to I can actually build an app, right? I can build probably a symbol to start with app, right? So that's a massive value change in what you can certainly do. For developers, it's a little bit less because you could always like anything you can build in OrgCraft, you could probably already build the same thing. But at the same time, the barrier of injury is lower. It's easier for developers to understand because what we see people who don't come from a developer

background, it's not necessarily that they have a hard time using the tool. It's that they hit those developer problems of saying, well, I don't actually know how to solve this problem. And it wouldn't really matter whether it was like what the medium was. It's just how do you solve the problem? Right? How do you I have a let's say I have an array of 25 likes and I need to figure out if I like this post. So you have to search through that list of likes to figure out the one that you made, right? Okay, is that how how do I do that? And the answer is like abstractly the same whether you're doing it in Northcraft or JavaScript.

But if you've never done either, right? That doesn't help. Certainly seems like a big win for designers who are consistently interfacing with their developers, building applications, not obviously building out other things that are not applications because that's what this is for. Because you don't have the risk of your research and your baby and all your work not getting translated well.

And you get to work directly in a tool that is essentially as real time as real time can be to your production interface. and you get to work directly in a tool that is essentially as real time as real time can be to your production interface. You can branch, you could do all these fun things and you don't have to double the work. Your team doesn't have to do double the work. So from a business standpoint, it's like, well, we could save a lot of money.

And the tool is actually, the one tool is the one tool. It's not this tool and that tool and some sort of translation period. It's not this tool and that tool and some sort of translation period. It's in this static design pixel-perfect world that has to get translated. So it sounds like designers are probably your first customers and developers, engineers following suit because they're being pulled.

Maybe happily, I'm not sure. I'm not sure. Whenever we talk to companies, that's how we go about it, right? We're saying this is a tool for your designers that brings your developers in. And that's very much our strategy. Of course, when it's just people trying it out, people come in for whatever that interests them. Yeah.

But one of the interesting thing about the design profession is that, as I said, well, with frameworks, we definitely push them out of the browser, right? design profession is that, as I said, with frameworks, we definitely push them out of the browser. They're not working that anymore, but we pigeonhole designers a little bit. I think design tools are maybe a bit to blame as well, because we have UI UX designers working in Figma, but you cannot do UX design in Figma. There's nothing for you there. It makes like it can do a semi responsive website. But what about keyboard interaction, right? Like those things have to be designed.

What about like, there's so many aspects of UX, which is until you touch and feel the application, that is the user experience. Like, so, so we've kind of cut a lot of that roll off and say, actually, so today in a standard dev team, developers, front end developers, does more UX than UX designers, because they're the one who actually hands on, right? I remember talking to my partner and saying like, I talked to him about tabindex,

and he's like, what is tabindex? Because I mean, he didn't know, right? And it's the, well, that's basically how you decide what order you're going to go through the interface when you press the tab key, right? And which things can be focused, which thing can't. That is a big part of UX, but there's none of that in Figma, right? And I would probably guess that a lot of especially younger UX designers today have no idea. Mm-hmm. Because they don't have the tools to work with that, right?

By the time that becomes relevant, that is way into the developer domain, right? You also get to fast forward a lot, too, because you make, I've made, design choices that were incorrect and it was evident immediately as soon as you use the real application. It's like, oh my gosh, like we actually implemented

the way I wanted to, but it wasn't, what I designed was static, it wasn't really usable or in modern tooling you can do a lot of this step through something like that, but you can sort of define some of the UX, but not all of it. And so until you see the real thing and the real thing, you're kind of making some educated guesses

and hoping that your selections are right. And they weren't so wrong that you got to do a bunch of rework. Yeah. And we actually usually do what we sort of dubbed jokingly, the reverse handoff, which a lot of times I will build something hideous. And we actually almost made a sport out of making UI that's as ugly as possible before

we handed off to designer. Because then the designer would actually do the UI, right? We just technically needed to get the data on the screen. Because that when they're designing, they're designing with real data, real application right there. Like everything they're designing, they're designing with real data, real application right there. Everything they're doing. And I mean, they'll be rearranging the stuff around and making sure there's layout, everything. But it's the real app. And the funny thing is when we talk responsive design, we always talk about changing the width of the browser. But there's a lot more to it,

because the content changes, right? So everyone, every developer has at some point received the design that looked great. And then come back and say, what do I do when the title is 120 characters? And then it's like, well, then actually, unfortunately, the whole design falls apart because it can't break line, there's not enough room and it can't overflow. And do we do a tool tip? Like these kinds of things. What happens when there are no tags on this element? Because then it just leaves this massive white space in the middle.

All the two nodes, like all these things will, will design change based on data when you're building dynamic applications. So if you can't see the data, you don't know the cases. Right. And that's why we have these sort of like back and forth in our teams all the time. We're like, well, what about this case?

Right. Well, this has certainly been probably the most expensive part of most build outs in the history of development is the glue between design and dev and implementation, front and back end, like all the seams, where we come together and collaborate, it always gets very expensive. And you can save a lot of money if you have teams that are good at collaborating

around those things and catching stuff early. But that takes time and experience. And so having a tool where you can meet in the middle, develop in the middle and design in the middle and get that quick feedback certainly I think needs to exist. So I'm excited that y'all are building one and that it's gonna be open source

and that it's polished and ready to be used. So I'm gonna give this thing a shot. I'm gonna try to build a really ugly UI. I'm going to try to build a really ugly UI and then pass it to Adam and see if he can make it look better. Yeah. I mean, I find that all the named HTML colors are really good in this case. Like there's a lot of, yeah, there's a lot of good ones there. You don't need to go into any of this hex business. Just pick one that has a name. That's kind of the best ones. That's my strategy before I hand off to a designer.

This hex business. That's what it is. Yeah. Very cool. Andreas, thanks for sharing with us, man. Well, thank you very much for having me. It's been a pleasure. I've been listening to the show for so long.

So it's really exciting to be on it. Very cool. Glad to have you here. Absolutely. So I love the idea of this gaming engine, this web dev engine for developers. Having been in the trenches, in design to dev workflows for many, many times,

many, many years with very mixed results. It's just refreshing to see a team like this approach such a big ambitious goal. And they're doing it. Check them out, Nordcraft.com if you haven't already. Big thanks to our friends over at Heroku for sponsoring this show. Our friends over at Depot, Depot.dev.

Check them out. And of course, our friends over at depo, depo.dev, check them out. And of course our friends at fly.io. And to the beat freak in residence, break, master, cylinder, those banging beats, love those beats. Okay, show's done, we'll see you on Friday. So Thanks for watching!