Software Eng for Vibe Coders: On Frontends + Backends

Technically launched a six-part series, "Software Engineering for Vibe Coders," to teach non-engineers how frontends and backends work and how apps can break as they scale. The first installment explains that frontends are built only with HTML, CSS, and JavaScript, while backends can use any language, and uses a restaurant analogy to illustrate the distinction. The series is sponsored by Railway, which offers deployment services at railway.com/new.

Software Eng for Vibe Coders: On Frontends + Backends A new series to help non-engineers build products that can handle going viral. Vibe coding is amazing. But do you actually understand what you’ve built, so you can maintain and improve it over time? This 6-part Technically series, Software Engineering for Vibe Coders, teaches you everything you need to know about how the apps you’re vibe coding work under the hood, and crucially how they might break as your user base scales. Thanks to our friends at Railway, who help you peacefully deploy those vibe coded apps, for sponsoring this series. Spin up anything your vibe coded app might need at railway.com/new. The TL;DR Every app that you vibe code into existence has two major parts: the frontend https://technically.dev/universe/frontend and the backend https://technically.dev/universe/backend . The AI builds both parts for you, but they’re very, very different: The frontend is everything the user sees and interacts with: text, buttons, forms, shapes…all the visual and interactive stuff.The backend is the factory behind the scenes that makes the app work: APIs https://technically.dev/universe/api , databases https://technically.dev/universe/database , and business logic.Web frontends are only written in HTML https://technically.dev/universe/html , CSS https://technically.dev/universe/css , and JavaScript https://technically.dev/universe/javascript , while backends can be in practically any programming language that runs on a computer like Rust .The magic is how frontends and backends talk to each other , sending data and logic back and forth so you can do things like log in and actually use the app. If you want to be a better vibe coder, understanding this distinction is absolutely critical. So let’s dive in. The restaurant analogy for frontends and backends Technically readers by now know that I’m a “big food guy.” Ergo, the best analogy I’ve thought of for frontends and backends is a restaurant . Say you’re out on a hot date and you stroll into your favorite upscale Manhattan eatery. As you chow down on your Michelin Star Crab Rangoon, you might notice that your experience is interfacing with a few things: A nice table with comfortable chairs High quality food and drink brought to your table Servers catering to your every whim Fantastic. Behind the scenes though, there’s tons of logistical work that goes into being able to provide you with said experience. In particular, there’s an entire kitchen staff that worries about: What should be on the menu Rangoon How to cook everything consistently and perfectly deep fry the Rangoon Where to source quality ingredients from good crabs for the Rangoon How to prepare and store those ingredients What to do in situations where ingredients are missing or go bad buy frozen Rangoon As a patron, you don’t need to think or deal with any of this – you interface with the “frontend” of the restaurant, and the “backend” takes care of making sure the food that arrives on your table makes you want to leave a 5 star review unless you’re Pete Wells, in which case 4 stars will suffice . It’s not a perfect comparison, but this is pretty much how I think of application frontends and backends: except instead of food, it’s data. The frontend’s job is to interface with the user. Whenever any sort of data or now, AI responses needs to get involved in that user experience, it is time to call upon the backend. The backend’s job is to take care of all of the data and logistics behind the scenes. It consists of the database, API endpoints https://technically.dev/universe/endpoint for interacting with that database, and increasingly today, calls to AI models and HarNeSSeS plus other such highly interesting and obscure tasks. The backend, of course, can only do what you or Claude programs it to do. There’s a discrete menu no pun intended of things that the backend can do for the frontend – these are API endpoints – like sending a user’s profile information, creating a new user account, or accepting credit card information. Getting into the import / export business The best way to better understand these concepts is to walk through an actual vibe coded example. Meet Vandelay Industries , importer and exporter of fine potato chips, the finest in all the land where from specifically, we cannot reveal . Art Vandelay – proprietor – has decided to digitize the family business, which he runs out of a one-room windowless office Penske material . Thanks to the advent of vibe coding tools, he prompted his way to a website. But he has no idea what’s happening inside it, so we will need to explain it to him. This is the website homepage. Everything that you see here – text, dividers, a navigation bar – is some combination of HTML, CSS, and JavaScript…our frontend. In fact, most marketing websites can be created as what we in the biz call “static.” Static means that they are completely frontend with no backend data component at all. But Art has suppliers and vendors who need to access their accounts and move shipments around, so unfortunately a simply static website won’t do. Here, for example, is a page of his app yes, app now, not website where he can review applications submitted from new potential suppliers. Hm…where are these applications coming from…could it be… data??? Yes, data. As Art’s suppliers submit their applications, their responses get stored somewhere like a database. And on our app’s Supplier application page, we get our first glimpse of the backend. The data in the table here – an application from a seemingly fraudulent supplier named Kostanza Logistics LLC – is backend data . More specifically, when the page loaded, it sent a request via API to the backend to pull all open applications, which the backend happily sent back. This same logic holds for any pages in Art’s app that have a data component. One way to think about it is: if any information on the page is liable to change from day to day, it’s probably backend related. The confusing thing here is that when you prompt something like Claude Code of v0, it just goes ahead and builds the whole app. It doesn’t always but sometimes does explain to you which pieces are which. It might suggest you use Supabase backend , and React https://technically.dev/universe/react frontend , and perhaps Railway infrastructure https://technically.dev/universe/infrastructure , backend and maybe Tailwind frontend . If you want to begin to understand what any of these tools do, it all starts with understanding frontend / backend. More practically, every time something breaks, ask “is this a frontend or a backend problem?” For example, Art is frustrated because clicking the “Become a Vandelay” button is supposed to open the form for a supplier application, but instead does absolutely nothing. Seems simple enough, but there are actually several things that could be going wrong here: The button is broken under the hood. The backend logic that pulls the latest version of the form isn’t working and needs fixing.The button isn’t clickable because of a CSS property that tells the browser to disallow the user from clicking. This is a frontend problem If you can do this, you are already ahead of most vibe coders Frontend and backend concepts, 201 If you’re curious to go deeper evidently you have time on your hands there are a few more things worth knowing about frontends / backends for vibe coding. What and where the frontend actually is There are all different types of frontends depending on where they’re built. Many most? apps that people access today are web apps, meaning that you use them in a web browser Chrome, Safari, etc. . For these apps, you only have 3 languages you can use, because only 3 languages can run in the browser: HTML, CSS, and JavaScript. On top of these languages, Claude Code will likely use some framework https://technically.dev/universe/framework s to make things easier to generate. The most popular frontend framework https://technically.dev/universe/framework for building UIs is React. React helps turn your frontend into reusable components and also handles complicated stuff like data flow and when to update the page. You’ve probably seen a React component in the wild before. It’s just a reusable chunk of code that under the hood is another chunk of code. When you want to use a component in your code, you write it like a tag: And the component itself is just… a function with a name that returns some UI. In addition to React, your AI model will likely choose to use a web framework. This is a piece of software that’s somewhere between a frontend and a backend, doing little bits of both. One of the most popular web frameworks for React is Next.js https://technically.dev/posts/what-is-nextjs , which helps with things like defining URLs, pre-loading data so your pages are really fast, and making it easy to add authentication https://technically.dev/universe/authentication . Outside of web apps, you have native apps – ones that run on phones as iOS or Android apps, or tablets and desktops, or even special-purpose hardware in factories, doctors offices, and other fun places. Though the languages and frameworks for these frontends are slightly different, the concepts are the same. For example, on mobile there is React Native , often used through Expo . What and where the backend actually is Backends, for the most part, do not run in a browser or on your device. They instead run in the cloud https://technically.dev/universe/cloud , on one or many giant servers specially built for exactly this purpose. The most important component of most backends is the database . It’s the backbone of the application you’re building because it’s where the data goes . Recall that so much of what you’re seeing on a webpage is actually just data: your username and password hopefully not https://read.technically.dev/p/what-are-passkeys , your profile information, your emails in Gmail, your playlists in Spotify…all data. All stored in a database somewhere. Databases are one of the areas where you tend to see the most competition among vendors leaking into vibe coding. If you’ve ever seen Claude propose using Supabase https://supabase.com/ , or Neon https://neon.com/ , or Planetscale https://planetscale.com/ , or unlikely RDS https://aws.amazon.com/rds/ , you are choosing a database provider. There are hundreds, maybe even thousands, all optimized for different types of data and different types of customers. The advent of vibe coding has been good to the database industry; Supabase co-founder Paul Copplestone has tweeted https://x.com/kiwicopple/status/2062595351824187678?s=20 about how a large percentage of their growth is actually coming from agents and vibe coders. You might think the frontend just talks directly to the database when it needs data, but it does not. Instead, you have APIs that act as a translation layer for a few reasons: Protecting your backend from strangers: the data in your database is proprietary, you don’t want just anyone to be able to query https://technically.dev/universe/query it. Data cleaning, formatting, and organization : databases store data for many reasons, and your frontend is only one of many consumers of that data. Centralizing query logic for re-use : several pages in your app might reuse the same data. Instead of rewriting that query in every single place, you can just use a single API endpoint each time. Not all APIs exist just to protect your database. You might build APIs to kick off workflows, or even use APIs from 3rd party providers like Stripe https://technically.dev/posts/what-does-stripe-do . APIs also have a language they speak, and it is for the most part called JSON. When your code asks an API for something, this is the format you’ll usually get the data back in. JSON looks like this: The structure is fairly self explanatory, but it’s worth noting that this is not how the data is actually stored. Part of the hard work of API building and design is exactly this: formatting, structuring, and aggregating. You’ll see the word JSON every day for the rest of your life as a builder. Now you know: it’s just data. If I had written this post a few years ago, I would have stopped here. But there’s a newly popular component of backends, and that’s AI models . If you’re building a product that has AI as part of it, there’s an entire new discipline of AI Engineering™ that encompasses picking the right model, prompting it correctly, doing evals https://technically.dev/posts/ai-user-guide-to-evals , context management…there’s a lot. All of this conceivably is backend work. The code that defines your APIs, when they get used, this AI nonsense, and other stuff like that also needs to run on a server somewhere. You may have also seen vibe coding tools suggesting places to do this. If you use something like Replit or Bolt, they provide their own hosting service for a fee often including database . If you use something like Claude Code or Codex, they might suggest a hosting provider like Vercel https://technically.dev/posts/how-vercel-became-the-ai-cloud , Netlify, or even AWS https://technically.dev/posts/aws-for-the-rest-of-us . Bringing all of this back to the Vandelay Industries app; when Art prompted Claude, the model went and built out a whole backend too. There’s a database for storing supplier and shipment data, plus a set of APIs the frontend uses to access that database. Art is smart, so he decided to host all of this on Railway https://railway.com/??utm medium=sponsor&utm campaign=technically , the all-in-one intelligent cloud provider. It gives him one place to run his database, API server, frontend, scheduled jobs, and anything else Claude might cook up for him in the future. The messy middle between modern frontends and backends Everything I just wrote is…mostly true. Unfortunately for those of us who explain things for a living, the lines between frontend and backend are starting to blur, and one particular culprit is Next.js. In Next.js and other web frameworks , you write your frontend and backend pretty much in the same place; it takes care of figuring out which is which and what runs where. In fact, your backend often lives in the same folder as your frontend. If you drop a file at app/api/applications/route.ts you’ve created a backend endpoint at /api/applications. Same project, same language This used to be two separate codebases maintained by two different teams who occasionally yelled at each other. Another area where the lines blur is server side rendering . When an app or website needs to send you a page that has data in it – in other words, a page that has some backend content – there are two places that can actually create that page. You can do it on the server side, pulling the requisite data and generating and formatting the whole page before sending it off to the client https://technically.dev/universe/client .Or you can do it on the client side, sending just the data from the backend and then actually melding it with the webpage on the client in the browser, phone, etc. . In practice, the difference is in where the backend logic happens: all on the server, or mostly in the browser calling APIs on the server. Traditionally, server side rendering was the dominant form of building web applications – it usually leads to much faster web pages. But as Javascript has gotten better and web apps have gotten more complicated, client side rendering is getting more popular, to the point where it’s now pretty much the default for most tech startups building their stuff from scratch. React is the poster child of that movement. So what’s really frontend, and what’s really backend? It’s complicated. We can safely say that HTML, CSS, and JavaScript in your browser is definitely frontend. We can also safely say that databases, APIs, and AI models running in the cloud are definitely backend. Everything else…well, the devil is in the details.