NoCode Chat

acquisitions, and if you're getting acquired by a company, that you're not actually getting the money. Maybe that's a good way to start today's session.

Yeah, the, um, I think when people see like, hey, this company got bought for $100 million, they imagine, you know, uh, you know, a bunch of armored cars full of, you know, money that's being wrapped up, being delivered from one company to the other. And that's actually not usually how these things work. It's usually a lot more boring than that. So what happens is you have your company and your shares are worth X, and we're going to trade your company shares for a certain number of our company shares, right? So if we are saying, you know, we're going to take your 2 million shares and we're going to buy them, and we're going to trade each one of your shares for one share of our company, and our company is, you know, currently worth $30 a share, well, then you can sort of take that millions and multiply it and you sort of come out with like what the, what the valuation is. Right? And the— usually in these, what you see, the big sales are heavily, we're giving you stock, right? And then that way you have now an interest in our success, and you're only going to make money on the other side of that. So like, uh, they're— then the, uh— and so if you're, if you're selling to a private company, often that means you sold and you get to put something on the scoreboard, but that's Not the same as like having a bunch of riches because you can't sell that stock, right? You're stuck with it because it's private. Usually you get some amount of cash and you usually get like a job that goes along with it. So when you hear about an acquihire, what you're usually seeing is they get almost no cash, they get a job, and that job might come with participation in the option pool, but they're not really getting much equity for it. And then you have companies where they're getting basically more shares of the company, right, in return for the comp. And when you're selling to a private company, that is, well, that's not very liquid, right? Like, it's funny money. And when you sell to a public company, public companies work basically the same way. And then, but then you can do something with that money. Mark Cuban, right, the owner of the Dallas Mavericks, you know, famously made this trade where when he sold one of his most successful companies called Broadcast.com, he sold it to Yahoo., right, like back in '99, 2000-something. Uh, and Yahoo gave him a whole bunch of stock as a result, right? And then the, the thing he did was, in order to make that Yahoo stock look more like money, he purchased what are called put options on it. And so the idea is that a put option says, I am— I have the option to be able to sell a share of stock at this price. So they gave him a bunch of options, which basically, if the price went up, they'd be more valuable. And he bought these put options that basically, as the stock goes down, protects his downside, right? So like it says, he will always have a certain amount of value in a stock. And so by doing that, he was able to convert things from stock that are super, super high risk into something that looks more like money because money doesn't sort of fluctuate nearly as much. And it's one of the better trades I've ever heard from a startup guy. And of course, it worked out fantastically for him because, you know, right after he sold, The market crashed. And so those put options became, you know, really, really important to him being able to maintain his wealth and be able to go on to do the kinds of things he wanted to do after that, like, you know, buying Mavericks and all that. So the— which— and I bring all that stuff up because when you have public stock, you can do things like that to make it more like money. Like, hey, you actually did sell for $100 million. Whereas when you sell privately— and we were talking about another friend of mine who had sold for over $200 million. You know, but to a privately held company, even though that company is a unicorn and whatever, there's not much you can do with that. You can't hedge it because you can't buy options on a private company stock. Um, you, you're sort of stuck with, is this company going to be successful? And basically you've traded one bet for another until much later.

Someone said good insights.

That's very nice.

Thank you. How we just talked about it is we're talking about Base44 and how the CEO sold for $90 million. And I was jokingly saying that they still have a terrible hybrid mobile application solution considering they sold for $90 million. And then Ray told me, you know, they probably didn't get at all $90 million. This is how it works. And then I was like, oh, I didn't know that.

Yeah. I mean, Wix, Wix is public, I think, at this point.

Yes. So, so They, they— but I didn't know that you get it in stock. I thought you're going to get a check and then you have to be very careful walking to the bank with that.

When you're selling a smaller company, often smaller company can look like that. But like, when you often— you sometimes hear the term like earnout or what have you as it relates to smaller companies, and a lot of that sort of gets tied up in this idea of getting, uh, access to, to equity or whatever. And there are big tax advantages as well to using, uh, your stock as opposed to just sort of putting out the cash, as well as like, it's, you know, hey, you got— you can always make more stock stock, and you can't just make more cash out of thin air. So the, uh, these all become considerations of like, you know, when you're, when you're thinking about those kinds of deals. But that's also what we call a high-class problem.

It is a high-class problem. Yes, yes. I prefer to have cash than stocks because I don't know what they're going to do. I, I, I, I don't want to be— I feel like you— I don't feel like you have control if you have stocks from someone else's company and you can't make the decisions, but be But what I would prefer more than cash is being in charge of it and not having to be bought out. So that's why I prefer owning my stuff.

Yeah, there's definitely a, a control trade-off. Um, and then, you know, the, you know, there's a wonderful book called Finish Big, uh, by Bo Burlingham. Um, and, you know, in it he walks through a bunch of companies that sold out, and the ones that got the biggest price for their companies were the ones that watched the complete destruction of their companies. Because what happens is like your company is valuable at this level, right? And then the, uh, and then when you sell to like a much bigger company that's willing to pay a lot for it, it's like, oh, you're running this hamburger stand and this hamburger stand is viable and you're like, you've got customers, they're happy with you and you know how to make hamburgers. And then you sell to McDonald's or some other big, you know, burger chain, right? And what the reason they're buying you though is not because you know how to run a burger stand. It's not because of your burger stands, it's because of your special sauce, right? What they want to do is take your special sauce and put it inside all of their restaurants.

Kind of sounds like Wix with Base44.

