Articles
← All articles

What AI Won’t Tell You When It Builds Your App

Fair warning. This one’s for the builders.

Not the engineers. Not the developers who’ve been doing this for years. This one is for the marketer who just shipped their first internal tool. The ops person who spent a weekend building something useful and thought, “wait, this actually works.” The freelancer who scoped a project for a client and realized AI could get them 80% of the way there.

If that’s you, keep reading.

TL;DR AI will build whatever you ask it to. What it won’t do on its own is set up the foundation that keeps your project from falling apart as it grows. This article covers four things experienced developers do by default that most first-time builders skip: version control (so your work is never lost and your team can always pick up where you left off), CI/CD (so your app gets to the world automatically every time you make a change), backends (so your data has somewhere to live and the right people can access it), and security (so you’re not accidentally handing your passwords to the internet). It also includes a free repo with prompts and a Claude skill that does most of this setup for you.

AI will build whatever you ask it to.

It won’t stop and say “hey, you probably should have saved a checkpoint before adding three more features.” It won’t ask “who’s supposed to have access to this?” It won’t flag that the password you just typed into your project is now visible to anyone who finds it online.

It just builds.

And that’s the gap this article is about. Not a rant against AI or against moving fast. A practical look at the habits experienced developers apply by default, the ones that protect their work, their users, and their sanity, that most first-time builders skip entirely. Usually not out of laziness. Out of not knowing they existed.

The Two-Hour Mark

You’ve probably seen it by now. Someone in your feed built an app over a weekend. A marketer automated something that used to take their team hours. A freelancer delivered a working prototype in a day. Tools like Cursor, Lovable, and Claude Code have only recently hit their stride, and the wave of non-technical people building real things is just getting started. The habits around how to do it well haven’t caught up yet.

(And if you’re a developer reading this, I know, you already do this… but I’m curious what you think of my list. Drop a comment.)

Someone starts building. AI makes it fast, almost frictionless. An hour in, they have something that actually does the thing they imagined. So they keep going. Add a feature. Then another. Fix a thing. Add a thing. And here’s the part nobody warns you about: every prompt you send is another chance for your AI co-worker to break something beyond saving. The further in you go without a foundation, the harder it gets to unwind.

But people work differently, and that’s worth acknowledging.

Some people need to plan before they do. If that’s you, set up the foundation before you write a single line of the app. The idea will wait.

Some people need to do before they can plan. The idea has to exist before it makes sense to protect it. If that’s you, build until the moment you think “this has wings” — then stop. Go back. Set up the foundation before you add another feature. It’s a little more work than starting clean, but sometimes being creative means being flexible enough to bend the rules a little.

Either way, there’s a shortcut: build a skill or a reusable template that sets the foundation up automatically every time you start a new project. Most AI tools support this in some form. Do it once, and you never have to think about it again.

So. What does that foundation actually look like?

🗂️ Version Control: Your Project’s Memory

Think about the last presentation deck you worked on alone.

You knew where everything was. You had a system. Maybe the file was called “Q3_Deck_Final.pptx” or “Q3_Deck_Final_v2_ACTUAL_FINAL.pptx.” We’ve all been there.

Now think about what happened the moment that deck got good enough to share. Suddenly there were five people in it. Someone updated the intro. Someone else changed the data on slide 12. A third person reformatted half the thing. By the end, nobody was sure which version was the real one, who changed what, or where that original headline went.

That chaos has a solution. It’s called a repository (repo for short), and it’s been standard practice in software development for decades.

A repo isn’t just a backup. It’s a living record of your project, every version, every change, every note you leave yourself about why you did what you did. If something breaks, you can go back. If someone needs to pick up where you left off, they can. If you want to reuse a piece of something you built three months ago, it’s there.

And here’s the part that gets more interesting over time: your repo can store more than just code.

It can store your prompt templates. The instructions you’ve refined over weeks of working with AI. The notes you’ve built up about how a particular client’s system works, what to avoid, what always trips things up. Over time, that repo becomes institutional memory. Not the kind that lives in someone’s head and walks out the door when they leave. The kind that compounds.

Some AI tools can connect directly to a project repo and pull from that context automatically. Not all of them do this yet, and how they do it varies. But even without that integration, having a structured, version-controlled set of instructions is infinitely better than rebuilding your prompts from scratch every time.

Where to start

You don’t need the command line for this. (Command Line = that black screen with white or green text you often see “hackers” use in movies, or think “The Matrix.”) But for almost everything you can do in this technical tool, almost always, there is a point and click version of it, called a GUI (Graphical User Interface).

For where your repo lives (pick one):

For how you interact with it (pick one):

