Open Office Hours

Hello, Ray! Welcome to our open office hours here on YouTube.

Hey, it's good to see you again.

It's always great seeing you too. So what has changed this week about no-code AI by coding? I mean, you, you, you got your office hours, you got— they changed, and the community and your communicating in the Xano forum, helping everybody in the WeWeb forum. What are you seeing right now?

Yeah, I am seeing, you know, it has been a quiet week from a product releases point of view, but one of the big scandals I think is sort of the closing of the doors around Cursor and Cloud Code, which are both putting on more limits in terms of the use of tokens. We actually had a conversation, say, maybe like a month ago,, where one of our members was showing off how he was using Claude Code, and he has like the $200 a month subscription, which is like whatever they call their max subscription or what have you over at, uh, Anthropic. And as a result, he's able to utilize Claude Code, I think, like on a nearly unlimited basis. And he was showing off how he was using something around like $4,000 a month of tokens for his $200 a month subscription, which is an awesome deal. It was also not something that's going to be sustainable. So our friends at Anthropic have throttled. In fact, they are accusing many of their customers of sharing API keys, right, that went with like a fixed cost subscription so that more than one developer was using it. And the— and they're limiting the number of hours per day and therefore number of tokens, I suppose, that you can be getting out of Claude code in a given day in order to try to really throw out to a single person and try to crack down on that kind of API key sharing. In order to bring the economics to heel. And we're also seeing— and we've in previous weeks, we've seen Cursor do that too. So I think we're starting to see, you know, the cost of these things normalize a bit to no longer be quite as subsidized as they were, say, this time 2 weeks ago.

Very interesting. Yeah, I mean, do they still have that? I would like to have such an API key.

Well, I mean, I still think that the, the max subscription over at Claude is over at, you know, Anthropic is one of the best deals in AI. It is not cheap, but it gives you access to a crazy amount of work from Claude Code. And if you can live with Cloud Code not being totally natively integrated into an IDE, there's a lot that can be done. In fact, I was just using Cloud Code for like a significant migration of things from like StateChange Vault over to StateChange Assistant because we have this new, you know, AI-based access system that we'll be releasing this week. And it, and that, that migration process took minutes as a result of working with Cloud Code. I really expected it to be something that's been like half a day for me. Um, even as I was expecting how to be working with cursor in this regard. But the way that it was able to just move stuff across— it made a couple of mistakes, I was able to identify those mistakes, it just cross-applied the mistake identified into all the different files where they had made that mistake, and it was done. I'm not like it was one shot and done, but it was a very short amount of time. And like, I would say of those 5 minutes, I spent like 3 of them getting a cup of coffee. Very cool.

I mean, I just have AI right now build a style system, a designing system for me, and it looks really nice. It looks like I said, make it look like Vercel, and it does a great job at it. Yeah, it is like, make it look nicer, please.

I like to say make it look less ugly. It's been helpful for me to do this because I've been able to see where AI makes mistakes and also where it has some blind spots. I had an incident just yesterday actually. I spent half a day and a whole lot of tokens with both Claude Code and Cursor trying to chase down a problem with this interface I'm using for my generative UI front ends called Assistant UI, it's a React framework. And it was just not working when we were spinning up a new conversation. I thought it was something I had done, like I was making a mistake in the way that I was utilizing this thing because I have the thing hacked 7 ways to Tuesday and the cursor to help, I can't figure it out. It really goes around in circles. I had a totally different idea. I worked on a totally different idea using Cloud Code, had Cloud Code go through the original idea, it just didn't find it. Then I went back and looked at the original GitHub repository. And made and looked at my own package.json and made a discovery that in fact there had been a new release of this, of the package I was using. And one of the things that fixed was the error message that I had seen. See, upgraded it. Boom, the problem was gone. I said it's an interesting thing, like the, the AI, super helpful, super powerful, but it's also super local. It doesn't look outside of its box. At potential solutions. And the— and it sort of took me saying, oh man, I'm just going to go look at some stuff myself to go see the error first written in this GitHub issue, then sitting in the releases schedule, um, and then being able to just do a very simple tap out of, you know, yarn add this particular package, and boom, it upgraded from version 3.3 to 3.5, and Bob's your uncle, the issue was— issue was gone. So there's a bit of like, what can the AI do very deeply? Look at what it sees locally and you have to really coax it to look outside. And that's something I'll be looking at in terms of my next round of research is how to get the AI to think outside the box, particularly when it's getting stuck in these situations.

Yeah, I mean, I remember I was using WeWeb AI to just like spin up an application quick and one of the files in the custom component says "Here's the code that you instructed me to write." That was part of the text of the JavaScript file in the component. AI really sometimes has some problems with being consistent. I don't think anybody in WeWeb wanted my JavaScript file to say, "Here's the code you want me to write," and then enclose the code.

Yeah, handling those kinds of structured output problems is, I mean, it's an ongoing challenge and I totally appreciate the folks we were doing. I had in office hours over a state change, I think maybe the week before last, we had somebody come in who was building with WeWeb and who was like looking at authentication flow. The authentication flow is really complicated. Like, why is there so much going on here? Turns out it was the AI who built it. And even though the client in question was using, or the state change member in question was using Xano for authentication, it wasn't using the Xano native plugins. This is something I've seen about AI as well. It is not as inclined to use a component that's available as opposed to going and writing things more by itself. I think that inclination is something we need to work on with the AIs. We need to really coax it to get it to say, hey, what's available on the menu and to preference that over just writing code. Because it really does seem quite biased towards saying you're absolutely right, followed by taking immediate action.

