Artem Marinov

Big news. Same plan: build something people love using. Back to it 🚀

Wabi 2.0 is here! 🥹 So happy to be part of this team. Congrats, everyone ❤️ Give it a try!

One thing became really clear to us building @wabi - the AI apps that feel most native and precise are the ones where the LLM doesn’t touch most of the data. This is already live in production. After months of prototyping and testing, wanted to share the architecture behind it. The Problem When AI creates an app that can connect to your Twitter, email, or calendar, there are two obvious approaches: 1. Let the LLM do everything - read your data, interpret it, and generate all the content. 2. Give the app direct API access and skip the LLM entirely. Both are wrong on their own. If you let the LLM handle everything, it has to regenerate content that already exists. Your tweet has 280 characters. The model has to retype it token by token - that’s hundreds of milliseconds of streaming, API costs for every token, and worst of all: it might hallucinate. Slightly different wording, wrong metric, a like count that’s off by a thousand. The data exists already. Why are we asking AI to reproduce it? But if you skip the LLM and just pipe raw API data into the app, you lose everything that makes AI apps powerful. You can’t ask “which of my emails actually matter this morning?” or “find tweets in my timeline that are relevant to the project I’m working on.” That requires reasoning, not just data fetching. Two Systems, One App So we built two parallel paths that our app creation agent chooses between: SDK - direct, typed access to your integrations. The app gets back exact, structured data through API calls. The real tweet, with the real text, real author, real engagement metrics, real media. No LLM in the loop. Instant. Precise. Zero hallucination risk. MCP - AI-mediated access where the model can reason over your connected integrations. When the app needs to analyze, summarize, find patterns, or make decisions about your data - the LLM iterates over your emails, calendar, tweets, and applies actual intelligence to it. The app creation agent decides which path to use for each operation. This isn’t something the user configures - it’s an architectural decision made at app generation time. When the LLM Should Think, Not Type Summarizing your inbox into “urgent / FYI / can wait” categories? That’s reasoning. The LLM is brilliant here - it reads your emails through MCP, understands context, and produces insights no API call could. Finding newsletters you should unsubscribe from? The model iterates over your email history, spots patterns, identifies marketing from real correspondence. Pure agentic work. Looking at your calendar and emails together to suggest how to reorganize your day? Cross-integration reasoning that only an LLM can do. When Data Should Just Be Data But when that email summarizer needs to show you the actual email thread - that comes through the SDK. Exact subject lines. Exact timestamps. Exact sender addresses. The model already decided which emails matter. Now the SDK delivers them precisely. Same with Twitter. The model finds tweets relevant to your interests - but the tweets themselves render with real text, real author avatars, real engagement counts, real media. Not an LLM’s approximation of what the tweet said. This matters more than you’d think. When a user sees a tweet in their app, they expect it to be exact. One wrong word and it feels fake. One made-up metric and trust is gone. Where It Gets Really Interesting The magic happens when both systems work together in the same flow. Imagine a reply assistant app. MCP scans tweets mentioning you, identifies which ones deserve a response, even drafts reply ideas based on your tone and the conversation context. That’s all LLM reasoning. But when it shows you the tweet you’re about to reply to - that’s the real tweet, pulled through the SDK. Exact text, exact thread, exact author. And when you tap reply, you see a confirmation card with the full response before it posts. You review it, you approve it, it goes out. Or think about a social + email bridge. Someone emails you about a partnership. MCP connects the dots - finds their Twitter profile, pulls their recent activity, summarizes what they’ve been posting about. The insights are AI-generated. But the actual tweets and email threads the app shows you? SDK. Real data. You’re looking at their exact words, not the model’s interpretation of them. Keeping Things Safe One more thing worth mentioning. No data modification operations go through MCP. Ever. Reading your timeline? Fine. Summarizing emails? Go ahead. But the moment an app wants to follow someone, post a tweet, send an email, or archive a thread - that goes exclusively through the SDK, and every single mutation triggers a confirmation UI. You see exactly what’s about to happen, and you approve it. Models are getting incredibly capable, but they’re not infallible. When an action has real consequences - following a stranger, sending an email to your boss, deleting a tweet - we want a human in the loop. Always. What This Means To build truly great AI apps, you can’t leave everything to the LLM. And you can’t do everything we want without one. The result is a combination where the app creation agent decides which path to use for which case - LLM reasoning where it matters, precise data delivery where accuracy matters, and human confirmation where consequences matter. That’s how you get apps that feel native, interactive, and trustworthy - with real data from your real accounts.

Very proud to be part of this journey, huge respect to the team

