What happens after you decide to build a custom web application

Turning the idea into an agreed scope

The first stage is about making the application clear enough to build. A business may begin with a straightforward objective such as managing orders, coordinating internal work, or giving customers access to a particular service—but that objective does not yet describe everything the application needs to do.

The development team needs to understand how the business actually operates and what the application is expected to change or support. That means clarifying the people who will use it, the workflows they need to follow, the information they need to work with, the rules the application needs to enforce, and any important constraints. Questions that seem small at this point can affect what eventually needs to be designed and developed.

Consider a business that asks for an application to “manage orders.” Before development can begin, that could mean several different things. Who creates an order? Who can approve it? What statuses can it have? Can an order be edited after approval? Which users can see particular orders? What happens when an order is cancelled? Until those decisions are understood, there is no sufficiently precise definition of what “order management” actually means in the application.

This is where the client's role is particularly important. The client brings knowledge of the business, its users, and the desired outcome; the developer uses that information to translate the idea into concrete application requirements. The client is not expected to determine how the software should be implemented. Their responsibility is to provide the information and decisions needed to establish what the software should do.

The result should be an agreed understanding of what is being built, rather than simply a collection of conversations about possible features. That distinction matters because clarification is not the same as development. A requirement being discussed or approved does not mean the corresponding functionality has already been implemented.

It also creates an important dependency for everything that follows. If a workflow is left ambiguous, the developer may have to make assumptions during design or development. If those assumptions are discovered later to be wrong, decisions that appeared to be settled can have to be revisited. The earlier a significant uncertainty is resolved, the less likely it is to affect work that has already been built around it.

The scope does not need to predict every detail of the finished application before anything else can happen. It needs to be clear enough that both the client and developer share the same understanding of what the application is intended to accomplish and can make the next set of decisions on that basis.

Planning and designing the application

Once the requirements are sufficiently clear, the next step is to turn them into a practical direction for the application. Planning establishes what needs to be designed and built and how the agreed requirements can be approached. Design then makes that direction more concrete by defining how users will move through the application and how the required functionality will be presented.

The development team uses the agreed requirements to work through the application's structure and intended user experience. This can involve deciding how different parts of the application relate to one another, what users need to do at each point in a workflow, and how those requirements should be represented in the interface. The purpose is not simply to produce something that looks right. The decisions made here give development a clearer definition of what needs to be implemented.

The client's role is to provide the business context that cannot be determined from the requirements alone and to review decisions that affect how the application will work for its users. For example, if a workflow has several possible paths depending on a user's role or the state of a record, the client may need to confirm that those paths reflect the way the business actually operates. The developer can translate that information into an application structure, but the client remains the source of the business decisions behind it.

This is also where the effect of earlier decisions becomes more visible. A change to an approved workflow or interface may require corresponding changes to work that has already been planned. A client who initially approves a process in which users complete several steps before submitting something may later decide that the entire process should happen on one screen. Although that may appear to be a design change, it can affect how the underlying functionality needs to be implemented. The later a decision changes, the more likely it is that work depending on that decision will also need to be reconsidered.

A design approval should therefore be understood as agreement on the intended experience, not as approval of the finished application. The application still needs to be implemented and tested. At this stage, the useful outcome is that both sides have a clearer understanding of what is being built and the direction development will follow.

Building the application

Once the requirements and design provide a clear direction, development turns those decisions into working software. The development team implements the agreed functionality, connects the different parts of the application, and resolves the technical details required to make the intended workflows function in practice.

At this stage, the client is not expected to manage the implementation itself. The client's role is to provide clarification when a business rule or requirement needs further explanation and to review the work when there is something meaningful to validate. The developer is responsible for translating those decisions into the application.

That distinction matters because an approved requirement is not the same thing as completed functionality. A decision such as “managers can approve orders” still needs to be translated into the actual behavior of the application: who can perform the action, what happens when an order is approved, and how that change is reflected elsewhere in the workflow. Those implementation decisions belong to the development work, while the client remains the source of the business context needed when the intended behavior is unclear.

Development can also expose questions that were not apparent earlier. A requirement may have seemed straightforward until its interaction with another part of the application becomes clear. In those situations, the team may need the client to clarify the intended business behavior before continuing. Making that uncertainty visible is preferable to silently choosing an assumption that later turns out to be wrong.