Well, I mean, this, this, this really is like, if you want to make a big sale, it needs to look like that. Like, what's going to create huge leverage across that organization? And at that point, it's not about like being a multiple on your revenues., right? Because it's not really a financial acquisition, it's what's called strategic acquisition. Yeah, it's like, because you're now contributing to the equity through, hey, here's this additional asset that then has this big multiplier. Because that's kind of like— sorry, what?

It's kind of like Lovable bought like some cybersecurity software company for like detecting vulnerabilities in bad-coded apps or something. They bought them and then after then they kind of like completely disappeared. Or Figma. I remember Figma bought like for $60 million. What was it like a no-code tool like years ago? I remember they said Figma is going to be the next Webflow. They just bought this visual editor with database built in. And now a couple of years later, they have Figma Make, right? With the AI thing and the, and all that kind of stuff. So they just bought that to kind of like get some smart people or maybe get some, some systems that they have already put in place. Right.

So like really when you're buying, you can be— I mean, you can buy because it's financial, like, hey, here's this additional line of business which we're going to grow and get leverage on because we know how to sell it or whatever. There can be the strategic acquisition, which is you have an asset, intellectual property, some special thing that we can then bring to all these things. That's like the special sauce example from the, from the hamburgers. And then third is that kind of what you're getting at is like a lot of these companies are like, hey, it grew really fast and then sold. What those are often what we call acquihires, right? Because what you're really doing is like you have these great people and then what they're doing is paying off the previous investors and giving these people a really big signing bonus, right? In the form of, you know, whatever the conversion of equity is in return for sticking around. Like people who are really high quality and they will, they get paid millions for this. And the, and that's, and then, but when it looks like that, Right? So unless it looks like door number 1, which is the financial sale, the company's got no incentive to keep the old business running. Yeah.

Right?

If you have an asset, if I'm going to, you know, you take your special sauce and put it everywhere else, your hamburger, your little hamburger stalls are going to go away because I don't want to run your little hamburger stalls. I want to run McDonald's and we just made McDonald's 5% better and making McDonald's 5% better is worth 100 times what your hamburger stands were. If you, if I just want to hire you, I want to hire you to work on things that matter to my company, not to keep on, you know, tinkering with whatever you're working on before. So now we're going to fold you in. And you see this, you know, repeatedly, even if they're going to continue to be like the cybersecurity group. I don't want you to be doing that. I want you to be doing this thing for Lovable or whoever it is.

Yes.

Yes.

That's how that looks. Very interesting. Yeah, very, very interesting. And I figured out by looking at kind of like right now, all the acquisitions that are happening in this industry, live coding, most of the times those companies get bought just to get shut down. Like this big tool is buying this one. And then you kind of like, you know, like most of the times they either disappear, like with a cybersecurity thing, I forgot their name, or like lovable bot, like there's not lovable Webflow. Bought this analytic tool, Leargo or something, shut down, right? And Figma did this thing and it shut down. And if it's all prior or during live coding. And I think right now we see like a pattern where everybody who has something that's getting bought, it's because they have something special and either they don't want them to take away their market, so they just want to buy it away so it can't compete, or they want to buy it to put it into their product.

Right. To put, take your asset, put it into their product, take your people and have it work on my product. I mean, that, that's just, and, and like the, the, uh, I mean, you're, you're very close to it now, so you're seeing a bunch of it, but this has like been a continuous phenomenon over the course of the last, you know, 25 years of, of, of tech because it's question like who has the money and who has the talent. And then it's about—

I think it's so something that we're seeing more and more during, um, like with those no-code tools, like, like in the time when Xano was new, we didn't hear about this too much. Like, I— like, we only heard that they were all raising money. Like, they are raising, they are raising, they are raising, right? And, and now they're all getting bought.

Well, that's a really interesting point because I think some of that has to do with like the, um, you know, falling—

it's a new wave of gold rush because back then when we were talking about Xano and all done and WeWeb and all of that, that was already end of the no-code curve because Bubble started it and it was already starting to go down. Now there is a new curve and it's not, I don't think it's fully risen up yet. So I think this is where the buying happens. The buying happens when you go down, the selling happens, or the raising happens when you, the buying happens when you go up, right? And the selling happens when you go down or, uh, you know, the raising happens also when you go down because then everybody just buys. And then when there's nobody wanting to buy anymore, then you have to raise to kind of like make this thing profitable.

Uh, that's— I, I think there's a lot, you know, uh, a lot to that is also just how frothy it is. Like, you know, I think there are these little micro markets that are coming up and down where like, hey, this has been a really good thing to be doing in the fourth quarter of 2025, and now the market's sort of fading, and then now I need to be, you know, figuring out a different way of, of proceeding. And everyone wants to keep on moving fast. I, I think, uh, I mean, how many, how many times have I seen like the zombie startup? Like, hey, it was really good, it was moving really fast, and now it's sort of lost momentum is trying to find its footing again, it's very hard to get a restart. And the— and then, uh, and so what happens is really good people, they, they jump ship. So if you want to keep things moving, you really need to either, you know, sell or disband so you can move on to the next thing that's actually going to bring you 10x income. I'm, I'm—

I don't want to sound like I'm, I'm not, not positive, but I'm curious to see like the next couple of years for WeWeb because they've been around for a while. And I've been trying to use it a couple of days ago and nothing really much changed. Or what's your intel on that?

Well, I think WeWeb is making a bet that more visual control is going to be a very important part of what they do. And that the vibe coding allows you to move very fast. But there's a concern about danger, right, associated with things just sort of spinning out of control. And I think that the low-code players who are getting into AI, like, and WeWeb sort of is in that category, are basically selling a guardrail story, I think, a bit more than most other things. And like, the trick is they need to be able to move fast and offer the guardrails. And the guardrails can often slow things down. Like, in a naive implementation, security is going to cause friction relative to speed. And, and be able to maintain that balance is something that they then need to do super well and hope that somebody else doesn't do it super well.

