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 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 ↗

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 ↗

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. It 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 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 ↗

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 it 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 ↗

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 ↗