Client review during development is therefore about keeping the implementation aligned with the agreed outcome, not directing the technical work. Feedback may confirm that a workflow behaves as expected, identify something that does not match the agreed requirement, or reveal a genuine question that needs clarification. If the client instead decides that the application should behave differently from what was previously agreed, that is a change to the requirements rather than simply a correction to the implementation.

The amount of interaction varies by project. Some parts of development can proceed without client input, while others depend on a business decision before the developer can confidently continue. The important point is that development is not a black box between approval and delivery: the software is being built from earlier decisions, and new decisions may still be needed when implementation reveals something that requires clarification.

Testing, review, and refinement

Once a working version of the application exists, it needs to be checked against what was agreed, not simply against whether the software appears to function. Testing looks for technical problems and unexpected behavior, while review gives the client an opportunity to confirm that the application actually supports the intended business workflow.

The development team can test things such as whether features behave as expected, whether different parts of the application work together correctly, and whether known requirements have been implemented. The client brings a different form of validation: they can assess the application from the perspective of the people who will use it and the business processes it is meant to support. A technically functioning application can still behave differently from what the business expected.

This distinction matters because technical testing and client acceptance answer different questions. Testing asks whether the implementation works correctly according to its defined behavior. Client review asks whether that behavior corresponds with the agreed business requirements and practical expectations. Both are needed before the application can be considered ready to move forward.

Review also needs to distinguish between a problem with the implementation and a change to what was agreed. Suppose an application contains a calculation that was explicitly defined during requirements clarification, but the completed application produces the wrong result. Correcting that calculation is a fix: the implementation does not match the agreed requirement. If the client later decides that the calculation should use a different business rule, that is a change to the requirement itself. It may be a perfectly reasonable change, but it is not the same kind of work as correcting an implementation problem.

The same distinction applies to design and workflow feedback. A client might review a completed screen and discover that an agreed interaction does not work as intended. That feedback helps identify something that needs refinement. But if the client decides that users should follow a different workflow altogether, the request may affect work that has already been designed or implemented. The developer then needs to understand the change and determine what existing work it affects before incorporating it.

This is why feedback can become more consequential as development progresses. Early decisions often provide the basis for later work. Changing one of those decisions after related screens, workflows, or functionality have already been implemented can require some of that work to be revised. A review process therefore should not treat every comment as an isolated request that can simply be added to the application without considering its dependencies.

Client involvement at this stage does not mean taking over technical testing or managing implementation. The client's role is to provide the business context needed to judge whether the resulting behavior is right. The development team remains responsible for investigating technical problems, determining how the application should be corrected, and translating confirmed requirements into changes.

The review process can also lead back to earlier decisions. Testing may expose an ambiguity that was not apparent during requirements clarification, or client review may reveal that an agreed workflow needs reconsideration. That does not make the original stages meaningless. It reflects the fact that a development process has recognizable stages without being completely rigid. The important part is to make the reason for returning to an earlier decision clear and understand what subsequent work is affected.

By the end of testing and review, both sides should have a clearer understanding of what has been validated, what problems have been corrected, and whether any remaining requests represent changes to the agreed application rather than fixes to it. That distinction provides a clearer basis for deciding what needs to happen before the application is ready for its users.

Preparing the application for launch

Completing development does not automatically mean an application is ready for users. Before release, the working application needs to be moved into its intended production environment and checked in the context in which it will actually operate. This is where development work becomes a usable application rather than simply a completed implementation.

The development team typically prepares the application for deployment, verifies that the intended production setup is in place, and addresses issues that could prevent the application from operating as expected after release. The exact work depends on the application and its operating environment, so a small internal application may require relatively little preparation while a more complex application may involve additional checks and coordination.

The client still has a role at this point, although it is different from the decisions made during requirements and design. The client may need to provide or confirm information about the intended users, operating environment, access arrangements, or other business conditions required for release. They may also need to confirm that the application is ready to be made available from a business perspective. The developer handles the technical preparation; the client confirms that the result is ready to serve its intended purpose.

This distinction matters because an application can be technically complete while something outside the implementation still prevents a successful release. A feature may have been developed and tested, for example, but the application may still need to be configured for its actual operating environment before users can access it. Deployment therefore represents a transition from building and validating the application to making it available for real use.

The process also does not necessarily end with a single irreversible release step. Depending on the project, the application may require final checks, adjustments, or validation after it has been placed in its intended environment. What counts as launch readiness therefore depends on the application's requirements and the conditions under which it will be used, rather than simply on whether the development work has been marked complete.