But also, I, I feel about that— I, I did try to work with WeWeb, and I'm surprised how slow it is for being a single-page application. I, if I build something in Lovable, it's instant. You just navigate I don't know why they're— what's going on with the router. You do it, you do it page navigation, it takes forever even though it's a single page application, right? Because it probably runs the API calls before it does the navigation rather than running them after navigation. Or sometimes the router strips away some hash parameters and all that kind of stuff. And I was like, how do I edit how the router works, right? But then you can't, you, you know, like, because then that, that's the part that makes it proprietary, that makes it low-code. So I found that when you go with low-code, no-code, those visual things you're losing so much control. And we're now in a market where we are exposed to so much control and we want the control, yet we still want the guardrails mainly for the visual pieces, but we don't want the guardrails for how the router works or how my single-page application is set up. Or maybe I wanna do a multi-page application, right? In WeWeb, you can't just like host a HTML file in between. Like that was an issue someone had with Despia. They needed to host a static file for to— because the router was stripping away the hash parameters for, you know, like Google implicit authentication flows through Supabase, and they weren't able to do it. So they would have to kind of like self-host and then reverse proxy an HTML file and all that kind of stuff to kind of like figure it out, which was a pain.

Right. And the visual control plane is, you know, That's a big promise. How do you make that work with the AI? And I gotta say, like the visual control plane I can get from, you know, like expressing myself through, you know, using like Claude code or one of these others, because then the gag becomes, oh wait, well how are you gonna control exactly what's gonna happen there? Well, first of all, I don't care about that most of the time. And the times I do care about it, there are some increasingly good methods of like, you know, taking the image and like, you know, annotating an image.

No, but also, also there— I'm, I'm surprised why nobody is doing this. You know, there's something called Craft.js. It's a visual way to reorchestrate React layouts, and it works with any React-based framework, possibly also Vue because it's also JSX. Did we lose me or did we lose you? Oh, we're back. Okay. So coming back to it, there is something called Craft.js, right? And that lets you visually lay out applications, kind of like Webflow. It's open source. I'm super surprised why Lovable hasn't added Craft.js or Bolt or any of them. So you can say, I want to move that button from here to here. Now, what I assume what the problem about that is, because the code that the AI generates is not well thought out to work that way because in React, you can't move a button from here to here because then you're also like, the hooks aren't attached to it and all that kind of stuff. Right. In React, the component context is, you know, what brings the entire functionality. That's why Cursor did visual edits. But every time you drag it from here to there, you have to spend like 20 tokens or something because it has to refactor all the things attached to it. So I think the future may be creating a React ecosystem where you place every component in a slot and that slot has its own state, has its own communication, and the slots then communicate through each other with like web signals or something.

Well, that's what you're talking about is web components, right? That this is a lot of theory of how— yes, yes. And, uh, the, the place I'm seeing a lot more use of web components is in what we now call MSP apps.

Because you want that flexibility. Exactly. Yeah, I think, I think Nordkraft has a whole, whole business they're not going after because in Nordkraft you can build web components, you can build great web components in it. I don't know why they don't have a no-code MCP builder that lets you build your visual interfaces for your MCP servers. I think they should be jumping on that train because they do have the entire infrastructure and worked years on getting it. I don't know any visual AI-enabled tool that just, just does like 1% of what they can, yet they're just completely sleeping on everything AI. And I'm sorry to say, because I do like that tool.

Well, uh, yeah, I appreciate your— you, you, you are a fan of, of Norcraft, and, you know, uh, Andreas, their CEO, has thoughts on the subject.

He has thoughts on AI, yes.

Um, I think there's a question like, how much control do you need versus how much observability do you need? And like, what kind of controls are really going to matter. And I think there's also a question of all this work that's going into building something like a WeWeb. I mean, often it's— sure, it's a big complicated piece of software that offers you a lot of control, but also offers everyone else a lot of control. So what they're trying to do is make the software that allows—

I never found that WeWeb is giving me that much control. Maybe my definition of control is slightly different to other people's definition of control because in WeWeb, I can't build my own dropdown. I have to use their dropdown and I can't put div blocks and div blocks and div blocks really and have an easy way to manage state. I have to use their prebuilt Vue component and then I have limited customization. I think the argument nowadays that no-code visual editing is giving you control, it's not really true because you have more control using Lovable or Cursor or Windsor for literally anything because you can customize every little component to the little pixel of it if you are patient and prompting.

Yeah, we actually had somebody in StateChange who basically Ralphed his way to pixel precision of taking a design from a, you know, Figma or what have you and having the web app be able to match it exactly just by having the AI loop through that because what he had was like the baseline. And then that means like his control, if you will, came from the work he was doing on the design tool side. Not the work he was doing through the development tool. But the thing I wanted to throw in there was that your point about how much control you feel, I think is a point that's well taken because what they're trying to do, what many of these low-code builders were trying to do, the thesis of low-code was we're going to build a better environment for you to express your intent and that this one environment is going to be good for a lot of different people expressing a lot of different kinds of intent. It was supposed to be more generalizable. The trick is AI can beat that by saying, well, how about instead of we use your tool that's trying to solve a whole lot of edge cases, I make you a tool that solves just your edge cases. That becomes the thing I think gets slept on sometimes in the world of AI-driven development is that you're not actually— it is not to use the AI to drive your development, use the AI to make the tools that can drive your development. Yeah, like by introducing additional level of articulation, you can actually express a lot more intent with a lot less time. And while, you know, asking the AI to remake WeWeb would be a huge lift, asking it to make WeWeb for me, yeah, smaller lift that it can do.

