What a Serious App Development Process Includes

Process is not overhead

When a software project fails, the post-mortem rarely finds bad code. It finds a requirement nobody confirmed, a role nobody modelled, an integration nobody tested against real data, or a launch nobody planned. These are process failures, and they are considerably more expensive than engineering failures because they surface late.

A serious process is not ceremony. Each phase exists to answer a question that becomes more expensive to answer later, and each produces an output the client can read and challenge.

Discovery

Discovery establishes what the operation actually does — not what the org chart says, and not what the process document from three years ago describes. That means talking to the people doing the work, watching where they improvise, and identifying which exceptions are frequent enough to be requirements.

The output is a map of users, workflows, business rules, integration points, risks, and the goals the software has to serve. It should be specific enough that someone can disagree with it. A discovery document nobody can argue with has not said anything.

Requirements

Requirements convert that map into statements precise enough to build and test against. The useful discipline here is to write requirements that can fail: a statement no observation could contradict is not a requirement.

This phase also decides what is out of scope, which matters more than it sounds. Explicit exclusions prevent the slow expansion that consumes budget without anyone approving it. Prioritization belongs here too, because everything cannot be in the first release and choosing under pressure later produces worse choices.

Architecture

Architecture settles the decisions that are expensive to reverse: the data model, the role and permission structure, the integration boundaries, the hosting and environment strategy, and the security posture.

The permission model deserves particular attention in multi-role systems, because it is the decision most often approximated early and most painful to correct later. Retrofitting a boundary through a system that assumed open access touches every query and every screen.

Architecture should also state what the system does when a dependency fails. Failure behaviour designed at this stage is a feature; discovered in production it is an incident.

Product design

Design here means workflow design, not decoration. The question is whether a person can complete their task without holding the system's structure in their head — and complexity should live inside the software rather than being handed to the user as a set of steps to remember.

Responsive behaviour is part of this, decided at design time rather than compressed at the end. A field application and an administrative console have genuinely different requirements, and pretending one layout serves both produces two mediocre experiences.

Accessibility belongs here as well. Heading structure, focus behaviour, keyboard paths, and contrast are cheap to design in and expensive to retrofit.

Implementation

Implementation should proceed in phases with visible progress and reviewable scope. Long stretches without demonstrable output are where projects lose their way, because divergence between what was meant and what was built compounds silently.

Decisions made during the build should be recorded as they happen. Six months later, the reason a particular approach was chosen is genuinely difficult to reconstruct, and the absence of that reasoning makes every subsequent change riskier.

Quality assurance

Testing covers more than whether a feature works for the person who built it. It covers permissions — confirming each role can reach exactly what it should and nothing more. It covers failure paths, where systems behave worst. It covers responsive behaviour on real devices, performance against realistic data volumes rather than seed data, and the edge cases discovery identified.

Permission testing deserves explicit mention because it is the most commonly skipped and the most consequential when missed. A functional bug frustrates a user; a permission bug exposes records.

Security planning

Security is architectural, not a review at the end. It covers identity and authentication, authorization at the data-access layer rather than only in the interface, transport and storage protection, secret management, dependency currency, logging of consequential actions, and defined boundaries with every third party.

It also covers what the system deliberately does not collect. Data that is never captured cannot be exposed, and declining to store something is often the strongest available control.

Launch

Launch is a planned event with its own requirements: data migration validated against real records, environment configuration confirmed, monitoring in place before traffic arrives, a rollback path, and users who have been trained rather than surprised.

Migration is routinely underestimated. Real data is messier than the schema suggests, and mapping it properly is a project in itself. Discovering that during cutover is the wrong time.

Continuing support

Software is not finished at launch; it enters operation. Dependencies need updating, security advisories need attention, monitoring needs someone watching it, and the operation will change in ways that require the system to change with it.

Plan for this explicitly. A system nobody is funding to maintain becomes a liability at a predictable rate — and the organizations that get the most from custom software are the ones that treat the first release as the beginning of the relationship rather than the end of the project.