YEAR 4 / COURSE 1 / STUDENT LAB

From your idea to a shareable link.

Build a new idea or an extra for your existing business. Start with a working example. Put it online. Make one purposeful change on a branch. Test it with a partner, publish it, and explain how you would recover.

Download the starter ZIP · Try the example

What you need: your own GitHub and Vercel access, a browser, an editor, and a partner. Local Git and a coding agent are useful; the GitHub browser interface can also create a branch, edit, commit and open a pull request. The starter itself needs no API key, package install or database.

Before you build

Your venture sentenceWhat do you want to learn?

These fields stay in this page. Print or save a PDF to keep your answers; reloading clears them.

Connect today’s build to the minor

0403EE · Entrepreneurial Essentials · 7 EC. The full module is about experiences customers participate in and share. This lab starts the website contribution; it does not complete the full digital-presence requirement.

Disruptive strategy: what customer expectation are you changing?
Value proposition: why would someone take part?
Technologies and processes: how will the useful action work?
Leadership and organisation: who builds, reviews and learns?
Business model: how does the experience create and capture value?

Your experience proposition

1. Get the first version online

20–30 minutes. Show your partner the live result before moving on.

Unzip the starter. Read README.md and open index.html in your browser.
Create a session plan. Find the headline in index.html, the design in styles.css, and the action in app.js.
Create your own GitHub repository and upload the starter files at its root. The root should contain index.html directly.
In Vercel, add a project and import this repository. Use the Other framework preset for this plain static site. Leave the build command empty and ensure the output serves the root containing index.html.
Deploy. Open the deployment URL in a fresh browser session. Confirm a classmate can open it.
Check which branch is configured for production; use main for the class example if that is your project's setting.

Official reference: Vercel build configuration.

2. Make one purposeful change

20–25 minutes. Clarify the headline for a specific audience and benefit. Keep the session-plan interaction working.

Clone your repository using your editor or GitHub Desktop. If using a terminal, Git must be installed and authenticated:

git clone YOUR_REPOSITORY_URL
cd YOUR_REPOSITORY_FOLDER
git switch -c improve-headline

Replace the placeholders with your own repository URL and folder. Run the commands in your project, not in an unrelated folder.

A useful request for your coding agent

Read this project and explain how it runs.
Change the headline for students preparing for a maths exam.
Keep the existing style and session-plan interaction.
Do not add dependencies or a backend.
Show the diff. Test desktop, mobile and keyboard use.
Report what you tested and what still needs review.

Read the actual edit. Try the page locally. Then record and share it:

git status
git diff
git add index.html
git commit -m "Clarify the offer"
git push -u origin improve-headline

If other files changed, inspect them individually before staging the intended files. Open a pull request on GitHub and follow the linked Vercel preview. The web-interface alternative is: create the branch → edit the file → commit → open a pull request.

3. Review with a partner

10–15 minutes. Give a task: “Create a maths session plan.” Stay quiet and watch. Your partner should review the actual preview for your change.

The headline names an audience and benefit. The preview opens in a fresh session or for the intended reviewer. A narrow screen has no horizontal scroll. Required selections prevent an empty submission. Creating a plan shows the expected result; Start again resets it. Keyboard navigation reaches and activates the controls. The page makes clear that the demo does not create a real booking. What did your partner do or say?What did you improve?

4. Release and practise recovery

15–20 minutes. Merge the reviewed change into the configured production branch. Wait for the deployment and test the production URL again. Record its commit.

In a practice branch, make a harmless text change and rehearse reverting it. Explain which known-good deployment you would restore if a live release failed. A hosting rollback does not repair Git history or undo database changes; the source must be corrected too.

Official references: Git revert · Vercel rollback.

When something goes wrong

Symptom	First useful check
404 or blank page	Root/output folder and the location of index.html.
No styles	CSS path, filename case and the browser network response.
Old version	Deployment status, URL, branch and commit.
Login screen	Preview protection and reviewer access.
Build error	First meaningful build-log error and the build command.

Give your agent the expected result, observed error and environment. Ask for one diagnosis and one small check before making a broad change.

Your evidence

Repository URLChange commit URLReviewed preview URLProduction URLHow would you undo a bad release?What will you test with a real target user next?

These are workshop evidence fields for the AI and deployment session. The full 0403EE module also requires digital presence, advertising, experimentation and active participation as described in the supplied brief.

Explain it without the agent

What is the difference between saving and committing?
Which tool records history, and which hosts the website?
Why do you test a preview before merging?
Why can't a private API key live in browser code?
What remains unchanged when you roll back a deployment?