And then, you know, that, that feels— starts with Craft.js. It's my favorite library now. Okay, it's great. It's like essentially open source Webflow you can just use as a React component.

There's a lot that you can do with it. And then, but you know, I look at it and think, well, actually it solves a lot of very simple problems that I just don't care about, you know. But like, that's the amazing thing. You haven't seen my problems though. Sorry, what? I said you haven't seen my problems.

My problems are all UI related. I wanna, I wanna put the button to the top.

Corner manually, you know. Got it. Well, that's a really good point. So like, the thing is, like, Craft.js is something that's gonna make more sense for you and probably for like, you know, let's say 1,000 other people. And then there's something else that makes sense for others. In fact, when I look at— the thing I find is that the thing I wish it would do more of is shop. Because to your point, like, if Craft.js can solve a problem for you and 1,000 other people, I bet that would, you know, significantly decrease, you know, work if it would just sort of start with a tool like that. Whereas I think the a fair knock on cloud code, etc., is that its first instinct is it wants to go write. It's like working with a junior engineer. They want to go code, right? Whereas if you're talking with a senior engineer, they're like, how can I avoid coding?

Yeah, very, very insightful.

Very insightful.

I think that that does make sense. But I'm very interested and, um, you know, I, I'm just looking at all like Bubble is now doing AI. WeWeb is doing AI. Norcraft is doing AI. Webflow is doing AI, even though I've never heard anything from Webflow recently. And they like, I feel like they completely fall off. But, um, from my opinion, the, the best one, even though they have a terrible AI, the best one still is Norcraft because what it does, it's, it's OutSystems for people who don't wanna spend 100 grand for it a year. That's how I describe it. Also, I can't use OutSystems, they're the enemy.

So, uh, okay, well, why is OutSystems the enemy?

That's an interesting point, because they own Capacitor now.

I see, because they bought Ionic. Well, that's been 3 years now. They bought it so a few years ago. Yeah, um, but they bought it before, before there was Despia, right?

They were, they were there Technically, Despex exists since 2011. Like, they're like— my business partner got some beef with Capacitor, but got it.

But that's, uh, but you know, they're— oh man, this stuff is just moving so fast. Can I ask, have you been doing any, uh, cloud botting?

No, no, I've, I've heard everybody talk about setting up a little Mac Mini in their office And there's like a service here. They come to you and set up a Mac Mini for 5 times the price of a Mac Mini and to like set up your virtual employee. I just haven't been interested in it. I was like, it's probably not going to be that good because if I have AI do complex tasks on my computer, like I don't, I don't believe it's going to be that good. We, I do run a business. That makes money by running Mac Minis for other people autonomously. I know of the error rates that can happen and it took us 2 years to get it working correctly. So my overall enthusiasm about having a robot control a Mac Mini is rather limited after those 2 years of pain and suffering. So, but if you have any insights, I'd love to hear, but I also think Mac Mini is probably not the interface you wanna do this on. You probably want to have a specific device that is only made for AI inference, which is going to probably be half the price because a Mac Mini has a human interface. It has a whole system that it doesn't need if you're just trying to run AI agent, right?

Well, it depends on what you want the AI agent to do. One of the big insights I think about using cloud code locally, and that cloud code gets good at in a way that Claude and ChatGPT and others aren't, is that by moving, by being more local, And having, you know, one, you get access to the file system, which AI is much, much happier with than doing like cloud-based resources. Oh yeah. And this is something also terrifying to no-code, low-code vendors, 'cause a lot of them are basically about cloud hosting and like, okay, but, but, but if local is better, what, what are we doing here?

I mean, I do love Cursor. I use Cursor all the time. I, I think, I mean, everybody tells me you're spending money on credits that doesn't need to be spent on Cursor, but I, I like the convenience of Cursor. I don't mind paying extra for it. I just like, that I have everything in Cursor. I don't have to work with VS Code extensions and plugins and then I lose the chat and I can't find the icon anymore like with— I tried Cloud Code. I like the convenience of Cursor. It's a company, they run everything for you. It's convenient. It's what you taught me. I'm already used to it.

One aspect of access is the fact that it's local file system. But the other, and this is really important, is there's access to you. And the reason why it runs on a Mac Mini is so that it can do like computer use things to like operate software that's logged in as you, uh, to go do things on your behalf. And that really, I think, I think that gets like the, the crux of it is like instead of a, I'm gonna go over to Zapier and I'm going to start wiring together in automations, like you can just say go do a thing. It goes, oh, okay, well I guess I better go open up your email. And it goes open up your email browser.

I'm doing something similar. I'm doing something similar, you know, like generating bundle IDs and linking them is a pain with Apple. It's a process and many people are not willing to do that. I'm right now building a Chrome extension that you just log into your Apple developer account, you click a button and it goes through all the pages and sets up all your bundle IDs automatically. One click sets up all your app groups and wires them all together.

Yep. It's called Agentic Browsing. And I think that's a fantastic idea., but it doesn't use AI.

I just built a whole JSON-based script and I essentially built my own. So what I did is, you know, like Fastlane Spaceship.

Mm-hmm.

I built it. Yeah, sure. As a client-side Java, I built it as a client-side JavaScript library that can execute in a Chrome extension.

No iCloud password needed.

Got it.

So you, you're using Fastlane JS?

No, no, there's no Fastlane JS.

I invented it. Well, you're using the Ruby version of Fastlane.

Okay. No, I'm not using anything Fastlane. I just re-architected how it works and it's all written in JavaScript.

