Why are we boring? Open Office Hours - With Ray Deck (LIVE) - Episode 3

Hello, we are here. Thank you, Ray, for being here, and thank you for all of you for watching this amazing podcast or vidcast or whatever it is we're doing. Apparently we're too boring though, and we may need to change this up a little bit.

Yeah, well, you know, whatever. Max Weber said that the only things— anything matters happens is through the slow boring of hardboards.

There you go. You want to look at the comment we got last time?

Yeah. Let's look at that. That was a good one. I'm actually very grateful for it.

I am too. We got to go more with the vibe, like live coding. But I'm also behind a cubicle here because we're doing boring stuff. But let's take a look at the comment here. It's on your YouTube channel, KingKong007. Said, I think you guys both would have so, so much more success if you would attack no-code from a non-developer standpoint. 90% of no-code users are not technical, and even more have no understanding of product development. We don't care about component events. We just want to build our MVPs. Okay, no, this is kind of like a shot against me. I like component events. The title versus WeWeb argument you present provides zero value. The fact that we can express what we want using AI is powerful to the 90%. Think more like the 90% and watch your channel. You want to talk about that or you want to also read the reply from someone else under there?

I think the debate is what makes this really interesting. Let's put Lucas conversation.

Okay, let's bring Lucas in there. By the way, shout out to Lucas. He's also a No-Code Pro Code member. So thank you so much for stepping in here. I think, Ray, you're a little bit in the view here. Let's see if I can move you to the side here. Let's see, can I move you somewhere?

I think I can make out the words, which says, you've got it wrong.

You've got it wrong, mate. This content isn't for the no-code or AI will do everything for me crowd. These guys specialize in visual development and front-end, back-end skill acquisition. Now that's the debate. Now where are we going in?

Yeah, you know, I, I, I would, um, first of all, I'm super grateful for, for both these comments because I think that that kind of gets to a lot of what we, what, what, what, what we think matters, right, in this, uh, in this industry.

And also means we're getting views.

Their views. And even controversy creates views, right? So the controversy itself is useful.

I'm a master at that.

But yeah, that's a fair point. But I think there's— I would take issue. I mean, first of all, I think the point of be more accessible is a point well taken and something we should work on. But I would take issue with the idea that like, 90% of users are not technical. I would say 90% of no-code users probably don't have a background in software development, but I can't tell you how many people I talk to in like who are, who are adopting, you know, low-code or, or getting into building AI agents or what have you, who describe themselves as having done code usually like back when they were in school, right? They're a bit into their career. They haven't been using code directly for the stuff they've been doing lately. They're usually some kind of intellectual, you know, either, paperwork or managerial professional type person. They have this idea that they should be able to do this with code, or they should be able to build an app, build technology, and they're not totally afraid of the code. This idea, you can do this without writing a line of code. I'm not sure that's really what they're looking for. They're looking just to be able to create. I think that was probably more true of people who are picking up you know, low-code, no-code, say 4 years ago than it is today. Because there's just, because we sort of look backwards or there's this rolling, you know, computer science and like coding becomes more like part of our general education. But the idea is like, hey, you almost remember that stuff, but you don't quite know how to make it work. And that's really the promise of the tech is that like, it sort of helps you cross that bridge, right? That you don't need to remember how to do a for loop or how to do if or what have you, but You remember there's something like branching and then there's looping and whatever, and those ideas aren't super alien. AI can help you with that.

You know about the concepts and you don't necessarily know how to apply them.

Yeah, it's the arcana of the language itself that I think is where people get more difficult. I think that's something that's more true today than it was a few years ago. But also changes the kinds of tools that are valuable and the way that we use them.

The only code I can write without having some AI or Stack Overflow help is an if statement. I know how to put it together and how it needs to work and that I need to do a loop, but I never remember the syntax. Do I now need to do like, I don't know, where to put the space and I don't know. Also filter in JavaScript, I'll always get the syntax wrong. I get close. I'm like 80% there, but I'm like, oh no, actually it needs to be, I forgot the equals or whatever.

Which is the one, which is the negative one, right?

Yeah.

Those little details are things that the AI can really help with and things that the no-code tools can also filter out a bit to make more explicit how this stuff works and be able to make that work better for you. But the idea of what they want to create is pretty good. What I have also found working with a, whatever, hundreds of builders at this point, maybe thousands at this point, is that they— is it's always like at the complicated parts where things go off the rails. So like a discussion of the basics isn't as helpful, I find. It's gonna be about where are people more likely to get stuck and how can you sort of either avoid getting stuck or have some mental models that will let you get ahead of it.

Yeah.

So that's what we can do with this, right? So simultaneously talk about the parts that are hard but connect them back to people who are trying to evaluate how they might want to, you know, bring their dream right into the world in the form of software.

I actually think you need to be technical, otherwise you wouldn't know how to log into WeWeb. So you need to have a little bit of technical knowledge, otherwise you wouldn't be in front of a computer and you wouldn't know how to do the login and that you wouldn't have an email. So you need to have some sort of technical understanding. And, you know, I think as people, we just have a basic understanding of logic. If this, then that. We can kind of like make a flowchart. And I think that I would consider that being a technical thinking pattern, even though I think most people may not recognize that they're already developers. And they still see themselves as a marketer. But if they're doing stuff with Bubble or with WeWeb or with AI and they know, no, AI, you got to do it different. It needs to do this first and then that. I would call that a developer. That's the definition of a developer. You are solving problems. It doesn't matter how. You're not a programmer, but you're still a developer.

I think that's a really good point. And I would use the word almost. I think there's a huge population of people who are almost developers, right? They have intuition for this. They're almost there. And like the, the job of the software is kind of get you from almost to there. And, and that's very different from what, what the, the state of the world say, you know, 3, 5, 10 years ago for the previous rounds of the way low-code came in. Uh, and so simultaneously tooling has got better. I mean, the low-code tools today are much better than they were. The AI tools are much, much better, obviously exist, whereas they didn't exist before. And then at the same time, people have gotten far more technically skilled. I think anybody like 38 or younger has had a smartphone in their pocket for their entire professional career.