What happens after launch

Launch does not necessarily mark the end of the development work. Once the application is available to users, there may be issues to correct, adjustments to make, maintenance to perform, or new functionality to develop. These are different kinds of work, even though they all happen after release.

If a problem is found in functionality that was agreed and implemented, the work is generally a fix. For example, if an agreed calculation produces an incorrect result or a previously working feature does not behave as intended, correcting that implementation problem is different from changing what the application was originally supposed to do.

Post-launch requests can also involve adjustments or further development. A client may decide that an existing workflow should behave differently, or that the application should support a new type of user or process. Such a request changes or extends the application's intended behavior rather than simply correcting an implementation problem. Because it may affect existing functionality, it can require additional design, development, and testing.

There may also be ongoing maintenance as the application continues to be used. The exact nature of that work depends on the application and its operating requirements, so it should not be assumed that every project requires the same level of ongoing involvement.

The important distinction is between completing the agreed application and deciding what happens next. The original delivery establishes a working version of the application, while post-launch work addresses problems discovered in use, changes in requirements, or further needs that emerge over time. The point at which the original development engagement ends and ongoing support or further development begins depends on the arrangements for that particular project.

The process is structured, but not identical for every project

The stages of a custom web application provide a useful structure for the work, but they should not be treated as rigid phases that every project passes through in exactly the same way. A relatively simple application may require limited clarification and design before development begins, while a more complex application may need substantially more time to resolve requirements, explore workflows, review designs, and validate the finished result.

The stages can also overlap or lead back to an earlier decision. Testing may reveal that an expected behavior needs clarification. Development may expose a design detail that needs to be reconsidered. Client feedback may identify a change that affects work already completed. Iteration does not mean the process has failed; it is a normal consequence of discovering information as the application becomes more concrete.

Client involvement changes along with this work. Early stages may require more business information and decisions from the client, while development may involve more focused reviews and questions. Later, testing and acceptance require the client to confirm that the application behaves as expected for the intended business use. The client is not expected to manage the technical work, but timely answers and decisions can determine whether dependent work can continue.

The same principle applies to changes. A new requirement introduced after design or development has progressed may affect work that depends on the earlier decision. That does not make the change inappropriate, but it means the change needs to be understood in the context of what has already been established. A clear process makes these dependencies visible instead of treating every request as though it has no effect on the work around it.

The purpose of having a defined process, then, is not to make the project perfectly predictable. It is to give both sides a shared understanding of what needs to be established, reviewed, or decided as the application moves forward. The exact amount of work at each stage can vary with the application's size, complexity, and requirements, while the underlying purpose of those stages remains consistent.

FAQs

How involved does the client need to be during a custom web application project?

The client does not need to manage the technical development, but their input is needed at points where business knowledge, decisions, reviews, or approvals affect the work. The amount of involvement varies by stage and by project.

Can requirements or features change after development has started?

Yes, but a change to an agreed requirement can affect work that has already been designed or implemented, as well as work that depends on it. It is therefore different from clarifying an existing requirement or correcting a problem with agreed functionality.

Does every custom web application follow the same development process?

The major stages provide a useful framework, but the amount of work and iteration within each stage can vary. A smaller application may move through planning, design, development, and testing relatively quickly, while a more complex application may require considerably more clarification and review.

What happens if testing finds a problem?

The problem is reviewed against the agreed requirements and intended behavior. If the implementation does not meet what was agreed, it can be corrected. This is different from deciding after the fact that the application should behave differently from the original requirement.

Does approving the design mean the application is finished?

No. Design approval establishes the intended user experience and interface; the functioning application still needs to be developed, tested, and reviewed before it is ready for users.

What happens if a decision is delayed during development?

If other work depends on that decision, the dependent work may need to wait or be approached differently. This is why reviews and approvals are part of the delivery process rather than merely administrative checkpoints.

What happens after the application is launched?

Post-launch work can include fixing implementation problems, making adjustments, maintaining the application, or developing new functionality. These types of work are distinct from one another and may also be distinct from the original application delivery.

Does launching the application mean the developer's work is permanently finished?

Not necessarily. Some projects transition into ongoing support or further development, while others conclude after the agreed application has been delivered. What happens after launch depends on the needs and arrangements of the particular project.