Yeah. You relearned how to use the App Store API by reverse engineering SpatialOS.

No, no.

It's 100% unofficial. Yeah, sure.

Well, I like that reverse engineering.

Yes. Yes.

Yes. So I went into the console and I saw what internal APIs is Apple calling. And then the issue is you can't call them from their server. Then it would be against their guidelines and you get your account suspended because they can see it. But I was like, if you build it as a Chrome extension, we can make the network requests with a big enough delay to make it look like a human is executing it from Apple's own origin. And that's what we're doing. And it works. And they can't figure out they're using the extension, right?

Cause it runs from developer.apple.com. Right. So you have your origin, which is just gonna be whatever the website is. Yes. Uh, and really what you're doing is providing them with extensions so that they can just sort of walk through the process because you're sourcing it.

It will navigate pages and it will look like a human is doing it, but it's all automated based on a script. And the thing is like you don't, because like I looked at Expo, how Expo is doing it, you need to put in your iCloud password in there. I don't trust myself in handling iCloud passwords from people, so I'm building a Chrome extension that doesn't do any network requests to my server.

With a password. I think that's a fantastic idea. I love that. Love the, the, um, how can you push the logic back to the person? In fact, that's very much like the idea behind, you know, ClaudeBot and these others is like not having me—

I'm going to make this way simpler because you don't have to install like something on your browser computer. It just is a Chrome extension. You can open the network tab, you can see what it's doing and where it's sending your data, and then you like, you can observe how safe it actually is. That, that was the important thing. And I built it actually in Nordkraft. And I built a custom extension bridge. I built a custom extension bridge in Cursor as an npm package that then my Chrome extension is consuming. And then I have like kind of like a WebView Chrome extension, just iframing my love, my not lovable, my Nordkraft application. And then I built a custom Nordkraft package to consume it. Manual because I wanted to have a nice interface. You know, I'm obsessed about interface.

Yeah, the— yeah, and I really like that idea of using that Chrome extension. And there's a broader theme here of, I think when we're looking at the stuff, say, 5 years ago, it was about how to move things from the local machine into the cloud, like the— and a lot of what you're paying for with no-code, low-code systems was really the hosting, right? Hey, you've got this thing that's going to be out in the cloud, it's going to do things. But even what you're discovering is a lot of the big value is sitting locally, right? So it's a Chrome extension you need to run on your computer, Cursor, which is going to run on your computer. Making use of that local compute starts on the local file system becomes a big source of value in 2026 in a way that we didn't see, you know, 5 or even really like 3 years ago.

And like, I think looking at those, you know, helps point us in the direction of like where the value I mean, I do think file system is very important and it will be even more important for mobile apps because now you want to access local AI models in your app and you want to store like data on the, on the application, on the device attached to the app that can be consumed by AI models in chunks and all that. And without, I don't want to ruin the surprise, but Despia is going to have access to the local file system. We call it local CDN, and you'll be able to store as much gigabytes on there as the phone can handle. So if you have a 1 terabyte phone, you can probably store like 800 gigabytes on there, on the app. And you can stream videos like full blockbuster length movies, hundreds of them if the phone can handle it. And then they can be put back into a local AI because that makes it very interesting because now you can run local AI models on this. That then run on the device.

Super cool.

I, I want to build features that impress Ray, so this is what's coming. And we have streaming. We're going to have a specific JavaScript SDK that will essentially be a fork of Vercel's AI SDK, just working with our local endpoints for streaming.

Okay. Yeah, to be able to offer a streaming interface for people.

Streaming interface, but it all runs on a local server, so it all runs on a local HTTP server. Now the North Star of Despia is the local HTTP server, because now you can make API calls and fetch calls and streaming calls to the local server that then has access to the compute and has access to the native file system, has access to the native AI models. So it'll be like calling Supabase, but it'll all run on your phone and offline.

Well, that's a really interesting point. Like, we started talking about, you know, local AI models. That's something you're seeing some uptake on or that you're doing with Despia?

I have no idea if users want it, but I want it, so I'm building it. And I told my team to work on it, so.

Okay, cool. And so just by having, you know, just APIs, API hooks, right, they'll be able to go down.

But they all like, they just, you just call localhost. To get like the whole thing. So it doesn't have to write into memory, which is a big issue because we have to worry about memory.

That's true, right? Uh, and then like, because JavaScript does not handle memory well.

Yeah. Yes. So this is kind of like, this is what we also built. Like, for example, if you have like a 5-hour video, if you use Capacitor, you have like IndexedDB, right? And IndexedDB has a file size limit of 200 megabytes. But what if you need a 1GB video? With Despia, you can make a POST request to the local HTTP server and send as much as you want, like the biggest blob imaginable, direct from a file uploader if you want, to there. It will then be stored on the server. And when you're serving it, you're not getting the blob. You're not getting it as Base64, not 44. 44 is a terrible no-code tool. 64 is an encoding. You're not getting it as Base64 because that would be 30% bigger and you would have to write it into memory. You can just use a source attribute on a video player to then put the localhost server link in there so it streams the video directly into the video element, making sure your application doesn't blow up on you. You can full play full blockbusters like Netflix or YouTube and all that stuff. It's very memory efficient, surprisingly, because you're just streaming it from the link. From the HTTP server. So that's where the native file system also on mobile apps can get very interesting.

That's super. Okay. So what's next for Despia, if I might ask? It's all month-to-month stuff.

So what's February for Despia? So right now we are working on a bunch of features. Let me pull that up.

Open ClickUp.