Remember when we said the apps you create in @wabi wouldn’t just be solo experiences? Well — here it is. Multiplayer is now a platform feature. Every app you’ve built (yes, even old ones) now supports multiplayer. No code changes. No new API. It just works. How Multiplayer Works If you remember our real-time data sync update from a bit ago — this is exactly what it was preparing for. Multiplayer is built right on top of it. When you invite someone, you’re both operating on the same live data model. Every change syncs through the backend to all connected devices. The challenge? Users expect instant feedback. Even 100ms of delay between tapping a button and seeing it change feels sluggish. Syncing everything through the backend is much easier to implement, but waiting for a server round-trip before updating the UI isn’t an option. So we update locally first, then sync to the backend, then propagate to other devices. The UI responds immediately, and data becomes eventually consistent across all participants (we’re talking sub-seconds, not even seconds). But this creates another problem: race conditions. Imagine a tap counter — you and a friend both tap when the value is 26. Each device sends “the count is 27.” Instead of two increments reaching 28, the value collapses into a single update and you stay at 27. We solved this using RFC 6902 (JSON patches) with atomic deltas. Instead of pushing values, we push intent — “increment by 1.” These deltas merge correctly even when they happen simultaneously. The result: competitive real-time apps work deterministically. What This Unlocks This creates two very different patterns: 1. Share any app with friends or family Not every app needs multiplayer logic built in — but you might still want to use it together. Made a trip planner? Invite your partner to work on the itinerary together. Built a grocery list? Share it with your household. Recipe collection? Collaborate with friends. The app doesn’t need to know about multiplayer — it just syncs. 2. Build true multiplayer experiences For apps that DO have multiplayer logic, things get interesting. We built a photo moments app for our team where everyone can add photos, react, and see who’s online. At the platform level, the model understands user profiles, nicknames, avatars, admin roles, and online status — all synced in real time — and you can build apps that use these properties out of the box. What You Can Build Now 🎯 Collaborative apps — trip planners, grocery lists, shared journals, family calendars 👥 Social apps — photo feeds, reactions, group challenges, team dashboards 🎮 Competitive apps — leaderboard games, trivia, daily challenges with friends 👪 Family apps — chore trackers, meal planners, shared wishlists P.S. Quick note on terminology 🌍 Publishing — Put your app template in Explore so anyone can discover it. People can take it and spin up their own version, with their own data. Built a great todo app? Let the community use it. 📤 Sharing — Keep it private, but still give people the template. You send a link, they get their own instance with their own data. Same app, completely separate environments. 👥 Inviting — This is the new thing. You invite people into the same instance of your app. Shared data. Shared state. Real-time sync across all devices. That’s multiplayer. Try inviting a friend to an app and let us know how it goes — curious what you'll build with this.

We shipped something at @wabi a few days ago that we're really excited about. The Big Idea: Your app data lives in the cloud and syncs in real-time with your device - streaming updates field-by-field as things change. Sounds technical, but here’s why this matters: you can now edit your app’s data just like you edit its code. Why This Architecture Is Powerful: Building real-time data sync is genuinely hard. Cross-device sync, cross-user sync with your friends, streaming updates - it’s complex, error-prone code that most AI models struggle to generate correctly. So we made it platform-level and completely transparent. When the AI builds your app, it doesn’t have to think about any of this. It just works. And your data works like any modern app - accessible from any device, never lost if something happens to your phone. But here’s what’s different: you can migrate, transform, and edit it - just by asking. And this is what makes them feel like real, polished apps: they work even when you’re not using them. Your book summary app generates daily content, your habit tracker creates timely reminders, your calorie counter can process yesterday’s meals overnight. Everything syncs automatically, so when you open the app, your new content is already waiting. What You Can Do Right Now: ✏️ Transform all your existing data: Built a joke app with 30 jokes you love? Ask to “add funny images from the internet to each joke” - done. One edit, all 30 jokes updated. Don’t like them? “regenerate as illustrated drawings instead” - another edit, all updated again. ⚙️ Edit settings as easily as data: Recipe app making descriptions too long? Just ask to “make all recipes content shorter and more concise” - it updates the setting and can recreate existing content to match. 🔄 Recategorize everything: Have a habit tracker? “reorganize my habits into morning and evening routines” - one edit, all your data restructured. 📸 Import from screenshots: Send a screenshot of data from another app on your phone (notes, lists, whatever) and we’ll migrate it directly into your Wabi app. No manual retyping needed. What’s Next: This real-time sync foundation unlocks something we’ve been working on: imagine building a family meal planner where everyone can add recipes, vote on dinner options, and see updates instantly (we’re talking under a second). Or a trip planning app you share with friends where itinerary changes sync to everyone’s phones immediately. The apps you build won’t just be for you anymore. More on that very soon!

Really proud to share something we shipped in @wabi last week! We built split bundle architecture because we're not just building apps - we're building a platform we want to support long-term. When we improve something, ALL apps should benefit. Not just new ones 🧵 --- The problem we were facing: Every time someone opened a NEW app in Wabi, they had to download 3MB and wait for a few seconds. Not great when you have tons of apps to explore. Worse: when we wanted to fix a bug or add a feature to the core platform, we'd have to rebuild every single app individually. We want to give the smoothest, most native experience possible. --- What we built: Split bundle architecture: • Core bundle (3MB): Your Wabi platform - all shared code, components, features. Downloads once, updates automatically when we push improvements. • MiniApp bundles (10-20KB): Just the unique parts of each app. Instant download. --- What this means: ✨ Apps open in ~600ms instead of a few seconds 🚀 When we ship bug fixes or new features, ALL created apps get them automatically 💝 Everyone benefits from platform improvements, without forcing them to do anything by hand --- We're building this for the long term. When someone creates an app in Wabi, we want to be able to keep improving it for them - better UI, new capabilities, performance improvements. And this architecture gives us something really exciting: we can now bring features like multiplayer into ALL existing apps 🤯 Coming soon 🚀