Toolkit setup guide

From zero to an app you can edit, with a database and a public address. No programming required.

This guide gets your tools ready. It is written for someone who has never programmed. The exact names of buttons change between tools and between months, so each step says what you are trying to achieve and what you should see when it worked. Your instructor names the specific tools by email one week before session 1.

If a step fails, do not guess. Copy the sentence in “Ask the assistant” and paste it, with the error message, into your assistant.

The tools and what each is for

Tool What it is for You will recognize it by
An AI assistant that supports skills, connectors and agents Thinking, drafting, and later building in your repository A chat window that can also open a folder of files and act on it
An app builder Your first version, from a sentence to a deployed app You describe the app and it appears, with a “Publish” button
GitHub The home of your app’s files, with every version kept A website where each project is a “repository”
A managed database and a hosting platform Where the data lives, and where the public address comes from Dashboards with a project name, keys and a web address
A model provider’s developer account (from session 3) The model your app calls, billed by use A console with usage, a spending limit and API keys

Expected cost for the course: USD 45 to 60 per student: two months of the assistant’s individual plan and about USD 5 to 10 of model usage. Confirm the current prices before you pay; they change.

The data rule

Until your team has completed the session 4 lab, closed every critical finding, and has the written agreement of the organization that owns the data, use only invented or de-identified information: no real names, phone numbers, addresses or tax numbers. Most teams will stay with de-identified data through Demo Day, and that costs nothing in the grade. A realistic message with the names, phone numbers and addresses changed teaches you exactly as much as the real one.

Before session 1 (about 20 minutes, every student)

  • Create an account on the AI assistant named by your instructor, on the individual paid plan if the free plan does not include skills and connectors.
  • Create an account on the app builder. The free tier is enough for session 1.
  • Create a GitHub account. Use a personal email you will keep after the course.
  • Write down the one business problem you will bring: who has it, how often, and what it costs them.

Before session 2 (about 75 minutes)

In session 1 you built a first version inside the app builder. Before session 2 you move it to a place where your assistant can work on it properly, and you prepare the database.

Who does what. Parts A, C and D are done once per team, by the member whose builder account holds the app. Part B is done by every member, on their own laptop. Do the parts in order.

Part A. Put the app in a private repository (10 minutes, once per team)

Goal: the files of your app live in a GitHub repository that only your team can see.

  1. In the app builder, open your project and find the option to connect to GitHub or export the project. It is usually in the project settings or behind a GitHub icon.
  2. Allow the builder to create a repository in your GitHub account. Name it after your product, for example quotedesk.
  3. Open GitHub in your browser, find the new repository, open its settings, and confirm its visibility is Private. If it says Public, change it now.
  4. In the repository settings, invite your teammates as collaborators.

It worked when: you can see a list of files in the repository on GitHub, a small padlock or the word “Private” sits next to its name, and your teammates can open it.

Ask the assistant: “I am not a programmer. I built an app in [builder name] and I need its files in a private GitHub repository. Tell me exactly where to click, one step at a time, and wait for me to confirm each step.”

Part B. Open the repository in your assistant (30 minutes, every member)

Goal: your assistant can read and change the files of your app on your own laptop.

  1. Install the desktop version of your assistant, or the editor your instructor named, on your laptop.
  2. Sign in to GitHub from inside it when it asks.
  3. Choose the option to open a repository from GitHub (it may be called “clone”, which means download a linked copy), pick your repository from the list, and choose a folder on your laptop to keep it in.
  4. Ask the assistant: “Describe this project to me in five sentences. What does it do, what are its main parts, and how do I run it on my laptop to see it?”
  5. Follow its instructions to run the app on your laptop. It will ask to install two free programs (Git and Node.js) and may ask for your computer password; say yes. Allow 30 minutes the first time. A browser tab opens with your app in it.

It worked when: the assistant describes your app correctly and you can see the app in a browser tab on your own laptop.

Ask the assistant: “I cannot see my app running. Here is what I see: [paste]. Fix it and tell me in one sentence what was wrong.”

Part C. Create the database project (15 minutes, once per team)

Goal: an empty database exists, ready for session 2. You do not design tables now.

  1. Create an account on the managed database service named by your instructor and create a new project. Give it the same name as your product. Choose the region closest to your users.
  2. The service shows you a project address and two keys. Read the section “Keys” below before you copy anything.
  3. Put the project address and the publishable key in your project’s settings, following your assistant’s instructions (see “Ask the assistant” in the Keys section). The secret key waits for Part D.
  4. Do not create tables. Your team does that together in the session 2 lab.

It worked when: you can see an empty project dashboard, your project’s settings hold the address and the publishable key, and no secret key is anywhere in the repository.

