Dating Site "Anonymous" Development Timeline

This is my expected working timeline in the development of the Dating Site. Time frame will vary depending on the specifications of the website which will be identified during the "Requirement Analysis Phase". This shows the possible maximum length of the development. Temptative start date: May 15, 2013 The design process is based from "Following A Web Design Process" by By Luke Reimer Prepared by: Christian Gonzales


The planning stage is arguably the most important, because what’s decided and mapped here sets the stage for the entire project. This is also the stage that requires client interaction and the accompanying attention to detail.

Requirement Analysis

05/15/2013 - 05/29/2013

This phase includes the goals, the site's target audience, detailed feature requests and relevant information as you can possibly gather.

Specifications Review And Approval

05/29/2013 - 06/03/2013

This includes client goals, target audience, detailed feature requests and as much relevant information as you can possibly gather. Even if the client has carefully planned his or her website, don’t be afraid to offer useful suggestions from your experience.


The design stage typically involves moving the information outlined in the planning stage further into reality. The main deliverables are a documented site structure and, more importantly, a visual representation. Upon completion of the design phase, the website should more or less have taken shape, but for the absence of the content and special features.

Wireframe and Design Elements Planning

06/04/2013 - 06/11/2013

This is where the visual layout of the website begins to take shape. Using information gathered from the client in the planning phase, begin designing the layout using a wireframe. Pencil and paper are surprisingly helpful during this phase, although many tools are online to aid as well.

Mock-ups Based onRequirements Analysis

06/12/2013 - 06/17/2013

Designing mock-ups in Photoshop allows for relatively easy modification, it keeps the design elements organized in layers, and it primes you for slicing and coding when the time later on.

Review and Approval cycle

06/17/2013 - 06/21/2013

A cycle of reviewing, tweaking and approving the mock-ups often takes place until (ideally) both client and contractor are satisfied with the design. This is the easiest time to make changes, not after the design has been coded.

Slice and Code valid HTML5/CSS3

06/24/2013 - 06/28/2013

t’s coding time. Slice the final Photoshop mock-up, and write the HTML and CSS code for the basic design. Interactive elements and jQuery come later: for now, just get the visuals together on screen, and be sure to validate all of the code before moving on.


Development involves the bulk of the programming work, as well as loading content (whether by your team or the client’s). Keep code organized and commented, and refer constantly to the planning details as the full website takes shape. Take a strategic approach, and avoid future hassles by constantly testing as you go.

Build Development Framework.

07/01/2013 - 07/05/2013

This is when unique requirements might force you to diverge from the process. If you’re using Ruby on Rails, an ASP/PHP framework or a content management system, now is the time to implement it and get the basic engine up and running. Doing this early ensures that the server can handle the installation and set-up smoothly.

Code templates for each page type.

07/05/2013 - 07/12/2013

A website usually has several pages (e.g. home, general content, blog post, form) that can be based on templates. Creating your own templates for this purpose is good practice.

Develop and test special features and interactivity.

07/15/2013 - 07/19/2013

Here’s where the fancy elements come into play. I like to take care of this before adding the static content because the website now provides a relatively clean and uncluttered workspace. Some developers like to get forms and validation up and running at this stage as well.

Code Functions

07/20/2013 - 08/27/2013

This part way through the most difficult part of the site which require more work. There are lots of functions to be written that will identify the purpose of the site. Function may include database connection, saving and retrieving from and to the database, transactions, site's security, payment methods, messaging system etc.

Test and Verify Functionality

08/28/2013 - 09/06/2013

This is a good time for a full website review. Using your file manager as a guide, walk through every single page you’ve created—everything from the home page to the submission confirmation page—and make sure everything is in working order and that you haven’t missed anything visually or functionally.


The purpose of the launch phase is to prepare the website for public viewing. This requires final polishing of design elements, deep testing of interactivity and features and, most of all, a consideration of the user experience. An important early step in this phase is to move the website, if need be, to its permanent Web server. Testing in the production environment is important because different servers can have different features and unexpected behavior (e.g. different database host addresses).


09/09/2013 - 09/12/2013

Particularly if you’re not scrambling to meet the deadline, polishing a basically completed design can make a big difference. Here, you can identify parts of the website that could be improved in small ways. After all, you want to be as proud of this website as the client is.

Transfer to live server

09/16/2013 - 09/18/2013

This could mean transferring to a live Web server (although hopefully you’ve been testing in the production environment), “unhiding” the website or removing the “Under construction” page. Your last-minute review of the live website happens now. Be sure the client knows about this stage, and be sensitive to timing if the website is already popular.


09/19/2013 - 09/20/2013

Run the website through the final diagnostics using the available tools: code validators, broken-link checkers, website health checks, spell-checker and the like. You want to find any mistakes yourself rather than hearing complaints from the client or an end-user.


Business re-enters the picture at this point as you take care of all the little tasks related to closing the project. Packaging source files, providing instructions for use and any required training occurs at this time. Always leave the client as succinctly informed as possible, and try to predict any questions they may have. Don’t leave the project with a closed door; communicate that you’re available for future maintenance and are committed to ongoing support. If maintenance charges haven’t already been shared, establish them now.

Hand off to client


Be sure the client is satisfied with the product and that all contractual obligations have been met (refer to the project charter). A closed project should leave both you and the client satisfied, with no burned bridges.

Provide documentation and source files


Provide documentation for the website, such as a soft-copy site map and details on the framework and languages used. This will prevent any surprises for the client later on, and it will also be useful should they ever work with another Web developer.

Project close, final documentation


Get the client to sign off on the last checks, provide your contact information for support, and officially close the project. Maintain a relationship with the client, though; checking in a month down the road to make sure everything is going smoothly is often appreciated.


Maintenance to insure good functionality even after the launching