Yeah.

Which like sort of, we think we sort of take that for granted maybe if you're, you know, perhaps younger than 38, like some people in this room. But it is, it's a remarkable change in like people's relationship with technology and this idea that there can be an app for that. And that they're coming in, they're ready, they want to be able to do more stuff. And I think they're ready to be treated as adults.

I like that. I like that a lot. We now talked about the comment that kind of like got the heading and the outline for this conversation. Anything else you want to talk about that, about that we're focusing on boring stuff?

I would just take this opportunity to say that we would love to have more of these comments, like ones that are stirring up controversy. Because if there were no controversy in this market, there'd be nothing for us to talk about.

Exactly, we got to come up with topics.

Yeah. The controversy that matters, like people who are watching this either on video or live or whatever, is just super valuable to us in terms of understanding how we can be a better service. But it's also super helpful for us to just think about like what really matters in this industry. And while we have our own ideas about that, the best ideas, I tell people, they change all the time, come from your market. Yes.

Also, if you go to the chat below, I got a question for you. Do you find us boring? Be honest, don't hold back. Go to the chat or into the comments and let us know if you find us boring, and then if you do, why. And then, you know, we would love to take that as a chance to kind of like, you know, make more un-boring content, more exciting stuff. Or be more boring. We could also be more boring. Whatever you want, we'll do it. Is there any particular thing you want to talk about now that our topic is boring?

I heard that you recently tried out Lovable.

Oh, yeah. I mean, I love how you just went from boring to lovable. But yeah, Lovable added Lovable 2.0, and I got very excited. I was like, oh, it's finally good. Before we'll take a look at that, actually, we got a LinkedIn comment, but let's take first a look at the Lovable 2.0 ad and then we'll take a look at that.

Stick with us.

By the way, before I keep playing, we're not— Doesn't this make you want to use Lovable?

Makes me want to use whatever they're using for video production.

I, I did try it in real time and, um, it's not as they advertise.

Yeah, this is like people watching CSI and thinking that's what it's like to be a forensic technician.

I can actually take a look. How do I share my screen in here? Let's see. Can I share my screen in this scene? I should be able to.

Yeah.

Let me know once you can see my screen.

Yes, I see your screen with infinite mirror going.

Let's take a look at Lovable. I had an app, I wanted Lovable to build a crypto app for me. We're going to see this again preview, there you go. This is what it made. Loading crypto data and there's no data available. And that's the app that I think I spent half of my credits for the day on. And that's Lovable. And I was like, okay, how can I get results like they have in their app, in their ads? I would love to try that. So I found Lovable is very cool, but I think it's just something to play around with. It's not— it doesn't really have that much of a real-life use case to it, at least right now. It's nice for prototypes. It's nice to give you some concept of an idea, if that makes sense. But beyond that, I feel it will have some, you know, it will have some— it will be complex to use this in a production environment. I think people, especially the founders, are on X They really like selling the hype. They like selling the feeling. They like selling the vibe, if you will. They're not really selling a development tool. They're selling the vision of you can build a startup and you can build an app and you can do it using Lovable. And I don't think that there are too many people who are actually building stuff that is production-ready using Lovable.

You see more people build stuff that's not production ready than is production ready, right? That's kind of all over the place. Yeah.

But it's, it's probably also where most of the revenue from WeWeb comes, uh, or any no-code tool.

Yep. Or any, any developer tool. I mean, we, we prototype more than we ship, and that, I don't think that's intrinsically bad, but the, I, I look at, uh, at Lovable. I, I think it can be, uh, great for making something initially. What I have found is that it works best if you don't have strong opinions about what you're trying to produce.

Yeah, the—

but once I start having strong opinions, and I'm a pretty opinionated guy, I found myself having more challenges. And I think that's gonna be the case for like all these systems, is like how do they combine the ability to move fast with giving control? And so I think Lovable is really exciting in terms of like where the industry is going and where Lovable itself is going. 2.0 is much better than than previous versions. It's not what I would use right now.

I think there are things like Lovable or the Vibe Code app. There's a mobile app that lets you vibe code mobile applications. You can just type in there. I don't think Apple will ever allow this on the App Store, but we'll see. There's a good chance because they didn't also not really like Expo. But I think there is a hype to it, but I think those are applications for one. Like you brought up with your Suno music songs, like you are going wild on Suno. I think there is a market, let's call it AI for one, where you're using Lovable, you're using the Vibe Code app, you're using Suno, you're using whatever AI out there to do stuff that's only for yourself, to make a song that you like. I could see Lovable be a valid option if you need to build an expense tracker app for yourself and everything else on the market doesn't work for the way you budget, or you need to have an app to do something specific like an AI app. Where security doesn't matter, like a viral hashtag generator for your no-code YouTube channel, where there will be a small market like this and nobody really wants to build that thing. But you can build it in an app and you could use that app yourself technically. So I think there may be the option of that.

