Understand how your app works.

An informal term for building software by describing what you want to an AI coding tool, trying the result and asking for changes. People use it loosely; it does not tell you how carefully the code has been reviewed or tested.

In practice: You describe a booking app, then ask the agent to add sign-up and a calendar. Seeing those screens work is a starting point for checking what happens with real users and data.

An AI assistant that can work on a software project using tools: reading and changing files, running commands and checking results within the access you give it. You still need to define the goal and assess its work.

In practice: You ask the agent to add session booking, explain the booking rules and then inspect its report and try the resulting app. A confident completion message alone does not prove the feature works.

Everything an AI model can take into account at one time: your messages, its replies, the files it has read, command output and the project instructions. The context window has a fixed size. As a long conversation fills it, older and unrelated material competes with the current task and the agent’s work tends to get worse.

In practice: After an hour spent fixing a login bug, the conversation still holds every file and failed attempt from that work. Starting a fresh conversation for the next feature gives the agent only what that feature needs.

A command you type into a coding agent’s message box, starting with a forward slash, to control the tool itself instead of asking the model to do work. Slash commands start new conversations, switch models, reconnect services and similar. Each tool has its own list, and the lists change between versions.

In practice: Typing /clear starts a new conversation with an empty context window. Typing / on its own shows the commands your version supports.

Saved guidance that tells a coding agent how to work in a project: who it is working with, how to work, what it must never do and where things are kept. The guidance lives in a file at the top, or root, of the project, which the agent reads at the start of every conversation. It plays a similar role to telling a chat tool “act like…”, except that it is saved and read every time. It is strong guidance and not a lock: tool permissions are separate, and prose instructions do not enforce security boundaries.

In practice: An AGENTS.md file asks the agent to work on one stage at a time, never to publish without being asked, and to report which checks actually passed. A one-line CLAUDE.md can point Claude Code at the same file.

Reusable instructions, sometimes with supporting files or tools, for a particular kind of task. Skills can guide an agent’s workflow but do not guarantee that its result is correct.

In practice: A testing skill guides the agent to check meaningful behaviour and retain evidence of failures. You still assess whether the checks cover the requirement.

Our name for a written procedure for one kind of work, kept in the project and listed in the root file, so that a coding agent follows the same steps every time without being told them again. The tools themselves have no word for it.

In practice: After asking for the same end-of-part routine five times, you have the agent write it down as docs/handbooks/checkpoint.md. From then on, “Checkpoint: Save the list” runs the whole routine.

An installable package that adds capabilities to an agent application. Depending on the product, it can include skills, connections to services and other configuration.

In practice: A Figma plugin can bundle design-task instructions with the connection that lets an agent use Figma tools.

A group of related tasks organised around a useful outcome. Teams use epics to keep larger pieces of work manageable and track what remains. Coding-agent tools usually call the same thing a plan or a spec.

In practice: A session-booking epic might include showing available times, reserving a slot and sending a confirmation. These tasks contribute to one outcome: letting a client book a session.

The main folder that contains a project’s files and subfolders. A path written relative to the project starts from this folder.

In practice: In a reading-list project, reading-list is the project root. docs/project-brief.md means the project-brief.md file inside its docs folder.

A plain-text format that uses simple characters for headings, links and lists. Files usually end in .md and can be read as text or displayed with formatting.

In practice: Your project brief is a Markdown file. You can read its scope and checklists without understanding application code.

A version control tool that records changes to project files so you can inspect history and recover earlier work.

In practice: You save a checkpoint before changing a booking feature.

An online service that hosts Git repositories and provides collaboration tools. A local commit is only sent there when you push it.

In practice: Your private GitHub repository holds a copy of the project history from your computer.

A project and its version history, stored locally or on a hosting service such as GitHub.

In practice: Your RepGarden repository contains documents, app files and the history of changes you saved.

A recorded checkpoint of selected project changes in Git, with a message describing them. You can return to it if later work goes wrong. It is local until sent to a remote.

In practice: A commit called Prepare RepGarden workspace records your initial project documents.

Sending local Git commits to a remote repository. This does not automatically deploy your app or include uncommitted changes.

In practice: After checking a change, you push its commit to your private GitHub repository.

A free editor from Microsoft for working with project files. It includes a folder browser, Markdown preview and a terminal, and extensions can add tools for different programming languages.

In practice: You open a project folder in VS Code and preview its README as a formatted document, with headings, links and lists.

VS Code documentation ↗

An application that brings software-development tools together, usually a code editor, tools to run or build a project, and a debugger for investigating problems. Editors such as VS Code can provide many of these capabilities through built-in features and extensions.

In practice: A developer changes a booking form, runs the app and pauses it at a particular point to investigate a bug, all in the same application.

A runtime that runs JavaScript outside the browser. Web projects often use it to run development tools, even when the finished app runs entirely in the browser.