One thing worth knowing: some GUI clients work across multiple repo hosts. GitKraken, for example, connects to GitHub, GitLab, and Bitbucket. You’re not locked into one platform just because of the tool you use to access it. That flexibility matters more than it might seem right now.

The habit to build: commit your work often. Think of a commit like hitting save, but with a note that says what you just did and why. You’ll thank yourself later.

⚙️ CI/CD: The Conveyor Belt

Let me explain this the way I’d explain it to someone who’s never heard the acronym before.

Think about a PowerPoint sitting on your desktop. Until you email it, upload it to Google Drive, or share it some other way, nobody can see it. Apps and websites work exactly the same way. They live on your computer, invisible to the world, until someone puts them somewhere public.

The act of making an app/tool/website “public” usually means uploading your project to the internet. That process can be tedious, or simple, depending on your project. In the early days, it meant manually taking files and uploading them. Every time you made a change. Every time you fixed a bug. Every single update, done by hand.

CI/CD automates that. Every time you save a change and push it, the system sees it and handles the upload for you automatically. You make a change, you push it, and a few minutes later the updated version is live.

CI stands for Continuous Integration. CD stands for Continuous Deployment (or Delivery, depending on who you ask). Together, they’re the conveyor belt between your work and the world.

Where to start

Some options are baked directly into your repo platform:

Standalone tools that are beginner-friendly:

Then there are platforms that blur the line between CI/CD and hosting entirely:

These all-in-one platforms are worth calling out specifically. They’re genuinely great starting points, and plenty of experienced developers use them. But they come with a tradeoff worth understanding: you’re trading some control for convenience. Free tiers change. Platforms sunset features. Pricing models evolve.

The thing to notice is that even Vercel, which does a lot for you, doesn’t host your repo. Your code still lives on GitHub. That distinction matters. The more of your project that lives in your own repo, the more portable you are — meaning, the easier it is to pick up and move to a different platform if you ever need to. (More on that in a future piece.)

Whatever platform you choose: have an exit plan. Not because something will necessarily go wrong, but because knowing you could leave is what keeps you from being stuck.

🗄️ Backends: Where Your Data Lives

Every app has an output.

Sometimes it’s something to copy and paste. Sometimes it’s a PDF, an email, an API call to another tool. Sometimes it’s just “I want to show someone this.” Whatever it is, there’s a moment in almost every project where you realize: I need this to reach someone else, or still be there tomorrow.

That’s the backend moment. And it usually hits somewhere between hour three and hour ten of building, if you’re not thinking about it early.

The needs tend to surface in two tiers.

The first is sharing. How do I get the output to someone who isn’t sitting next to me? Can they just use a link? Do they need to enter something first? Will they need an example ready to go, or can they bring their own input?

The second is storage. Does the app need to remember anything? Does it need to know who’s asking? Does it need to keep a record of what happened last time?

The moment you answer yes to any of those questions, you need somewhere for that data to live.

But here’s the thing: not every app needs a database. Some apps just need a well-organized file.

I have a resume app I built where all the data is a simple JSON file that lives directly in the project. There’s no database, no backend service, no monthly bill. Just a structured file in the repo, version controlled, easy to update, perfectly sufficient for what the app does. When I update my resume, I update the file. I commit it. Done.

Knowing whether your app needs a full backend or just a well-structured file is the first question to answer. Here’s a simple frame:

When you do need a backend, my personal preference is Supabase. It gives you a database, authentication, and storage in one place, the interface is clean enough that non-developers can navigate it, and it’s open source, which means you’re not locked into a proprietary ecosystem. But I want to be clear: that’s a preference, not a prescription. I know people who swear by Vercel’s ecosystem, by Firebase, by PocketBase. There is no universally right answer here.

The best advice I can give: describe what your app does to the AI that helped you build it, and ask it to recommend a backend architecture. It knows your project. It will have a more informed opinion than any listicle, including this one.

For projects that don’t need a database at all but do need somewhere to run server-side logic, Cloudflare Workers is worth knowing. It’s fast, the free tier is generous, and it sits at the edge of the network in a way that makes lightweight tools feel snappy. If your app is simple enough that it doesn’t need auth or storage but does need to do something on the server, Workers might be all you need.

A note on all-in-one platforms: some tools will offer to handle your backend, your deployment, and your hosting all in one place. That can be a perfectly reasonable choice, especially early on. Just go back to what we talked about in the CI/CD section. Understand what you’re trading. Have an exit plan. Make sure your code lives somewhere you control.

🔒 Security: What AI Skips By Default

This is the section I most want you to actually read.

Not because I want to scare you. Because the risks here are invisible until they’re not, and by then the damage is already done.

