What is production software

What is production software? A working definition

If you are asking what is production software, the short answer is this: it is software running in a live environment where real people use it for real tasks, with real data and real consequences. The word refers to where the software runs and who depends on it. It does not describe how large or impressive the code is. Development, staging and demo environments exist to build and inspect. Production is where the software has to do its job.

The term has other uses. Teams in manufacturing or media sometimes say production software to mean tools that plan factory output or edit film and audio. This article covers the software engineering sense: a system in live operation that someone relies on. In that sense, a small, narrow tool can be production software, and a polished demo with no real users is not.

Production software versus prototypes, proofs of concept and MVPs

These labels are often used inconsistently, so it helps to separate them by purpose, as IVRYN's decision guide does. A prototype explores how an experience should work. A proof of concept tests whether one important technical assumption is feasible. An MVP is the smallest responsibly operated product that is released to produce useful evidence from a real user path. The guide does not use the term production software for an MVP. Our own inference, based on the definition above, is that once an MVP is released to real users, it counts as production software, even though its scope is deliberately small.

The guide also sets out what each artefact cannot show. A convincing prototype does not prove production quality. A successful technical proof does not prove demand. A deployed MVP does not prove adoption, revenue or product-market fit. The practical point is that being in production describes a responsibility, not a result. It means you have accepted that someone will depend on the software. It does not mean the software has succeeded.

This is why the guide recommends writing a one-sentence decision before choosing a format. That sentence should name who will use the software, where it will run, which data it may touch, and what the result cannot demonstrate. Without it, a stakeholder demo can quietly become a production commitment that nobody planned to operate.

The details that matter before you rely on it

Production readiness starts before any code is written. It starts with problem clarity. IVRYN's methodology begins with a specific user, task and context. It records assumptions, dependencies and exclusions early, so that a polished interface cannot hide a problem nobody has defined. If you cannot say what the software will not do, you cannot judge whether it is safe to rely on.

Next, look at behaviour when things go wrong. Critical flows need failure states, plain language and a recovery path. Data collection should be limited to what the feature and its operation require. Third-party services are dependencies with their own availability, policy and cost constraints. Where AI generates output, the interface should say so, show where human review is expected, and explain what happens if the model or provider is unavailable.

Accessibility belongs on the same list. An interface that some users cannot operate is not reliable for those users, whatever its uptime figures say.

• Is the intended user and task written down, along with what the product will not do?
• Does every critical flow have a visible failure state and a recovery path?
• Is the data collected limited to what the feature actually needs?
• Are third-party services listed as dependencies, with their availability, policy and cost constraints understood? Planning a fallback for each one is this article's own suggestion, not a methodology requirement.
• Can people using keyboards, screen readers or small screens complete the core task?
• Is AI-generated output labelled, and is it clear what happens when the model or provider is unavailable?

How a release actually reaches production

A successful build on a laptop is not a production release. The methodology is explicit that a release is not called successful until the public endpoint has been checked. Verification should match the risk of the change. Depending on that risk, it can include automated checks, manual tests of key flows, responsive visual checks, structured-data validation, crawl checks and monitoring of the deployed route.

Treat performance scores with similar care. A Lighthouse score is a lab measurement taken at one moment. It is not a ranking and not a guarantee of how real users will experience the software. It is useful as a signal, but it cannot prove production quality on its own.

Small, testable releases make this discipline affordable. When each change is narrow, you can verify it in proportion to its risk, see quickly whether it broke something, and roll it back without unpicking a month of unrelated work.

Example: deciding whether a tool is ready to rely on

Hypothetical example, for illustration only. A three-person team has built a tool that reminds freelancers about unpaid invoices. A demo impressed early contacts, and the team now wants ten freelancers to use it with their real client lists.

Using the questions above, the team writes its decision: ten named freelancers will use the hosted tool for a set period. It will touch client names and email addresses. If reminders go out on time and freelancers keep using it, the team will widen access. The test cannot show whether people would pay for it. In checking flows, the team finds that a failed email send currently shows nothing to the user, so it adds a visible error and a manual resend before inviting anyone. It also confirms the deployed reminder route works on the public URL, not only on a local machine.

The checklist did not block the release. It turned a demo into software the team could operate and explain. It also stated plainly what the first release could and could not demonstrate.

Keeping production software useful after launch

Going live is the start of operation, not the end of the work. Decide which outcomes you will measure before launch, such as completed tasks, recovered errors or repeat use. Without those measures, you cannot tell whether the software is helping anyone. Measure in a way that matches what you said the release could show, and avoid treating early activity as proof of adoption.

This guidance reflects how IVRYN, an independent studio in Paris, approaches its own work. The studio runs several separate products, each built for a distinct audience. That context limits the advice: it describes a published working standard, not research findings or observed client outcomes. Use it as a set of questions to adapt to your own risks, not as a guarantee.