Software Development Terms Every Startup Founder Should Know: A Glossary

Are you a non-technical founder, startup owner or entrepreneur? Then you've probably been in a meeting where your technology team or vendor used words you'd never heard before. It happens to everyone. Even as a technical founder, when I meet marketing vendors they mention ABM or A/B testing, and I have to stop and ask what they mean.

So here's the vocabulary you'll hear from software vendors and developers. It's grouped the way a project runs, from planning to launch, and then cloud, security and AI. For each term we explain what it means and why it matters to you as the person paying for the software. To see what those terms cost, read our guide to the hidden costs of building an app.

Planning and scope

Discovery phase

The first paid step of many projects. The vendor works with you to understand the problem, talks to the people who will use the software, and defines the scope.

Why it matters to you: discovery should produce something you can hold: wireframes, a requirements document or a clear in-scope/out-of-scope list, an estimate and a high-level project plan. If you pay for discovery, the output should be clear enough for another vendor to build from. If it isn't, you've paid for meetings.

Functional specs (requirements)

A description of what the software must do, written before development starts. A vendor may call them functional requirements, a feature spec or an SRS (software requirements specification). They can be as small as an annotated wireframe or as detailed as a full document with use cases and acceptance criteria.

Why it matters to you: good software is built after the specs are written, not before. Ask to review and sign off on the specs, so you and the vendor agree on what "done" means.

MVP (minimum viable product)

The smallest version of your product that real users can use, built to find out whether they want it, and will pay for it, before you spend the rest of your budget. An MVP is not a cheap version of the final product. It does one job well for one group of users.

Why it matters to you: it's the most budget-friendly way to test an idea, and the version most investors want to see working. Our MVP development page explains how we scope one with founders.

POC (proof of concept)

A small program built to answer one technical question, such as "can we read data from this machine?" or "is this algorithm fast enough?". It isn't meant for users.

Why it matters to you: a POC lowers the risk before you commit a budget. Some vendors use POC and MVP interchangeably, but an MVP is a product and a POC is an experiment.

Prototype

A clickable version of the screens that doesn't use real data. Users can tap through it and see how the app will work, but nothing is saved.

Why it matters to you: a prototype is the cheapest way to show the product to users and investors, and to agree on the scope before development starts.

	Prototype	POC	MVP
Question it answers	Does the design make sense?	Can the technology do it?	Will customers use it, and pay?
Who uses it	You, test users, investors	The development team	Real early users
Real data	No	Sometimes	Yes
Typical next step	Specs and estimate	Technology decision	Feedback, funding, version two

Estimate and statement of work (SOW)

The estimate says what the vendor thinks the work will take and cost. The statement of work is the contract document that sets out the scope, deliverables, timeline, payment terms and assumptions.

Why it matters to you: read what the estimate leaves out as carefully as what it includes. Testing, deployment, support and project management should all be in it.

Fixed price, milestone and hourly

These are the three common ways to pay for software. A fixed price covers a defined scope. Milestone pricing pays for agreed deliverables as each one is finished. Hourly (time and materials) pays for the time worked.

Why it matters to you: a fixed price suits a well-defined scope. Hourly suits work that will change as you learn. We work all three ways, and our How We Work page explains when we use each one.

NDA (non-disclosure agreement)

A contract in which the vendor agrees to keep your idea and business details confidential.

Why it matters to you: sign one before you share the details of your idea. We sign the client's NDA or use our own.

Change request and scope creep

A change request is a formal request to change something already agreed. Scope creep is what happens when many small changes are added without one.

Why it matters to you: each "small" change adds time and cost, and many of them are how budgets run out. Agree in writing how changes are estimated and approved before work starts.

Design

Wireframe

A simple sketch of a screen's layout, made digitally instead of on paper. Wireframes show what goes where, not colors or fonts. They're made during discovery or while the specs are written.

Why it matters to you: they're the cheapest place to change your mind. Developers are much more productive when they see the wireframes before they start.

UI and UX (user interface and user experience)

The two terms are often used together, but they mean different things. UI is how the product looks: the color theme, fonts, images and icons. UX is how easily your users get things done. If one task takes too many clicks, the experience is poor, however good it looks.

Why it matters to you: a graphic designer can create a good UI, but a good UX takes someone who understands your users' work. Ask who on the team is responsible for each.