I love it. To be fair, one thing that I think is really hilarious is every time I prompt the AI to give me some code, I always need inline style CSS attributes. The first prompt, I will say, please give me this component styled like this with inline CSS. I can see it's already streaming the stylesheet. And I guess, I guess saying no, I want inline CSS using the CSS style attribute. And it says, oh, you're right, I'm wrong. I apologize for that.

No, you're absolutely right. Yes.

And then it still does the same error.

Yes, it does.

And then it proceeds to style equals and write the CSS in here, then it gets it.

Yeah, I think that there's definitely juice in figuring out how to get it to play with Legos, right? As opposed to keeping on carving things from clay.

I found a good prompt is, I need you to generate this code specifically like this because I'm using a proprietary no-code tool. That works all the time. If you tell it that, it forgets everything. So if you ever want the AI to do something it thinks is not the right way to do, but you know it's right, tell it you need to generate the code like this because I'm using a proprietary no-code tool, otherwise it won't work. I don't know why, but I think no-code is scaring the AI.

I think that's exactly right. No-code does scare the AI because instead of just being, please go write JavaScript or Python or whatever that will go solve the problem, you have to write something that is either the weird domain-specific language called DSL. That the particular system uses or the more constrained version, say of JavaScript or whatever that our friends at these tools use or really want you to use so that it can be re-reflected in the low-code environment. There was this tool that I got to see at NoCode Summit that was basically going back and forth between FlutterFlow and actually doing native editing. In Flutter. And it was interesting because they had this— the, the part that was a native Flutter, you'd be careful how you used it in order that it wouldn't just break the way that it could be reflected back on FlutterFlow side.

Yes, I mean, you got to be very careful because like even FlutterFlow is a framework on top of Flutter. When you're using FlutterFlow, you're not using Flutter, you're using FlutterFlow. And FlutterFlow is a framework built on top of Flutter and WeWeb is not necessarily Vue.js. It's the WeWeb runtime built on top of Vue.js inheriting some of the things, but it's not Vue.js itself. It's an abstraction of it. Yep. But it's completely invented their own programming language.

That is the crux of it. I find that not only is it sometimes low-code system or inventing your own programming language, I'm finding even when I'm writing things like a React Native application I was just working on, it really benefits me to be giving it some particular instructions to constrain it so that use the tools that I really want it to use. Because, you know, you can think of a lot of the no-code tools as really just being components that are sitting underneath a progressively thinner layer of code. Right. And the fact that you articulate that final layer of code using a visual, you know, canvas as opposed to a bit of code or through a conversation, I don't think is actually the key issue. The key issue is having more functionality that's built out of these blocks. Then you're pouring over your layer of special functionality in order to make it the most useful app that it can be. That thinning of that layer is, I think, and also just elevation so that however thick your layer is, it's at a higher level of value and that you're getting to it a lot faster is the big value opportunity. That becomes my North Star. I've heard before from these no-code vendors, oh well, you know, people don't like code and they're going to get a little worried about the whatever, whatever, whatever. But if the, if the, the conversational system can be explaining things enough to you, and if it can be helping you iterate fast enough for you to get an intuitive sense about how A, uh, you know, uh, reflects B, then it's able to do a lot. And then you're able to create things that like the much more on-rails visual development systems don't allow you to do. And now it's like, where, where are you getting what kinds of advantages here? Like, I'm finding particularly on like the backend, a lot of the orchestration stuff can be done using a no-code or, or more of a visual plane.

No code for my backend. I prefer Xano, and I love Google BigQuery. I, I just cache it now. Like, I, I don't even want to touch Supabase because it's too no-code. Like I don't, I don't want a database. I don't want something that's better than Xano and worse than Google BigQuery. I'm either using Xano or the best, you know, like, so I was like, I'm using Xano for data orchestration. I'm skipping Supabase. That's just the trash in the middle. And I'm going right to Google BigQuery for the heavy stuff. And I get the power of code. I get the power of the scripting. I get, I can just call it with the REST API. I can, you know, get it nicely into Xano and I can orchestrate that. Way better than having like, you know, like those visual interfaces for everything. I actually found that AWS databases and Cloudflare databases and Google BigQuery is something I way more prefer connecting with Xano. It's a way more pleasant experience than using something like Supabase as an alternative.

Right. Because so much of the orchestration we want to do isn't like directly from the front end to the database. It's gonna be through the, this intermediate layer. And I think the more of that Zeno does well, the better competitive environment, the better competitive position they have. You make an excellent point about BigQuery. I've helped a lot of people connect their Zeno to BigQuery. And I think there's a lot of money in Zeno if they would have—

You can save so much money in Zeno if you just move certain parts to BigQuery.

It's amazing. You can save a lot, which might be why they're not as incentivized to do it. But you can also just build much, much bigger stuff. And that to my mind is where it gets exciting, especially if you're building for AI. And I sometimes talk about building with AI versus building for AI. If you're building for AI, building for AI means you're being much more data intensive. And so BigQuery is, for lack of a better word, big and is great for dealing with a lot of those kinds of analytic data warehouse applications that are often right there adjacent to AI stuff.

