sxsphinxstack

Skills / Build a web app

Build a web app

Build a small web app and put it live. One data type done completely: it works, persists, and handles bad input. Use when they say "build an app", "make a tool for X", or bring an idea that needs data.

Use this skill. Nothing to install.

Open in ChatGPT Open in Claude prefilled and ready; just hit send
for Gemini, Copilot, or Cursor: paste it, then say "build an app that …"

Don't have an agent?  ·  Raw file: skills/build-web-app.md

Watch the first two minutes

This is how a session goes, including the part where the app sounds too hard. Click through it.

(pastes the skill) build me an app
On it. The best first app is one you'll open twice. What do you already track, collect, or work out on paper or in your notes app?
I keep score for my family's game nights on paper. but real apps need servers and databases and I know none of that
This one doesn't. One data type, stored in your browser with localStorage, live at a URL on a free host. If you ever outgrow that, servers are a later skill. So: what is one entry? A game night has a date and then what?
date, which game, who won, and everyone's points
That's the whole data model, and you just did the hard part. We ship add and list first so it's live today, then edit, delete, and making it survive a reload.
can it also do achievements and player profiles and a season mode?
Those go in the README under "later", in writing, so they stop nagging you. Scope stays at one thing done completely. The payoff feature we do build: an all-time standings table, which is the reason anyone opens it twice.

Scripted example of a real session.

Think an app needs a server and a login?

The smallest real app needs neither. It needs one data type handled completely: you can add an entry, see it, change it, delete it, and it is still there after a reload. The browser's own localStorage covers persistence, a free host covers the URL, and bad input gets rejected with a message instead of breaking things. People ship apps like these with this skill:

Score keeper for game nights Manager for a real collection Sign-up sheet a group will use

What you end up with

A working app at a URL, and a repo that shows restraint. Here is the shape of a finished first app:

Example
game-nights/
├── index.html
├── app.js       the whole app, ~150 lines  1
└── README.md    what it is + "later" list  2

one entry:  { date, game, winner, points }
lives in:   localStorage, survives reload
live at:    username.github.io/game-nights

the loop, all working:
  add entry     validated, bad input refused
  list          designed empty state
  edit / delete both there
  standings     all-time table   3
  1. Small enough to read. You modeled the data out loud before any code, so you can point at the line that stores an entry and the line that sorts the standings.
  2. The README holds the cut features. Achievements, profiles, season mode: all written down under "later". Writing them down is how the version that exists got finished.
  3. One payoff feature. The derived view that makes the app worth opening: a streak, a total, a standings table. This skill picks it with you and builds it last.

Questions people actually ask

Is this free?

Yes. The skill is free, hosting on GitHub Pages is free at this scale, and localStorage costs nothing because it ships inside the browser. The agent you paste the skill into may have a free tier; Gemini's is the widest.

Do I need to know how to code?

No, but you will learn some by watching. The agent implements in visible steps and explains each one in a sentence, and your choices decide the names, the fields, and what the app shows first.

Will my data disappear?

localStorage lives in one browser on one device, and clearing that browser's site data clears it. For a first app that trade is fine, and the skill says so up front. An export button is a reasonable "later" item if the data starts to matter.

Will it work on my phone?

Yes, and the skill treats that as part of done. Session five is unhappy paths plus a phone pass, because a tracker you can't use in the moment doesn't get used.

What happens when I want accounts and shared data?

That is the honest boundary of this skill: everything lives in one browser. When a real second user shows up, backend-basics and auth-basics are the next skills, and the app you built here is the right starting point for them.

Where to go from here

Need an idea you'd actually open twice? Start from your real life:

Pantry inventory Reading list with a verdict Study group hub

App live? Build on it:

Turn it into a resume line Database basics Backend basics

Ideas to use it on

Curious? Read the full skill — the exact instructions your agent gets 
---
name: build-web-app
category: web
description: Build a small web app and put it live. One data type done completely: it works, persists, and handles bad input. Use when they say "build an app", "make a tool for X", or bring an idea that needs data.
---

# build-web-app

Build a small real app with someone. Small means one data
type or one calculation, done completely: it works, it persists, it
handles bad input, and it is live at a URL.

## Ground rules

- Build it around their real life. The best first app is one they will
  open twice: a tracker for something they already track, a manager
  for a collection they actually keep, a calculator for a decision
  they actually face, a sign-up sheet a real group will use. If they
  have no idea, offer three from https://sphinxstack.com/ideas/ and
  let them pick.
- Scope is one thing done completely. Add, see, change, delete;
  survives a reload (localStorage is fine); empty state designed; bad
  input rejected with a message. Control scope by writing the cut
  features into the README as "later".
- Boring stack: HTML/CSS/JS, no build step, unless they already know a
  framework. Deploy on GitHub Pages (ship-on-github skill if present)
  as soon as it does anything.
- Work with them, not instead of them. Model the data out loud
  together before code ("what is one entry? what are its fields?").
  Implement in visible steps; explain each in a sentence. Their
  choices decide names, fields, and what the app shows first.

## Session shape

1. Pick the thing and model it: one entry, its fields, what the app
   shows when there are none.
2. Walking skeleton, deployed: add + list, live URL.
3. Persistence + the rest of the loop: edit, delete, reload-proof.
4. The payoff feature: the derived number or view that makes it worth
   opening — streak, total, filter, export.
5. Unhappy paths + phone pass + README in their words.

## Done

- Live URL; data survives a reload
- Complete loop on one data type; designed empty state; validated
  input
- Works on a phone
- README they wrote describing what it is and what "later" holds

Then: build-resume turns this into a resume line with a live link.