So here's what we're working on. We're working on HealthKit version 2, giving you access to every health identifier, because I, I slightly underestimated how much they are and how much there are and how much we have to add support for all imaginable identifiers, because there are people, they want very random values. So we're going to add all the, like, 99% of all the values, because you do have to pretty much add them manually into there. So there may be a slight maybe like 3 to 5 not fully supported unless we know, but we're doing HealthKit version 2. And then the big thing is the local CDN, right? That's what I talked about, the local file system. Then local AI models. So you can run local AI models with streaming and all that kind of stuff directly on your phone. One thing that we're still working on is making it run halfway decent on low-budget Android devices. Maybe you got some tips on that.

Well, what's the challenges are not having enough compute in terms of they're just slow?

Yeah, like it's not going to be like if you run it like on a $50 Android. Yeah. Like it's not that good of an experience, but I guess people are used to not that good of an experience on a $50 Android.

Well, I think there's something to that. If you're making something that's compute-intensive and you put it on something that doesn't have that much compute, there's a little bit of like what we're trying to have.

Downscaling. We are going to detect what the device can do, so we're automatically downscaling to a different model or showing you which model or giving you injecting an array of suggested models and then you can It's something like this. So we're working on handling those edge cases better as well. Um, and then we're improving the Android interface, so like getting Material UI in there and all that kind of stuff. And then we are, um, the big thing is going to be offline support for the apps. So that, that is multiple parts. We're going to add a full database in there, a SQLite database, so you can have like offline compute with database sync So what we're going to build is an SDK that will then sync with your Supabase, with your Xano, with anything. So the data is always in sync and up to date. Right. And then that the second part of that will be the local CDN to store big files locally on the device and serve the memory efficiently. And then the application itself will also be served from that local server. So it can work offline because that is, as you know, a big limitation of WebView apps, cause it is called web view, not offline view, and we're trying to make it offline view. Got it.

So that's the— oh well, yeah. And try to make the whole thing be able to work offline. I actually really love that. I think that once, once you do that, you will have—

oh, we already have it. We really have. We just like— I just got the message on ClickUp. It was just finished. The only thing that we still need to work on is the SQLite. 'Cause they just said like, you just call SQL queries, our developers. And I was like, yeah, people don't know how to call SQL queries. I want the URLs to look like Supabase. Like, you know, like how Supabase does it when you call Supabase, where they provide you those REST APIs and you can do like eq, you know, this. And so you have it in the URL, makes it easier. So we're trying to essentially copy exactly the URL structure for the database queries as the default that Supabase is doing. Because AI already knows how to do that and you can then reuse your existing calls and just take the same URL, just change the host to localhost and do the same queries.

That's super cool. Suibase is also all open source, so ripping it from Suibase would be relatively straightforward, right? Yes, and it's legal. Yeah, sure. That too. But it's also the thing that AI does really well. Is that kind of porting process. And so that's exciting and sort of shows like which parts— well, you talk about having a team. So like when you're doing your own AI-driven development, like which parts do you find you really need the team more for?

Like really—

Everything Swift and everything Java Kotlin.

Okay, got it. I'm not a Swift developer. I'm not a Java developer. I built Desca. So I, as a web developer, can build mobile apps I'm proud of. And, you know, part of building mobile apps is somehow getting someone to do the native code. I don't know how to write Swift. I can correct Swift. Like if I'm on the weekend, the team doesn't work and there's something wrong, I'll be able to fix it. And worst case, fix it with the help of Cloud Code, right? Like I understand because I know JavaScript. Swift is rather simple and rather straightforward and very close to JavaScript, I would say. Like, it kind of mimics React a little bit, right? Same with Java, mostly. It's just their strings are funky and arrays are not really arrays. Like, I don't know what they mean with their arrays. Doesn't make sense to me as a JavaScript developer. But, you know, like, I can understand my way around it. But when it's like about implementing all those kinds of native features, I can't do that. I know how they should be implemented. I know how the experience should be for a web developer or a web-based AI coding tool to set it up. I know the architecture and all that kind of stuff. I wouldn't know how to build the native code for it from scratch, or probably I would rely too much on AI for it to be a quality experience, right? So that's why we have a team that's working on the native code, that's working on all the stuff that's mainly native, right? And that's going to be my business partner and our team, John, and, you know, the team working on that because he's a real native developer. The idea about Despia is I wanted something that I can build powerful mobile applications and not like just wrap an app. I want to be able to build a powerful mobile app that can do everything a real native app could do, and if not, maybe even more easier, right? Using web technology. And that's what I know. I do the, you know, I do the web interface, I do the npm package and all that kind of stuff. I, you know, I say this has to be divided this way, it has to call this, and this should be the naming conventions for the JavaScript. And I tinkle with the bridge and, you know, improve the bridge. But the actual native implementation, I do need them for that because I'm not a native developer, I'm a web developer. And this is why I'm I'm number one user of Despia because it's a product that solves my problem.

That's a pretty good place to be. I see plenty of people sort of struggle like, hey, what's my product market fit? But if you are using the product, then it's so much easier to find it. You're seeing that both in terms of your own use, but then correlating with the market uptake you're getting, which is super cool. Yeah.

For example, I was working on an app just for fun. And I was like, how do I store videos in Despia? I was trying to work with the IndexedDB and I was like, no way, this is terrible. And then I put down a technical sheet, how it has to be set up. And I sent it to our developers and they were like, we don't know what you're talking about. We're not web developers. So I had to like explain to them how it has to be implemented on the web. And then we have to talk together and I have to explain them because they're like everybody, our team, They're all native developers. They don't know too much about web development. Then I have to come in and explain them how it has to be bridging with web development and then what things should be done native, what things should be done on the web and all that stuff.

