How long does it take to build a digital product?
After feature requests and budget, the number one topic of conversation before we embark on a project with a new client is timeframes. How long will it take? How quickly can you deliver this? Can you do it quicker than that? (we love this one đ)
In this post, weâll dig into the typical process for a digital product build and the stages youâll go through along the way, to give you a feel for how long a project might take.
Digital product development timeframes
As weâll set out throughout this post, it can be difficult to put a fixed timeframe on digital product development, because it depends on a lot of factors. But – there is one approach which gives developers (like us) and clients (like you) the visibility, control and flexibility to create, launch and develop something without unnecessary delays.
Agile digital product development
Agile is a project management approach which breaks down development into iterative, feature-based chunks. Essentially, development is completed in relatively short, pre-defined timeframes which focus on delivering a particular set of features in each chunk (known as a âsprintâ). Agile sprints enable you to make rapid improvements and iterations to a product over a relatively short period of time and without having to delay a release.
How long is a development sprint?
How much time a development sprint consists of will vary depending on the studio/agency youâre working with, how they define a sprint and how they chunk up sprint time. It could also be influenced by the complexity of the product and your internal processes/timeframes. Project timelines and approaches will always vary from client to client and will be dependent on overall project goals.
Understanding scope and complexity through discovery
We always start the digital product process with discovery. Discovery involves a focused period of research and discussion into the requirements and key objectives of the project. Itâs an incredibly important part of the process in helping you to define a sprint backlog, timeframes and key milestones and ensure the project sets off on the right path.
At the end of discovery youâll usually have some documentation which sets out:
- Objectives and goals for the project
- Primary users (internal and external) and tasks they need to complete
- Key features and functionality
- Definition of a âminimum viable productâ (MVP) – what basic features your product needs to have to enable early adoption and validation of your idea
- Platforms/technologies/technical stack to be employed and the reasons for selecting these
- Any third-party software or plugins that need to be included/integrated with and some exploration of how this will function
- A roadmap/project timeframe with key milestones that sets out what will aim to work towards in each development sprint
Planning
Each digital product sprint starts with a focused period of planning. There is some slight crossover here with discovery, but involves taking the overarching objectives of the project and using them to decide on the main goal for each sprint, and the steps for getting there. All of this will be distilled by your project manager and product lead into a clear plan of what work will be undertaken across the sprint, and usually logged in whichever software or platform being used to run and track progress on the project (we use Monday.com). Once this has been communicated and agreed upon, work can begin.
Design and user experience
Once youâve defined what it is your product needs to do and help your users to achieve, itâs time to begin scoping out how it will look and behave. The design phase is the first step in bringing what was discussed and set out in the discovery sprint to life. A typical process for a design sprint might look like the following:
- Create rough sketches and lo-fi wireframes to visualise possible experiences and journeys
- Develop interactive prototypes which demonstrate the look and feel as well as interactive elements and the flow of each user story – these can be made available for user testing as well as for internal sign off
- Review against accessibility principles and standards in order to ensure that these are instilled and incorporated at the design stage
- Establish a design system and the prototypes in such a way that they can be effortlessly iterated on in future versions based on user and stakeholder feedback, whilst ensuring visual consistency is maintained
Development phase
Once designs/prototypes have been developed and agreed on, itâs time to bring these to life in the development phase of a sprint.The development involves working through key user stories, building and releasing functionality in priority order as set out and agreed upon in the discovery phase. As discussed earlier in this post, usually in a digital product build the first development sprint(s) will focus on delivering a minimum viable product (MVP) with the fundamental features and functionality needed to launch and begin testing with stakeholders and users. Ongoing testing and feedback will then be collated to continue feeding into subsequent development phases in future sprints.
Internal quality assurance (QA)
When weâre working on a digital product, our internal testing processes run throughout the development phase of a sprint. We use several automated techniques and measures to continually check the stability of the product as we build. We also dedicate time as part of the development face to do internal quality assurance – this involves checking the âliveâ product (in a staging environment) against designs/prototypes as well as testing key functionality, and addressing any issues before it is sent over to the client for testing.
User testing and feedback
A vital part of the digital product build process is collecting feedback from core users and stakeholders. This is the idea behind an iterative approach organised into agile sprints – that the experience is continually refined and improved to effectively meet user needs. Weâll usually agree with the client as part of sprint planning how much time will be dedicated to user acceptance testing (UAT). A variety of tools will be employed to help us with UAT – including Google Analytics and HotJar – and weâll also look to conduct A/B tests where appropriate to find the best approach.
Typical user testing might look like the following:
- Define best ways to validate and test assumptions utilising video-based testing sessions, surveys and data analysis
- Incorporate any key user feedback into the backlog for future development sprints
- Ensure that each release meets agreed-upon acceptance criteria for each user story
Iterative development
As weâve mentioned throughout this post, the core ideology behind an agile sprint approach is that your product can be developed in iterations, enabling you to prioritise key features and incorporate user feedback into phased releases. Features are prioritised and a development backlog maintained in order to ensure that time is used as effectively as possible in each sprint. An agile approach means that digital product development could be theoretically âendlessâ – your product will be live and providing value to your users and your organisation, but development and iterative improvement will continue indefinitely. Because of the nature of the approach, once you have an MVP in place, you have the control and the flexibility to stop and start this cycle as and when you need, as long as basic acceptance criteria is met.
So how long does it take to build a digital product?
The truth is, as weâve set out in this post – there isnât a simple answer to that question. It depends on a lot of factors, and it also depends on when/how you consider a digital product to be âfinishedâ. A digital product may never truly be âfinishedâ – and nor should it be. Continuous improvement is key to ensuring your product continues to meet the ever-changing needs of your users and adapt to the evolving requirements of your organisation.
Need some guidance on how your digital product project or idea? Get in touch and weâll talk through your needs and our approach.