My Approach

What you can expect when you work with me

This page summarises my approach to web development. I hope this gives you a general sense of how I work. My workflow is, of course, adjusted to suit the context of each project.

Initial consulatation

Should we work together?

I'd like to meet with you and learn about what you need and why you need it. The goal is to figure out whether it makes sense for us to work together. Factors include:

  • The project goals and scope
  • Whether I can deliver on the scope
  • Whether the cost of my work matches your budget constraints

Requirements gathering

Let's make sure we build the right thing

It's of vital importance that I deliver a result that actually helps you: there's no glory in building the wrong website quickly and efficiently.

Here I'll meet with you, and any other relevant stakeholders, to understand, in detail, what the website needs to actually do. The outputs of these discussions and my own research will be:

  • A list of project requirements
  • User profiles: who is using this site?
  • User stories: what do these users need?
  • User journeys: what steps will users take to achieve their goals?
  • Low fidelity wireframes: an indicative sketch
  • A release strategy: what should be worked on before / after release?
  • Work defined as discrete tasks on a Kanban board

Design & build

Where I write all the code

At this stage I build the actual website.

Depending on your requirements, you may need high-fidelity (read: fancy) webpage designs. This can be done by myself, a designer of your choosing, or I can engage a designer on your behalf.

While the site is being built, I will regularly push updates to a test environment (eg. test.yoursite.com), which you may review at your lesiure. I will hold a scheduled, regular demo meeting to update you on the progress of the build.

Work-in-progress will also be visible on the project Kanban board.

Launch

Let's get this thing out the door

This is where the website goes "live" and is available for use. This activity is relatively quick and low-risk, since most of the work of setting up the infrastructure has already been done to create the test environment.

A key decision here is choosing which pages or features to complete before launching the site. Given the ease of post-launch continuous improvment (see below), I favour launching as soon as possible, so that the website can start delivering value sooner.

Continuous improvment and maintenance

Let's make it better, one step at a time

It's very common to realise, post launch, that:

  • There are features we want that we didn't anticipate
  • There are features we thought we needed, but aren't actually that important

Modern developer tooling allows us to update and re-launch the website dozens of times a day with low operational risk. This means we can continously improve the site at a steady pace, post-launch. Organising this work into small, incremental updates allows us to nimbly re-prioritise based on our evolving understanding of the project.