The vibe coder’s guide to real coding

Things you should know as a vibe coder that will make your app actually work / not die.

This Thursday (10/23) is Vercel’s Ship AI conference, and I thought there’d be no better way to mark it than to give you something unprecedented for Technically: a three (yes, 3) post week.

We’ve got three (yes, 3) new pieces coming to you about the Vercel cinematic universe and why it’s so important for developers:

1. Yesterday: How building AI apps requires different infrastructure than web apps

2. Today: The vibe coder’s guide to real coding — all the things you need to know to turn your vibe coded app into a reliable product

3. Tomorrow: How to build AI products that actually work (all about evals)

Enjoy!

—

So you sat down and vibe coded an app that you’ve wanted to build for a while. Like magic, you prompted a model (maybe it was in a product like v0) and the app of your dreams appeared. The obvious question is…now what? What is your app, exactly? And how do you make sure it works fast and smooth?

This is the vibe coder’s guide to real coding. I’m going to run through the 5 most important things to know about the app you’ve built so you can take it to the moon…or just avoid getting hacked.

1) All about servers and the cloud: where your app is running (or needs to run)

When you build an app from scratch, one of the things you need to worry about is distribution – how do you get it running on a server somewhere so everyone can access it? Today, most developers have a two step process for building their apps:

• First, they build the app locally: on their laptops or desktops. All of the code runs on your computer, and nobody else can access it. Think of it like your personal sandbox.

• Once the app is ready, it gets deployed to the cloud: big, rented servers. Via these, users (hopefully many of them) access the app over the internet.

This is the world of cloud infrastructure. You’ve probably heard of the big dogs – AWS, GCP, and Azure – and maybe even smaller managed service providers like Heroku. There really are a million ways to get your app in the cloud today. The important thing to know is that apps have to run somewhere; and where and how you choose to run them have major impacts on how they perform.

If you built an app using something like v0 or Lovable, this step of the equation is already taken care of for you. v0 gives you a one click option to deploy your app to Vercel’s cloud; all you do is click deploy and you get a URL. But if you used something like Claude Code, OpenAI Codex, or even regular old Claude or ChatGPT, you might need some help turning that app into something everyone can use.

One of the many reasons that developers like the cloud (instead of buying and racking their own servers) is how easy it is to scale. If your app is successful – and pray we do, assuredly – it will require increasing amounts of both compute power and data storage. With modern cloud services, doing this is as easy as just clicking on a bigger server and paying for it. Of course if you ever get to insane giga-scale (like Meta or Google)...things are a bit more complicated. But one step at a time.

Speaking of backends…

2) A basic primer on backends, the foundation of your app and data

Websites are kind of just a bunch of text, images, and colors. Apps, on the other hand, are a lot more complicated. To quote myself, which I will happily do:

An application – like the one you’re reading this post on – is made up of just two parts: a frontend and a backend.

The best analogy I’ve thought of for frontends and backends is a restaurant. Say you’re having a lovely evening with the homies (after you’ve hugged and kissed them of course) and you stroll into your favorite upscale Brooklyn eatery. 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

• How to cook everything consistently and perfectly

• Where to source quality ingredients from

• How to prepare and store those ingredients

• What to do in situations where ingredients are missing or go bad

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.

More specifically, every single app backend is going to start with a database. Databases are where you store most of the data related to your app. Every app uses databases for different things. Gmail stores your emails in one, Twitter stores your tweets in one, and Substack stores your posts, likes, and comments in one too. There are 300+ different databases, many of which are custom built for very specific use cases and types of apps.

Then there are APIs, which you’ve probably heard of. They are like little drive through windows in front of your database, helping developers roll up common operations on the database into a few lines of code instead of a long SQL query. Sometimes developers will even provide APIs to their customers so they can use their apps programmatically… but I digress.

There are other logistical parts of backends today, too. One of those is authentication: letting users log into your app quickly and securely. Then there are payments, which most startups these days will outsource to Stripe. Increasingly today, you might make use of LLMs from OpenAI or Anthropic…using those is backend work too.

Backends are probably the most important thing for vibe coders to understand, because they’ll mean the difference between success and your app literally not working. If you built your app using something like v0, you get access to built-in integrations with database providers like Supabase and Neon – they handle this for you automatically without you needing to create / manage other accounts. But chances are as you build out more and more of your app, you’ll need to peek under the hood and get to know your database just a little bit better.

3) Version control and making safe changes to your app

One of the most underrated challenges in modern app development is playing nice with friends. Startup codebases will have tens, or even hundreds of developers working on them simultaneously. And if you’re talking about a huge app like Gmail, forget about it; you could have thousands or tens of thousands of developers, all editing the same code at the same time. How the hell does this work?

The quick answer is version control, and more specifically in most cases Git. It’s like the “save as” functionality you’d use in Microsoft Office, but on steroids:

