Contact

App development glossary

116 terms you will meet when you build an app, explained for the person paying for it: what each one means, why it changes the cost or the launch, and where it came up in a product we built.

Updated October 2026

Product and scope

  • Acceptance criteriaThe checks that decide whether a piece of work is done, agreed before the work starts so nobody argues about it afterwards.
  • Change requestA formal ask to alter agreed work, with its cost and its effect on the timeline written down before anyone builds it.
  • Clickable prototypeScreens you can tap through in a browser, running on made-up data, so people can try the product before anything real is built behind it.
  • Design systemOne shared set of colours, type, spacing and components that every screen draws from, so a product looks and behaves like one thing.
  • Discovery phasePaid research before a build, in which the team maps what the business really needs and returns a scope and architecture it can price against.
  • LocalisationAdapting a product for other languages, scripts and regions, from translated text to names, fonts and formats that render correctly.
  • MVPThe smallest version of your product that real users can put to work, built to test whether the idea holds before you pay for everything else.
  • PRDWritten before the build starts, it sets out what the product must do, for whom and under which rules, so both sides can check the work against it.
  • Product analyticsCounting what people actually do in your product, so decisions rest on behaviour rather than guesses or the loudest feedback.
  • Scope creepWork that slips into a project without anyone agreeing to it, one reasonable-sounding request at a time.
  • SEOMaking your pages easy for search engines to read, understand and rank, so people find the product without paid ads.
  • Unit economicsWhat one unit of your business, such as a trip, a scan or a booking, costs you to deliver, set against what it earns.

Architecture

  • Admin panelThe private web console your own team uses to run the product: approving people, fixing records, handling money and watching what happens.
  • APIThe set of doors one piece of software opens for another: defined requests it accepts and the answers it promises to send back.
  • Background job queueA waiting list of work that runs outside the user's request, so slow or risky jobs such as migrations and bulk email don't hold up the screen.
  • CacheKeeping a recent answer close at hand so the system doesn't pay again, in time or money, to work it out.
  • CDNCopies of your images, videos and files kept on servers around the world, close to your users, so they load quickly wherever people are.
  • CMSSoftware that lets someone who isn't a developer add and edit a website's content, such as pages, posts and portfolio items, without touching code.
  • Email deliverabilityWhether the email your product sends lands in inboxes rather than spam, which depends on signed mail, sending reputation and how fast volume grows.
  • IdempotencyDesigning an action so that doing it twice has the same effect as doing it once, which protects money and messages from retries.
  • Monolith vs microservicesWhether a backend is one deployable application or many small services talking over the network, and when it makes sense to split.
  • Multi-tenant architectureMany customer organisations sharing one running copy of a SaaS product, each strictly walled off from the others' data.
  • Scheduled jobWork a system runs by itself at set times, such as nightly roll-ups or hourly reminders, rather than in response to a user.
  • Static siteReady-made HTML, CSS and JavaScript files served as they are, with no database or server code behind them, which keeps a website cheap, fast and hard to break.
  • Third-party APIMaps, SMS, payments, AI, tax filing: services run by other companies that your product calls over the internet and usually pays for per call.
  • WebhookInstead of your server asking another system over and over whether something happened, the other system calls you the moment it does, for example when a payment succeeds.
  • WebSocketChat, live maps and online status all run on this: a connection between app and server that stays open, so updates arrive the instant they happen.

Mobile apps

  • App permissionsPhotos, location, camera: every piece of access an app asks for, which the stores expect to be justified, kept minimal and explained to the user.
  • App signing and bundle identifiersThe cryptographic signature and permanent ID that prove each app update comes from you, and that the stores use to tie every release together.
  • App store reviewThe check Apple and Google run on every app release against their policies, which can delay or block a launch over permissions, payments or missing details.
  • Beta testingGiving a pre-release build to a limited group of testers, through TestFlight on iPhone or a closed track on Google Play, before the public sees it.
  • In-app purchaseBuying digital features or subscriptions inside a mobile app through Apple's or Google's own billing, which the stores generally require and take a cut of.
  • Live trackingShowing a moving person or vehicle on a map in near real time, as delivery and ride apps do, with an ETA that updates along the way.
  • Offline supportHow an app behaves when the network drops: whether work in progress is kept, queued and sent later, or simply lost.
  • Push notificationSent by your server and shown on the lock screen, a push notification reaches someone even when the app is closed, bringing them back at the right moment.
  • React NativeMeta's open-source framework for writing iOS and Android apps from one JavaScript and TypeScript codebase, with native code added where a feature needs it.