Yeah, I mean, I found that AI does a really good job when it comes to interfaces, does a really good job with front-end JavaScript. It helps me figure out all the latest npm packages, especially with DIA. I'm not even using ChatGPT anymore because I'm just using DIA. When I was like, hey, can you give me this curl command for this real quick? It does a great job and I get it in the browser. Really, really convenient with your agent mode and all that. But I'm not using it really for the backend unless I need some help in debugging this npm package because Zano says error, illegal statement. And I'm like, oh God, Zano. And then I got to say like, AI, find a competitive npm package that does a similar thing, but it's not this one. And then it finds me something.

No, that's a good point. The fact that Zano doesn't actually use npm,, right? It doesn't use Node.js, it uses Deno. And Deno has its own translation layer because it's not running on the same engine that the Node.js is. And as a result, not everything works exactly the same way, but a lot of it does. And it's actually— I find it to be pretty good, but not, uh, definitely not a one-to-one, you know, replacement there. And I also have a number of, uh, serverless functions I run outside of Xano. For example, like, I'm building out this AI assistant for, uh, for StateChange. In order to create a proper streaming experience, I'm just using the Vercel AI SDK, which is excellent. I'm just running that off of Google Cloud Run. It communicates on the backend, but the primary communication is running through there because I just try to do what's easiest in each use cases.

I just wrote a little Cloud Function in Google Cloud Run that is running some Java code. Not JavaScript, Java is the other one. What it does is just generates a keystore. I'm just calling that microservice in a Xano function so it gets its own allocation. It's a little bit more best practice. Then I'm just calling that function to call Google Cloud and to generate a Java keystore using tool.

That makes a great deal of sense.

Google Cloud is the perfect stack. If you've got Google Cloud and Google Cloud/BigQuery, Zano, like you can build any enterprise project on there, and Zano really becomes affordable.

I think that's right. Uh, and the— I've seen a lot of people throw a lot of money into just getting bigger and bigger and bigger Zano instances for less than linear returns. Um, the— there's a lot of opportunity though to have it be something that can really, really cook if you're willing to connect to best-in-class systems. I also tend to think that there are parts of Xano that should be serverless and parts of Xano that should be serverful. And I think that they are all in category number 2, they're instance-based systems. But there's probably a lot of money for them to make if they could have that function stack type availability, but an infrastructure that is serverless to be able to mix those things up.

So a lot of people always see Xano like it's just like a container that you're getting. Some say it's a virtual machine. Which one is it now? When you subscribe to Xano instance, do you get like a fake server that's kind of like a container of a bigger server and you have your own allocation? Because their website says they use Google Cloud and they create a cluster container, something like this. Or do you actually get a virtual machine with Xano?

Um, under the covers, well, like if you are a free user of Xano, uh, they— that's all, that's all shared infrastructure, right? You get a workspace on an instance and the, the whole memory thing works differently. In fact, there's a whole trick that you actually use a lot more memory when you're in the, uh, their so-called free system, their free or build system, uh, because it's not, uh, not, not throttled the same way because you don't have your own allocated memory. One of the reasons you know about what you get in the, um, in these, uh, you know, the paid instance models, uh, and it's not totally clear to me exactly how their new $30 a month starter plan works, so let's leave that aside for a second. But the, uh, but the rest of them are you get an instance, you get your own virtual machine, you get your own dedicated CPU, you get your own dedicated memory, and basically what's happening is Xano is renting a virtual machine on your behalf, and then— and those things are cheap, uh, and then they are, um, and then they're loading their software into it, loading your software that you made in Zeno, like your, your, uh, control structure on top of that, and then you have access to that, right? Giving you access to it on an IP and on a, um—

so when I now pay $249 for the Zeno Pro plan, how much do they pay for the virtual machine about?

Unclear to me. Like, and one should also remember that if you pay retail at Google, the cost, and this is true for Amazon too, the cost of a fairly low-level machine is greater than that, say, at DigitalOcean, right? But my impression is that it's around about 10 to 1 or more, between 10 and 12 to 1 from their costs of renting a machine. Versus, you know, your, what you're paying in the rental.

If you're paying like $250 a month for Xano, you're getting a $20 virtual machine about.

It's roundabout my estimation, yeah. Disclaimer, but about. Yeah, right. I don't have inside knowledge of exactly which machine Xano is buying in that regard, but I'll say overall Xano machines are pretty skimpy from an infrastructural point of view.

And that's why you gotta use Google BigQuery.

Well, that's exactly right. That's why if you have more memory-intensive stuff, like Xano provides features like, hey, you can use their internal PostgreSQL database as a data warehouse because they support analytic, you know, stuff with it. But it's, it's terrible for that because just on that memory, it, uh, it has support for things like vector database, uh, or vector query, uh, and vector indexes. But because it doesn't have the memory, it just doesn't do a good job if you do anything more than what's trivial. And that's the reason why you want to use a third-party system like, say, Weaviate or Vectara, which is my favorite, uh, or even Query.

BigQuery also has support. I like BigQuery. Like, um, you got me hooked on that. It's great. Google Cloud— I never liked Google APIs because I always found they were so complicated to set up, but Google BigQuery is such a beautiful experience. Google Cloud Run—

