22:09Ras Mic · Tutorial
Building beautiful UI using AI (My design workflow)
A 22-minute live-demo tutorial showing how design tokens and Claude Design eliminate the inconsistency that makes AI-built apps look cheap.
June 23rdThe argument in one line.
AI made writing code trivial, so the skill that now separates a shipped product from a prototype that crashes at ten users is system design: picking a client/server/database architecture and tools that both scale and are already well understood by coding agents.
Read if. Skip if.
READ IF YOU ARE…
- You're using AI to build an app you actually intend to put in front of paying users, not just a demo.
- You've shipped a working prototype but aren't sure how to structure the backend, database, or services as it grows.
- You're evaluating Convex, Supabase, or a similar backend-as-a-service and want a real architecture comparison.
- You're deciding between a monorepo and separate repos for a multi-client app (web, mobile, desktop).
SKIP IF…
- You're only building single-file scripts or internal tools with no real users.
- You already have a senior backend background and don't need the client/server/database refresher.
The full version, fast.
Vibe-coded apps look done but collapse under real traffic because their builders skipped system design. The video breaks down system design as four trade-offs - scalability, reliability, performance, cost - then walks through how the author's product, Pluto, was actually built: a Turborepo monorepo holding a SvelteKit web app, an Expo/React Native mobile app, and an Electron desktop app, all talking to Convex, which merges backend and database into one system (queries, mutations, actions, durable workflows, queues) instead of a separate Node.js server plus Postgres. Two things were carved out as standalone services - an iMessage bridge and an Inference/Payments ledger on Effect.ts and Postgres - because they were self-contained enough to deserve their own box. Payments run through Autumn for credit-based billing, auth through WorkOS for enterprise SSO, and errors through Sentry and PostHog. The through-line: every tool was chosen because it scales AND because coding agents already write good code against it, and cost was explicitly sacrificed for reliability.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Create a free account →Where the time goes.
00:00 – 01:00
01 · Cold open
Vibe-coded apps crash at 10 users; promises a full teardown of how his product Pluto was built.
01:00 – 02:27
02 · What system design means
Defines the four pillars: scalability, reliability, performance, cost/maintainability.
02:27 – 07:18
03 · History of infra abstraction
On-prem metal to AWS/GCP/Azure/Cloudflare to a second abstraction layer of Convex/Vercel/Supabase/Neon.
07:18 – 10:02
04 · Sponsor: Greptile
AI PR code review with a confidence-score gate for what's worth manually reviewing.
10:02 – 14:57
05 · Client layer for Pluto
SvelteKit web, Expo/React Native mobile, Electron desktop, unified in a Turborepo monorepo.
14:57 – 19:31
06 · Backend + database
Client never talks to the DB directly; Convex merges backend and database via queries/mutations/actions, durable workflows, and queues.
19:31 – 24:16
07 · Standalone services
iMessage bridge and Inference/Payments ledger carved out as separate services on Effect.ts (+ Postgres/PlanetScale for payments).
24:16 – 26:55
08 · Payments + observability
Autumn for credit-based billing vs. Stripe for subscriptions; Sentry + PostHog for monitoring.
26:55 – 30:18
09 · Full diagram recap + trade-offs
OpenClaw agent on Daytona sandboxes, WorkOS for enterprise OAuth, honest admission cost was deprioritized for reliability.
Lines worth screenshotting.
- The gap between a vibe-coded demo and a real app isn't the code quality - it's that the demo has no system design behind it, so it breaks at roughly ten concurrent users.
- A developer who understands system design will get a more robust result from AI than a non-developer using the same AI, because the human still has to make the architecture calls.
- Every engineering choice is a trade-off; there's no system that handles every scenario, so the design question is which trade-offs you're willing to make.
- Backend-as-a-service platforms like Convex, Vercel, Supabase, and Neon are a second abstraction layer built on top of AWS, GCP, Azure, and Cloudflare - not a replacement for them.
- AWS, GCP, and Azure are powerful but have famously poor developer experience; deploying a basic React app to Azure in under five minutes is close to impossible.
- The client should never talk directly to the database - if it does, anyone can open dev tools, read the API key off the network tab, and compromise the backend.
- This is the author's core objection to typical Supabase usage: most people connect the client straight to the database and patch the hole with row-level security instead of routing everything through a server.
- A durable process is one that keeps running even if the user closes the tab or refreshes the page - without it, a chat message or long AI task can silently die mid-stream.
- Convex bundles backend and database into one system with three primitives - queries for reads, mutations for writes, actions for calling external services - removing the need to wire a separate Node.js API to a separate Postgres instance.
- Starting every project as a monorepo (one repository holding every client and the backend) means a coding agent has full cross-app context instead of fragmented visibility across separate repos.
- A piece of functionality deserves to become its own standalone service when it's self-contained, has little footprint in the rest of the codebase, and would eventually warrant a dedicated owner - a judgment call based on experience, not a formula.
- Credit-based billing (via Autumn) fits products where usage is metered and top-uppable; flat subscription billing (via Stripe) fits simpler, fixed-price products - the architecture should match the pricing model, not the other way around.
- Enterprise-facing products need OAuth built for businesses (SSO, compliance) from day one if the target buyer is a company with 15-60 employees and a manager provisioning seats, not an individual user.
- The author is spending over $100/month against a $20/month base plan and has deliberately not optimized for cost - reliability and speed for early users came first, cost optimization was pushed to later.
- Choosing tools partly because AI coding agents are already fluent in them (Convex components, Effect.ts's error handling, Vercel deploys) is now a legitimate architecture criterion, not just a convenience.
System design, not AI skill, decides if your app survives real users.
WHAT TO LEARN
The trade-offs that separate a working app from a demo that crashes at ten users are the same four every builder has always had to weigh: scalability, reliability, performance, and cost - AI just changed which tools make those trade-offs easy.
- A vibe-coded app that works in a demo will crash under real traffic if nobody thought through scalability, reliability, performance, and cost as explicit trade-offs.
- Backend-as-a-service platforms like Convex, Vercel, and Supabase are a second abstraction layer on top of AWS/GCP/Azure, not a replacement for understanding what they're abstracting.
- The client should never read from or write to the database directly - route everything through a server so an inspected network tab can't leak credentials.
- Starting with a monorepo that holds every client (web, mobile, desktop) and the backend together gives a coding agent full cross-app context instead of fragmented visibility.
- A durable, retry-capable workflow is required for any long-running AI task, so it survives the user closing the tab - build this in from the start rather than bolting it on after failures.
- Only carve a feature into its own standalone service when it's self-contained, has little footprint elsewhere in the codebase, and will eventually need a dedicated owner.
- Match the billing architecture to the pricing model: credit-based systems need a different backend shape than flat subscriptions.
- Enterprise buyers need enterprise-grade OAuth and compliance support built in from day one if the product targets companies, not individuals.
- It's reasonable to explicitly deprioritize cost optimization early on in favor of reliability and speed, as long as that trade-off is a conscious choice, not an accident.
- Choosing tools your coding agent already handles well (via components, strong typing, or clean error handling) is now a legitimate architecture criterion alongside scalability and cost.
Terms worth knowing.
- System design
- The process of planning a software system's architecture, components, modules, interfaces, and data flow to meet a set of requirements before writing the implementation.
- Abstraction (in this context)
- A layer of software or infrastructure that hides complex implementation details so a builder only has to interact with a simpler, higher-level interface - e.g. a platform that wraps a cloud provider's raw services.
- Monorepo
- A single repository that holds multiple applications or services (e.g. a web app, a mobile app, and a backend) together, instead of splitting each into its own separate repository.
- Durable process / durable workflow
- A background task or workflow that keeps executing to completion even if the user closes the browser tab, refreshes, or disconnects - typically implemented with retries and persisted state rather than an in-memory request handler.
- Query / mutation / action
- The three operation types in a Convex backend: a query reads data, a mutation writes data, and an action calls an external service (e.g. a third-party API).
- Work pool / queue
- A backend primitive that lets many tasks run in parallel in a coordinated, rate-limited way, similar in purpose to a service like Amazon SQS but managed inside the same backend platform.
- Control plane
- The central orchestrating system that coordinates and has authority over the rest of an application's components - here, Convex acts as Pluto's control plane.
- Service (in an architecture)
- A self-contained, reusable block of functionality that performs one specific task for the rest of the application or for external clients, deliberately separated so it can be built, deployed, or owned independently.
- Credit-based billing
- A payment model where users pre-purchase or top up a balance of credits that are then consumed by usage, as opposed to a fixed recurring subscription charge.
- Sandbox provider (agent computer)
- A hosted, isolated execution environment where an AI agent can run code, browse, and take actions safely, separate from the main application's production infrastructure.
Things they pointed at.
11:30toolSvelteKit
12:10toolExpo / React Native
12:25toolElectron
13:05toolTurborepo
15:40toolConvex
21:40toolEffect.ts
22:10toolPlanetScale
23:40toolAutumn
23:40toolStripe
24:20toolSentry
24:20toolPostHog
26:42toolDaytona
26:55toolOpenClaw
27:40toolWorkOS
Lines you could clip.
02:48
“Engineering is all about trade-offs. There is no such thing as a perfect system.”
00:40
“Whenever you see someone vibe code an app, the moment they have 10 users, that app crashes.”
15:40
“You should never ever ever ever ever ever read data from the client directly to the database.”
15:46
“The client calls the server, the server calls the database, the database responds to the server, and then the server tells the client. This is secure.”
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
metaphoranalogystory
00:00Building applications has gone a lot easier, thanks to AI. But let's be honest, when I say applications, I really mean prototypes. There's not that much quality that's shipped.
00:08Whenever you see someone vibe code an app, the moment they have 10 users, that app crashes. And that's because they don't know how to design a system. And that's the same reason why a developer who uses AI will build a more robust app compared to someone who's not a developer.
00:23But that's what today's video is going to help with. I'm going to show you how to design a robust system when agentic engineering, when you're building your applications with AI.
00:32And the way I'm going to do it is I'm going to explain to you how my app Pluto was built from the ground up. All the tools that I use, the text stack that I use, the info that I use, the decisions I made, how the code is structured, how I use AI. I'm literally going to cover everything.
00:46If you have plans on building an app that's going to go to production that people are going to be using, you're going to need to watch this video. I'm gonna leave no stone unturned. This might be twenty minutes, thirty minutes, however long this video is.
00:58Let's get straight into it. So building robust applications with AI. First and foremost, what does system design mean?
01:06And I'm going to more so focus in this age of AI. The simple definition of system design, the fancy definition is it's a process of planning the architecture, components, modules, interfaces, and data flow of the software system to satisfy specific requirements.
01:21In the old days pre AI, we used to watch a lot of videos like this to learn how to design systems. Right? You have to figure out what you're going to use for storage, where you're gonna place your load balancer, what service you're gonna use for alerts, what your CICD pipeline look like.
01:35All this stuff was something that a system designer has to think about. But in this current age of AI, there are a lot of tools that abstract this that make it a lot easier for us to implement these things in our system. Now one thing you need to realize about designing a system is in engineering, whether you're an engineer or not, one thing you need to understand is engineering is all about trade offs.
01:55Meaning, there is no such thing as a perfect system. There is no such thing as this system handles every scenario, every case, everything has trade offs.
02:04Every stack has trade offs. Every tool you use has trade offs. Every you use has trade offs.
02:10. So understanding this, when designing our system, there's a couple of things we need to think about. First is scalability.
02:17The system's ability to handle growing amount of traffic or data by adding resources. Meaning, if your app starts to get bombarded, is your system designed in a way where all you have to do is go to some dashboard, add some servers, and then you're good to go?
02:30Or does it auto scale? Reliability. What is the chance of your system going down?
02:34Is the provider you're using known to go down always? That's a decision we have to take into consideration. Performance.
02:40Does this allow your app to be faster? We need our apps to be zooming fast. If the tool that we're using or the way we've architected the app is slow, that's something we need to think about.
02:50And last but not least is the money. Is this going to cost us an arm and a leg? Can we only afford an arm or can we afford an arm and a leg or can we afford nothing?
02:58These are things we need to think about. Engineering is all about trade offs. Before we get into Pluto system design, I wanna kinda give you a breakdown of all the info available and how all these things work.
03:08In the old days, the way websites and apps would be served is companies had their own servers. They had their own metal. They had server racks in their office.
03:17There was a couple of IT nerds. There was a couple of, you know, computer programmers. There's a couple of DevOps people, and you are basically scaling the website yourself.
03:26So if you have a lot of traffic and you don't have the hardware to support you, you are cooked. If you have all these server racks and you don't have traffic, you just wasted a bunch of money. So it was a time where you had to be very calculated.
03:37It's very expensive. Hard to predict, and it's not easy to scale up. Then companies like Amazon, uh, Google, and Microsoft built their own cloud providers.
03:47Right? Amazon built AWS. Google built GCP.
03:51Microsoft built Azure, and then you have Cloudflare. And these guys basically bought their own metal, placed it in different areas, and they're like, we will be the provider where you can run your apps.
04:03Right? And what was cool about AWS and GCP and Azure is that I didn't have to manage my own server racks anymore. I didn't need IT guys on the floor plugging in stuff.
04:13I can just deploy my application straight to AWS, straight to Azure.
04:18They have all these different services and tools, right, that are all managed by them, and they handle the nitty gritty and heavy stuff. And this is when the web exploded. This is when sites exploded, back ends exploded.
04:30A lot of cool stuff started to show up in the web. And this is also what we call an abstraction. Now you might feel like these are all big engineering terms.
04:37If you wanna build something cool, lock in and listen. Abstraction in computer science is the process of hiding complex implementation details and focusing only on essential high level features of an object or a system. So they basically AWS, GCP, and Azure, and Cloudflare, they basically abstracted the need for me to have a physical server, the need for me to set up software to run stuff on the physical server.
05:01They took care of that. And then as time went on, another layer of abstraction popped up. Right?
05:06And you have Convex. You have Vercel. You have Superbase.
05:09You have Neon, and all these different companies. Now just, you know, if any of the employees from the companies watch, yes, Vercel, for example, does have their own metal, I I I think, so does planet scale.
05:21But just hypothetically, Vercel, when they started, wrapped AWS, GCP, or one of these guys.
05:27Right? Convex wrapped, same thing. Right?
05:29So this level of abstraction made it a lot easier to use these tools, which made it a lot easier to use this. Right? Because I don't know if many of you have used AWS.
05:40AWS is pretty fine. Don't I know if many of you have used GCP or Azure. I have an Azure certificate.
05:45Azure is terrible to use. GCP is terrible to use. I don't even know anyone who knows how to deploy React app on Azure in under five minutes.
05:54It's that messed up and all over the place. So you have tools and info providers like Convex, Vercel, Supabase, Neon, all these other companies that basically wrap or abstract AWS, GCP, Azure, and Cloudflare.
06:08The reason why I say this, this layer of infrastructure has essentially made it easy for you and me to build our applications. I don't deploy on AWS, GCP, Azure.
06:21Uh, sometimes I use Cloudflare, but for the most part, I use Vercel. For my back end, I use Convex. If I need a Postgres database, I'm gonna use PlanetScale.
06:29I no longer have to go this level down the abstraction path nor do I have to go this level down. Now you might be like, why are you explaining this to me? I'm trying to Ingentic engineer because when I talk about Pluto system design, all this stuff is going to help it make sense.
06:44And to just give you a breakdown of how things are today, you still have people who use their own metal, um, don't recommend. You have things that are built. You have companies that provide this service for you like the AWS, the GCPs.
06:56These things are very powerful, but the developer experience, or should I say the agent experience sucks. And then you have tools like Convex, Vercel, and all these other companies that have amazing developer experience can easily scale up.
07:06They do a lot of the hard work for you that you and I don't need to worry about. Yo. Yo.
07:12No. Wake up. You can't be sleeping on the job.
07:15Who's gonna review the code?
07:20I hate code review, but it has to get done. And that's why I love GREPTL. See, I have a huge PR here on an open source project I have called Ralphie.
07:28Over 4,341 lines done by this contributor. Now this is a lot of lines of code, and I'm probably going to miss something.
07:35But the way I use Greptile in my code review is as follows. I have a Greptile review that's run on this PR. Mind you, this is a pretty large PR.
07:42And what I love about Greptile is the summary it gives me plus the confidence score. The confidence score tells me whether this is worth my time reviewing or not. Anything below a four out of five is something I'm not going to personally review.
07:54Imagine spending all that time only to find out this PR still requires work. But with the GrebTile, all I need to do is read the summary, review the confidence score. If it's under a four out of five, it's not worth merging.
08:05Doing this has allowed me and my team to ship at warp speed. So make sure to check out Greptile. The link is in the description down below, or you can go to rossmike.link/greptile.
08:14They have a two week free trial, and it's pretty generous. So take advantage of it. Believe me, once you start using it, you won't wanna stop.
08:21Check them out. The link is down in the description below. So let's talk about Pluto.
08:25So when building Pluto, there's a couple things that are pretty interesting. First and foremost, with Pluto, I needed OAuth that businesses could use.
08:33Right? I needed the big boy OAuth. I needed people who maybe want SOC two compliance and all these other things.
08:40Right? So OAuth is something I have to think about. And then I know there might be people who are using this for personal use, but there also might be businesses.
08:47And if businesses want to use this, maybe it's a manager who's setting this up, and then the manager invites the employees of the company, and then they set it up. And then I have to think about billing. Right?
08:57What kind of billing do I want? Do I want a subscription? People already pay for subscriptions, and I think people are tired of subscriptions.
09:03Maybe we can do a credit based system where you can just top up and use as you go. So then you have to build that out as well. Another thing is, again, this is an agent.
09:11Right? So I need to think about where I'm going to deploy this agent. The place I deploy needs to be sort of affordable, but it also needs to be able to scale and needs to not go down.
09:19It needs to be something that's reliable. So these are all the things I had to think about when initially planning out Pluto. Now let's talk about Pluto.
09:26Pluto has four client surfaces. Right? There's a web app.
09:30There's a desktop app. There's a mobile app. Well, the mobile app was just one Fable run.
09:35And then there's an admin site. Right? Like, the an internal admin site.
09:39Now when you're building your app, you gotta think of a couple of things. You gotta think of the client, the server, and the database.
09:48The client is basically the place where people interact with your app. So this could be your website, your mobile app, or your desktop app.
09:58Now it's important to pick the tool you're familiar with. And in this case, for my web apps, I use SvelteKit. So SvelteKit is basically the Next.
10:07Js for Svelte. I love SvelteKit, and I love SvelteKit. It's very minimal.
10:11It's fast. It's easy to build performance sites with it. So I'm using SvelteKit for the client.
10:17But here's the thing. What if I wanted a mobile app? Right?
10:20If I wanted a mobile app, I can build a native macOS app. But let's say I want an Android app as well. Expo plus React Native for the mobile app.
10:30Right? And let's say I want a desktop app. And then for the desktop app, I'm going to use Electron and I'm just going to wrap the website.
10:37Right? This is these are things that I can do with Electron. Now I have a web app.
10:42I have a mobile app, and then I have a desktop app. Like, am I going to have, like, three different projects with three different repos? Like, how am I gonna manage this?
10:51Let me introduce you to our good friend called a mono repo. A mono repo is basically one giant repository of code where multiple different pieces of your application can live.
11:06Right? So I can have my web app in one repo. I can have my mobile app in one repo.
11:13I can have my desktop in one repo. And I can also have my back end, right, that all these different services, right, the desktop app communicates with the back end, the mobile app communicates with the back end, and the web app communicates with the back end.
11:30The reason why a mono repo is cool or having all this in one code base is cool is because when I'm using my agent, when I'm using my AI of choice, in this case, Fable five, it's finally back. When I'm using Fable five or whatever model of choice, Fable five, the agent has access to the entire code base even though I have a web app, a desktop app, a mobile app.
11:53Right? If I have, like, a web app, a separate repository for the web app, a separate repository for the mobile app, a separate repository for the desktop app, then there's all these separated context. It's very hard for me, the human, to manage, and you might be someone who doesn't really know how to code.
12:08Good luck. It's going to be a tough time. So whenever I initialize my applications or whenever I start my application, I almost always start with a mono repo.
12:20And in this case, because I use Vercel to deploy, I use Turbo repo, and this is how I architect my apps. Right? So I always start with a mono repo.
12:29The reason I start with a mono repo is it allows me to have, you know, multiple different clients, one unified back end. I can even have one component library, one UI library, and it'd be shared with all these different client surfaces. Right?
12:43And in terms of what I use for my web app, I told you I use Svelte. For mobile, Unless I don't need an Android app, I usually I like to go Swift, but I'm gonna use Expo and React Native, and then I'm using Electron for the desktop app. But now I have to think about my server and my database.
12:58And by the way, if you feel like this is a lot of information, I'm literally gonna put this all of this together. So just listen and take notes. When it comes to my server and database and particularly my server or my back end, there's a couple things I need to think about.
13:12My server is going to allow me to read data from my database. My server is gonna allow me to write data to my database. My server is going to allow me to interact with external services.
13:26Right? Like, make an API call to, like, a a weather API. Right?
13:30And there's a couple things I also want. I wanna make sure these don't fail and these aren't slow. Now here's the thing.
13:39One thing that I want you to know is you should never ever ever ever ever ever read data from the client directly to the database.
13:49The client should never ever ever ever talk to the database. And this is one of the biggest reasons why why I'm not a fan of Supabase. Now Supabase does have a server library, you can not do this, but most people do this.
14:01And then they set up RLS. And to me, that's just a fool's game. Real system should work as follows.
14:07The client calls the server, the server calls the database, the database responds to the server, and then the server tells the client.
14:17This is secure. But if I have my client talking to my database, what basically someone can do is they can inspect element, go to the network tab, see the networks, read your API key, and then you're cooked. You're absolutely cooked.
14:30So when I am designing my back end, I need my back end to do all these things, but I also need to make sure my back end communicates with my database. In the old days, you would have or not in the old days. I mean, people still do it now.
14:43You can have a Node. Js back end and then you have a Postgres DB.
14:48Right? You would build this and then build this and have these communicate. Remember when I told you there are abstractions that make things easier.
14:55Right? Back in the day, I would have to deploy my Node.
15:00Js app, the back end on AWS, and then I would have to set up an AWS Postgres instance or I you can use GCP, whatever it is, and then I'd have those to communicate. But then we have an abstraction layer above AWS called Convex, and Convex is a beautiful thing.
15:16Why is Convex a beautiful thing? Convex takes my server, right, my back end and marries it to my database.
15:26And what I mean by marries it, let me use better language. I basically get both of them in one box. So I get a back end.
15:34I think a back end is better here where I can read data from the DB, write data to the to my DB, interact with external services. These don't fail and these aren't slow, and I also get a database. So instead of managing a separate back end and a separate database, I'm managing one infrastructure, and that's called Convex.
15:52And what's cool about Convex is everything is real time, so it's fast. I can read data from the database. I can write data to my database, and I can interact with external services.
16:02If you're familiar with Convex, these are basically called queries, mutations, and actions.
16:08Right? Queries is querying data, read. Mutations is mutating data.
16:12Right? And actions is interacting with external services.
16:16But here's another thing I need to think about when I'm building a back end. What if, let's say, I'm building a chat app and someone types a message and they leave the chat app.
16:26Right? Is the chat gonna continue or is it going to fail? Now if you build the standard way, it will probably fail.
16:33If you're vibe coding and you don't understand how chat stream works and all stuff, it will probably fail. I know that I need durable processes.
16:41Now again, you feel like I'm throwing all these big words. I'm telling you lock in, this is easy. Durable processes.
16:46A durable process is basically a process that's durable. Right? That continues to go on even if you close the tab, close the page, refresh, whatever it is, it will continue to work.
16:57Now if I didn't have convicts, this is an additional thing I have to build. Convicts already builds this. They call it workflow.
17:04I can set up a workflow using their workflow component. And if you don't know how to set this up, literally, if you have convicts, you go to convicts components, right, and you go search workflow and you can literally copy paste this to your agent.
17:16Simplify programming long running code flows workflow executes durably with configurable retries and delays. So I need this because I'm building an AI agent and the AI agent can't stop working if people go and leave.
17:30What if I wanted like a lineup? Like, let's say you're building like a Ticketmaster type site and people are just hammering this and you have thousands of people using your site and you want a queue. Right?
17:41Again, with back end engineering, you would have to build this yourself, but with Convex, this is available. I can have queues.
17:48I can have coordinated parallel tasks, which means I can have things run parallel. That's a hard word to say.
17:56Parallel. Parallel. You know what I'm trying to say.
18:00Have bunch tasks run-in parallel. And I could do this. And they have a component for this called work pool.
18:06Right? Again, if I wanted a queue, I can use I believe it's Amazon AWS queues.
18:12Is is it called SQS? Right? Amazon simple queue service.
18:15Right? So if I wanted a queue, I would have to use this. If I wanted a database, I would have to use RDS.
18:21If I wanted virtual servers, I would use this. Right? So there's all these different services.
18:26They're powerful, but it's terrible user experience, developer experience, agent experience.
18:32Convex simplifies this, abstracts this and gives me one complete package. So I get all this and then on top of that, I have my database.
18:41So when it comes to my back end and database, instead of building these out separately, why don't I use a service like Convex to do it? It makes my life easier.
18:50Another pro to Convex is everything is code. And the reason why this is necessary and is important is I want the agent to do the work. I want the agent to build these features.
18:58I want the agent to do this, that, and the third. And if the entire back end is all code, if the database is code, if everything is code, then the agent can do those things for me. So going back to Pluto, we have the client surface.
19:11Right? And then Pluto's control plane, meaning the main orchestrator, the main back end is Convex. Convex is the source of truth.
19:19Convex is the bridge. Convex handles everything. And I use Convex components.
19:25And, again, here's the thing. Another thing I love Convex for, and it just makes life easier, is integrations. Right?
19:30And what do I mean by integrations is let's say I wanted to integrate Cloudflare's r two storage. All I do is search r two and Convex has a component for that.
19:38You know how I set this up? I copied this link, give it to my agent, and my agent set it up. Now I have storage in my app and it's connected to my back end.
19:45Now this seems amazing. Right? I have my client.
19:49I have my back end and database, and that's it. That's all to it.
19:54That's all Pluto is. But hold on. There's a lot to Pluto.
19:58One thing that Pluto has is services. And to best explain a service, I'm gonna use AI. It says a service is a self contained reusable block of software functionality that performs a specific task for other parts of the application or for external clients.
20:14So there are two services in Pluto, Inference slash payments and iMessage. Let me explain iMessage because it's easier.
20:22So with Pluto, one of the ways you can communicate with your agent apart from the internal chat or using Telegram, Slack, Discord soon is you can use iMessage. You can talk with your agent using iMessage. Now, um, there's quite a bit of work to it, and it almost felt like the iMessage code should live in its own little contained box.
20:46Reason being is it doesn't really mess with the rest of the code base. Like, it doesn't have that much of a foothold in many different places, and it feels like it's better off being its own contained thing. Now this is a decision sort of made off of experience slash vibes, and it made sense for iMessage to be its own contained thing.
21:06So in my mono repo, I can I'll remove UI and then I can have iMessage here. This is its own service. And then for inference slash payments, again, this might be thinking a little too ahead.
21:17I plan on Pluto having its own inference system and the inference is very tied and coupled with payments. Right?
21:24Again, people are able to fund credits, and these credits can be used for inference, and they use different sort of models. This felt like a system that should be on its own, a, because for the convex back end started to get big.
21:37I wanted to separate some things that could be their own standalone service. But second, god willing, if Pluto succeeds and other developers are working on it, I assume that there would be a dedicated person solely working on this.
21:50Right? There'd be a dedicated person solely focused on this. Now the iMessage thing might be too small, but, again, it's literally its own thing, its own box, and it makes sense to me for it to be its own service.
22:02When we think of services, I want us to think of a block of code that can that touches one surface area, that does one specific thing, that doesn't really have a foothold in the entire code base, but can be cleanly architected ed separately, I think that makes sense to be a service. Again, it's more experience and vibes than it is a specific formula.
22:22So I chose to make these two things separate services. Now what stack did I use? Now this may shock you.
22:29I used effect, t s and Postgres.
22:35Now I used effect t s for the inference payments and Postgres. For the iMessage, it was just effect t s.
22:43You might be asking me why effect. And the reason why I used effect is a, AI is actually very good with writing effect code, but b, I needed really strong error handling because if things go wrong in inference and payments, I need to know about it.
22:59It needs to be clean. It needs to be architected. And when it comes to error handling, nothing is as good as effect.
23:06Right? So I use effect in the inference service.
23:10I use effect in the iMessage service. And for the payment stuff, it there's it's it's own DB. I have a Postgres database.
23:18I'm using PlanetScale for this, but you can use any other provider. And this, again, also lives in the monorepo.
23:24So when I'm using whatever agent I'm using, that agent has access to all the information and understands how the system works. Again, going back when you think of how to set up your services, think about what things in your app that you want to segment.
23:39You can also ask Fable five, which is back this question. And for payments, you might be wondering payments, what am I using? Again, there's Stripe, there's Polar, there's Autumn.
23:49Most of you probably be like, why don't you you could just use Stripe. I wanted to use Autumn because I have a credit based system, and the way my payments is architected is, uh, very unique where there's credits and there's things that consume credits. There's things that are free.
24:03There's things that you need to top up. And all this different stuff, like, example, on Pluto, you can give your agent a card and this card you obviously need to give it money and you can use your credits to top that up.
24:14So that's something that Autumn takes care of well. And what's cool again about using Convex is Convex has an Autumn component. So you know what I did?
24:24I literally copied this and gave it to the agent. So for payments, if it's just direct straight up subscription, use Stripe.
24:32If you have some credit based stuff going on, I would use Autumn. Now you could already tell this is a pretty large app. There's many places things can go wrong.
24:40Right? There's many places in the client, on the back end, the different services, heck, the mono repo.
24:47You might be using Next. Js, you might whatever it is that you're using.
24:50There's a lot of places where this goes wrong. I recommend checking out, and this is not sponsored, Sentry and Posthawk.
24:58This is what I use for analytics, error logging, and all that type of stuff. You need to have robust logging because you wanna make sure when something goes wrong, when your app goes down, whatever it is, when a build fails, whatever it is, you want to make sure that you know exactly what happened.
25:15And if you're a nontechnical person asking how do I do this, you just tell AI, hey. I wanna make sure whenever an error happens, I need to know how to track it. I need to know when it happened.
25:25Use Sentry and Posthawk to make this happen. The system architecture diagram drawn by cursor agent explained about con explained convicts control plane to you, explained how I use components.
25:36Uh, we have the inference ledger system. Right? This is, again, built with effect.
25:41We have a Postgres wallet ledger. We're using open router as the underlying, you know, inference provider, and I'm obviously using OpenClaw as the agent.
25:50OpenClaw is being deployed on Daytona. I need Daytona because Daytona is a great sandbox provider. And not only do I get sandbox with Daytona, but every agent also gets a computer.
26:03Right? So right here, you're going to see that my very own Pluto agent has its own computer with a browser. I asked it to take a screenshot and believe it or not, something broke itself healed and then it sent me the screenshot.
26:16Right? So this is something I can't build myself. Again, I need an abstraction layer that makes it easy.
26:22Daytona is great. And then for OAuth, I'm using WorkOS. And the reason why I'm using WorkOS is for one simple main reason.
26:31First and foremost, it's, uh, pretty good. And second of all, it's enterprise ready. Right?
26:36Pluto, I'm not really targeting personal agent people. I really wanna go for businesses, you know, small to medium, like 15 to, like, 60 employees.
26:46Manager sets it up, invites people. WorkOS makes the OAuth for, like, companies. And if there's a specific compliance that I need, it makes it really, really easy and the agents love it, so I'm using it.
26:58Now when I look at this system that I've designed for Pluto, what are some of the trade offs I made? The first one is cost. I don't know how this business is going to make money.
27:08Like, I more so want people to try it out and really like it, and that's a problem for later. So that's the one thing. I have not, like, thought of, like, cost optimizations, this, this, that, and the third.
27:18I just wanna make sure when people use the app, it doesn't break. Even, like, the Daytona boxes that we're using are, you know, medium to large sized boxes. I wanna make sure everyone's agent is fast.
27:28You know, WorkOS has a pretty generous free tier, so does Convex. And then, like, again, I have a separate service. Like, if I wanted to save money, I would just literally put everything in Convex, but I have a separate service.
27:38I'm using Vercel for deployments, and I can actually show you that. And with Vercel so I have Pluto.
27:45I have a staging environment. I have the inference, uh, service.
27:49I have an admin site. You know, all these, like, are, deploying these and shipping changes that you can see. I'm on the $20 a month plan, but I've spent over a $100 so far.
27:58So cost is the one thing where I'm like, you know what? We ball. So this is why I think it's very important when you're building your app out to think about this.
28:06Right? To architect it in a way where adding new features and tools and stuff won't break your app.
28:13This is why I always start with a mono repo. Right? One repo that can have multiple different things, a web app, a mobile app, a desktop app, one unified back end, many back ends, many services, whatever it is.
28:24Right? Because the agent has everything in one repo, has access to all the code. And then even the tools I use are tools that the agents are very familiar with and know how to use.
28:35Vercel, excellent. Right?
28:37Excellent place to deploy. Uh, Convex, excellent. Everything is code.
28:41The agents love it. Payments, Autumn. Autumn is really pretty good.
28:45Like, again, because I'm using Convex, there's tools that maybe the agent might not be good at using the tool specifically, but it's good at using the Convex component. So the Convex component helps me integrate tools that I like, like Autumn, like Recent, like Stripe, or, like, whatever it is.
29:01I literally just go to Convex components and then I search it. And because this is how I start my applications now, adding on services, segmenting specific things, it's not difficult.
29:11The agent itself can do it. And every tool I'm using can handle scale. Vercel can handle scale.
29:17Convex can handle scale. Autumn can handle scale. You know, all these tools that I'm using are tried and true.
29:23A lot of people use them. A lot of successful companies use them. And for the most part, there's not, like, like, increasing like, let's say a thousand users join in the app.
29:32The only thing that I need to do for the most part is up my subscription, and then I can use AI to sort of optimize the app. There's not going to be a reason why the app goes down because I built it on solid infra unless there's bad code, but we're talking about system design here. That's pretty much it.
29:49This video is pretty long. I hope you enjoyed it. I hope you enjoy me talking about the decisions and and the design and the way I'm building things.
29:57Again, I'm not saying this is the greatest way to do so, but this is how I'm thinking about apps. This is how I build apps at my agency, Heyfabrica. And I hope this makes sense.
30:07I hope you enjoyed it. Make sure to like, comment, subscribe. Let me know if you wanna watch more videos like this.
30:12I'll cook them up for you. But as always, you've been awesome. My name is Ross.
30:15I'll see you in the next one. Peace.
The Hook
The bait, then the rug-pull.
Whenever you see someone vibe-code an app, the moment they hit ten users, it crashes - and that, the author argues, is a system-design failure, not an AI failure.
Named ideas worth stealing.
02:27list
Four pillars of system design
- Scalability
- Reliability
- Performance
- Cost & Maintainability
The four trade-offs to weigh when architecting any system: ability to handle growth, uptime under failure, latency/throughput, and price plus long-term upkeep.
Steal forFraming any new project's tech-stack decision as an explicit trade-off table instead of picking tools by default habit.
04:21model
Two-layer cloud abstraction stack
- Metal
- Hyperscalers (AWS/GCP/Azure/Cloudflare)
- Dev-platform wrappers (Convex/Vercel/Supabase/Neon)
Modern infra is built in layers: raw hardware, then cloud providers that abstract hardware, then a newer layer of platforms that wrap the cloud providers with much better developer experience.
Steal forExplaining to non-technical stakeholders why a project is on Vercel/Supabase instead of raw AWS.
10:02concept
Client / Server / Database
- Client
- Server
- Database
The baseline three-box mental model for any application - and the hard rule that the client must only ever talk to the server, never directly to the database.
Steal forAuditing any project (including ones using Supabase from the client) for a direct client-to-DB security hole.
19:31concept
Vibes-based service-extraction heuristic
- Self-contained
- Low footprint elsewhere in the codebase
- Would eventually deserve a dedicated owner
A rough, experience-driven test for when a piece of app functionality should be pulled out into its own standalone service rather than living inside the main backend.
Steal forDeciding when to split a feature like transcription, rendering, or billing out of a monolith into its own service.
How they asked for the click.
VERBAL ASK
30:18next-video
“Make sure to like, comment, subscribe. Let me know if you wanna watch more videos like this. I'll cook them up for you.”
Soft, low-pressure end-of-video ask tied to a promise of more content in the same format - no hard sell.
MENTIONED ON CAMERA
Visual structure at a glance.
