Software Development Glossary for Non-Developers: 60 Terms Explained

This software development glossary explains 60 terms you'll hear when you hire a developer or run a software project, from API and MVP to staging, technical debt and DPAs. Every definition is written for the person paying for the software, not the person writing it, and says what the word means for your budget, timeline or risk.

I'm a freelance developer, so the definitions reflect how I use these words in my own projects. Other developers use a few of them slightly differently, which is exactly why it pays to ask.

The short answer

These six terms most often drive price and risk on a project. The right-hand column is the question I'd ask in your seat.

My rule of thumb: if a word in a proposal doesn't make sense to you, ask before you sign. To see where these terms show up in a real project, start with my walkthrough of the software development process from idea to launch.

How software is built

These terms describe what a system is made of. You don't have to pick the technology, but it helps to understand what your developer proposes.

Frontend

The part of the system users see and click: pages, buttons and forms. It runs in the browser. Common tools include React, Vue and Tailwind CSS.

Backend

The part that runs on the server and users never see: business rules, calculations, login and the connection to the database. If the frontend is the shop floor, the backend is the stockroom and the office.

Full stack

A developer who works on both frontend and backend, so one person can keep the whole picture on small and mid-sized projects. That's how I work. I've compared the roles in frontend vs backend vs full-stack developers.

Database

Where the system stores its data in a fixed structure, such as customers, orders and bookings. Many web apps use MySQL or PostgreSQL. The database is often the most valuable part of your system.

API

An agreed way for two systems to talk, for example when your online store pulls stock levels from your inventory system. I've written a full guide to what an API is and why your system needs one.

Integration

A connection between two systems, usually through an API, so data flows automatically instead of being typed in twice. Always ask what happens when the other system is down.

Webhook

A message one system sends to another automatically when something happens, such as a completed payment. An API answers when asked. A webhook speaks up on its own.

Framework

A ready-made foundation developers build on, so login and security don't have to be reinvented. Laravel and Next.js are examples. A popular framework makes it easier to find a new developer later.

Tech stack

The combination of technologies a system is built with: language, framework, database and hosting. Mine is usually Laravel, React and Tailwind CSS. Here's what a tech stack is, explained without jargon.

Web app

Software that runs in the browser and does more than a website: users log in, data is saved and there are workflows. Customer portals, booking systems and internal tools are typical web apps.

Native app and PWA

A native app is built for iPhone or Android and installed from an app store. A PWA (progressive web app) is a web app users can add to their home screen, often cheaper because there's one codebase.

SaaS

Software as a service: software you pay for by subscription and use in the browser without installing anything. The provider handles hosting and updates.

Monolith and microservices

A monolith is one system with one codebase. Microservices are many small systems talking to each other. Microservices suit very large systems with many teams. For most projects, a well-organized monolith is cheaper and simpler.

Open source

Code anyone may use, read and usually modify under a specific license. Laravel and React are open source. You pay no license fee for the tools, only for the time it takes to build with them.

Projects and contracts

You'll meet these words in the first call and the proposal. They decide what you get, when and at what cost.

MVP

Minimum viable product: the smallest version of a product that real users can use and give feedback on. A good MVP does one job properly rather than many jobs halfway.

Proof of concept (PoC)

A quick test of whether a technical idea works at all, such as whether two systems can exchange data. The code is often thrown away. The point is to remove the biggest unknown early.

Wireframe and prototype

A wireframe is a rough sketch of a screen. A prototype is a clickable mockup, usually made in Figma. Both are cheap to change, and that's the point: fixes cost less before any code exists.

Discovery phase

A short, scoped phase before the build where requirements, risks and price get pinned down. You come out with a prioritized feature list and a firmer estimate. I run a paid, fixed-price discovery phase before larger builds.

Requirements specification

A document describing what the system must do, who uses it and which rules it follows. It doesn't need to be long. Here's my software requirements specification template and how to fill it in.

Statement of work (SOW)

The contract document setting out what gets delivered, by when, for how much and how changes are handled. A vague SOW turns every later disagreement into a negotiation.

User story