Data

  • BackupYour insurance copy of the data: kept somewhere a mistake, attack or outage in the main system can't reach, and proven by actually restoring from it.
  • Data deletionRemoving a user's data when they ask or when it is no longer needed, in a way that is final, logged and safe from accidents.
  • Data migrationMoving data from one place or shape to another, such as between clouds, out of a legacy system or into a new structure, without losing or corrupting any of it.
  • Data modelThe map of what your system records, which things exist, what each holds and how they connect, worked out before any screen is designed.
  • Data residencyWhere in the world your data is physically stored and processed, which can be set by law, by customer contracts or by plain trust.
  • DatabaseWhere your product keeps its records, such as users, bookings and payments, along with the rules for how they are stored, found and changed.
  • Database indexLike the index at the back of a book, it lets the database jump straight to matching records instead of reading every one, and it can forbid duplicates outright.
  • Geospatial querySearching your own database by location, such as 'nearest eligible drivers within 3 km', from stored coordinates rather than through a paid maps service.
  • Object storageCloud storage for files such as photos, videos and documents, kept in buckets and reached by URL rather than stored in your database.
  • UTC and time zonesStoring every time against one universal clock and converting only for display, so bookings, reminders and invoices land on the right day everywhere.

Security and privacy

  • 2FASigning in with a second proof beyond the password, such as a code from an authenticator app or a passkey, so a leaked password alone isn't enough.
  • Audit logWho did what, to which record and when, written down so it can't be quietly edited afterwards.
  • CSPYour site's instructions to the browser about which scripts, styles and frames it may load, so injected code has nowhere to run.
  • DPDP ActIndia's Digital Personal Data Protection Act, 2023, which sets out how businesses may collect and use people's personal data and what they owe those people.
  • Encryption at restScrambling stored data, such as other services' passwords, API keys and files, so that someone who copies the database or disk can't read it.
  • JWTHanded out at sign-in and sent back with every request, this signed token tells the server who is asking without a session lookup each time.
  • Least privilegeGiving every person, service and integration only the access its job needs and nothing more, so a single mistake or breach stays small.
  • OAuthBehind every 'Sign in with Google' button: a standard that lets people allow one app to act on their account elsewhere without handing over a password.
  • OTPA short code delivered by SMS and valid once, briefly, that signs people in, confirms phone numbers and, in delivery apps, proves a parcel changed hands.
  • Rate limitingCapping how often someone can call an action in a given time, which blocks abuse, guessing attacks and runaway costs.
  • RBACGranting permissions to roles, such as admin, editor or finance, rather than to individuals, so each person sees and does only what their job needs.
  • Request signingAttaching a cryptographic signature to a message with a shared secret, so the receiver can prove it is genuine and wasn't altered on the way.
  • Secrets managementHow API keys, passwords and signing keys are stored, shared, rotated and kept out of code, logs and the apps people install.
  • Secure share linkAccess without an account: an unguessable link that opens one report, file or tracking page for one person, optionally behind a passcode or an expiry.
  • Server-side validationChecking every price, permission and rule on the server, never trusting what a phone or browser sends, because anyone can alter those requests.

Payments and money

  • Cash on deliveryLetting customers pay in cash at handover, which means the platform's share sits in drivers' or providers' pockets until it is settled.
  • Double-entry bookkeepingRecording every money movement as matching debits and credits that must balance, so an error shows up instead of hiding in one account.
  • FreemiumOffering a useful free plan alongside paid ones, so people can try the product properly before deciding to pay.
  • GST e-invoicingIssuing tax invoices under India's GST rules, with the right tax split for each sale and, where required, registering them with the government system for an IRN and QR code.
  • Invoice number seriesEvery invoice takes its number from a sequence that tax rules expect to be unique and in order, usually restarting each financial year.
  • LedgerThe append-only record of every money movement in your product, from which all balances, earnings and revenue are calculated.
  • Minor unitsStoring amounts as whole numbers of the smallest unit, such as paise, cents or fils, instead of decimals, so sums never drift by a fraction.
  • Multi-currency pricingSelling in more than one currency, with a price set for each rather than converted on the fly, and the books kept separately per currency.
  • Payment gatewayRazorpay, Stripe and their peers: the service that takes card, UPI and wallet payments for you and tells your system whether each one succeeded.
  • PayoutSending money a platform owes its providers, such as drivers, trainers or sellers, from their earned balance to their bank account.
  • ReconciliationChecking that your own records of money agree with each other and with what the payment provider actually moved, and flagging any difference.
  • RefundReturning money to a customer, in full or in part, which in a marketplace also means undoing the provider's earnings and the platform's commission.
  • Subscription billingCharging customers automatically on a recurring cycle, and handling everything that follows: renewals, failed payments, plan changes, refunds and invoices.
  • Tally exportSending your product's invoices, receipts and journal entries to Tally, the accounting software most Indian businesses already use, instead of rebuilding accounts.
  • WalletMoney the platform holds for someone inside the app, credited by earnings or top-ups and debited by fees and withdrawals, and backed by a ledger rather than a bank account.