Assets

The digital files that make up your product's look and marketing, such as images, icons, fonts, logos, design files and presentations.

Why it matters to you: you're paying for them, so make sure you get the source files back, not just the finished screens.

Building the software

Agile and Waterfall

Waterfall runs a project in sequence: all the requirements first, then all the development, then all the testing, with the big result at the end. Agile builds the software in small pieces, shows each piece to you, and adjusts the plan as you learn.

Why it matters to you: with Agile you see working software early, and you decide after each piece whether the next one is worth paying for. You also have to be involved regularly, to answer questions and review the work.

Scrum and sprint

Scrum is the most common way of working Agile. A sprint is a fixed period, usually one to four weeks, in which the team plans, builds and tests a set of items, then shows you the result in a sprint review. Our sprints are two weeks by default, and we run four-week sprints when that fits a client's schedule better. The Scrum Guide is the official definition.

Why it matters to you: ask how long the vendor's sprints are and what you'll see at the end of each one. You should see working features, not a status report.

Product owner

The person who decides what gets built and in what order. In a startup, that's usually you.

Why it matters to you: someone on your side has to answer the team's questions, set priorities and accept the work every sprint. Plan time for it.

Backlog, epic and user story

The backlog is the prioritized list of everything still to be built. An epic is a large feature, such as "online ordering", that is split into smaller user stories. A user story describes one feature from the user's point of view: "A customer should be able to save a card so that they can check out faster." We wrote more about what is, and what isn't, a user story.

Why it matters to you: user stories are how your ideas reach the developers. If you write them in plain business language, the team estimates and builds what you actually meant.

Acceptance criteria and definition of done

Acceptance criteria are the conditions a user story must meet before it's accepted, such as "the order confirmation email arrives within a minute". The definition of done is the checklist every item has to pass before the team calls it finished, such as code reviewed, tested and deployed to the test environment.

Why it matters to you: this is where disagreements are prevented. If "done" isn't written down, you and the vendor will each assume your own version.

Front end, back end and database

The front end is what users see and touch: the web pages or app screens. The back end is the server-side code that runs the business rules and talks to the database. The database is where your data is stored.

Why it matters to you: a vendor may quote for one and assume you have the others. Make sure the estimate covers all three.

API (application programming interface)

An API lets one piece of software exchange data and functions with another. Your mobile app talks to your back end through an API. Websites, ERP and CRM systems, payment gateways, maps and AI services are all connected the same way. Connecting your product to another system this way is called an integration.

Why it matters to you: every integration is work to build and maintain, and many third-party APIs charge more as your usage grows. List the systems your product must connect to early on. See our API development page.

Tech stack

The set of technologies the product is built with, such as the programming language, framework, database and cloud platform. For example: .NET and Angular on Azure. A framework is a ready-made foundation of code that developers build on instead of starting from scratch. Angular and React are frameworks for web screens, and .NET MAUI is one for mobile apps.

Why it matters to you: pick a stack that many developers know, so you aren't locked in to one vendor or one hard-to-hire skill.

Native, cross-platform, web app and PWA

A native app is built separately for iOS and for Android. A cross-platform app uses one codebase for both, built with a framework such as .NET MAUI or React Native. A web app runs in the browser. A PWA (progressive web app) is a web app that users can install on their phone like an app.

Why it matters to you: this choice changes your budget more than almost any other. For many first versions, a cross-platform app or a PWA is enough.

Source code, source control and repository

Source code is the human-readable code that developers write, in languages like C#, Java, Python or TypeScript. Source control (usually Git) records every change to that code. The repository is where it's stored, on a service such as GitHub or Azure DevOps.

Why it matters to you: the source code and the database are what you're paying for, not just the finished app. They're your intellectual property, so you should own them. If the relationship with a vendor goes sour, you need to be able to give the code to another vendor to carry on. Put ownership in the contract, and keep the repository account in your company's name, with the vendor given access.

Open-source license

Most software is built partly from open-source components: free code that anyone can use, under the terms of its license. Permissive licenses such as MIT and Apache 2.0 let you use the code in a commercial product with few conditions, mainly keeping the copyright notice. Copyleft licenses such as the GPL can require you to publish your own source code if you distribute software that includes it. The AGPL extends that to software people use over the internet.

