There's one decision in this first hour that makes the difference between a smooth afternoon and a confusing one, and it's not a technical decision at all. It's the order you do things in.

Deploy first, customize second

The instinct, once you've downloaded an app you own, is to open it up and start changing things — your business name, your colors, that one field you know you'll need. Resist it for about forty minutes. Get the app live on the internet first, completely unchanged, before you touch a single line.

The reason is simple and it saves people hours: if you deploy an untouched template and something breaks, the problem is in your setup — a key in the wrong place, a setting you skipped. If you change fifteen things first and then deploy, and something breaks, you have no idea which of the sixteen possible causes is responsible. Deploy first, customize second. Every step below follows from that.

Here's the hour.

0–10 min — Unzip it and look around

Download the zip, unzip it somewhere you'll find again (a Projects folder in your Documents is fine), and just read the folder names for a minute. You're not looking for anything. You're building a mental map, and it takes ten minutes once instead of confusing you for a week.

Nearly every web app, this one included, is three parts:

  • The frontend — everything your staff and customers actually see and click. Buttons, pages, forms.
  • The backend — the part nobody sees, which decides what's allowed, does the calculations, and talks to the database.
  • The database — where the information lives. These templates use SQLite, which is a database that's just a single file sitting on disk. No server to install, nothing to configure. (More on that in What a database is, in plain language.)

The folders in your zip map onto those three parts, usually as their own top-level folders — your README will name them exactly, since the layout varies slightly from template to template.

One file matters more than the rest, and you want to know where it is before you need it: the setup instructions (usually the README.md). This is the step-by-step guide for your specific template. If it ever disagrees with this post, the setup instructions win.

That's the whole tour. Don't open the code to edit yet.

10–20 min — Introduce the app to your AI assistant

This is the step almost everyone skips, and it's the one that changes how the rest of the project feels.

You're going to be asking an AI assistant — Claude, ChatGPT, whichever you prefer — to make changes to this app. AI assistants are very good at modifying code that already works, and much shakier at inventing an app from nothing. But they can only be good at it if they understand your app's structure first. Ask for a change cold, and the assistant guesses at the architecture and writes something that fights the code that's already there.

So before you ask for anything, give it a map.

Open a new conversation, upload your README.md file along with a core database file (like your schema.sql or models file), and say something close to this:

"These are the core structure and documentation files for an app I own the source code to. Read them and give me back, in plain language: what the app does, what the main pieces of data are, and how a user moves through it. Don't suggest any code changes yet — I just want to check that you understand its architecture."

Read what comes back. If it describes your app correctly, the assistant now has the context it needs, and every request you make from here will land in the right place. If it gets something wrong, correct it now — in this conversation, before any code is involved, where a mistake costs you one sentence instead of an afternoon.

Keep that conversation open. It's the one you'll come back to. (More on this — including how to make it permanent with a CLAUDE.md file — in Get your AI assistant to understand code you didn't write.)

Then close it and go deploy. Still no code changes.

20–40 min — Get it onto Azure's free tier

Your app is currently just a folder on your laptop. To be a real thing your team can open from their phones, it needs hosting — a computer on the internet that runs it and never turns off.

These templates are pre-wired for Microsoft Azure, and the deployment configuration ships inside the zip. You're not building a hosting environment from scratch; you're just pointing a pre-configured setup at an account that belongs to you.

Two things to know before you start, because they're the two that surprise people:

Azure asks for a credit card, even for free. It's an identity check, not a charge. The tier these templates run on stays free indefinitely — it isn't a trial that expires and starts billing you. Add a spending limit anyway while you're in there; it takes twenty seconds and it means the account can't surprise you later. (Full walkthrough: Create a free Azure account and the free-tier traps to avoid.)

Free tier means genuinely free, with genuine limits. The app sleeps when nobody's used it for a while, so the first visit after a quiet night takes a few extra seconds to wake up. For a business app your own team uses, that's a non-issue. It's worth knowing so you don't think something's broken the first time you see it.

The deploy itself: push your code to a GitHub repository, connect that repository to your Azure Web App from the Azure Portal (App Service → Deployment Center), and Azure takes it from there — the GitHub Actions workflow already bundled with your template builds and redeploys automatically on every push after that. Your README covers the exact one-time setup for your template; once it's connected, the deploy itself is just a git push.

When it finishes, Azure gives you a URL. Open it. The app loads, and it's the untouched template — which is exactly what you want to see, because now you know the setup works. Nothing you do from here can be blamed on the deployment.

40–55 min — Turn on login

Your app needs to know who's using it, and the answer is not to build a username-and-password system. Storing other people's passwords safely is a genuinely hard problem with real consequences for getting it wrong, and there's no reason to take it on. The template uses "Log in with Google" instead, which hands the whole problem safely over to Google.

That plumbing is already wired up in the app. Your job is simply to create your own set of credentials and paste them in — three values, one place, no code.

In the Google Cloud Console you'll create a project, request OAuth credentials for a web application, and get back a Client ID and a Client Secret. You also give Google a redirect URL: the exact web address it should send people back to after they log in.

That redirect URL is the one thing that trips up nearly everyone, so read this twice: it has to match your live Azure address exactly. Same protocol (https://), same domain, no missing or extra slashes at the end. If logging in sends you to an error page, this is the cause roughly nine times out of ten.

Then paste the two values into your app's configuration exactly where your README tells you to — typically a local secrets store while you're testing, and your Azure Web App's environment variables once it's live — and redeploy.

One rule worth adopting permanently: your Client Secret never goes into a file you push to GitHub. It goes strictly into your hosting configuration, where it stays private. (Both covered properly in Configure Google login in your app and Keep your secret keys safe. Background: "Log in with Google" explained.)

55–60 min — Log in and stop

Open your live URL on your phone. Sign in with your own Google account. Click through the main screens the way someone on your team would.

That's the hour. There's a live web app on the internet, with real login, a real database, and your name on the whole thing — and you haven't customized anything yet, which was exactly the point. You now have a known, working starting position to build upon.

Before you close the laptop, write your Azure URL and the name of your resource group somewhere you'll find them in three weeks. It sounds trivial, but it isn't.

What the second hour looks like

Now you customize — and now it's easy. You are making small, specific changes against an application that already works, which is exactly the kind of task an AI assistant handles best.

Go back to that conversation where the assistant already mapped your app's structure, and ask for one thing. Rename the app to your business. Change the colors. Add that one specific field your workflow needs that the template doesn't have.

One change, redeploy, check that it still works, repeat. That rhythm is the whole job from here.

Next: The right way to prompt AI to add a feature to your app. Start here if you're earlier in the journey: Launch your first business app with no coding.