Mobile apps come in many different guises now and now no offering seems complete without a one.
Our Mobile App service can provide your business with an app where you control where your users can get it from, be that the Apple App Store, Google Play, or direct from your website. This means that you can go native if you must, but a progressive web app is the current force du jour.
The techonology choices that we have available make it possible to design and create a mobile app at the same time as we're building your website.
If native is more your thing, then using the powerful NativeScript platform, we can build one app to target both major stores.
Our process, based on industry best practices, follows a simple formula, but at the heart of it is communication with you, your business, and the people who will be using the application.
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.
Software used to be pre-specified all up front and then handed off to a software team to build, then after not hearing anything for months or years, something was delivered. Invariably, in the intervening timeframe, requirements changed, parts were left to interpretation, or just missed and the returned product was wrong.
We don’t work that way.
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:
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.
This initial meeting is where your team meets ours - this will be full of awkward intros and the obligatory presentations. We’ll use this time to discuss the high-level project aims and outcomes, and discover or storyboard out any sticky technical issues.
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.
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.
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:
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.
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.
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.
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.
Software development happens here. It’s that simple.
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:
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.
After the final Show and Tell and 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.
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.
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.