Build a Small App You Will Use

Somewhere in your day is a small irritation you have learned to tolerate: rebuilding a checklist, rearranging a reading queue, or working out whether three tasks fit before lunch. Pick one you actually care about. By the end, you will have an app you can open again and use for that job.

An app responds to your input and performs an action that produces a useful output; a mockup only shows what that experience might look like. A beautiful screen with a button that does nothing is still a sketch.

1. Structure: give your app one job

Finish this sentence: “When I ___, I want to ___, so I can ___.” Keep the first version useful to you alone.

If you need a starting point, choose or adapt one of these:

• Lab preparation: turn your own equipment list into a checklist for a routine session, with packed items and remaining items clearly separated.
• Research reading: enter paper titles and your own priority ratings, then arrange a reading queue for your next free hour.
• Everyday or work planning: enter tasks and estimated minutes, then see the total and whether it fits your available time.

These are invitations, not assigned projects. Your own recurring task is welcome.

Name three things: input (what you supply), action (what the app does), and output (what you can use). For the planner, those might be task durations, adding them, and a total with minutes remaining. Write one example whose answer you already understand. Use invented, public, or approved information when asking a model for help.

2. Understand: borrow before you build

Try the nearest existing solution: perhaps your current spreadsheet, a checklist application, or a small example you are permitted to adapt. Complete your chosen task with it once. What does it already get right? Where exactly do you still do awkward manual work?

Ask your assistant: “Explain how this solution gets from input to output. Which parts could I reuse for my task, and what would actually need to change?” If you share code, ask it to point out where inputs are read, the action happens, and the result appears. You do not need to understand every symbol; you should understand the journey.

Reuse a suitable template, existing code with permission, or the interaction that already makes sense to you. If an existing tool solves the whole problem, configuring it may be your finished app. Otherwise, build only the missing convenience. “My version totals these durations without rearranging a spreadsheet” is a better reason than “I should build something impressive.”

3. Choose LLMs, Agents, skills, tools

Use a coding assistant you can access under suitable terms. OpenCode is one possible workbench; it supports different model providers. Choose a model available to you that can explain and edit a small browser app. One assistant is enough; add a skill or tool only for a specific need.

A local browser app is an easy starting route: one index.html file containing HTML for structure, CSS for appearance, and JavaScript for behaviour. Simple list and calculation tasks need no backend or app accounts. Start without saved history unless remembering entries is essential to your task.

Running the app locally does not mean model processing is local: your coding assistant may send prompts and code to its configured provider.

Create a project folder somewhere you can find again. If your assistant can edit files, work in that folder. If it only returns text, request the complete file contents and save them as plain text named index.html, not index.html.txt.

4. Build: make the useful part work first

Replace the brackets and copy this project brief:

Help me build a small personal app for [my recurring task].
Input: [what I enter]. Action: [what it does]. Output: [what I use].
Example: [an input and the result I expect].
Existing solution I tried: [tool or example].
Reuse what works: [parts]. Improve this friction: [one problem].

First explain the input-to-output flow and the smallest useful version.
Then build incrementally, starting with the main interaction.
For a new browser version, use one self-contained index.html with
embedded CSS and JavaScript, no external services or dependencies.
Use labelled inputs, keyboard-operable controls, and readable results.
Handle missing or invalid input clearly. Say whether entries survive
refreshing; do not imply they are saved if they are not.
Create the actual file if you can; otherwise give its complete contents.
Tell me exactly which file to open and how to use it.

First, get one interaction working. Enter something, trigger the action, and see the result. Leave decoration until that loop works. Ask for a short explanation of the relevant code if the result surprises you.

Next, open the artifact. Find index.html in your project folder and open it with your browser, using your operating system’s file-opening options if necessary. You should see the app, not source code. After an edit, save the file and refresh the browser. The chat answer is not the deliverable; this working file is.

Then, use it for your task. Try two ordinary inputs and one relevant edge case, such as an empty list or a negative duration. Compare the result with what you expected. Try the controls with the keyboard too. If something fails, describe the input, what happened, and what should happen; request that focused correction.

Finally, make one worthwhile refinement. Use the app during the activity it was meant to help. Notice one actual annoyance. Perhaps your reading queue loses context because titles are truncated. Ask for wrapping titles, then repeat that same activity. Keep the change if it makes the task easier. Let experience choose the refinement.

What to keep, and what comes next

Keep the working file, your brief, and a short note on how to open it and whether entries persist. Put the folder where you will look for it next time the task arises.

When someone else needs to use the app with you, continue to T06-L02, A tool from a prompt (opens in a new tab), for the shared-app responsibilities: access, storage, and exports.

Source notes

Checked 9 September 2026:

• OpenCode introduction and usage (opens in a new tab): coding workbench and iterative changes.
• OpenCode providers (opens in a new tab): provider choice, including local-model options.
• MDN: HTML—Creating the content (opens in a new tab): HTML structure and opening a saved HTML file in a browser.