Well, I think you raise a really important point about like just, you know, low-code, no-code in general, AI coding. It's all about shrinking the necessary market, right? So like if you were trying to build software in 2010, you know, it was pretty expensive to build software, right? And so you were raising some money and then you would, you know, well, now I need to have a million customers in order to pay for this big investment I made in building all the software. And the promise that you sort of seen linearly, right? Like frameworks like React or what have you have brought down the cost of development. You know, low-code tools sitting on top of that brought down the cost of development. AI tools similarly bring down the cost of development. And as it brings down the cost, the size of market you have to be able to solve for to justify the investment goes down and down and down. And, and so like a lot of people who I talk to are like working for— I'm— they want to build something for like a very specific audience. And definitely could be audience one, personal productivity is a great use case, uh, and like you, if you were able to put a multiplier on yourself and previously you were making $200,000 a year and you're able to increase your productivity by 50%, I mean, that's, that's $100,000 a year, that's a lot. The, um, but if you are But you can expand that a bit and say you can have a very small market, my colleagues, right? Or of the 12 companies that are my clients or my target market or what have you, and create something that is just really focused around their needs, almost even bespoke, and do that at a much lower cost than previously it would have been. And now, while you would have to have been really rich before to have a piece of software just for you and your 5 friends, now it becomes a much more trivial thing in terms of cost to do. It's a question of like, what's the job to be done?. And I'm seeing like, and where I see people ship in this space, that's where I'm seeing them ship. It's not trying to compete and have 50 million customers. It's being able to have 5 or 15 customers. Those customers can pay you well, be able to support a small business. It's basically decapitalizing software creation and making it look much more like, well, a service or like an agency.

Oh, uh, yeah, agency as a software.

Yeah, yeah, absolutely.

Like LegalZoom. Like LegalZoom. Aren't they like built on Bubble, or did I dream that? Like, there was some like LegalZoom or something.

LegalZoom is a very big company. You're thinking of BetterLegal, uh, which is a wonderful company, uh, and he's got wonderful clients, uh, but it's not to be confused with LegalZoom.

Okay, okay. But there is like one of those legal companies will file your LLC in Delaware in 5 minutes or something that is built on Bubble. Yeah. And they're just an agency, but they turned that agency into a software or something like a software.

Yeah. And you know, this doesn't necessarily require low-code or require AI code to do. Like our friends over at FinSuite, right? Actually made some significant software packages that they've sold, make money with, including Wized that, you know, even though they are an agency and don't really have, you know, capital backing behind them. And these things all point towards like the financial factor.

What they do, you consider that FinSuite hasn't raised any money. Money to build with. I think it's very, uh, very impressive on what they have been doing because WeWeb has been raising, I think, a few millions. Tunnel has been raising $4 million. Finsweet has been raising nothing, and they have built a product that can compete with all of them and bought it.

So yeah, yeah. And like, that's when you don't have no-code tools, and then you start bringing in no-code tools, you can work, you can do pretty remarkable things for even smaller environments. I can't tell you how many people come in like Statechains. What they really want to do is create like a no-code builder for whatever their specific domain is, because they see not only the power of what they can build, but they see the idea that they can be enabling someone else.

That's how I came to Statechains.

Yeah.

And now I did. I built a no-code builder that lets you turn your web application into mobile applications thanks to all the help of Ray. I couldn't have done it without you.

I think Despia is a great example, right, of that, where you are building enabling tools that in turn are just using the enabling tools. I think there was an attitude intended— I still see it— some of these low-code companies where the engineers there kind of look down their noses at their customers, like, they're not real developers, we're real developers, and we're doing the real interesting hard things here. But like, part of what you're showing with Despia is like how quickly you can climb that curve and be able to use these tools and stack on top of it, get another enabling layer that makes it even easier for people to do something else that's hard. And that's remarkable. I think it's one, it's a real credit to you. It's also, I think, a statement about like where the, you know, how the industry can continue to be, you have geometric growth.

Yeah. And with Despia, the big hurdle was, you know, making sure it actually works and the code signing works because you know how big of an issue like Bravo Studio, FlutterFlow often are fighting with code signing. Thanks to all the mental models that I learned from Ray, I was able to build that. Of course, I have a team who's helping me with lots of things and I couldn't have done it without the team. But Ray has been a significant part of that team and StateChange and his community. I'm very grateful. For having access to that. And if you are interested in taking a look at Despair, what we have built thanks to Ray's help, you can scan the QR code or go to despair.com. And if you're interested in turning your WeWeb application into a native mobile app, or your Tuddle application, or Nodecraft application, or whatever you've built into a native mobile app, check it out. I think it will help you. It will do the code signing for you. It'll do the— it'll provide you with an amazing runtime for that, and it's fully no-code. You won't have to deal with capacitor plugins. By the way, it's not based on capacitors. Some people in the web community are like, oh, is it based on capacitors? But it's not. We built our whole framework from scratch. We couldn't have done it without Ray.

So cool.

Thank you. Which brings me back to say, if you want some of Ray's help, go to statechange.ai.

I appreciate it, man. Yeah, the— yeah, so, um, can I ask, like, you, you played with Level a little bit, uh, have there been any other tours?

I'm right now all in here. Okay, sure. Uh, I, I don't know if we can— how can we, uh, can we move you here? Okay, can we remove me?

Let's see, can we remove you? Oh my goodness, there is a state change website, and for which people might reasonably conclude that my hardest 5% is graphic design, which would be a fair statement. Uh, you know, I'm a much more a backend quantitative person, uh, and I found that to be, um, you know, sort of where, where, where my, where my long suit is.

All right, I just accidentally removed myself here, but I, you know, this was like your shot to go for like a full like 1-minute advertisement about StateChange.

Go ahead. Oh, the full-on, the, the, the, the, the full-on ad. No, no, you see, the thing is the full-on ad and, you know, for people who are looking for like business counsel in addition to, you know, stuff relating to technology, the best ads are the ones that are by someone else. So like what you had to say about StateChange is just so kind and helpful. And for other people who are looking to understand more about StateChange, I'd encourage you to go check it out. We have office hours every day as well as a full archive of like, you know, over 4,000, I think, questions that have been asked that are all, you know, searchable and AI summarizable. And, you know, as well as forum for like, hey, people asking their hard questions. And, you know, our focus is that like a lot of the stuff is made easy and where we focus our attention on like which parts are hard. And everybody has their own hardest 5%, as we established, mine might be graphic design. But the— but like when sort of like, hey, what's sticking you, what's keeping you from being able to make progress? That's That's what we do every day over on SayChange.