Why it matters to you: open source saves time and money, but the license terms become your obligations. Ask your vendor for a list of the open-source components in your product and their licenses. Investors and buyers often ask for one during due diligence.

Technical debt

The future cost of shortcuts taken today: code written quickly instead of well, missing tests, an old library left unupdated. Like financial debt, a little is fine and too much slows everything down.

Why it matters to you: some technical debt is a sensible trade-off in an MVP. Ask your vendor to tell you when they're taking a shortcut, and to plan time to pay it back before it piles up.

Scalability

Whether the product can handle more users and data without a rewrite.

Why it matters to you: don't pay to build for a million users on day one, but ask how the architecture would grow if the product takes off. Investors often ask the same question.

Hearing these terms in a vendor proposal and not sure what's missing? Send it to us and we'll walk you through it.

Testing

Alpha test

Testing by the development team, before anyone outside the team sees the software.

Why it matters to you: testing isn't an extra. It belongs in every estimate, and the more your revenue depends on the product, the more it matters.

Beta test

Testing by real end users or pilot users, after the alpha test. The vendor should tell you when the system is ready and what has already been tested internally.

Why it matters to you: agree in the contract how long the test window is, and how quickly and on what terms bugs found in it will be fixed.

UAT (user acceptance testing)

Testing by you or your users to confirm that the software does what the specs said it would. The vendor should give you a UAT plan or test cases that describe the expected behavior. You note where the real behavior differs, and those differences become bugs to fix.

Why it matters to you: UAT is how you formally accept the work. Don't skip it, and don't sign off on what you haven't tested.

Regression testing

Re-testing the parts that already worked, to make sure a new change hasn't broken them.

Why it matters to you: most "it worked last week" problems are regressions. Ask how the vendor checks for them, manually, with automated tests, or both.

Bug severity and priority

Severity is how much damage a bug does: critical (the system is down or data is wrong), high (a main feature is broken), medium, or low (a cosmetic problem). Priority is how soon it gets fixed. The two usually go together, but not always. A typo on your home page is low severity and may still be high priority before a launch.

Why it matters to you: agree on the levels, and what each one means for response time, before launch. On our projects a critical bug is priority 1: it goes into the current sprint and is released as a hotfix. A high-severity bug is priority 1 or 2, and medium and low bugs are scheduled with you by priority.

Launch and after

Environments (development, QA, production)

Separate copies of your system for each stage: development for the developers, QA or staging for testing, and production for your real users.

Why it matters to you: changes should reach your users only after they've passed testing in QA. Testing on production puts your users' data at risk.

Deploy, publish and release

Deploying or publishing puts the software where users can reach it. Web apps and APIs are published to cloud servers, and mobile apps to the Apple App Store and Google Play. A release is a numbered version of the software that moves through the environments, first to test and then to production. Every version should follow the same release cycle.

Why it matters to you: if you don't have a technical team, you'll need help setting up the store accounts, publishing and passing app store review. Make sure the contract includes it.

DevOps and CI/CD (continuous integration and continuous delivery)

DevOps is the practice of having the people who build the software and the people who run it work as one team, with as much automated as possible. That covers builds, testing, deployments, the server set-up, monitoring and alerts. CI/CD is the core of it: automated pipelines that build, test and deploy the code every time a change is made, instead of a developer doing it by hand. Tools such as Azure DevOps and GitHub Actions run these pipelines.

Why it matters to you: releases become faster and less error-prone, and problems are spotted before your users report them. Ask whether production deployments still need your approval. They should. Also ask who gets the alert when the system goes down at night.

Hotfix

An urgent fix released outside the normal cycle, for a serious bug in production.

Why it matters to you: agree how serious a bug has to be for a hotfix, and how fast the vendor responds.

Maintenance and support

Maintenance is the ongoing work after launch: bug fixes, security updates, and the updates Apple and Google require every year. Support is how your users' problems are reported and resolved.

Why it matters to you: software is never finished. Ask what support costs per month and how quickly the vendor responds.

SLA (service level agreement)