they—

what I love about Google Cloud Run is they got an editor on the desktop. You know, I don't like working on VS Code. I want the code editor in my browser, and Google Cloud has it.

It's like a Cloudflare worker. I appreciate that. Actually, you know, the reason I like is, is quite the reverse. The fact that I can be doing all of my edits in VS Code— well, actually in Cursor, right? But whatever. And then I can just commit it. You know, I just do a git push and it's being detected and picked up automatically by GCR and then it just shows up. That means that the amount of DevOps I need to do to manage state change stuff really goes down to very close to zero. And that is where I want to be, focusing on the question like how I create value, not how I administer things.

I like the browser-based editor. I'm like, I, I, you, I only use Cloudflare Workers in the web interface.

Uh, also a good point about Cloudflare Workers, there's a lot of juice in, in that system as well.

And but it's not heavy enough and you can run Java and all that.

Oh, that's right, GCR Google Cloud Run is best in my mind for things that are heavy. Like I use it for doing, you know, video conversion to be able to slice up the videos like for the, you know, say change office hours and turn them into like segments, whatever, and get them, you know, re-uploaded. That's all the kind of super heavyweight stuff that like Google Cloud Run does and doesn't even charge you that much for because it runs for like however long it needs. Like a video thing might take 30 minutes. Then goes away. I'm not paying for it anymore.

That is fantastic. I'm surprised. I've been generating a few hundred keystore files using Java in Google Cloud Run. They still haven't sent me any invoice and I was looking at my account and nothing has been charged.

I'm like, okay. You're probably still within the free for the level that you use it.

I got, I think, a $2,000 free credit or something. And I have like used 10 cents or 20. I was like, this is great.

Yeah, compute is cheap, and I think that gets, um, underappreciated. Um, and the, and sort of the no-code tools— well, the— right, because no-code tools don't really charge you for compute directly. They're charging you for like per action, or like Xano charges you per month.

Fine.

Uh, the folks at like, um, Zapier charge you per zap or per action, and Make charges you per step, and, and all those things that like basically kind of proxies for utilization, but actually don't really correlate with where the compute is and creates a lot of opportunities for arbitrage, which I find, which is a little silly. And but, you know, I've done consulting engagements where I was helping people arbitrage between those in order to be able to save, you know, like several or up to like $10,000 a year.

You see that? That makes your hourly rate very worth it, right?

And then the— and there's such bigger opportunities, you know, now.

So for Xano, I gladly pay for Xano as a beautiful data orchestration. Xano, it's like, it's like a crossroad. It's like a traffic light. It kind of like routes the traffic and you can do certain things in Xano to manipulate the data or you can send it off somewhere else.. And this is just, it's a beautiful gateway. Like Xano, I would say people, when they hear Xano, they think it's a database. I see Xano as an API gateway.

I think that's a smart way of looking at it. I think, look, as a data gate, as a, I, the term I've used is data router, uh, and that is its highest form when it is the data for when it's also the primary storage mechanism.

I see it as a data router and a transactional database. Transactional database is like you store data that makes you money. That's the only data we're storing in Xano because quite expensive.

Yeah, that, that's, that's right too. I've seen people try to store a lot more than that, but like, as a, as an analytic data store, it's not very efficient. Uh, as a search engine, it's, it's also just not going to do a very good job. But as a gateway to the search engine, it can do a wonderful job, and that allows you to, to compose these things, you know, while spending a lot less money. More importantly, spend a lot less time. Um, I, I think that the The temptation by product people is to want to be the central character, but the, but the, the way I describe it is I want to be important but not central. And I think that's going to be where you actually wind up, you know, having a greater willingness to pay, and that's where there's better economic benefit. So that's why I talk to people when they're building their software packages, but it's also kind of where I recommend my friends over at Xano. I think that the, the The best stuff about it is when they're— when they can be that supporting player, you know, getting things out to where they need to go. And where Xano has gone most off the rails is when they are trying to be the central character. And like, I, I call it Xano for X versus X for Xano. Xano for X, fantastic stuff. Like, I'm using Xano to get to BigQuery, I'm using Xano to get to Vectorar, I'm using Xano to hook up to, you know, OpenAI. That's fantastic. But when it's X for Xano, like agents, but inside Xano. I don't, I don't know that I care all that much.

Like, it doesn't change sense because you take the MCP, you put it into ChatGPT. Putting ChatGPT into Xano natively and then putting a Xano MCP in there is quite a— it's not beneficial. I want to be mindful of my words here, but it's not— I don't see the value in it because Xano is a great layer. It's a great logic system. It's a great API gateway data router. Why even bother making it to the— into the next Zapier? I'm afraid if Xano continues the way they're doing right now, they'll turn into a Zapier in a few months. But I, I, I, I, I'm glad that you, Ray, are watching over this. And if they go off the rails, you're going to talk to Sean Montgomery, you're going to talk to Prakash. And you're going to make sure that they're right on track.

