I will be writing about the familiar part of the flow, the process of starting to build the website from scratch to launch, which comes at a stage after you have validated and ensured that you’d be working on getting the website up.
- Get the idea right detailed in a 1 pager. Detail in what the service does and what its not supposed to do. StackExchange has a great example – Area51 (The Staging Zone) go through an elaborate process of where users define what are considered good & bad questions so that it clearly defines the scope
- Find and Analyse the competition. You should think about complementing the existing services or do much better than them to avoid people saying “another e-commerce website”. Companies with deep pockets spend money in capturing users and new companies without funding can drain faster trying to keep up with competition.
- The process for getting the site out live – I have seen many websites in this phase which I can explain well (both the good and the bad parts). Skipping (1) & (2) might cost you a visible hole in the financials if realised after the fact.
Since you have the functionality listed now, you’d need a lot of other things to get over.
Step 1 – Company and Domain Name:
Determining the name of the company is a challenge since you’d want the search result on Google to get your name rather than somebody else’s. Having the same domain name and company name helps for referencing (startups usually do, others dont).
This is the toughest one if you are looking for dotCom domain since most of the names you can think of are parked or already been setup, especially if you are starting another cloud based product. If you are looking for a local websites using ccTLDs (has impact on SEO), you might be in a better position to get the name you want.
Step 2 – WireFraming:
WireFraming helps you understand the essential items in each and every page that are listed along with the basic user experience of the website.
If you want a different layout for phones, ensure you cover them as well. (The wireframes would be different for phones based on the resolution).
Popular choice of tools: Balsamiq, Pen & Paper
Step 3 – UI Design:
The aesthetics and colours are decided here with dimensions of the components in each of the pages. The non-web designers who do not deal with interactions in the rich-web space do not care about hovers, dynamic content, screens when loading content, image aspect ratios, several fonts, not using default web elements (good and bad).
The most frustrating and annoying thing is they say the site looks like this for a certain text. They do not deal with what happens when text is more or less. (This ends on the neck of the HTML / CSS designer which is found when adding dynamic content to the site).
Popular choice of tools: Adobe Photoshop/Illustrator
Step 4 – Architecture of the service:
There are 2 schools of thought. Each of these have their own pros and cons
- Considering the scaling aspect before starting to code
- Scaling when required
You determine how your system looks and what services it’d depend on with basic interactions and information. Ensure your system is de-coupled and clear ownership of the services and interactions between services/servers.
Once decided, it could be good idea to determine which languages/frameworks that would be used. Having a rough estimate about monitoring would not harm the conversation.
Step 5 – Static Site:
PSD to HTML/JS/CSS Conversion is done here with basic interactions and AJAX loading of dynamic content should be mocked to get the complete workflow.
Step 6 – BackEnd:
The dynamic part of the data comes in now. You integrate with the backend (data in mysql/sqlite) to add dynamicity and display data. Well, you will find more problems here about few interactions and assumptions you made about representation of data in the frontend.
Step 7 – Others: Social Handles since you would want all of twitter, facebook, pinterest, Google+ where you expect to drive in the social traffic from.
Step 8 – Sandbox and Staging environments:
It is a good idea to setup a CI or deploy often with migrations in place to help look at the state of the system and changelogs to ensure everything works w/o manual intervention. Capistrano might help with deployments and Jenkins CI would help with making it continuous. The staging environment is usually the replica of production database to test newer versions before hitting production
Step 9 – Analytics & Monitoring:
Prior launch / going live, this is an essential part even on your staging server. At Amazon where everything is a service (mostly), there are lot of alarms. Bad alarms can be fixed, but in a situation of no alarms, its hard to figure out the state of the service(s). This is not just for backend services, FrontEnd services also require monitoring.
Sites like Pingdom offers monitoring of websites from various locations. You can setup your own tracking with Nagios for internal systems like databases or other backend services shared.
Step 10 – Production Servers:
Once you are ready, you go live with the website tested on staging. Prior launch, you would want to perform load testing to ensure you know how many users you can handle and ensure it can handle enough load. Ensure your servers are horizontally scalable for peaceful scaling up and down.
Selecting where to host the servers from a.k.a. Hosting:
Hosting depends on your target audience locations. It seems that the server response time impacts SEO. The choice of scalability options with the now popular IaaS options like AWS EC2 / RackSpace or take a PaaS like Heroku or AWS Beanstalk which scales based on pre-set parameters. Speed is all that matters for the customer to wait for your site to show up.
These are the few of the common steps required when building a website from scratch. Also note that, SEO is important too for the website to be search engine friendly.
Sairam's Blog 