Building infrastructure on a cloud provider can be confusing. There are lots of services on offer and it's not easy to determine the best fit for your organisation, or even if cloud services are suitable for your application.

Our web applications team has the benefit of many years actively working with large organisations and their cloud deployments, so we can guide, design and deploy a suitable cloud strategy for your application.

At our disposal are a number of tools, including Terraform for infrastructure creation and deployment, claudia.js for serverless deployments, or managed services at Heroku or DigitalOcean that we can use to house the application that you want us to create.

From the first point of contact, you will have direct access to the people who will be completing the work, no account manager, handler or sales and marketing people. You've come to us for technical expertise, not to be sold more than you require.

How we work with you to build your web application and cloud infrastructure

With so many options available, it can be difficult to know where to navigate the various cloud eco-systems. Our engineers work alongside your teams to design the right application and environment for you and your business.

Our process, based on the Agile Manifesto, follows industry best practices and aims to provide constant and consistent communication with you, the client and your business to make sure that everything is on track.

From a high level our process is as follows:

Arrow icons made by Lyolya from www.flaticon.com

More detail on each stage is provided below.

We also use the ShipIt Journal Workbook journal designed by Seth Godin as a general guide and source of inspiration.

Interaction, information and outcomes of all stages will be fully documented.

Kick-off meeting

As with all processes, this one also starts with a meeting, unfortunately. Here, we'll talk with the various project stakeholders to ensure that we understand the aims and requirements around the desired web application, storage and data capacities and company expansion plans. It's rare that this meeting determines the deployment platform and tools, but this can also be a topic of discussion. The main outcome expectation is to open channels of communication between ourselves.

The meeting can be as formal (or informal) as you like, but outcome of this initial meeting is primarily to open up channels of communication, not to come up with a finalised and signed-off design.

Requirements Gathering & Planning

Sometimes called the ‘consultants invasion’, this part of our process involves our team talking to people involved in the outcomes of the project. This doesn’t mean just the decision makers; we’ll want to talk to the people who actually do the work, those that will ultimately be affected by the implementation of the project. Sometimes this will involve building basic prototypes in order for our team to full understand the internal business processes.

The aim here is to ensure that the project proposals will provide benefit, that they meet expectations to all that will be using the work and finally that we fully understand the criteria for success. Not everyone in a business has the same view, requirements or understanding of outcomes.

Once our team has gathered and confirmed all the requirements, we’ll be able to provide an initial plan and outcomes document that feeds into the initial design stage.

Initial Design

With all the requirements and outcomes collected and an understanding of the technical constraints, we will produce an initial design.

This will be a living document for the length of the project.

As with all things, project elements can, or rather will, change; there’s a new requirement, or the focus of the business changes, or some new technical constraint comes to light, so the contents of this document will also change to match.

The initial design document will cover some or all of the following elements:

• designs:
  • application
    • user interface
    • elements and experience
    • architectural
  • hosting environment
    • architectural
    • services proposal
    • storage requirements
    • bandwidth/throughput requirements
    • initial basic costing
  • API outline
• work breakdown
• element build sequence
• technology breakdown

This document will also cover the final delivery arrangements.

The contents of this document are shared across all stakeholders to check and approve. Once this is complete, we’ll move onto development.

Development

The real work starts here. We should have everything that we need to get started.

From here the dynamic changes somewhat: we’ll build something, present it to your business, high-five..., rinse and repeat until we’re done.

Sprint 0

This is the initial project set up stage. We set up the development and staging environments, make sure that we’ve got all the frameworks and libraries we think we’re going to need.

Initial iteration length and outcome is set here and the first Show and Tell meeting is booked.

We also use Sprint 0 to double check the element build sequence given in the initial design, to ensure that everything will run smoothly.

Iterations

Our software build process is basically: build a little bit, check, build a bit more, check and change stuff, etc, until complete.

The length of each iteration is typically 2 weeks.

Build

Software and infrastructure development happens here. It’s that simple.

Show and Tells

We use the Show and Tell to demonstrate what has been achieved since the last get-together. All relevant stakeholders are invited to see how things are shaping up.

This meeting is the point where changes to the following parts of the of the process can be discussed and made:

• any part of the initial design
• iteration length
• show and tell frequency

We’ll also agree what the next set of deliverables are for the next Show and Tell and when that’s going to happen.

These meetings form part of the design document, so that changes are minuted and approved.

Delivery

Once we've built the application, deployment infrastucture and deployment process, i.e. everything is delivered as required, we’ll package or deploy the project code as specified in the design document.

As delivery is highly individual to any organisation, this needs to be determined ahead of time so that everything runs smoothly.

Sign off meeting

We’ll ask for this meeting a couple of weeks after delivery. This gives all stakeholders the chance to use the application and determine if there are any issues that need addressing or changes required.

Post-delivery support

We usually offer 4 weeks of remedial support and bug fixing for any project that we deliver. Any work outside of this time will be by negotiation only.

Our support contracts can be tailored to your exact requirements.