It's always very exciting. Super cool.

Well, this has been—

Got a comment.

Yeah. Hello, I wrapped my first test version of my web app using Deska and I'm really impressed. I'm struggling to get notifications to work natively. Do I need to use OneSignal for this or APNs? OneSignal is going to abstract APNs, but one thing with OneSignal is that doesn't help right now with too many AI coding tools is they essentially change the entire thing, how it works. You're not working with player IDs anymore. You're now working with external IDs. And then the problem is they already have something called external IDs, but that is already discontinued. So it's now External IDs version 2. And if you tell most AI coding models, I need to set up external IDs for OneSignal, it'll look up their old documentation because it was also called external IDs. Now I think they did rebrand them now to user IDs. So what you wanna make sure is that you use the user IDs. The problem is that all our developers at Desvia are all OG. Like I think the first OneSignal integration that they built was like 10 years ago. Back then, like, like for Despia before it was called Despia, it was called Advanced WebView, right? And so it's still called OneSignal player ID with Despia because of all the legacy users, but it's now the user ID. So it's lots of confusion happening, but what you have to call is you have to call setOneSignalPlayerId://?user_id, I think it was. You'll find that on the documentation. Equals, and then you put the ID of the logged in user that will log in that user ID from the authentication session with OneSignal on the device. And then in OneSignal, you will see them appear. And then when you want to send a push notification through the OneSignal REST API, you need to make sure to use the latest REST API. I think this will be include external IDs. And then you just put an array with the first item being the ID of the logged in user, and then you can send a personalized push notification to that user. We'll also have that though on our documentation. I think it is setup.despi.com/native-features/onesignal. Super cool. That's pretty much number one question people have. Cause like OneSignal is very confusing. They gotta get their documentation in a row.

OneSignal and RevenueCat. Oh, well, now is that to your mind, is that because they're more confusing than average or because they're just more popular than average because notifications in commerce matter a lot?

The problem is like most of the times when people are using like complex APIs, like the iCloud storage key-value pairs, they work pretty well because I think our documentation is at least halfway decent. OneSignal's documentation is very confusing. Same as RevenueCat. They have multiple versions, like version 1, 8, Version 2 API, you don't know, should you be using version 1 or version 2? And then version 2 API only does half of what version 1 can do. So, and then you need a separate key for version, version 1 and version 2. And then you have a webhook calling version 1 for this and version 2 for this. And then AI mixes up the keys and it forgets. And then it says, let's migrate to version 2 from version 1, cause it's better. And then half of your stuff is broken, you know? So this is when we started making templates. If you go now to the Despair documentation, On setup.despia.com, we have something called best practices, and that's just like pre-made templates that we know will work. So you don't have to take a look at OneSignal's documentation.

Got it. And do you find people are sort of using it themselves or are they like farming out, you know, the Despia work to like the Cloud Codes of the world?

And they didn't do farm that out to any other AI agent. This is why those issues occur because then the AI agent is looking at version 2 and not version 1, right?

Well, that's a fair point. And then when you come into that, like, is this something you're looking— are you looking into like skills for, you know, for Despia at all?

We built the MCP. So we moved our entire documentation to Mintlify and that works amazing. Before that we were with Hashnode, but I think they didn't pay their AI invoice even though we paid them because every time someone asked the AI something it returned 404 error.

Oof.

Okay. Yes. So we had to move the entire documentation and now it's on Midlify, which is amazing. That's what all the tech companies use and they provide you an MCP that lets people and like, it's like a vector database and all that kind of stuff. So when the MCP puts a question in there, it like doesn't just reference the article named this way, it references everything and finds the specific text chunks that make sense. Providing context to the AI and it works amazingly. And the sad thing is Lovable charge people to add MCPs. Like if you add an MCP, you have to pay twice the money for credits, but now they removed it because I told everybody who was complaining about Despia, I said, please complain to Lovable about this. Got it.

So people will use Lovable with Despia MCP in order to get this done.

Well, like not just Lovable, like v0 cursor clock. It's just Lovable is the biggest one.

Right.

And, uh, and, and this is usually what, what people then use because we made all videos about Lovable. Cause you told me just, just focus on Lovable cause it's the biggest one. And then we now need to focus on the other ones as well. Like make videos for v0 cause Next.js is completely different. Right. But when I need to explain how to set up Despia on a React Vue application, I tend to use Lovable cause that's the most React Vue used one. Right. But then Next.js, you need to use v0. And then if you use Vue, you may want to use WeWeb or probably cursor.

Or Cloud Code, right?

All right. Person said, right now I'm making a chat function inside the app, so I don't know if OneSignal applies to this. Yes, if you have a chat, you don't want the chat to be client-side, right? This is probably— Ray can probably vouch for that. Like, you don't need that to be client-side. You need that to be happening on the server, right? This may be also a good thing for our next conversation. What's the difference between client-side and server-side? Because I know in StageChange many people say, I just want this to work and then we need to explain them. But this is an edge function and this is your database and then there's a cron job and then maybe you got something to say about that because I learned that from you ultimately many years ago or not too many.