Well, we'll see about that. But I think it's also worth knowing, like the reason it's useful to have this kind of conversation is partially, you know, sort of like, hey, sort of an analysis of Zeno, but it's also worth just thinking about like, okay, what the, all of these systems, right? Like we talk about Norcraft, we talk about WeWeb, we talk about Zeno, we talk about like, you know, even things like Victora or what have you. Like Victora has like a whole bunch of other services. Like what are they really world-class at and what is the piece of it that you want to take out and like use that because they're really awesome. And then sure, there are these other things they're kind of faffing around with that are not as awesome and that you should be, you know, that they exist, but you should not be as exposed to, right? As you're building up and understanding the difference between these things makes you a better customer, right? Of these systems and therefore a better vendor to your clients, whatever business value you're trying to provide to your consumers, businesses, whatever that you then turn around and, uh, and work with. And it's not like, oh wait, like Bubble's the best. Bubble's best for what? Xano's the best. It's best for what? What is the thing that they do really well? Or multiple things, because they do multiple things really well. But then, uh, but that's not the same as saying, oh wait, because this thing has Xano on it, it is therefore good. And it's worth us keeping that in mind and keeping our senses sharp in this regard, especially when they are getting very excited about promoting things that might not be the things that are most valuable to people building great business value.

No, I think Xano, what it really does well is authentication, transactional database, APIs, workflows. NPM is really awesome. The lambdas, it's a very nice way to write Lambda functions and cloud functions. It's really good at that, and that's where it's worth paying for. Now apparently MCPs and tools too, where it starts to get more of useful thing that's like a toy rather than a tool is like agents, as what's it called, their expressions. And then a few other things like I think Xano Actions. I never really used Xano Actions. They kind of like promoted that's a new future how you can share stuff. I wouldn't necessarily trust the Xano community to use an action in my back end that is critical and someone could change unless they have like specific versioning and advertise it as secure. But I would never like install a package that someone else built on my back and I'm not insane.

So well, there's some more work we do npm packages all the time, but the—

but you know what I mean? Like with no code, I may be like a little bit biased here. But my expression of people building in Xano is most of the people don't necessarily know what they're doing. I'm trying to offend the whole Xano community here, but I would be careful on installing a package when it was made by someone within the no-code community. Sounds really bad for someone that is called No Code Pro Code, but—

Well, I think that's actually a really key point. Like when we go over to npm and we bring in npm package, we don't just bring in any npm package. The first thing you do is you go over to npmjs.com. Right? And you're going to go take a look at that package and you're probably going to judge it based on how many downloads it has, right? If it's a popular package, great, let's go for it. And if it's an unpopular package, you're going to treat it with much more skepticism. The thing is, anything you're sort of looking at in Actions is something that doesn't have a lot of action because one, Xano's user base is insanely small. Uh, second, the number of people within that who use Xano Actions is a really, really small population. And then within that, the, the number of packages out there just isn't that great. I'm not even that thrilled about the ones that are first party from Xano because my concern, not your concern about like them, you know, messing around with it. I'm concerned about them maintaining it. It's not clear to me how serious it's going to be. And that's because example, like something that's already a weird and interesting thing about Xano, but not a core thing. That's why the core things you were talking about, I thought that was like really on target because that's Xano for X. Yeah.

I mean, Xano's Stripe plugin, Xano's Ably plugin, Xano's Twilio plugin, or whatever they have, Xano's Resend plugin, or not Resend, SendGrid. Yeah, all pretty bad. Like, we have people in the office hours say like, I'm using this Xano Marketplace plugin for Google Auth and it's not working. And the first instruction I give people in office hours is just delete that thing and we'll build it from scratch.

Yeah, a lot of that like one-click stuff in Xano is not very good. I would say that like the one-click create CRUD endpoints is almost always an anti-pattern.

I, uh, never seen anybody who used the one-click create CRUD endpoints who's after one year still using the one-click. Yeah, delete them at some point because it just becomes a mess.

Yeah, and they don't usually come— there's a question of security, there's a question like just what you're looking to do, because the, the, the one-click versions sort of take away one of the biggest benefits of Xano, which is the, the function stack. I think understanding Xano less as a REST backend and more as a remote procedure calling backend makes a lot of sense. One of the reasons why I sort of had courage once upon a time that they might look at the JSON-RPC directly, um, not And, you know, I heard their, um, uh, their, their, uh, agent huddle, uh, agency huddle, like, you know, what they were talking about, like people buying professional services for Xano. And they made some allusions to it. Maybe they're going to wind up doing that stuff. I don't really have any insight into what their product roadmap looks like. In fact, I would generally say that, like, I would not trust their product roadmap because, uh, I remember when, uh, Sean Montgomery sort of announced, or said, at least in the Slack as it then was, of the, um, of the Xano community that like, yeah, we're gonna have the, um, you know, and, you know, support for npm packages. Um, and I'm bringing that up because it was 2023, uh, and they came out with it in the second quarter of 2025. The— and that's which is, which is fine. I mean, things come out when they come out. But like, and there's also a long history in software of people saying, I'm about to have this thing, and then it doesn't come out for a long time, or maybe never comes out, or whatever. So like Best. Yeah, who knows what the future is going to bring like that. That's why focusing on like what they do well today is a pretty good mental model for deciding what you want to use them for today instead of asking what am I going to invest in them on, like what's the vector for it.

Yeah, I just said like, like, that's been offline mode, something that should happen, it hasn't happened yet.

I can see that being a relatively challenging technical problem.