Yeah, and it is amazing what you're doing over there, and it's helping so many people, including me. I think you've done very great stuff with that.

Oh, thank you. We have some questions in the comments.

Yes, we got Daniel here. Some of my favorite people to learn from.

Woohoo!

I mean, you're one of our favorite persons to learn from as well. We can't wait to learn all about MCPs from you on how we can use them in Xano. You got— we got to have him on here, just like all, like all of us three, and we'll just build MCPs.

That's a great idea.

And then we got Leonard. He built the biggest TOTL application, like bigger than TOTL. He got more users than TOTL, more traffic. Uh, he said, what do you think of Xano Transfer? Is the speed improvement worth the increase in complexity and maintenance? Wasn't that the thing you invented?

What? Xeno Transform?

No, that's all like some— like Daniel told me something. You— there was something that you invented with Xeno, like with the, with the template engine or something.

Oh, well, they occasionally say nice things about like me giving them, uh, ideas for, uh, for, for things they might be doing. But let's be clear, there are wonderful engineers there. I'm not one of them. They've made very good stuff and that's all them. But yeah, the idea behind the Transform Engine is it's sort of an inline language to try to allow you to express more logic just inside a XAML expression. And the expression idea is that instead of like using like the low-code filters, you can sort of write out some text and it will interpret that text as code, just sort of special Xano language code. For my money, the juice isn't worth the squeeze most of the time. When you're getting to the point of that kind of complexity, right, of what you're trying to transform your data in Xano, and like the really, the, you know, the no-code tooling is kind of letting you down, probably because you're trying to do something that's much more complicated. Um, I, I'm actually a big fan of switching over and using, uh, JavaScript instead and using the, the lambdas, uh, in, in Xano. Uh, you can get a little bit more performance by using the Xano transform engine, but I think you're totally on target. It really hurts readability, right? So you create something that operates better, but your ability to maintain it goes way through the floor. Um, the, the, the newer engine engine, right, which is the newer Lambda engine in Xano, is actually much faster than it used to be, and it is far more complete than it used to be. It has better autocomplete support, has support also for SDKs that might also change even the way that we think about working with that stuff. And so that would be my go-to more often than main— than making complex expressions using Xano expressions or using the Transform engine, just because that way it's more plain vanilla, right? Either using the no-code where it's obvious what's happening, or you're using a standard language where it can be obvious what's happening, it can be documented. Frankly, if you don't really understand what's going on, you can copy and paste it into AI, and AI that's been trained on however many billions of lines of JavaScript code in GitHub is able to explain to you with great clarity what's going on. That's my usual approach for thinking about that stuff.

I actually don't use the Xano template engine because we're doing lots of string replacements with Despia, lots of string replacements. And we're— I think it's called Mustache.js or something. It's a templating language for HTML.

That's right.

That's right. This is great. I need this.

Yeah. The text templating engine in Xano, which is built on something called Twig, is excellent. Right. So the— so the— oh, there could be multiple T things, right? So Xano Transform is like part of their expression editor and expression language. The Xano template engine is just a big box of text that you can modify. It makes it much easier for creating things like prompts that you're looking to structure. It's really good to use.

I think it makes more sense for AI prompts. I think if you're generating about 2,000 binary files, it's a little bit tedious to use, especially—

I don't think a text editor is the best way to generate binary files.

It's a good point. That's why we have CodeMagic as well.

But, but yeah, I actually, I think that the, that text editor is one of the biggest things in terms of changing the way people can use Zano because Zano sort of naturally thinks in structured language, right? With like JSON, what have you, like keys and values and arrays, whatever. And the, but the, but the, the text, the template editor allows you to express, you know, significant natural language and AI talks in natural language and AI actually does not work well with structured language. Language, which we'll bring back to MCP thing in a second. But actually, it's one of the key things about MCP is that MCP wants you to have lots and lots of structure, whereas the— oh, sorry, sorry, MCP wants to think more in natural language because we're interfacing with the AI. And so it becomes a bridge between where you have more structure inside these, you know, deterministic software machines and being able to deliver over to the AI. And that's a pretty important skill to develop as we need to not only develop with AI like you're doing with Lovable, but also develop for AI like we do with MCP.

Now speaking of MCP, we got another question from Daniel. Um, hola, what do you think about MCP servers in Xano?

Well, first, hola, right? Um, the, um, and the, uh, the, the other thing I would say about Xenno MCP servers is that they're not fully baked. I think their best use case right now is for prototyping and for doing the kind of personal productivity thing you're talking about. One of the tricks is that like the MCP spec from November of 2024, which is the major one that, you know, is most supported out there and the one that Xenno is basically adopted at the moment, doesn't, doesn't have support for authentication or security in the network layer. It doesn't really know how to deal with who you are. Now, in theory, you can go add headers, you can have a header like an authorization header, and Xano actually has support for those things. The trick though is that the clients don't know how to use those auth headers. You have to start engineering more stuff to be able to distribute to the client, And at that point, like, wait, what are we doing with the MCP? How has it really created value? Has it made life easier for us? I look at things like the way Zapier does it as really kind of a gold standard for security as such it is right now, which is like the dynamic URL approach where like your key is sort of built into the URL because that can then be distributed and actually works really well if you use Zapier MCP server. And the— so right now what I do is I use Zapier— sorry, not the, the Xano MCP server for myself. And I am just kind of, you know, tapping my fingers, waiting for the release of sufficient features that I could actually bring it to like the rest of my state change members because it would actually have, you know, the kind of security that I would require in order to be able to expose an API to them. And there's definitely demand for it too, right there. The people want more of that technology available to them.

