Development Process

Within our web application and development service, our process consists of 5 standard phases:


During Exploration potential clients tell us what they want to do and we engage in a conversation. During this phase, we each see if we would be a good fit. Clients “interview” us and we “interview” them. During our conversations and exploration of ideas, we determine if we want to work together. If so, then we get a good idea of what the scope of the project entails and we create a proposal. The proposal includes a preliminary time and cost estimate.


If the proposal is accepted, then we move into Discovery. We require a deposit to begin this phase. The deposit is based upon the approved proposal. In this phase, we discuss the details of the project. Depending on the overall cost/complexity, we may create a full specification, which includes “wireframes” of pages, click-through paths, and other charts outlining logic, etc.

The intention of this phase is to create a functional specification (what it should do) and a design specification (how it should look). Both are used as the blue-print according to which we build. A signed contract (“Statement of Work”) includes this specification and also outlines the development calendar (with key milestones), responsibilities, key contacts and the budget and payment terms.


Once the discovery phase is completed and the Statement of Work (with specifications) is completed and approved, we can begin development.

Development is where most of the time is spent on a project. This phase also includes design. During development there are typically a few milestones that are met:

  1. Design Comps
    This is the first of a typical 2 rounds of design. Typically 3 initial comps are created from the client interview. Then feedback and discussion generate to a final round with 1 or 2 final versions. The design process is determined by the overall budget, and may be altered according to needs.
  2. Design Approval
    After any final design changes are made, the design is approved and starts getting applied as the interface to the web application project.
  3. Alpha Version
    This is not a feature-complete application, but at least some of the design is applied to the interface. Typically, the alpha version allows the client to see the main navigation, with functioning links to main sections of the site. Also, some key functionality may be demoed. This is an opportunity for initial feedback for any areas that were not completely outlined in the specification. Some change requests may be able to be managed in the approved budget, while others may require a change order.
  4. Beta Version
    Final developed version of the project. Fully functional and integrated (application code and interface combined). There will likely be some bugs, but this is where the final product is fully reviewed with the client.


Starting in the launch phase we take any additional feedback regarding the beta version and also start addressing any bugs that were found/reported. Additionally, we start final QA testing. We’ll also begin final data migration or new data population in prepararion for launch.

The official launch (“throwing the switch”) is typically timed for an evening. Larger projects may be timed for a weekend evening to minimize down-time of any existing applications the client has that related to the new site. The final payment is due when the project launches.


After launch, we monitor the site and performance heavily for the first few days, tapering off over the next 1 - 2 weeks. We remain immediately available for any trouble, or bug reports so we can address them immediately.

After this, we may continue to provide support or maintenance depending on the client’s needs. This can be on a per hour basis, or a maintenance contract (retainer) may be created.

Additionally, we provide a 30-day “guarantee” for our projects. This means that we fix any bugs or problems without charge for 30 days after launch. This does not include new functionality. After that 30-day period, any reports of bugs or changes are addressed according to whatever maintenance terms are in place (per hour or retainer).