We generally follow the below process in building the application.
Building the story board
We would need to meet a couple of times to determine what to build where we would write user stories.
Below is a Wikipedia definition:
A user story is a software system requirement formulated as one or more sentences in the everyday or business language of the user. User stories are used with Agile software development methodologies for the specification of requirements (together with acceptance tests). Each user story is limited, so it fits on a small paper note card usually a 3"x5" card to ensure that it does not grow too large. The user stories should be written by the customers for a software project and are their main instrument to influence the development of the software.
Rather a simple example would help than the boring definition above:
As a moderator, I should be able to approve a comment to show it on the relevant article.
We use simple tracking solutions to deliver these stories once in two weeks. So, in effect, the entire process of the construction of software is transparent and visible to you.
UI Mockup
We first need to understand the parts of the solution that interface with the user. We then build quick sketches of the user interface to ensure that all the user interface points are well understood before we start building the solution. Also it allows us to quickly visualize the solution before it is actually built.
Design
This is where the actual application is designed. This lays the foundation of the application. Some of the more technical pieces of the puzzle are solved as smaller proof of concept projects. By the end of this phase, we would choose the architecture and tools that would be relevant to build such a solution.
Sprints
Now that we have made the preparation, it is the time to sprint. We plan on the stories to be implemented in a sprint. After the end of every sprint, we re-evaluate the priorities of the user stories we built and choose the appropriate course of action. This works really well as we celebrate the small successes and consistently hit our goals. Each delivered story can be considered finished. That means that it is tested and certified to work as defined.
Alpha launch
We can get an initial feedback from a select group of users, who are likely to accept it and use the solution. We then actively listen to their feedback and make the appropriate changes to the solution.
Beta launch
Once we are comfortable with the quality of the solution, we can then make a public release. For all practical purposes, this is the final software. Most of the edge cases that were undetected during testing would emerge here. We can then fix the priority changes to stabilize the product.
Final launch
After the launch party, we offer continued support on maintaining your servers and monitoring them for any anomalous behavior. We set up monitoring tools that would alert us of problems even before users have to report them.