I actually built a little SaaS and then, you know, Xano killed my business with their MCP feature. And I built a feature that was— I got the domain, I think, already. It was, you know, it was REST to MCP. Yeah, yeah, I, I think MCP.com. And I built a technology, sits a Cloudflare worker wrapping it. And the way we solved authentication was like, like Zapier did. You're going to pass on the API key as a query parameter if people are going to use your API. Zapier has an API actually. You would use your Zapier API key. If you, for example, need to call Zapier from Make, you would use Zapier's API key. So what we did, I was like, okay, how about we'll just put it as a query parameter in there and that's how people authenticate with their API key. So your platform would expose an API key, you'll put that in the URL, it's actually how Google also does the requests. And then if they lose your API key, it's onto them, that's connected to their credit card and you just add a disclaimer on the dashboard, don't share this with people.

Yeah, well, and that's why it's not perfect forever, right? And fortunately, there's a newer spec that came out in March, at the end of March, I think on the 26th, the folks at the Model Contact Protocol project approved, you know, a new set of standards that includes things like, you know, self-discovery of authentication methods. Now, there is actually nobody that I know of that's actually really implementing that. It does allow for self-discovery for OAuth. OAuth is now built-in support in the MCP standard. But that doesn't mean anybody who's implemented MCP actually has that ready to go yet. It's still early days. Yeah.

Also, we got a very, very interesting topic. Something very important. As of April 2025, is it still not recommended to use automatic CRUD endpoints generated by XAML? I mean, I'm telling people don't use the generated, auto-generated CRUD endpoints because Ray told me to not use them.

So, right. What's your opinion on that? Yeah, I would not use them. I think the three best words in Xano are start from scratch. They used to actually be called start from scratch. I think it's just called custom endpoint. And the reason I say that is because Xano is not Supabase. If you were building in Supabase, you would care a great deal about your data structures. And then you're looking to expose the data structures to your frontend. And that's basically the way people use Supabase. It's like, yeah, you can have edge functions or whatever, but the most classic way of using Supabase, you have your database, you introduce a little bit of, you know, row-level security control that most people don't know how to configure. And then they, and then you have a frontend whose job it is to go talk to Supabase, basically, you know, make SQL queries right back into Supabase and get data back out. And that's how you go back and forth, subject to an authentication token. The Xano, Xano doesn't work that way, or at least isn't the strongest that way. Xano has a database that is not nearly as good as Supabase's database, but you probably don't care because the database is perfectly good for the vast majority of use cases. I run into people all the time who are like, wait, I need to have a bigger, you know, buy a bigger Xano instance because the database is sort of, you know, getting crunchy or whatever. But the bigger problem isn't usually the database. Usually the problem is when going to be in the logic. And so where Xano really shines is where you have your requests coming from, you know, the front end or from your MSP client or whatever, and you need to make some decisions now, right? And it's going to be where you have more code that— or, or, you know, workflow logic, right, that's running inside, um, you know, that would be code if you're running this in a serverless Lambda, and that in Xano is what they call a function And Zapier is like a workflow with boxes and arrows or whatever. And Xano does that part really well, right? Zapier would require you to be much more simplistic about how it works. AWS or live coding it would be a little bit hard, not a little bit, a lot harder to understand and read. Xano really strikes an excellent balance of allowing you to develop fast and having it be clear and understandable. So if you understand the underlying ideas like I want to get record from database, like I want to loop, like I want to augment data with a little bit of pattern recognition, you're able to do a whole lot very, very quickly. Now that's the— but that's where Xano really shines. It's going to be when you have that kind of, wait, I'm deciding what I want to do, thinking of it like as a function call, right? I want to go do this action or have a computer do this action for me. That, and then part of that action is retrieving data or writing data or whatever, that's where at strongest. The I'm using a REST or so-called CRUD endpoint to go and manipulate data on the database, that's where like you don't want to have thoughts in the middle, and that's gonna be worse. Using something that's not Xano is going to pay the bills more. So if your inclination is like, I just want to go create all these CRUD endpoints and like, and that's why I'm going back and forth, I would be questioning why we're using Xano in the first place, because it's a more expensive solution for just getting to a database. This, but it is a world-class solution for getting to that logic.

Yeah, like if you're building a to-do list app, use Supabase. If you're building anything else, use Xano. I, I actually think there are always little, you know, shooting shots at Supabase at this YouTube channel, and people are used to it.

Yeah, and by the way, Supabase is a wonderful product, and like what you're looking for is a big scalable transactional database. It's not that expensive. It's— they do a fantastic job and They've totally earned their recent valuation for their fundraise. And I use Supabase. I think it's great, but it's like the, you know, there's actually on the homepage of Supabase, they've got like 6 features they talk about having. It's a really good way of thinking about like backend tech in general. And that the part that Supabase does really world-class is be a world-class database. But the part of logic, which is where Supabase has the edge functions, that's where Supabase is like very weak. And where I think Xano is, very strong. And like, when I think about Xano, when I talk to people about Xano, as I often do, I sort of have a, you know, free call policy. I meet all sorts of people who are using it in weird ways. Um, they, um, you know, the—

I, I—

the, the, the— that function stack is just where, where everything changes, uh, for people. Like, hey, how do I do this? It's not some weird configuration you need to go figure out and learn hidden in one of these screens. It's— you can just make the logic do it, and you can make it do anything. We used to call this infrastructure as code. That was like a term in DevOps in like 2016, 2017. And you're seeing Xano be able to do infrastructure as no-code.