A feature described from the user's point of view: "As a customer, I want to see my invoices so I don't have to call and ask." It forces everyone to think about who the feature is for.

Backlog

The prioritized list of everything that could be built: features, fixes and ideas. The top gets built first. It's normal for a backlog to grow faster than it shrinks.

Agile and sprints

Building the system in small pieces you see and approve as you go, often in one- or two-week cycles called sprints. You can change direction midway, but the final price is harder to predict.

Waterfall

The classic approach: specify everything first, then build, then test. It works when requirements are known and stable, such as an integration with a fixed data format.

Definition of done

A shared agreement on when a task counts as finished, for example tested, checked on staging and approved by you. Without it, "done" can mean "code written" to your developer and "ready to use" to you.

Estimate

An informed guess at how long a task will take, and neither a price nor a promise. The less defined the task, the wider the range should be, so ask for a range, not one number.

Fixed price vs time and materials

With a fixed price, you pay an agreed amount for a defined scope and the developer carries the risk of overruns. With time and materials (hourly or day rate), you pay for time spent and carry the risk.

Scope creep

When the scope slowly grows through "just one more small thing". Each change looks minor, but together they push the deadline and budget. The fix is a change process where every new request gets a price and a place in the backlog.

Code and quality

These terms are about the code itself. They decide how affordable it is to change your system a year from now.

Source code

The text developers write, which the system is made of. Make sure your contract says you own the source code and have access to it. With me, clients own the code from day one.

Repository

A code archive holding the source code and its full history, usually on GitHub or GitLab. Ask for it to live in an account you own or can access, so you're never left without your code.

Git and version control

Git is the version control tool the vast majority of developers use. It records every change with a timestamp and author, so a bug can be traced back to the change that caused it.

Pull request and code review

A pull request is a proposed change to the code. Code review is when another developer reads that change before it goes in. If your project has one developer, an occasional external review does the same job.

Bug

A defect: something that doesn't work as agreed. All software has bugs. What matters is how quickly they get fixed and who pays for the fix under your contract.

Automated tests

Small programs that check the system still works every time the code changes. They cost some time now but catch bugs before your users do.

Refactoring

Rewriting code so it's easier to understand and change, without adding new behavior. From the outside it looks like nothing happened, but the next features get cheaper to build.

Technical debt

Shortcuts in the code that work today but make later changes more expensive. Like a loan, a little debt is fine if it's a conscious choice. I've written about what technical debt costs when you put off dealing with it.

Legacy code

Older code that still runs the business but is hard to change, for example because it has no tests or only one person understands it. It rarely needs throwing out and can often be modernized in stages.

Dependencies

Third-party code libraries the system relies on, for example for payments or PDF generation. They save a lot of time but need regular updates, because old versions can contain security holes.

Documentation

Explanations of how the system is built, set up and run, so another developer can take over. A README (the intro file in the repository), a list of integrations and deployment notes go a long way.

Hosting and operations

A finished system has to run somewhere and keep running. These terms show up in hosting quotes and maintenance agreements.

Hosting

The service that provides a server and keeps your system online for a monthly fee. Ask where the servers are. If you handle personal data about EU residents, EU hosting keeps things simpler.

Server and cloud

A server is a computer that runs your system and is reachable online. Cloud means renting computing power from a large provider such as AWS or Microsoft Azure, so capacity can scale up and down.

Domain and DNS

The domain is your address, such as simonij.com. DNS is the internet's phone book, pointing that address to the right server. The domain should be registered to your company, never to your developer.

SSL/TLS certificate

What gives you https and the padlock in the browser. It encrypts the connection between user and server so nobody can read along. Certificates are available for free, for example from Let's Encrypt.

Local, staging and production

The three environments a system usually runs in: the developer's own machine, a test copy, and the live system your users rely on. Changes should pass through staging so you can test before they reach production.

Deployment

Releasing a new version of the code to the server. A good setup makes it one click or fully automatic, so it never depends on one person's memory.

CI/CD

Continuous integration and continuous delivery: an automated pipeline that runs the tests on every change and releases the new version if everything passes. The result is fewer broken releases.

Backups