Instead of just saving and losing all of your previous progress, version control makes you commit your changes as new versions while still keeping the old ones: and you can go back to any commit at any point in time. It’s basically as if you saved every group of changes as a new file separately, but in a much simpler, more efficient way.

If you’re a developer who wants to change up the codebase – let’s say, fixing a bug, or building a new feature – you start by making a copy of it on your laptop. You work on that copy, editing and adding to your heart’s content. Along the way, as you make progress, you group each set of changes into a commit and save them like you would a file. When you’re done, you merge your changes into the central, shared codebase that’s actually running in the cloud.

So essentially, developers aren’t literally all editing the same code at the same time, like 8 people at a table all reaching for the gravy. They’re making copies, changing those copies, and then figuring out how to reconcile all of the disparate versions. This might sound convoluted (and some would argue it is), but it’s the foundation of how apps are built safely today.

Now, for the vibe coder. For the first few versions of your app, you might be happy with making changes directly; you’re tinkering and haven’t gotten where you want yet. But once the app is in a stable place and you’re ready to share it with users, you should be a little more careful about how you make changes. You don’t want a bad prompt to break your app, and have no way to revert back to the good old days. And here again, v0 tracks your versions automatically, so you can always roll back to a previous state. If a prompt derails your app, just jump back and keep building.

4) Monitoring and observability: making sure your app is working

If there’s one thing people hate more than anything, it’s slow and buggy websites and apps. Countless research studies show that people have very low tolerance for hiccups in the software that they use. 10 years ago, everything on the web felt new and experimental. Today, there’s an expectation of near perfection. And if your software doesn’t work, users will find someone’s that does.

But fast and bug-free apps don’t simply fall out of the sky. They are crafted, meticulously, via tightly monitored feedback loops. The best engineering teams carefully track metrics across their entire stack, from how many errors different API endpoints are running into, to how much CPU their server on Amazon is utilizing on average today. This is why Datadog continues to print money!

There are a few big categories of things that engineers look for in a high performing app:

• How long it takes for different screens to load

• Bugs and errors, and how common they are

• How long API requests are taking

• Most common API requests

What a tool like Datadog does is check for anything you want it to (say, length of API requests). If the number crosses a threshold – say it’s taking 30+ seconds for your app to load a user’s profile – it will alert the team that something is wrong, and the frantic dash known as “an incident” begins.

It is not only the app that a developer must monitor, though. Remember that apps run in the cloud on specialized rented servers…and those servers are never quite perfect. You might continually check on:

• How much CPU the server is using

• How much RAM the server is using

• How much disk the server is using

• Peaks and valleys for this stuff

As a vibe coder, most of this server stuff is probably a little out of band for you. But you absolutely should be closely monitoring how your app performs in common scenarios. Since v0 essentially just deploys your project to Vercel, you can use Vercel’s Observability features to monitor things like error rates, response times, and traffic to your app.

If you’ve got a database too, you’ll likely want to set checks for that too.

5) Security 101

Every developer’s biggest nightmare is that their app gets no traction, and nobody wants to use it. But their second biggest nightmare is getting hacked. Vibe code or real code, you need to secure your app. Or you will get hacked. Probably.

To regale you with the tales of how developers secure their applications would take more time than either of us have today. Suffice it to say that really having a secure app – nay, a secure organization – is accomplished by paying close attention to every detail that pertains to your attack surface. A few examples:

• Setting up firewalls so your servers can only be accessed by authorized individuals

• Setting up guardrails around every form in your app, so hackers can’t submit malicious evil code through them

• Keeping your secrets – or credentials for pieces of your app – securely managed

The larger and more successful your app becomes, the more components it will have that need locking down. But simultaneously, the higher profile you are the more hackers are going to target you. A double edged sword if there ever was one, success is.

With AI apps, security is even more difficult. Hackers have found ways to manipulate LLMs into revealing the credentials of other users. People will casually send passwords, social security numbers, and other sensitive digits to models without thinking. It’s the wild west out there.

This is absolutely critical for vibe coders to start thinking about. If you don’t lock down your app, you will get hacked.

A good place to start is a checklist of some best practices. Make sure you don’t have any API keys or passwords hard-coded into your frontend code. Try to use a more secure authentication mechanism that isn’t username/password. Make sure you have a firewall set up.

If you’re using v0, it already does a few of these things for you:

• All of your credentials are managed tightly by Vercel. Unless you slip up, nobody is going to be able to steal them.

• Safe defaults for things like authentication and database access.

• Vercel takes measures to help prevent that pesky prompt injection (they even wrote a blog post about it).

Your app isn’t going to be bulletproof unless you really take the time to understand security (and even then…) – but v0 at least gives you secure defaults from the start.

---

“Follow these rules, and you’ll have mad bread to break up.”

– Christopher George Latore Wallace