I like that. I mean, the Xano function stack is such a great thing. We'll use it at Despia for all our routing. We're actually building some of the binary code files in the function stack. It can do it just by creating file resources and using text templates that reload from GitHub and all that stuff. Probably not something that Ray would suggest you to do, but I was like, you know, I'm a big believer in Xano. I don't mind upgrading my instance, but I just want to say I built it in Xano because I'm rather paying a few hundred bucks a month for Xano to do this in Xano than to have this somewhere on Lambda fashion or to have this on Google Cloud Run. Just not because I don't like writing code. I have some things in Google Cloud Run, but I like the ability that when we make a change today, tomorrow our Xano endpoint is updated, or maybe even this evening. And it's just the way we can ship features at Despia because we're using Xano is just rapidly more than if we have to go and go with the code. Because with Xano, we only have to work within the logic that we're building. And consider that where in, you know, Google Cloud Run, we have to, you know, update the logic but then also patch the code that puts it together. Where just the ability to go in there at midnight and to update a critical issue in your underlying structure because someone just sent you an angry email because their app cannot be published on their deadline and there is an error in your system because Apple updates— I mean, just being able to fix that in Xcode move the file to Xano, update that endpoint, and within 2 hours have it fixed, or within 1 hour. That's something you can do. And I think if you are really caring about your customers and you're building a SaaS and you want to get features out there to your customers super fast, I think you can't go better than Xano. And then of course we're sprinkling in some edge function, some Google Cloud Run for some, you know, generating Java keystores and all that kind of stuff. You need that. But you can run them as microservices and then just bring them back into the Xano ecosystem. And then you can connect it with CodeMagic where you do the build process and then you can bring in some AWS Lambda if you need to have more heavy Lambda going on because back then they didn't support the PM. I think I talked with Daniel about what I'm doing in Xano and he was like, ooh. I would say it works, it works, it does a great job. You got to be more self-confident here at what Xano can handle. It works perfectly. Like, we have hundreds of people using it and it works amazing and it never had any issues. I think, I don't know, maybe it's my confidence in Xano that makes it work so well.

I don't know, it could be. Um, the, uh, I, I have found, uh, that the, um, yeah, that, that, that it works pretty well. No, I think that the newer Lambda support they put in, they call it Lambda still, basically it's a little Deno server that's sitting inside it. It's much faster, it supports, I've removed actually most of my Google Cloud Run things I had running on the outside to deal with things like APIs or SDKs. And I've reduced it just things that are just so heavyweight that they can't run well inside Zano. Are you using— Sorry, what?

Oh, you need to use Java because we're Android, we need to run Java.

Yeah. If you need to run something other than JavaScript or code, then yes, it's not the place to be. I find that to be— and they keep on doing that relatively well, I think. I've got a lot of experience working with a lot of different programming languages including Java, including C#, including JavaScript and Python and PHP. PHP is actually the language SAM is built on. I'll tell you that for a lot of things I build today, It's not just a matter of it being low-code, it's the right place to build about 80% of the code that I write.

We actually got a good question here. I heard Xano might be lowering their prices. Does the logic of when to not use Xano change if suddenly Xano was cheaper?

Obviously, they're going to lower their prices. I think what they might offer is a more basic package that's paid. So I— so it sort of depends on what's going to be on.

Talk about that because I signed an NDA, but they got something in the works. And then I'll— now I'll let you talk, right?

Yeah, sure. I mean, I have, uh, I'm not privy to their, uh, pricing. So, uh, you know, the, um, yeah, the— so the question of update, I don't really have one, uh, for you.

I saw it, but I can't talk about it.

Okay.

But you can be very happy.

That's where we are. There is an aspect of where Xano is basically, they have these virtual machines, right? And then when you have a Xano instance, you're basically renting one of those virtual machines and put a bunch of Docker containers on it, and that's how it works. And it can be a little bit shocking when you compare the implicit amount of memory or resource you really have on a Xano machine with how much it would cost to rent that same amount of resource from, say, DigitalOcean. In the form of a droplet. And the other— wait, what kind of markup they have on that tells you how much you're paying for the software versus paying for the resource. So if Xano is buckling under a little bit of pressure to sort of reduce that markup, that would be, you know, I think a good thing for the, for the market.

I think they are under some pressure, quite some pressure, and they are working on it. And for other questions, we've got Daniel in the chat. Daniel, you got to answer those And then we had another one. Hi, is there any update on Zenos pricing? Oh, that seems to be our hot topic today. I'm curious if any changes or new plans are being considered. I can tell you I saw what they're planning. I'm very happy for that. It seems like I'm going to save lots of money, but I can talk about it.

I'm going to end it on that.

And then we got another one. Again, Xero pricing. Anything under $50, we'll be doing backflips.

Yeah, well, I guess we will find out what happens to their pricing in the coming weeks.

I think you can be very excited about it.

Cool. Hey, I'd love to pay less.

Me too. Um, speaking of pricing, I was on X and I saw something very interesting. Uh, I would love to get your opinion on that, Ray. So there has been someone, he has been building, um, an application, a SaaS, that is essentially, um, you know, kind of like generating, you know, AI ads like Canva but using ChatGPT's new image generation API. It's like an AI wrapper out there and you could probably buy code or use no-code, low-code tools to build those. If you then take a look at SensorTower, how much those apps are doing, this is now just a wrapper for Cling AI, they're making about estimated $100,000 a month. They got 1 million downloads and it's just a wrapper in their top market, are Indonesia, US, and Brazil. What do you think if everybody now will be able to build software? Every vibe coding influencer on X and everyone, will this still have a future? Because I think there are lots of people like I see Sylvan in StateChange who's building animatics, which is amazing. He is an AI rapper, but he's providing so much value to that. What will be the future of people just doing AI wrappers for the sake of making a quick buck compared to people who are actually on a mission to solve problems, and how will this, you know, kind of like reduce either one's, you know, market in that industry?

