1. 2. Environment requirements

Before you start developing, you need to understand the processes and technology environment for the project. Environment specifics influence many of your decisions such as the project type, hosting, backup plans, development approach, and additional software you'll need. We compiled the following questions to get you going with the types of questions to ask. 

Development team

  • How many developers are working on this project?
  • Do developers collaborate or work independently?
  • What source control system are you using?
  • Are any external resources being used for development?
  • Are the frontend and backend developed separately?

Deployment strategy

  • How often are you planning to deploy new features/code?
  • What is the acceptable downtime during deployments?
  • Are you planning on having automated deployments?

Infrastructure (dev, stg, live)

  • Are there multiple servers for load distribution?
  • Are the servers located in different geographical locations?
  • Is there any integration, testing, staging, or other environments?
  • Will content owners work in production environment directly?
  • Are you planning to use online marketing and/or e-commerce features?


  • Is hosting on-premise or in the cloud?
  • Is there a preferred hosting provider (e.g. Azure, AWS)?
  • Is the SQL server dedicated or shared? 
  • Do you require any type of auto-scaling?
  • Should the media and design assets be distributed to different geographic locations with CDN?
  • Do you need SSL for the public portion of the site?
  • What health monitoring and backup tools are in place?

Expected Traffic

  • Based on current traffic and projections, what is the expected average and peak traffic daily/monthly (e.g. unique visitors, pageviews, file downloads, etc.)?
  • What is the required maximum response time for a single page request to load? 
  • Are there different maximum response times for visitors from different geographic locations (e.g. US, APAC)?

Disaster recovery

  • What is the disaster recovery strategy?
  • How often is the database and site files backed up?
  • What are the expectations on what is recoverable?
  • What is the tolerance for time to recovery?

Here are some example scenarios to demonstrate how knowing or not knowing the answers to these questions can help or hurt your project.

  • Scenario: Client requires fast load times on a global site

    A partner was working with a client that operates a global site and required that the site would load within 1-2 seconds in every country they operate in. Because they knew that one of the biggest slowdowns to page loads in other countries are the supporting assets like images, CSS, and JavaScript, they planned to implement a CDN to load these assets.
    If they had not identified that the site needed a CDN, they might have stored the assets in ways that don't support CDNs out of the box. Additionally, they knew to configure the system to be aware of the CDN, so that the links are added properly. This avoided a costly delay in the project's go-live as they would have needed to re-link assets on the site. This resulted in a site that loaded quickly from day one.
  • Scenario: Performance issue due to on-premise hosting limitations

    The front-end developers did not pay close attention to optimization of resources like JS, CSS stylesheets and images. This led to a home page that loaded approximately 5MB of data spread across approximately 150 requests for new visitors and visitors with expired client caches. The organization hosted the site on-premise along with other mission critical services not connected to the web site. The organization had relatively limited bandwidth and the added request load from the un-optimized home page resulted in an outage not only for the website, but for the other mission critical services.
    If they considered the production environment's limitations, they could have avoided this issue by focusing more on the web site performance and considering to host this web site elsewhere. This would prevent the chain reaction from bringing down the unrelated services.
  • Scenario: Handling traffic spikes

    When discussing the traffic requirements for a project, a partner found that regular daily traffic is generally moderate to low, but the client expects significantly higher traffic once a quarter, due to a regular event. The partner used this knowledge to pitch Azure autoscaling features to keep costs lower while still providing capacity to handle these quarterly spikes. The client appreciated the partner's considerations of budget while maintaining performance year-round.