AI

  • AI agentGiven a goal, tools and rules, this kind of AI takes several steps on its own, such as looking things up, editing or handing over, rather than replying once.
  • AI guardrailsRules wrapped around an AI feature, covering what it may discuss, what it may claim and when it must stop, enforced by settings and code rather than hope.
  • BYOKLetting each customer connect their own AI provider account, so model usage is billed to them directly instead of being bundled into your prices.
  • HallucinationWhen an AI states something false with complete confidence, such as an invented fact, number, feature or source, because it produces plausible text rather than checked truth.
  • Human in the loopBuilding AI features so a person reviews, approves or takes over at the points where a mistake would matter.
  • LLMAn AI model trained on huge amounts of text that can write, summarise, classify and answer questions, offered by providers such as OpenAI, Anthropic and Google.
  • MCPAn open standard that lets AI assistants such as Claude use a product's tools and data through one defined interface.
  • Model evaluationTesting AI models on examples like your real inputs, with answers checked by hand, before choosing one, rather than trusting benchmarks or price alone.
  • Model routingSending each AI request to the model best suited to it, such as a cheap, fast one for simple turns and a stronger one for hard cases.
  • Prompt injectionText hidden in content an AI reads, such as a web page, document or photo, that tries to override its instructions and make it do something else.
  • RAGHaving an AI answer from documents you choose, by finding the relevant passages first and handing them to the model with the question.
  • Structured outputMaking an AI reply in a fixed machine-readable format, such as JSON with named fields, so code can check and use the answer instead of parsing prose.
  • TokensThe chunks of text, and images converted into similar units, that AI providers count and bill for, in both what you send and what comes back.
  • Vision modelAI that looks at a photo and reports what it sees, such as an object, printed text or a condition, as a description or as structured fields.

Delivery and quality

  • Automated testingCode that checks your product's behaviour every time something changes, so a fix in one place doesn't quietly break another.
  • Code reviewAnother engineer reading changes before they ship, or an outside party reviewing a whole codebase, to catch bugs, risks and shortcuts.
  • Error monitoringCrashes and errors from your live product, captured with enough detail to fix them and reported to the team before users have to complain.
  • Feature flagTurning a feature on or off from configuration, without a new release, so finished code can wait, be tried on a few users or be switched back safely.
  • HandoverTransferring a product from one team to another, covering code, accounts, keys, documents and the state of every open item, so the new team can carry on without guessing.
  • Launch readinessEvidence, not a feeling, that a product is ready to go live: which flows have been exercised, what is still open, and what will be watched on day one.
  • Open-source licenceThe legal terms attached to free software components, which decide whether you may use, change and sell them, and what you must credit or share in return.
  • QA passSomeone deliberately using and abusing the product, screen by screen, the way real users and store reviewers will, to find what automated tests missed.
  • Release managementControlling exactly what goes out in each release, which code, settings and version number, with checks that prove the build is the one you meant to ship.
  • SandboxPractice mode for payments and APIs: providers such as Razorpay let you run realistic checkouts, webhooks and refunds with no real money moving.
  • SLAResponse times, uptime or turnaround, promised in writing and measured, so both sides can tell whether the service was delivered as agreed.
  • Software maintenanceAfter launch, the steady work that keeps a live product safe and running: dependency upgrades, security fixes, OS and store changes, and repairs when outside services change.
  • Staging environmentProduction's rehearsal room: a private copy of your product with the same code and settings, where releases are checked before real users see them.
  • Technical debtThe future cost of shortcuts taken now, such as a simpler approach that works today but will need reworking as the product grows.
  • Vendor lock-inDepending so heavily on one supplier's service that leaving becomes expensive, slow or risky, even when it raises prices or no longer fits.
  • Vertical sliceBuilding one complete thread of a product end to end, data to screen for one role or feature, before starting the next, instead of all databases first and all screens last.

Marketplaces

  • Cold-start problemThe early marketplace trap in which customers won't come without providers and providers won't come without customers, so neither side arrives.
  • CommissionThe share of each transaction a marketplace keeps, taken as a percentage or a fixed fee, or replaced by a plan the provider pays for upfront.
  • Content moderationReviewing and acting on what users post or report, from muting a member to hiding a post, under written rules and with a route to appeal.
  • DispatchDeciding which provider is offered a job, in what order and for how long, and what happens when nobody accepts.
  • Dispute resolutionWhen a customer and a provider disagree about an order, this process decides who answers first, how it escalates and what happens to the money meanwhile.
  • EscrowHolding a buyer's payment until the service or goods are delivered, so the provider is paid only once the job is done and refunds stay possible.
  • KYCChecking who providers and business customers are, through documents such as licences, insurance, GSTIN and PAN, before they can work or trade on the platform.
  • Marketplace liquidityHow reliably a marketplace matches supply with demand in each place and moment, such as enough online drivers near the bookings that need them.
  • Multi-vendor checkoutOne cart and one payment covering items from several independent sellers, split behind the scenes into separate orders, deliveries and payouts per seller.
  • Two-sided marketplaceCustomers on one side, providers on the other and a platform in between that earns when they transact: senders and drivers, clients and trainers, buyers and nurseries.

About the glossary

Who is this app development glossary for?

Founders and product owners who work with developers: each entry explains a term in plain words, says why it matters to the budget or the launch, and shows where it came up in a real build.

Where do the examples in the glossary come from?

From our own case studies. Every entry links the project it draws on, and prototype or discovery work is labelled as such, so you can tell a shipped feature from a recommendation.