The part of a support or hosting contract that sets measurable promises. These are usually uptime (how much of the time the system is available), response time (how fast someone starts working on a reported problem), and resolution time (how fast it's fixed), each by bug severity. It also says what happens if a promise is missed, often a credit on the next invoice.

Why it matters to you: read the numbers, not the adjectives. 99.9% uptime still allows about 43 minutes of downtime a month. Check whether response times count business hours or every hour of the day. Your own customers may ask you for an SLA, and you can't promise them more than your vendors and cloud provider promise you.

Cloud and hosting

Cloud hosting

Running your software on servers you rent from a provider such as Microsoft Azure, Amazon Web Services (AWS) or Google Cloud, instead of buying your own. You pay for what you use, monthly. See our cloud consulting page.

Why it matters to you: the cloud account should be in your company's name, with the vendor given access. Ask for an estimate of the monthly bill for each environment.

SaaS (software as a service)

Software that customers use over the internet for a subscription, instead of installing it. Many startup products are SaaS, and you'll also buy SaaS tools to run your business.

Why it matters to you: if you're building SaaS, plan from the start for subscriptions, billing, and keeping each customer's data separate.

Serverless and containers

Serverless means the cloud provider runs your code only when it's needed, and you pay per use. A container packages an application with everything it needs, so it runs the same way everywhere. You may hear Kubernetes, a system for running many containers. Most MVPs don't need it.

Why it matters to you: these terms affect your monthly cloud bill and how easily the product can grow. Ask why the vendor picked the option they did.

Security and compliance

Authentication and authorization

Authentication checks who a user is, for example with a sign-in. Authorization decides what that user is allowed to see and do once they're signed in.

Why it matters to you: most data leaks come from authorization mistakes, such as one customer seeing another's data. List your user roles, and what each one can access, in the specs.

MFA and SSO

MFA (multi-factor authentication) asks for a second proof of identity, such as a code on your phone. SSO (single sign-on) lets users sign in with an account they already have, such as their Microsoft or Google work account.

Why it matters to you: business customers increasingly expect both, and both are cheaper to build in from the start than to add later.

Encryption

Scrambling data so that only authorized systems can read it, both when it travels over the internet ("in transit") and when it's stored ("at rest").

Why it matters to you: ask your vendor to confirm both kinds. It's a standard question in any customer's security review.

Penetration testing

An authorized, simulated attack on your system to find security holes before attackers do. It's usually done by a specialist firm.

Why it matters to you: larger customers and investors may ask for a recent report. Budget for one before you sell to enterprises.

HIPAA and SOC 2

HIPAA is the US law that protects patient health information. If your product stores or handles it, your vendor should sign a business associate agreement (BAA) with you. We do. SOC 2 is an independent audit of how a company protects its customers' data. Banks, insurers and larger companies may ask your company for one, and your company would get and pay for it. Several US states also have their own consumer privacy laws.

Why it matters to you: compliance decides how the product is built, where the data is hosted and what the vendor signs. Raise it in the first conversation.

GDPR (General Data Protection Regulation)

The European Union's data protection law. It applies to any company that offers its product to people in the EU, or tracks what they do online, wherever the company is based. A US startup with European users is covered. The UK has its own version, the UK GDPR, which works the same way.

GDPR matters for Europe because it gives every user strong rights over their personal data. You need a lawful reason, such as consent or a contract, to collect each piece of data. Users can ask to see their data, correct it, take it with them or have it deleted. A serious data breach has to be reported within 72 hours. Fines can reach €20 million or 4% of a company's worldwide annual revenue, whichever is higher.

Why it matters to you: if you plan to sell in Europe, tell your vendor at the start. It affects what data you collect, the cookie consent on your website, where the data is hosted, and features like account export and deletion. Retrofitting it later costs much more.

AI terms Updated 2026

AI, machine learning and generative AI

Artificial intelligence (AI) is software that performs tasks that normally need human judgment. Machine learning (ML) is the most common way to build it: the software learns patterns from data instead of following hand-written rules. Generative AI creates new content, such as text, images or code, in answer to a request.

Why it matters to you: "AI-powered" can mean anything from a simple rule to a custom model. Ask exactly what the AI does in your product, and what happens when it's wrong.

LLM (large language model)

The kind of AI model behind tools like ChatGPT. It's trained on huge amounts of text to understand and write language. Products usually use an LLM from a provider, such as Azure OpenAI, OpenAI or Google Gemini, rather than building their own.

Why it matters to you: you rent an LLM, you don't own it. Ask which provider and model your vendor plans to use, whose account it runs on, and where your data goes.

Prompt and prompt engineering

A prompt is the instruction given to an LLM. Prompt engineering is the work of writing and testing those instructions so the model gives reliable, well-formatted answers.

Why it matters to you: much of the quality of an AI feature comes from its prompts, so they should be tested and version-controlled like code.

RAG (retrieval-augmented generation)

A technique that looks up the relevant parts of your documents or data and gives them to the LLM along with the question, so it answers from your information instead of only from what it learned in training.

Why it matters to you: RAG is how most "chat with your documents" and company-knowledge features work. It's usually cheaper and faster than training a custom model.

Fine-tuning

Training an existing model further on your own examples, so it learns your style, format or domain.

Why it matters to you: it's often not needed for a first version. Good prompts plus RAG solve most problems, so ask why fine-tuning is needed before you pay for it.

AI agent

AI that doesn't just answer but takes actions, such as looking up an order, filling in a form or calling another system's API, often over several steps.

Why it matters to you: the more an agent can do, the more it matters what it's allowed to do. Ask what it can change on its own and where a person has to approve.

Hallucination

When an AI model gives a confident answer that is wrong or made up.

Why it matters to you: every AI feature needs a plan for it, such as showing the source of an answer, checking results against your data, or having a person review important outputs.

Tokens and usage cost

AI providers charge per token, a small chunk of text, both for what you send to the model and what it sends back. Every user request costs money.

Why it matters to you: AI costs grow with every user. Ask for an estimate of the cost per active user before you launch. Our guide on adding AI to existing software and our AI integration page explain how we plan this with clients.

Questions to ask a software vendor

Once you know the terms, these questions show you quickly how a vendor works:

• What do I get from discovery? Wireframes, specs, an estimate and a plan you could take to another vendor?
• How long are your sprints, and what will I see at the end of each one?
• How are change requests estimated and approved?
• Will I own the source code, and whose name are the repository, cloud and app store accounts in?
• How is the product tested before I see it, and how do I do UAT?
• How is user data secured? Authentication, encryption, backups, and the compliance my customers will ask about, such as HIPAA, or GDPR if I have users in Europe.
• What happens after launch? Who fixes bugs, how fast by severity, what the SLA promises, and what support costs each month. Our guide to the hidden costs of building an app covers the costs to plan for.
• Updated 2026 Does this product need AI, and if so, what will it cost to run per user?

If you're interviewing individual developers rather than a company, our post on how to interview or evaluate a software developer helps.

Frequently asked questions

Do I need to learn to code to work with a software vendor?

No. You need to understand the terms that decide scope, cost and ownership, and to know what your users need. A good vendor explains the technical choices in business terms, and tells you what not to build.

What's the difference between an MVP, a POC and a prototype?

A prototype shows the screens without real data, to test the design. A POC is a small experiment that tests whether a technology works. An MVP is the smallest real product that early users can use, to test whether they want it and will pay for it.

What should a discovery phase deliver?

Wireframes, a requirements document or a clear in-scope/out-of-scope list, an estimate and a high-level project plan. The output should be clear enough that another vendor could build from it.

Is Agile or fixed price better for a startup?

They answer different questions. Agile is how the work is done, and fixed price is how it's paid for. Many startups fix the price of a well-defined MVP and pay hourly for the changes they want after users try it.

Who should own the source code?

You should. The source code is your product's intellectual property, and you need it to change vendors or raise money. Make sure the contract says the code, the designs and the accounts are yours, and keep the repository in your company's name with the vendor given access.

Does GDPR apply to a US startup?

Yes, if you offer your product to people in the European Union or track what they do online. It applies because of where your users are, not where your company is. Plan for consent, data access and deletion requests, and breach reporting before you launch in Europe.

What is technical debt, and should I worry about it?

It's the future cost of shortcuts taken today. A little is normal in an MVP, if you know where it is and plan time to fix it. Too much makes every later change slower and more expensive.

Which AI terms do I need to know before adding AI to my product?

Updated 2026 LLM (the model), RAG (letting it answer from your data), hallucination (when it's confidently wrong) and tokens (how it's charged). Those four decide what the AI can be trusted with and what it costs per user.

---

Planning your first software product and want someone to translate the proposals? Tell us about your idea and we'll go through the scope, the terms and the trade-offs with you. We reply within two business days.