Yeah, well, I mean, people are always gonna make quick buck, right? And like when, when Cling comes out, hey, Cling is cool, how the heck do I use this thing? Oh wait, here's an app, I will be able to get that done, and then they make whatever revenue they make. I'm pretty sure they're gonna have to pay a bill to Cling, so I'm not sure what what the profit is, right, that's sitting behind that $100K. But let's assume it's significant, uh, and it's, um, then, and it'll last like a couple of months and then it will fade, right? Those kinds of flash-in-the-app, flash-in-the-pan apps, you know, happen, uh, and we'll continue to see them happen as, you know, cool tech comes out. And we saw that before with like things before AI, we'll see it later with more AI, and then after AI. Um, but when I think about The, like where there's gonna be more enduring value, right? It's gonna be like how you connect it to the business. And previously the hardest thing was, hey, dealing with the tech, right? But like, you know, you raised Sylvan's thing, which I think is really interesting because Sylvan is primarily a marketer, right? And he's helping fellow digital marketers. He understands the marketing problem and he's bringing the technology to bear for it.

I would not be in here. With us. I think we should interview him. And I was—

yeah, I feel right, because he's a guy who thinks in terms of how do you make sales and how do you do promotion and how do you— and like, which is what he's doing is he's creating an ad generator, right? Or an ad creating creation platform that uses all these cool AI tools. But he doesn't need to be the AI expert. He is the business expert in building a bridge between his expertise around advertising and his customers to this technology that he can bring to bear for it. And somebody who's making a generic Cling AI wrapper isn't going to be able to go where he goes. And that— and so he can work with that smaller number of major agencies who are trying to do really cool stuff. He can be charging them good money for it. They have to be worth it to them because they are able to make ads that nobody else can make. And that's his focus: making awesome, remarkable, differentiating, you know, ads and copy. And the, the rest of the— and somebody else can have some other, some other job. Like when I think about like what's the opportunity for making software here that's like beyond just like you say, big platforms or the 2010 quality SaaS. Yes, I totally think about Sylvan and I think about like what's the job to be done? Who's the market? How can you help them and really focus in on that and deliver extraordinary software?

Also, Sylvan built this in statechange.ai. So if you want to get the same help like Sylvain is getting from the one and only Ray Deck, scan the QR code on the screen and join StateChange. Look at that flash around it.

Very cool. We had a couple of questions come in here too.

Yeah, yeah, let's take a look at them. Oh, that's a good one. What's the most complex backend that exists today made in XAML? Is that the client that is like paying $750,000 a year for Xano, or—

uh, well, there are some clients who are paying a lot of money on this whole enterprise plan thing, so probably think about the enterprise clients to be pretty good. Um, you know, I, I have one— there's one who's like back in, um, a significant, you know, sales process, right? Um, and using it for sales enablement and almost, you know, and connecting to a bunch of AI things. It's, it's very complicated and it's very cool. Another one, sort of, I think about like big scale. When I think about like big complex systems, I think about big transactional systems. And, you know, from my career as management consultant, the biggest of those were all insurance companies. And I can think right now of an insurance company is actually running one of its insurance products for claim management on a Xano backend. And that's going to have like hundreds of tables and have to deal with a whole lot of simultaneous requests. I think it's based, I think it's a non-American insurance company and it is a significant deployment with, like I say, lots of tables and lots of logic and lots of rules that have to be right because we're dealing with the adjudication of claims that affect people's lives and being able to shepherd that through the process. That is, I don't know, there are different ways of looking at complicated. Structurally complicated, most data, the most code, most number of functions, what have you. And a lot of, but, and I think probably most of the most complicated ones are, you know, have people who are members of state changing them. So I've seen a lot of them and they can get really big and really wild. But the other thing I find that's kind of really cool about it is you can have something that's really quite complicated and sophisticated and not need that much hardware, which means you don't need that much big Xano instance, right? So some people like go enterprise, but the reason they go to enterprise isn't necessarily because they're going to need to have super, super heavyweight hardware. Some people do, but the biggest reason to go to enterprise is have it running privately, you know, behind the firewall and have more of that corporate use case.

Yeah, very cool. We got one. My biggest dilemma: I really want to build more AI agent type automation integrations and platforms like NAN or even Zapier look great, but should I be building these on Xano to prevent more subscriptions?

Okay, what do you think about this one?

I would say Chooseful makes sense for, for you because if you are, you know, going to spend like a week building this in Xano and in NAN, and it's going to take you a day to set up, I would probably suggest you to go with N8N 'cause it's first of all cheaper than Zapier. And if there is an immediate business value that this provides to you, it's probably worth better, you know, more like paying $10 for that and saving a week of your time. You'll probably be able to make much more money with that 10 days that you're saving compared to the $20 or $10 that you're saving subscribing to N8N.

Yeah, that sounds about right to me. The, um, I, I think a couple things. The first is these subscriptions are all worthwhile, uh, because they're saving you your time. Your time is worth a lot more than that. Uh, if you don't believe it's worth that much, you know, I probably shouldn't be in the game at all. And most people do understand at some level their time is really valuable, so spending a couple bucks to get a service that does this job well is where I would go. I would ask what allows you exactly what Yaseen was saying What can reduce something that might take days into hours and make it easy for you to do your first few? And I'd emphasize the word first. The way you start doesn't need to be the way you end. So what I would even encourage is go do something that allows you to create more of them faster and iterate. And then the 5 words that are the catchphrase inside StateChange among our members are, you will build this again. And the—

I gotta make T-shirt with that on it and we gotta share all the profits from that.

The, uh, and, and so like, you know, using N8N or Zapier allows you to learn faster, right? And if you learn faster how to make the, make an agent, like you get an intuitive sense of it and like, okay, well I wanna do something more advanced, right? Can I bring this over to my—

Already paying for Xano's launch plan.