AI will build a working app. It will do it fast, and it will do it well. What it won’t do, unless you specifically ask, is make sure that app is secure. It’s not being careless. It’s doing exactly what you asked. “Make it work” and “make it secure” are two different instructions, and most people only give the first one.

There are two categories of security gap I see most often with non-technical builders.

The first is technical: secrets ending up where they shouldn’t be. Secrets are exactly what they sound like — passwords, API keys (private codes that connect your app to other services like Google Maps or an email provider), and other credentials that are meant to stay private.

The most common version of this is those passwords and keys stored directly in the code, in a file that gets pushed to a public repository. GitHub has automated bots that scan public repos for exposed credentials in real time. By the time you realize the mistake, someone may have already found it.

The fix is environment variables — a separate, hidden file where your secrets live, that never gets uploaded along with your code. Your AI can set this up for you. Ask it to. Every time. Before you share anything publicly, check what’s in there.

The second gap is conceptual, and it’s harder to see: not understanding accounts, roles, and permissions.

When you build an app and share it with a few people, a set of questions tends to follow quickly. Can they change things, or just view them? Can they see each other’s data? Is there even a concept of “their data” versus “your data”? What happens if they share the link with someone else?

Most vibe-coded apps don’t have answers to these questions, because nobody asked them during the build. The app worked, so it shipped. And then it turned out the whole thing was wide open.

This isn’t a character flaw. It’s a knowledge gap. The concept of roles and permissions is something developers internalize early. For everyone else, it’s invisible until something goes wrong.

The antidote to both of these is curiosity, and a prompt.

Before you go much further with any app that will touch real data or real users, drop this into your AI tool of choice:

Before we go further, I want to make sure this app is built securely from the start. Please ask me the following questions one at a time, then use my answers to propose a security architecture, flag risks, and outline tradeoffs.

1. What does this app do, and who is it for? (Personal use, a small team, the public?) 2. Does it collect, store, or display any sensitive data? (Logins, personal info, financial data, API keys?) 3. Who should be able to do what? Are there different types of users with different levels of access? 4. Does it connect to any external services or APIs? 5. Where will this live? (Local only, shared link, public URL?)

Based on my answers, please propose: a simple security architecture appropriate for this project, any secrets or keys that should never be hardcoded, a recommended auth approach if users are involved, a role and permission structure if multiple user types exist, and the top three risks I should be aware of given what I’m building.

Use this prompt. Save it somewhere. Make it a habit.

And then: be curious.

The prompt is a starting point, not a ceiling. If the AI flags a risk you don’t understand, ask it to explain. If it proposes an auth approach you’ve never heard of, dig into it. If something feels off, it probably is.

The developers who build secure apps aren’t smarter than you. They’ve just asked more questions. The gap between you and them isn’t talent. It’s the accumulated habit of being curious about things that aren’t immediately visible.

You can build that habit. Start now, before the app gets any bigger.

One More Thing

Two things worth naming before I close, because they’ll come up as your projects grow.

The first is system agnosticism. The tools you choose shouldn’t hold you hostage. Whether it’s your repo host, your CI/CD platform, your backend, or your deployment target, the goal is to make choices that give you room to move. That doesn’t mean you have to switch tools constantly. It means you should always understand what it would take to leave, and make sure the answer isn’t “rebuild everything from scratch.”

The second is separation of concerns. This is a principle that experienced developers apply almost unconsciously: keep different parts of your app doing different jobs. Your data layer shouldn’t also be your logic layer. Your content shouldn’t be tangled up in your configuration. When everything is mixed together, changing one thing breaks three others, and nobody can figure out why.

Both of these deserve a longer conversation, and they’ll get one. But even just knowing the terms, and knowing they matter, puts you ahead of where most vibe-coded projects end up.

AI is genuinely one of the most useful tools I’ve seen come along for people who want to build things. I’m not here to put a ceiling on that.

I’m here to say: set up the foundation. At hour two, before you add another feature. Git, CI/CD, a backend decision, and a security prompt. In that order.

The app will still be there when you’re done. And it’ll be worth a lot more with a foundation under it.

What are you building? I’d love to hear. Drop it in the comments.

PS. In the spirit of not asking you to do something I wouldn’t do myself — I created a public repo with two things in it. One is a skill you can add directly to Claude that will handle the foundation setup for you automatically. The other is a file of prompts you can drop into any AI tool to walk through the security questions, the backend decision, all of it. No setup required. Just grab what’s useful and go.

https://github.com/fernieggg/project-foundation-skill

#martech #marketingops #vibecoding #aitools #buildinpublic #revops #systems