In practice: Node runs Vite on your computer while you develop the reading-list app.

A development tool that runs your web app locally while you work and builds the files you publish to a web host.

In practice: Vite serves your reading list on localhost; its build command creates a dist folder for Netlify.

A library for building user interfaces from reusable components: pieces such as a button, a sign-up form or a whole screen. React Native applies the component approach to native apps.

In practice: A reusable appointment card can appear on several screens while keeping the same behaviour and appearance.

React documentation ↗

A framework and set of tools for building apps with React Native. Its ecosystem also includes services for building, submitting and updating applications.

In practice: An Expo app can share much of its code across iOS and Android, while still needing testing on each platform and the relevant store submission work.

Expo documentation ↗

A tool that controls a real browser from a script: clicking, typing, reloading and checking what is on screen. It is used for automated tests of whole user journeys, and its visual runner lists each test and replays every step.

In practice: A Playwright test removes a book, chooses Undo and checks that the book returns with its note.

Playwright documentation ↗

An AI development platform for creating and changing web applications through natural-language instructions. The app still has code, data and configuration underneath the conversation.

In practice: A customer dashboard made in Lovable needs the same clear rules about who can see each customer’s records as any other app.

Lovable documentation ↗

Software provided as an ongoing online service. People use the product while its provider operates and maintains the underlying systems. It is often sold by subscription and can include web and mobile apps.

In practice: A trainer pays to use a service that manages clients and workouts, while the provider runs the shared backend and maintains the apps.

The part of the app the user sees and interacts with: screens, forms, navigation and the behaviour around them.

In practice: Hiding an admin button in the frontend makes the interface cleaner. Hiding the button does not stop someone calling the underlying API, so the backend still needs permission checks.

The part of the system that runs trusted operations away from the user’s device. It commonly handles business rules, data access, provider integrations and background work.

In practice: Your backend decides whether a payment really grants access. It should not trust a browser simply saying “I paid”. Serverless and edge functions are backend code too.

An application programming interface: a defined way for one piece of software to ask another to do something or return information.

In practice: When a customer saves a booking, the frontend may call an API. That API needs to check the request, the user’s permissions and whether the slot is still available.

A system for storing and retrieving structured information. Its design and rules help keep related records consistent as people use the app.

In practice: Customers and bookings might live in separate tables, connected by a customer ID. Deleting a customer then needs a deliberate rule for what happens to their bookings.

A server is a program that waits for requests and sends responses. A client, such as a web browser, makes those requests. Some servers only deliver files; others also run application code and store shared data.

In practice: The reading-list app involves two servers. The host only delivers the app’s files. A stand-in server, running in the browser, answers the app’s requests to add, change and remove books.

The two halves of every exchange between a client and a server. A request says what the client wants: a method, such as GET to fetch or POST to create, and an address saying what the action is about. A response says what happened, and usually carries data back.

In practice: Saving a new book sends the request POST /api/books. The server stores the book and responds with the status code 201 and the book as it was stored. Your browser’s developer tools list each exchange in the Network tab.

The three-digit number at the start of a server’s response, saying how the request went. Codes beginning with 2 mean it worked, codes beginning with 4 mean the server refused the request, and codes beginning with 5 mean the server itself failed.

In practice: 201 means a new book was created. 400 means the server refused a book, for example because it had no title. 500 means something went wrong on the server, so the app should say so and leave the list as it was.

A program that answers an app’s requests as the real server would, so the client can be built and tested without one. The stand-in server can run inside the browser. It keeps to the same API, but it is not a shared computer that every user’s browser can reach, so it cannot share information between people or devices.

In practice: The reading-list starter includes a stand-in server that runs in your browser. Your agent builds the client against it, and a friend who opens your published link gets their own separate, empty list.

The information an app holds in memory while it is running, such as the current list, the text in a search box or whether a form is open. State is lost when the page reloads unless the app saves it somewhere lasting.

In practice: A list kept only in memory disappears on refresh. Once it is saved somewhere lasting, such as a database or localStorage, the app can load it again.

Keeping data after the current interaction or session ends, so it can be retrieved later. Different storage methods offer different durability and sharing guarantees.

In practice: A saved reading status remains after you refresh the page. Browser storage can provide this without an account or server.

Browser storage that keeps small amounts of data between visits to the same website origin. It is separate for each browser profile and does not sync across devices; clearing site data removes it.

In practice: Your reading list survives a refresh, but opening its Netlify address gives you a separate list from the one saved on localhost.

Giving up on a request that has had no answer after a set time, so that the app can say so and offer to try again instead of waiting for ever.

In practice: The server takes ten seconds to answer. After a few seconds the app stops waiting, shows a message and a retry button, and says honestly that it does not know whether the change was made.