Yeah, sure. But like the, the, the fact that you're paying for the launch plan is, is great. I think it's, it's great to have a launch plan. Uh, I also think that, you know, Xano can get better at making agentic workflows, but right now Xano's not the easiest. It's not even close to being the easiest way to make an agentic workflow. So I think if you're trying to learn agentic workflows, I would go someplace where it's easier to learn that, climb the curve skill-wise, and then ask, okay, well, I have something I want to scale. Where do I want to scale that? Do I want to scale that in, in, in, um, in Zapier or N8N or Gumloop or whatever you might be using, or do you want to scale that more on the Xano side? And that control that you get out of it because you have it sort of inside your box as opposed to outside of the microservice, you know, one, lets you cut a subscription, which is nice, but more importantly, you get control. You get to do other fun transformation things that might not have been easy in those other places, but you do it from a position of understanding. And that would be where I'd want to come in. I think Xano is actually kind of a a terrible place for a lot of people to start their building journey because it's so generalized. There's so much you can do. Uh, but it can be a great place to, you know, do your step 2. And, uh, and I think a lot of people I've seen be more successful with Xano started with something like maybe they started with Bubble or they started with Zapier or whatever, and then they graduated to doing something in Xano because they wanted that higher level of control. And I would take the same approach here. Amazing.

Now we got one question that I actually got something prepared for the question. Let's see, can we show the question while showing this?

Yeah.

Your face is cut off. You want to move a little bit more to the right? We got one question. Another question, I want to pull all my Swagger from a Xano project in a Xano MCP server to use it in cursors. Is it a good idea or not? I think actually it's a pretty good idea. But I don't think necessarily you need to have an MCP server in Xano to do that. You could just add the Swagger into your reference file or something. If I'm not wrong about this, Ray, you may want to correct me here with cursor. But Xano has a cool feature where you can set as example, and I pull up the documentation. This will add example responses to your Swagger documentation. So your AI agent when you're vibe coding your application, your frontend, will know what responses to expect. This is a very important thing because right now you could only see what goes in, but you couldn't see what goes out in your Swagger. Now once you can see what goes out, this will give the AI the whole big picture. Without you having to prompt any additional stuff, it will actually set that up nicely and it will actually work because it knows what to expect and what types. Of data to expect. So this is a feature Xano clearly has added for all the vibe coders, right? So the, the new thing in there is being able to take an example response and put that into the example response so the AI knows your schema and what to expect.

Yes, right, in terms of response schema, because I always knew about the input schema, just know about the response. Yes, the, uh, I would say though that there are actually a couple of MCP servers out there for Xano that that make use of the metadata API that allow you to do this a little faster. I think if you go on to Smithereen or whatever your preferred mechanism for getting your MCB servers are, if you look up Xano, you will find some. Because there's a difference between like building an MCB server in Xano and building and using an MCB server that lets you develop for Xano, right? And it's that second category that like Robert Boulos's, I think Pablo Majenski's, has also made an MCP server, both of which are pretty cool, right? And you can sort of in cursors, hey, I'd like to express this thing I want to do in the, in my server, because when you set it up, you set up like with your metadata API token and then it gets that metadata and it can go create tables, go create whatever the other stuff is that you need within limitations of what the metadata API currently allows. And because the metadata API can be even richer thanks to what you were just pointing out,— you've seen the, you know, the utility of those systems just goes up. So you can totally use MCP to develop with Xano, but you don't have to use a Xano MCP server to develop for Xano through MCP, as confusing as that sentence was.

I'm also going through the chat. Someone said anything under $50 will have me doing back backflips. I think someone will be doing some backflips, but I can talk about it more. That's very cool. Yeah. And MCPs are very exciting. I think we talked about a lot of stuff today. I'm very happy with where we are here. We got 8 people watching and 2 from StateChange, 6 from NoCode/ProCode. And it was a great conversation. So do we want to end this? Do we want to ask if there are any final comments in the chat? I think we kind of nailed the topic. We started off boring and we ended very exciting.

I think that's the line of the episode, right? We started boring, but you all, you made us exciting.

Yes. We got to get more exciting comments here.

Come on.

Awesome. Oh, we got one. I still can't wrap my head around MCP servers and when to use them. They sound like the same thing you do with an API call. Maybe I need ChatGPT to explain it to me like I'm 5.

Yeah, you know, I think that that is something that deserves, I think, more discussion, and we should totally do that next week as well. I would say to HFE that what you have is a really good intuition because in many ways MCP servers are just API calls. They're just API calls that are structured to make it easier for the AI to work with. Yeah.

But also there's no hype around MCPs made by people who sell you courses how to build MCPs. You have lots of people in office hours. I remember Lucas joined office hours and said, I want to build an MCP server. We were like, I was like, why are you building this as an MCP? And he was like, yeah, I need to filter. But I was like, I don't think MCP is the right use case for this. And then he was like, oh yeah. And then he built it by probably just giving the AI custom system prompt or something like that. So just everybody on Access saying you can make notes with an MCP, it's the future, never been done before. Doesn't mean that your use case meets necessarily an MCP server.

It might not require an MCP server, but I actually think that they are very— I think next week, you know, talking more about like where the puck is going, I think MCP is going to be a big part of that. Whether it's the final standard we use for this kind of thing, I don't know. But let's totally make that more of the discussion that we do next week.

I once said I was in the live from Zano and even Michael who, the one who always does the tutorials, was lost with MCP.

It is a deep and complicated topic. Let's make that what we do next week. And for now, thank you so much.

Ray, you gotta help us get unlost.

I think that can be a wonderful boring topic for us next week.

I don't think we're boring. I think we made it.

Now.

We're not boring anymore. We're excited, at least in the middle ground. Thank you so much all for watching. We really appreciate that. Thank you, Ray, for taking the time to talk with us about all those boring topics. And it was actually quite exciting today. I don't, I don't feel bored. I think you don't feel bored either. I think the audience doesn't feel bored. So we are, you know, improving slowly but surely. Thank you so much for watching. Give us a like, share this with your friends. Like, comment, subscribe, whatever other people say on YouTube. Do all of that, and we can't wait to see you on the next one next week.

Take care.

Take care.