Part D. Connect the hosting platform (10 minutes, once per team)

Goal: every time your team saves a checkpoint, a public address updates by itself.

  1. Create an account on the hosting platform named by your instructor, signing in with GitHub.
  2. Choose “import a project” or “new project” and pick your repository.
  3. Before you deploy, open the platform’s page for “environment variables” or “secrets” (settings stored on the server, outside the code) and add the database project’s address, its publishable key and its secret key there. This page is the only place a secret key is ever typed.
  4. Accept the suggested settings and deploy. The platform gives you a public address.
  5. Open that address on your phone.

It worked when: your app opens on your phone at an address you did not have yesterday, and the secret key appears in the hosting platform’s settings and nowhere else: no chat, no message, no file.

Part E. Five checks (10 minutes)

  • The repository is private, and every teammate can open it.
  • Every member's assistant can describe the project and run it on their laptop.
  • The database project exists and its secret key has not been pasted into any chat, message or file.
  • The hosting address opens on a phone.
  • You asked the assistant to make one small visible change (for example the page title), saved a checkpoint, and saw the change appear at the public address a minute later.

A checkpoint is a named snapshot of the whole app at a moment it worked. In this course, saving a checkpoint always includes sending it to GitHub, which is what updates your public address. Until then, a change exists only on one laptop.

Before session 3 (about 25 minutes, once per team)

In session 3 your app calls a language model. That needs an account that is separate from your assistant subscription and is billed by use.

  1. Create an account on the model provider’s developer console named by your instructor. Add USD 5 of credit.
  2. Set a monthly spending limit of USD 10 and an email alert.
  3. Create one API key (a secret key that lets your app use the model), name it after your product, and type it into your hosting platform’s environment variables page. Nowhere else.

It worked when: the key appears on the hosting platform’s page, the spending limit shows in the provider’s console, and the key is in no chat, message or file.

Because the key lives only on the hosting platform, the AI feature will not run on your laptop. In the session 3 lab you save a checkpoint, wait a minute for the public address to update, and test there.

For the morning digest (session 3, option B)

One of the two options in session 3 is a morning digest that your team’s assistant prepares on a schedule. The assistant cannot see inside your deployed app, so you hand it a file through the same door it already uses for the price list.

  1. Ask the building assistant: “Add a manager-only button ‘Export pending requests’ that downloads a file with customer, time received and rep. No prices, no phone numbers.”
  2. Save that file each morning into the shared folder your price-list connector already reads. In the lab you do this once by hand.
  3. Ask your assistant one question that needs the file (“how many requests are older than three hours?”) and check the answer against the app.

It worked when: the answer matches what you see in the app, and the connector’s settings still show read access and nothing else.

A real deployment needs a view that refreshes by itself and a second alert channel. Note both as open items in your risk memo.

Keys

A key is a long string that lets software use a service on your behalf. Treat it like the keys of a building.

Kind of key Who may see it Where it goes
Publishable key (the database service may call it “anon” or “public”) Anyone. It is designed to reach the browser. In the project’s settings, where the assistant puts it
Secret key (it may be called “service” or “secret”; the key of the model provider is always secret) Nobody outside the server On the hosting platform’s “environment variables” or “secrets” page, and nowhere else

Three rules that are never broken:

  1. A secret key is never pasted into a chat, an email, a slide, a screenshot or the repository.
  2. If a secret key was ever pasted somewhere it should not be, it is revoked in the service’s dashboard and a new one is created. Deleting the message is not enough.
  3. The publishable key does not protect your data. The rules inside the database do. You set the first rules in session 2, with the login, and tighten and test them in session 4.

Ask the assistant: “I have a publishable key and a secret key for [service]. Tell me exactly where each one goes in this project and in [hosting platform], and confirm that the secret key will never be sent to the browser. Do not ask me to paste the secret key into this chat.”

If you could not get your app out of the builder

Use the course starter instead of Part A. It is the app as it stands at the end of session 1: paste a message, pick a customer, save to today’s list.

  1. Open github.com/hizocar/vibe-coding-starter. If the page says it cannot be found, ask your instructor for an invitation and open the link again.
  2. Press Use this template, then Create a new repository. Name it after your product, choose Private, and create it.
  3. Invite your teammates in the new repository’s settings.
  4. Continue this guide from Part B with your new repository. In the lab you will reshape its one screen to fit your own product.

It worked when: your own copy shows the word “Private” next to its name and contains a file called AGENTS.md, the standing instructions your assistant will read.

If you could not finish

Bring your laptop to session 2 fifteen minutes early. Nobody is graded on this guide.