Yeah, it's quite a pain. I mean, I'm waiting for the web platform to adapt this new framework that they propose where you can turn the whole application into a single file using an API and then you can cache that and then load that when it's unavailable. That would make it so simple. But service workers, we had some example implementing service workers in there, but it just makes real-time applications not real-time?

Well, any caching will by definition make it not real-time.

Yes. So we have to be like a little bit— so we actually have one proposal. The whole idea is you're going to have two web views over each other. Uh, one will be hidden, so it will be not loaded, but one web view will be your offline version, one web view will be your online version. Your online version is not caching, so you wouldn't implement any caching any service worker on your application. Then the offline one will be proxied with a service worker. Then when the application is offline, that one hides, that one shows, and then when it's online, that one hides, that one shows. That is the theory.

It's harder in practice. Yes, I can imagine so. I've been hearing good things about Despia lately. Can you tell us a little bit like what— I know you've been working your butt off on a lot Despia-related stuff. Um, can you be giving us a little bit of an update on what's going on with Despia?

Uh, we added one very cool feature that I think is, is, uh, very important because App Review used to say, hey, we don't like those metadata, this metadata, like you're saying we're using your camera because you clicked on the camera button. That was what we hardcoded in there. But you know, sometimes App Review doesn't like those generic descriptions why you use security stuff. So now we actually let you change the whole app metadata data. So we built— I built like in like half an hour, really quick, like a visual interface for you to set that up. I published it, and now we are back at every app that submits gets approved without issues. Because some people came and says Apple told us we can't submit the app unless we change the naming of those, uh, of those, um, info.plist items. I was like, we should build an interface for that. And the nice thing is, because we are built on top of Xano, It's so simple updating that backend at 3 AM in the morning, you know, when those things occur. So we're using no-code as an asset, not as a liability.

That's an excellent point. I think that thinking in terms of assets is really valuable when building out a business. We just had our marketing mastermind in StateChange earlier today. Ah, what is the next one? We're doing them weekly now. Oh yeah, so, so, so Say Change, we, we've been shifting around Say Change, um, I mean, totally lose thread on like, you know, the assets thing, but like we're, I suppose, a little bit like thinking about what are Say Change's assets, um, the, uh, the, we, we're now doing two mastermind type calls per week, one on marketing and one on AI, which have been just fantastic. We've been doing them for about a month now. And the, uh, the— and we also now have, uh, and that's in addition to like the office hours, uh, that we do every day. Um, and that's been, um, really fun and really keeping us focused on like creating the best value. And hey, there's a little QR code if people want to learn more.

To join Ray right here at his office hours, it's definitely worth all the money. It's worth the $39 and the $149, and it would be even worth $1,000. Month.

So make sure to sign up before he increases his pricing because I said that. Yep. Uh, the, the— that's a— thank you so much for that. Um, but, but that idea, like, it's about the business, right? The business. And my joke is that most technical problems have a business solution and most business problems have a technical solution. And like, just having, having that permission sort of feed that back all around has taken us from being a, you know, sort of a low-code fix-it zone, which is kind of where it started back in 2022, to really being much more about people, you know, building things that make money.

Yeah. Oh, also, I got good news for you. Remember how I told you last time that the whole Despia runtime didn't work on iOS 16 anymore because Apple changed something? Yeah, we fixed it. Congratulations. Turns out for every problem that Apple creates, they add a backdoor. There's something called device checks.

Yes. Perfect. And now you're able to like just have your code go through two different flows based on—

Yeah. Yeah. So we fixed that. Also, we're going to have a native WeWeb integration. Don't tell the WeWeb team though.

Okay. It's unofficial.

I found a very interesting creative way to get a native Despia integration inside of WeWeb because 80%, 85% to 90% actually of all Despia users are The web users, so I was thinking, yeah, that's our main priority right now.

They're going to want that. Is that being done through like just hooking to the URL from publication, from, from when they publish it?

Um, no, I mean, that, that already happens. You can just do some JavaScript. But what I did is I built a component that exposes component actions and component events that you can drop on every page that will then allow you to call those Despia SDKs without having to write code. Something I don't have in Norcraft is because they have the package system, it's like anybody say, hey, I can't write JavaScript, I don't know if I should use Despia because I don't want to write JavaScript. In WeWeb, you have that quite a lot where people were hesitant to use Despia because they didn't want to write JavaScript. Now they don't need to write JavaScript because we have this component they can drop in and that web component then gives you access to all the events to get the data out of it, to set the variables, it lets you call actions using the components. So it's, it's a really nice way to set that up. Super cool. You can just dump it in. You don't have to write any JavaScript because right now you have to copy and paste the code from weweb.despia.com because now we actually have separate documentations with videos only for the Weweb community to make sure that they get served the best because they're our number one stars because they make about 80 to 90% of our customers.

Very interesting. Uh, so, uh, if you don't mind my asking, I might use that sort of turn into, you know, another little bit of market analysis, because the two big front-end tools that we talk about the most— or, or that— or actually, I've seen you sort of iterate through three of them, right? I've seen you work with Wized, I've seen you work with, uh, Norcraft, and I've seen you work with, uh, WeWeb. And what, what's, what's your view of the, the state of play among those three? WeWeb components confuse me. Okay.

