How we work
Seven stages from the first call to a supported application. Each one ends with something you can read, use or sign off, and each one lists what we need from you before it can start.
-
1
Discovery and requirements
We map the process the application has to carry, the people who will use it, the systems it must exchange data with and the constraints around it. This is where a project is made cheaper: half the ideas that arrive as requirements turn out to be a symptom of something simpler.
What we need from you: Access to the people who do the work today, and any documents, spreadsheets or systems the process currently runs on.
-
2
Technical proposal and estimate
You get a written specification with a screen inventory, the technical approach, the assumptions we are making, the stages of delivery and the cost. Nothing is committed until you have read it and agreed it.
What we need from you: One person who can approve the scope on behalf of your business, and a decision on the platforms to support.
-
3
Design
Screen designs for the agreed scope, following the conventions of each platform so the application feels familiar to the people using it. Designs are reviewed with you before any code is written against them.
What we need from you: Your brand assets if you have them, and feedback on the designs in one consolidated round rather than in pieces.
-
4
Development
The build runs in short cycles. At the end of each one you receive an installable version through TestFlight or Google Play internal testing, so progress is something you can hold rather than a percentage in a report.
What we need from you: Test users from your team, access credentials for the systems we integrate with, and any content the app has to ship with.
-
5
Testing
Functional testing against the specification, testing on the device and OS versions agreed at the start, accessibility checks and a round of testing with your own staff on real work.
What we need from you: A small group of staff willing to use the application for genuine tasks and report what does not fit.
-
6
Store publication
We prepare the listing, screenshots, privacy declarations, Data safety form and rating questionnaires, submit to Apple and Google, respond to review feedback and resubmit until the application is live.
What we need from you: Access to your developer accounts, or a decision to set them up with us, plus sign-off on the listing text.
-
7
Support
The warranty period covers defects against the specification. After that, support keeps the application current: monitoring, dependency and OS updates, store compliance and planned improvements.
What we need from you: A named contact for reporting issues, and a decision on whether to continue with a support arrangement.
How changes are agreed
Requirements change during a build, and that is normal rather than a problem. What matters is that a change is priced and agreed before it is made. Anything outside the signed specification is written up as a change request with its own estimate and its effect on the timeline, and work on it starts once you approve it in writing. Nothing is added quietly and nothing appears on an invoice you have not seen coming.
Who holds the developer accounts
We recommend that the Apple Developer Program membership and the Google Play developer account are held in your company’s name, with us added as team members. The listing, the reviews, the certificates and the relationship with the customer then stay with you, and a change of supplier does not put your published application at risk. If you do not have these accounts yet we set them up with you as part of the project. Where a client prefers a different arrangement, it is written into the contract before work starts rather than assumed.
The warranty period after release
Every project includes a warranty period after the application goes live. During it we correct, at no extra cost, any defect where the application does not behave as the agreed specification says it should. New features, changes to the specification and work caused by third-party changes outside the application sit outside the warranty and are quoted separately. The length of the warranty period and the response times that apply are set out in the contract for your project.
What happens once the warranty ends
Applications need attention after launch whether or not anything is wrong with them: operating systems change every year, store requirements are updated, certificates expire and libraries fall out of date. That work is covered by our support and maintenance service, which can start immediately after the warranty period or later, if you would rather run the application in-house first.
Ready to start?
The first stage is a conversation. Tell us about the process the app has to carry and who will be using it.
Request a consultation