But— [LAUGHTER] Well, usually chat, you got your client-side piece and then you have You have your server-side piece, which is usually handling a streaming connection, and then you have your backend piece, which is the actual model itself. You have these three layers to it. You can run— that's like your local server thing you were talking about becomes an opportunity to have these so-called server piece actually run inside the device, which is super cool. Then there becomes an even cooler opportunity to have that then run with a local model. Keep everything offline. So that, you know, you still have those three ideas in those, but where those things are located can be anywhere. Where the one single thing comes in that I think is interesting is not to be managing the chat, right? Because you're thinking, hey, I send a message and then I get the chat back when it's going to reply. Usually you just have a streaming connection for that to manage that a little more straightforwardly. That's sort of the Vercel AI SDK thing you were talking about. But the, um, or one signal I think becomes interesting for it is like, I don't know if you've done this before, but like if you can, you know, kick off something on ChatGPT and mobile and then go do something else and you get a notification later, hey, this is done. Yeah, yeah, that's where using notifications like, or whether through OneSignal or otherwise through APNS and through, uh, uh, GCM, um, becomes really neat, you know, because that's— yeah, well, sure, uh, but it becomes a mechanism for it, like, to be able to send that reminder. So when someone has decided, yeah, I've done my thing and this happened, go somewhere else, be able to have the reminder that then brings them back. That would be the use case I think about for OneSignal. So it's not necessary to make the app work, but becomes a really cool, you know, plus one type feature. Yes.

Oh, this is one maybe I need to ask you about that. Uh, there's a problem with Desvia for Android 16. The app doesn't work good in Android 16. It works good on Android 15 and 14. It happens with Desvia version 3.5 and a customer supports that they're trying to solve it. Now the issue, I know about that, the issue with Android 16, Android 16 changed the way fullscreen is handled. Maybe you got some ideas to help us with that, Ray, because, you know, like now Android wants every app to be fullscreen, but then Android 15 and 14, like fullscreen was an option. So we enabled fullscreen and it works perfectly with the safe areas. But if you open this on Android 16, it doesn't consider the safe areas and there's no documentation from Google on how to work with those safe areas, like the documentation you look up on Google for the safe areas that our developers are working on is still for Android 15 and there is no documentation how to do it with 16. And I don't know why nobody's talking about in the Google forum about this.

Is nobody talking about it?

I didn't talk— like, I looked at this. I don't know if we're doing something wrong because like our developers looked at it and there was— they said they couldn't find anything. I was looking at it. I don't know, it's like from looking at the documentation, everything we're doing should be working, but for some reason it's not working. I tested it. It mainly happens on Samsung devices with Android 16. Maybe also others, we'll need to look into that. But maybe I'm thinking it's like a One UI issue because Samsung, they change a bunch of stuff with Android.

Well, that's entirely possible. Then there comes a bunch of Java stuff in terms of where I mean, edge to edge is set at the Java level and then your WebView is like a rectangle sitting inside there. You're a little bit at the mercy of have you set this stuff up right using Java or Kotlin and then making sure your WebView has the information about how to lay itself out well.

That works perfectly because we're just injecting it as a CSS variable. We just define a CSS variable, safe area top, safe area bottom, and that just gets calculated. It works perfectly in Android 14, 15, I think even 13. Like every Android. The main issue with that is 16, but, uh, we're still looking into it because we're trying to recreate some of the, um, some of the issues that people are facing. But now I know what all the tech support is always saying— we're trying to recreate the issue and then you can recreate it, or you need a little bit of time. Um, it also happens with Pixel, so we need to take a look at that. I know we're working on it for quite some while, but maybe, Ray, you got some ideas for us? Because we have a Java developer, Android developer for 15 years, like Davalos, looking at it and he's doing this for 15 years and he's like, I don't know.

I was like, oh God, if you don't know. Well, it's a new feature. The feature just came out with any level of support, like what, like 10 or 11 months ago. Yeah. Now they're making it more mandatory.

You have to do it. The issue was it works great with the versions where it was optional. But now with the version where it's mandatory, it's absolutely crap.

Interesting. I wonder if that's a timing issue too. You're invoking it at runtime versus always having to start with it.

Maybe also what I'm thinking, because like Android is known to like put PWA features in webviews for random reasons, maybe you have to put the environment safe area in there. And that's what I'm thinking, right? Maybe it detects if it's in a webview and then you need to use the environment safe area value rather than the custom Java safe. You know what I mean? Like, because like if fullscreen is by default, it could be because normally you move it up a little bit, right? You move it up and then you calculate how you moved it up and you inject that back into it so it can balance it out, right? I'm thinking maybe if their new default is fullscreen, they remove the ability for you to calculate how much you moved it up because it's already up, right? You can't move it more up than up. And maybe they give you that value with a CSS variable because Android loves doing that kind of stuff. That is somewhat confusing. So maybe I need to do some tests on that. Maybe we can just then, you know, use the environment safe area variable that the PWA would use, compute that value, and then inject it into the desk variable, or just use the, you know, environment safe area one as a fallback.

There's a lot in there. And I actually think the other thing I look at is how to get the WebView to talk back to me. So I will use like ugly rectangles to figure out what the, what I will use your ugly pink or neon green rectangles after this. And then also just getting to spit out more like, okay, well, what CSS variables do you have in here? Just get it to talk back to me and tell me more about what's inside. And then sifting through that yourself with your eye or hand it over to your best friend, Claude or GPT or whatever you prefer. Wonderful.

Thank you. I'll be playing with some rectangles after this. Um, but, and, and, you know, and like Android, Android is, is— I don't like Android. It's— they always change something without having proper documentation, or they discontinue something without letting you know.

It is, it is faster moving. It is a more fragmented ecosystem because they don't have control over the hardware. Um, it's, it's more challenging, but, but as you previously point out that, that same level, that, that same thing allows the cost to really drop, which means that there are many, many more people who can actually use it. And so that means harder for you, but, you know, bigger audience, and we, we sort these things out. Anyway, we should, we should be talking about this again.

Let's do this again next week. Wonderful. Thank you so much for your time, and thank you so much everybody for watching. Take care.