They're quite confusing because I want to write vanilla JavaScript. So I actually tell WeWeb AI, I need you to create a component that's just a proxy, lets me do everything in a runtime.js file. And it works. That's how I do that. Is it— would now the CEO of WeWeb look at that and be proud of what I'm doing?

Probably not.

Because the whole idea is that it's Vue, but I don't like Vue, I like vanilla JavaScript. So from that regards, I like Norecraft better because vanilla JavaScript, that's as far as I came with learning code. But with WeWeb, the AI is really helpful. It doesn't just tell you what names your variables are, it actually does things for you. And there is a reason why most Gatsby users are WeWeb users. I mean, if I count at the signups, actually, WeWeb is just half of the user base. But if I take a look at the customers that actually convert, 90%, 80 to 90% of that is WeWeb. Why? They found thanks to WeWeb's AI, people get to a point where they actually want to ship their application. Where with Nordkraft, you can't believe how many Nordcraft and Webflow apps that are in the Despia database. If I click on the link that go to a 404 page because it doesn't exist anymore because the person just quit while building it. Okay. So I found that if you get— if I get a WeWeb user to sign up into Despia, they have about a 10% conversion rate from the moment they create their account. To actually purchase the license. With Warcraft, it's like maybe one.

Same with Wist. So that brings me then door number 4 that I wanted to be asking you about, which was Lovable, right? The, um, you know, the, the, the people who are coding their app and then distribute through, through, uh, because with Lovable we get people to convert.

Yeah, but I'm going to— I have like day and night to do with them. They're, they're asking lots of questions to the customer support. I'm I'm happy to help everybody if they ask lots of questions. It's just with Lovable, it's like I'm getting questions like, when I open the application in Desperate, the whole screen is white. Why is that? I said, it seems like an issue with your React router. And then they're like, oh yeah, yeah, thank you, thank you. Just fix it. So I'll be doing, when anybody asks you Lovable URL, I know I'll be doing React customer support.

Sure. I'm sort of wondering like—

Now thanks to them, I learned React. I know everything now. I know React Router. I know Next Router.

Next Router is funky. It is kind of funky, especially solving a lot of problems that like Despi doesn't care about. Because right now I'm using Next for the state change, you know, main marketing site. Which I'm making into a more interesting app. But yeah, because the server-side rendering has caching, it's better for SEO. But for, I got to say, for almost all the micro apps that make up SayChange, I'm using React Router because it is simpler and a SPA does the job very, very well. Yeah. You get great loading times and all that.

Once the app is loaded— You get an app-like experience as great as the loading time for a single-page app.

Application could be, of course. Yeah. The— and I'm looking into like doing—

so anybody, anybody who's trying to build a tool for no-code community on top of there, there is a reason why Xano is heavily marketing with WeWeb. You know, like you have all those meetings, like all those webinars, WeWeb and Xano, because WeWeb knows that people who use Xano ship their backend And Xano knows that people who use Xano and WeWeb ship their backend and ship their frontend, which, you know, helps them make money. Yeah, yeah. I found that we want more WeWeb users for Despia, and I want more Norcraft users for my community. So, okay, that's an interesting point, very interesting point, because, you know, it's exciting to get to see that people are using your framework to get applications on the App Store. And we have already a handful of applications that are built in WeWeb on the App Store. And we have like one made in Norcraft on the App Store.

Interesting.

You know, I found people actually are abandoning sometimes their projects. And I want to help them because, you know, I'm using Norcraft. I like Norcraft. But the problem is there's lots of abandonment. Same with Wist, where with WeWeb, and I don't like WeWeb, but if I have to build an application, I wouldn't use WeWeb for it just because I like flexibility that I get in Norcraft. I like working with the web. I like running my code and componentizing my code and having HTML events. I like the fact that it's so close to how the web actually works. The code I would usually write. But I have to say that it's very rewarding seeing people who start using Despi actually finish their application. And the majority of people who finish their application that I see, that I'm looking through our database, use WeWeb. So while WeWeb is half of the people that sign up, it's 80 to 90% of the people that purchase, meaning they're shipping directly.

Application.

So it has a greater success rate of people actually getting their business out there and starting to make money.

Oh yeah, yeah. And I think that that becomes like a key activation thing. I think activation metrics as applied to like—

yeah, we don't charge you for the journey like that coding tools, so we charge you for success because, you know, we charge you to get on the App Store. So I, I have a, I have a business interest— that's called business interest— in people getting to a point where their application is done as soon as possible. And we have that with WeWeb. Abandoning Nordkraft. I will keep the Nordkraft package alive even if I'm the only user.

Right. Because you are using it. That makes it great.

I am the only user who actually finishes the apps.

Yes. And we got Johnny. I, I was thinking about this and, and reminded of a story I heard a few weeks ago, um, in which a, um, a consultant who was helping a guy out where the, the client was like building in WeWeb and they'd hired the consultant to like work in Xano. Um, and the, uh, and basically what the kind of the, the, the Xano work was going gangbusters. Of course the consultant knows what he's doing, uh, and the, uh, the client was slowing down on the website. They just didn't really have the time. It started getting bigger. How do I do this? It's all, you know, we've all seen this before, right? Like these things can be a little bit— it can be easy start and then you sort of get into the mid-zone. Like you can't really— you don't see either horizon. You're just starting to sink. And the— what, what the consultant did was he sort of looked at the app that had been sort of scaffolded thus far. He turned around and rebuilt it in less than a day. Using Lovable and then handed it back to the client. And the client then was able to sort of just move fast again. And that was making the whole experience go a lot better. And then the customer, the, the, the, the consultant gets to keep on doing their standard work. The client's having a much better experience. I, I kind of wonder whether, you know, the, the, the drop that you were seeing— I think there's a lot of drops on, uh, WeWeb as well, um, because of that slowdown factor. And the big advantage of like the Vibe Code tools is how fast you get to go.