Copies of your data and files stored somewhere other than the system itself. A backup is only worth something if it has been tested. Ask when someone last tried restoring one.

Monitoring

Automatic checks that the system is up and working, with alerts to the developer when something breaks. The goal is to spot problems before your customers do.

Uptime and SLA

Uptime is the share of time the system is available, as a percentage. An SLA (service level agreement) sets the uptime and response times you can expect. Higher uptime costs more, so agree on the level you actually need.

Caching and CDN

A cache stores ready-made copies of data or pages so they aren't rebuilt every time. A CDN (content delivery network) serves files from a server close to the user. Both make the system faster.

Security, data and compliance

The last group is about responsibility. Several of these terms have legal consequences, so check with a lawyer if you're unsure what applies to you.

GDPR

The EU's data protection regulation, governing how personal data is collected, stored and used. If your system holds names, emails or other data about people in the EU, it applies, and it can cover companies based outside the EU too.

Data processing agreement (DPA)

A contract with any supplier that handles personal data on your behalf, such as your hosting provider or a developer with database access. Article 28 of the GDPR requires one and lists what it must cover.

Encryption

Making data unreadable to anyone without the right key, both in transit and on the server. Passwords should be stored as a hash, a one-way transformation, so even the developer can't read them.

Two-factor authentication (2FA)

Login that requires something you know, like a password, and something you have, like a code from an app on your phone. It makes stolen passwords far less useful to an attacker.

Roles and permissions

Rules for who can see and do what, for example staff can view orders but only admins can change prices. They're much easier to build in from the start than to add later.

Vulnerability

A weakness in the code or setup that an attacker can exploit. OWASP publishes a list of the most critical web application security risks, which is a good basis for questions to your developer.

Penetration test

A test where a security specialist tries, with your permission, to break into the system to find weaknesses. It pays off when the system handles sensitive data, money or many users.

Logging

The system's automatic diary of errors, login attempts and key actions, and the first place a developer looks when something breaks. Logs can contain personal data, so delete them after a set period.

Vendor lock-in

When switching suppliers is hard or expensive, because the system sits on a closed platform or only one person understands the code. You reduce the risk by owning the code, the domain and the hosting account yourself.

Accessibility (WCAG)

Making the system usable by everyone, including people using screen readers or only a keyboard. The standard is WCAG, published by the W3C, and level AA is the usual target. The European Accessibility Act sets requirements for e-commerce and banking services, among others.

Next steps: use the glossary in your next developer call

Take the six terms from the table at the top into your next developer call and ask about each one. The answers tell you a lot about how that person works.

Three honest pieces of advice:

• If all you need is a simple marketing site, half of these terms won't matter to you. Squarespace or Webflow will usually be cheaper and faster than hiring a developer like me.
• If a developer uses jargon without explaining it, or gets impatient when you ask, take it as a preview of the collaboration.
• Write the definitions you agree on into the contract, especially what "done" means.

To see the kind of work I take on, from websites to custom web apps and SaaS products, have a look at the overview of my development services. You work directly with me, larger builds start with a fixed-price discovery phase, and you own the code from day one.

Frequently asked questions

Why do developers use so much jargon?+

Mostly because the terms are precise shorthand among developers, and most tools and documentation use the same vocabulary. The problem starts when that shorthand lands in proposals for people outside the field. It's entirely reasonable to ask for a plain-English explanation, and a developer who knows their craft can give one.

Do I need to learn to code to manage a software project?+

No. Your main job is to describe the problem, decide what matters most and test what gets built through your users' eyes. Knowing the common terms helps you ask the right questions, but the technical judgment is your developer's job, and they should explain their choices.

What does it mean when a system is scalable?+

It means the system can handle more users or data without being rebuilt, either by giving the server more power or by spreading the work across several servers. For most new projects, code that's easy to change matters more than handling millions of users on day one, so ask what growth would take rather than paying for scale upfront.

What's the difference between a software engineer and a developer?+

In practice, the titles often describe the same job. "Engineer" sometimes signals more focus on system design, while "developer" can cover anything from writing code to running the finished system. The title alone tells you little, so ask which parts of your project the person will own.