The part of a web address that identifies a site: the scheme, the hostname and the port, such as http://127.0.0.1:5173. A browser keeps each origin’s stored data separate.

In practice: Your reading list at a localhost address and the same app published on Netlify have different origins, so each keeps its own list.

A repeatable check run by software that compares observed behaviour with an expected result. Passing tests provide evidence for the cases they cover, rather than a guarantee that the whole app is correct.

In practice: A test edits a book, reloads the page and checks that the new title remains.

A test that fails once and passes when run again with nothing changed, usually because of timing in a real browser. Run it again; treat a failure that keeps coming back as real.

In practice: A browser test fails while your computer is busy with something else, then passes three times in a row. It was flaky. One that fails every time is telling you something.

A plain sketch of a screen that shows what is on it and roughly where, with no colours or styling. It settles what a screen needs before anyone decides how the screen looks.

In practice: Three labelled boxes on paper: a heading, an “Add a book” button and a space for the list. That is enough for an agent to build the page frame from.

A number from 1 to 21 that says how much a text colour stands out from its background. Ordinary text needs at least 4.5 to be comfortably readable, and large text at least 3.

In practice: Pale green text on cream measures 2.6, which is too low, so you choose a darker green that measures 4.6. Asking an agent for the number stops it simply telling you the colour looks fine.

The smallest version of an app that does its main job well enough for real people to use and pay for. Launching an MVP first means you learn what your users actually want before most of the budget is spent.

In practice: A personal trainer’s app that launches with booking and paying for sessions, and adds workout plans once clients are using it.

The steps someone takes in an app to get one thing done, such as booking a session: what they tap, and what the app shows them each time. It is also called a user journey. Writing these out before anything is built means everyone agrees on exactly how the app should behave, and each one can be tested.

In practice: Adding a book: choose Add a book, enter a title, choose Add to library, and the book appears in the list. If the title is empty, the form stays open and says why.

A collaborative design tool for creating and discussing interface designs and interactive prototypes. A prototype helps you explore an experience before implementing the working app.

In practice: A trainer reviews a proposed booking flow in Figma and suggests changes before you build the booking system.

A single document inside a project recording how an app looks and how it speaks: the colours and their jobs, the typefaces and sizes, the spacing, the corners, the shadows, the tone and the actual wording it shows. The pack is written before the screens are built, and the design tokens carry the same values in the form the code reads. A larger product’s pack can also hold its logo and imagery, so that every app and website made for it looks like the same product.

In practice: Your agent takes the empty-state message and the accent colour from the brand pack rather than inventing them, and a style-guide page displays every value in one place so you can review them.

The shared rules and building blocks every screen of a product is made from: colours, typefaces, spacing, and reusable pieces such as buttons and forms. It keeps every screen looking and behaving consistently, and makes new screens quicker to build.

In practice: A button in the design system has one look for its main action and one for a secondary action, so every page uses the same two instead of inventing new ones.

A named value an interface is built from, such as an accent colour or a step in a spacing scale. The name says what the value is for rather than what it is, so the token can be applied correctly and changed everywhere at once.

In practice: A button uses the accent colour by name instead of a colour code. Changing that one value restyles every button in the app, and nothing else.

A drawing described in text: the lines, curves and shapes, their positions and their colours, which the browser turns into a picture as the page loads. It stays sharp at any size and can take its colours from design tokens, unlike a photograph or a generated image.

In practice: A coding agent can draw an app mascot as an SVG, then change it when you ask for something rounder or friendlier, because the drawing is text it can edit.

A backend platform built around a Postgres database, with services including authentication, file storage, APIs, realtime features and server-side functions.

In practice: One project might use Supabase to store customer records, sign people in and hold uploaded files. Those pieces still need the right access rules and configuration.

Supabase documentation ↗

The process of checking who someone is. Signing in with a password, email link or identity provider gives the app a way to recognise that user.

In practice: A successful login establishes an identity. It does not automatically mean that user can view another customer’s orders.

Supabase Auth documentation ↗

The rules for what an identity is allowed to read, create, change or delete. Authorisation answers “are you allowed to do this?” after authentication answers “who are you?”.

In practice: Two people can both be signed in, while each can only read their own invoices. Those rules must be enforced where the data or action is controlled.

Authentication and authorisation in Supabase ↗

A Postgres feature that uses policies to control which rows a database role may read or change. In Supabase, policies can use the signed-in user’s identity to protect their records.

In practice: A customer should only read rows belonging to them. After enabling RLS, check the grants (database access privileges), the policies and what different test users can read, add, edit or delete. Privileged server credentials can bypass RLS and must stay private.

Supabase Row Level Security documentation ↗

Permission for a database role to run an operation, such as reading or inserting, on a table, view or function at all. Postgres checks grants first and only then applies RLS policies to decide which rows are involved.

