Have you ever shipped a vibe coded app and then, once the adrenaline wore off, thought “..now what?”. This post is to help you answer the following questions:

  • Are people visiting your app?
  • What are they even doing when they make it to your site?
  • Is your application actually working?
  • How can you know the moment your app breaks?
  • What should you do when your app breaks and how can you fix it?

There are answers to the above questions, all you need are the words to ask Claude Code (or whatever agent you use). Let’s get started!

Are people visiting your app?

This is probably THE question, right? If people aren’t visiting, it’s not quite as important if the software isn’t working properly. So how do you know if people are visiting?

One word: Analytics

What are analytics? They’re metrics that get collected when a user comes to the site. Depending on where you host your front end, chances are your provider already has some basic analytics built in like number of visitors, page views, and referrers (where your traffic is coming from). So whether you use Vercel, Cloudflare, or another provider, these basics are probably covered. Typically all you need to do is turn them on and there will be a dashboard you can check out.

What are they even doing when they make it to your site?

Here is where things get more interesting and nuanced. Let’s say the answer to the question “are people visiting your app?” is a resounding YES. Wonderful! But this is where I’ve found the default analytics tends to fall short. You probably want to know details that are very specific to your app. Not just page counts, but maybe whether or not users are clicking that important button. Are they using your most valuable feature? Do they seem like they understand the tool and are realizing the full value? How will you know what part of the app needs tweaking? The part people aren’t using. How will you know what user experience is working well and which one needs to be fixed?

This is exactly where vibe coded analytics are amazing! You can build perfectly tailored analytics to answer the questions you care about and move your app in the direction you want it to go.

So what does this look like? How do you make it a reality? Easy! You’ll need to sign up for some sort of backend/db as a service with a generous free tier (think Supabase, Firebase, there are lots to choose from) and honestly, that’s the hardest part. After that it’s just articulating the things you care about. Button clicks, sign ups, session lengths, whatever! Claude makes it really straight forward. Just have it collect the metrics, save them to the database, and then build you a dashboard that you can use to view the metrics you care about.

Is your application actually working?

This one is a little trickier. To keep this high level, let’s define “working” as not crashing or throwing errors.

There are several different ways to validate this. Things like compilation for static languages, writing tests, and running locally on your machine or in a test environment. Since this post is centered around validating that your app is working once users are actually using the app, that’s what I’m going to focus on. This section will cover Logging and the next one will cover Error Reporting.

Logging: think of logs as a history of actions your program took. You (or Claude) has control over what gets logged and what doesn’t. Let’s give an example. Imagine you need to save something to your database. Perhaps it has a transaction id associated with it. It would be useful to have logs of all transactions that occur. Successful transactions in the logs can let you know things are working properly. But it’s even more important to know when things are not successful. Those logs are one way to know that there is a bug in your application and it will help you (or Claude) understand what went wrong so that you can fix it. I will say this is a simplistic view of this and what constitutes a useful log vs noise can be a bit nuanced, but hopefully it portrays the point.

How can you know the moment your app breaks?

Alright, logs can be really useful if you already know something went wrong, but who has time to just constantly read logs proactively? Wouldn’t it be easy to miss something? YES! That’s where Error Reporting comes into play.

Error Reporting tools allow you to send crash and error data to them and then they will alert you when something comes in. The crashes can include all sorts of useful data that logs wouldn’t include like the exact line the crash happened at in the code, useful attributes, events that occurred leading up to the crash, and things like that. Essentially all of the raw materials needed to fix whatever is broken. Some examples of tools like this are Sentry, BugSnag, and Backtrace. This brings us to the next question:

What should you do when your app breaks and how can you fix it?

The best part about using Error Reporting tools these days is most of them have skills and MCP servers. They’ll alert you when something is going wrong and you can just have Claude Code do the debugging for you! Here’s what the flow could look like:

  • You’re hanging out and playing Rocket League (just me?)
  • You get an email (or text, or discord message, or whatever form of communication) that something is broken
  • You panic and feel a surge of adrenaline
  • You fire up Claude Code (or your agent) and ask it to investigate
  • Claude Code uses the Error Reporting tool and the logs to either determine an exact root cause, or identifies the information needed/additional logs to add, to fix the issue. It creates a fix, you validate it, then have it write new tests to make sure this doesn’t happen again.
  • Then back to your game

Without this tool you wouldn’t know something was going wrong until a customer complained.. not a good look.

Welp, that’s all for today! There’s tons more about each of these topics and this post is only scratching the surface. Let me know if you want me to dive deeper into anything specific.

Happy Sunday and keep on vibin’!