Lovable is a very small market share of Despia, but from the 5 people that signed up using Lovable, 4 of them upgraded and shipped their app.

Cool.

I mean, I'm still— it's only 5, so the market share is rather small because if you're building it in React, why not use React Native?

Right? Um, well, that— I think there can be a good answer. React Native is not the same as React. Uh, you get to get a much better— you get a much faster, you know, learning curve on it. Uh, I, I mean, I don't know, like, I, I think there's probably a lot of market value for you to get because Lovable— I mean, Lovable's at $100 million ARR, man. They have a lot of customers. It's a good point. It's a good point.

Gotta add the logo to the website and I gotta, I gotta get some more energy drinks next to my computer so I can do customer support or nothing.

People fix the React Router. Well, I think also that that sort of tells a story about how much value— that doesn't require you to be changing your product, that's just about documentation, right? Yeah. And like much of this, how much of you being successful, not just you, but like I think these tool vendors in general being successful is about their commitment to and execution on the documentation side.

No, I don't fully agree. But yeah, the problem with Lovable is you need to create prompts for them and the AI is very vague in how it works with it. So like in WeWeb, you can copy the snippet and you can paste it. In Lovable, copy JavaScript snippet and pasting it, they say connect with Despia. This is, oh yeah, absolutely. You're just going to call window.Despia. The Despia.EnableBiometricAuth function. And I would say I've never heard of that function before.

Right. And then this question, like, you know, how to get integrations going with it, right? Yeah.

But that's where we're going to add the MCP server to Despia. Actually, I just spelled it. So then Laravel can, you know, does Laravel support MCP?

I think it's like Cursor that does, right? Cursor supports MCP. It is not obvious to me that Lovable supports MCD, but Lovable does support things to give it context. You can give it additional context both through giving it URLs as well as giving it a—

When who vibe codes an application use Despia? I never found a use case for that because if you can do bold.new and just use like expo.

Well, you can use Expo, yes. That's how I do most of my native development. But then again, I look at native development differently than most other people do because most people will look at like, hey, I've got basically a web app, it's got rectangles, it's got buttons, it's got data I'm displaying for you, and now I want to be able to have that run on a phone. My bias towards using phone stuff is I will make a native app really around it being using native functionality, using the compute, using the sensors because that's where it can create value that a web app just doesn't. With Despi, you get access to native features. Despi does give you some bridging on that. It's a question of do you want to be using the React Native approach or using Despi approach for those features? But I think there's a much bigger market and I've experienced this. Lots more people want what I consider to be boring apps on the phone because there's a lot of need. They're trying to connect their business, their store, their whatever it is, and make that available to their customers, and there's a lot of value in that.

Yeah. I agree. I'm just saying in the HFAI, it's not that good of a selling point if someone can just write code and application in React Native, get it on Expo for free compared to me convincing you to build it as a web application first and then pay $200 $149 for Despia. Despia usually is for people who use WeWeb, who use, uh, who built the application themselves in Vue. It's actually really nice alternative for Vue, um, and all those kinds of things. But I, I don't find, like, if you vibe code with React, I found actually Expo is probably doing a way better job.

It gives you a bit of community as well, and, and it's open source, most of it. Uh, yeah. Uh, and like the, the, the, the Expo services are pretty good too. Um, uh, the, um, yeah, I, I certainly take your point, but that's, uh, that's just where the, the market keeps on, keeps on turning. So, uh, what are you looking forward to for next week, man?

I hope that the next one we're going to have RevenueCat integrated into Despia.

Oh, I've been hearing about that. Have you, have you yet looked at the RevenueCat? RevenueCat has a The Shipathon, right?

Shipathon, exactly right.

Yeah.

Yes. I mean, that's what we need to integrate. It's just they're not responding to our emails that quickly because it's probably off the Shipathon, you know.

Well, flip it, man. I think this should be part of the Shipathon.

I think so too. We just gotta, you know, have them hurry up a little bit so we can get the integration going.

Yep. Um, how much time is left on that thing?

I have no clue.

I'm—

my deadline is getting the— my number one priority is getting RevenueCat into Despia so people don't have to work with JWT tokens anymore, just to provide the experience.

Absolutely, man. Cool. Uh, well, we will see what is new in the, um, in the, in, in the coming week.

I will have introduced the new, uh, state change assistant, so I will be able to talk about, you know, give us a look behind the covers, like how you build it, look let's look at your cursor workspace.

Yeah, totally, man. Next week. Next time. I would be absolutely delighted to do so. Wonderful. That's fantastic.

Thank you for watching. It was a pleasure talking to you, and we'll do this next week, and I can't wait to learn on how you build your AI assistant.

Look forward to talking then, man. Take care. Bye. Bye.