In practice: If the role that signed-in users run as has no insert grant on a table, every insert fails with a “permission denied” error, whatever the policies say. A table with grants and no RLS is open to every role that holds them.

Supabase: securing your API ↗

The Supabase API key that ships inside a website or mobile app. It identifies the project, not a person, and is public by design. It begins sb_publishable_ and replaces the older anon key.

In practice: Anyone can read this key from your site’s JavaScript. The key is safe only because the database’s grants and RLS policies decide what a request carrying it may do.

Supabase API keys documentation ↗

The Supabase API key for servers. Requests made with it run as a database role that bypasses RLS policies, so the role can read and change every row it has been granted access to. The key begins sb_secret_ and replaces the older service_role key.

In practice: A payment webhook uses the secret key to mark an account as paid. The key lives in the server’s secret store and never in browser code, a mobile app or a public repository.

Supabase API keys documentation ↗

A signed piece of JSON that names a user and expires after a set time. The signature lets a service check that the token is genuine, so a user can read their own token and cannot alter it.

In practice: After sign-in, Supabase Auth gives the app an access token in this format. The database reads the user ID from the token when it evaluates RLS policies.

Supabase JWT documentation ↗

A small TypeScript function that runs on Supabase’s servers instead of in the browser. It is where a Supabase app puts work that needs a secret or a decision the user must not influence.

In practice: An Edge Function receives a payment provider’s webhook, verifies its signature and then records the payment. The function has to check who is calling it, because the platform’s default check does not do that on its own.

Supabase Edge Functions documentation ↗

The compact set of files generated from a project’s source for release. The source is arranged for editing; the build is arranged for browsers and is regenerated whenever the source changes.

In practice: Vite writes the reading list’s production build to a folder called dist, which is what gets uploaded to a host.

A small server that runs on your own computer while you work on an app. It delivers the app to your browser at a localhost address and refreshes the page when files change. Only your computer can reach it.

In practice: Your agent starts the development server and gives you an address such as http://127.0.0.1:5173. Closing the agent stops the server, and the page stops loading until the server is started again.

Panels built into a browser for inspecting a page. The Network tab lists every request the page makes, with its method, its status code and what came back.

In practice: With the Network tab open, adding a book shows a new row: a POST request answered with 201, and the book as the server stored it.

A service that stores a folder of files and delivers them unchanged to visitors’ browsers. It does not run application code or keep user data, which makes it simple and inexpensive for apps that run entirely in the browser.

In practice: Uploading the dist folder to Netlify publishes the reading list. Each visitor’s books stay in their own browser.

Making a particular version of your software available in an environment where it runs. For a website, this often means publishing a build to a hosting provider.

In practice: A deployment can finish successfully while a login redirect or database setting is wrong. Check the important user journeys on the deployed version, not only on your laptop.

Production is the environment your real users rely on. Staging is a separate environment used to check changes before those users receive them.

In practice: A staging checkout should use test payments and appropriate test data. A different website URL alone does not create separation if the staging site still writes to the production database.

Continuous integration runs agreed checks as code changes are combined. Continuous delivery keeps changes ready to release; continuous deployment goes further by releasing automatically when the required checks pass.

In practice: A change can run type checks, tests and a build before a deliberate production release. A green result means those checks passed, not that every possible problem was tested.

A message one system sends to another when an event happens, usually as an HTTP request to an endpoint you configure.

In practice: A payment provider can tell your backend that a subscription changed. Your app needs to verify the message and handle repeat deliveries without granting access twice.

Environment variables are configuration values supplied to a running app or its build. Some are public settings; others contain secrets such as private API credentials.

In practice: A frontend’s public project identifier is different from a privileged server key. Putting a value in an environment variable does not keep it secret if the build includes it in browser code.

The ability to understand what a running system is doing from the signals it produces, such as logs, metrics and traces. Useful signals help connect a user’s problem to what happened inside the app.

In practice: When a customer’s export fails, you want to know which request failed, at which step and why, without recording their private document contents.

OpenTelemetry observability primer ↗

A repeatable sequence of steps that uses AI to create content and moves it through checks, review and delivery. Generation is one step; the workflow also determines what can be published and what happens when a step fails.

In practice: Generate an exercise description, have a qualified trainer review it, then publish the approved version to the exercise library. Rejected content stays out of the app.

An open protocol that gives AI applications a common way to connect to tools, data and other systems. The available capabilities depend on the server and the access you allow.

In practice: An assistant could read a connected documentation source through MCP. Giving it a tool that changes a database is a separate, more consequential permission.

Model Context Protocol introduction ↗

A platform and SDKs for coordinating background jobs and multi-step workflows. Functions can respond to events or schedules, with steps that record progress and retry failed work.

In practice: After an upload, a workflow could extract text, ask an AI model to summarise it and save the result. You still need to validate the output and make repeat attempts safe.

Inngest Functions documentation ↗