Custom software is usually the right answer for a narrow band of problems and the wrong answer either side of it. Before scoping a build we establish whether an existing product, properly configured, would solve the problem for a fraction of the cost. Where it would, we say so. Where a custom application genuinely is the answer, the reasons are written down so that the decision can be defended later.
Platform choice follows the users rather than fashion. Where an organisation needs both iOS and Android and the application is not graphics-intensive, Flutter delivers a single codebase without a meaningful compromise. Where deep platform integration matters, native Swift or Kotlin is the right choice and we will say so even though it costs more.
The lifecycle is documented and followed rather than improvised. Requirements are written and agreed, the design is reviewed before implementation, testing is defined alongside the requirements rather than invented at the end, and releases go through the same process every time. This is unremarkable practice in a large organisation and unusual in a small one, which is precisely why it is worth stating.
What is included
Requirements and acceptance criteria
Written specifications with testable acceptance criteria agreed before implementation, so 'finished' is a fact rather than an opinion.
Architecture and data design
Documented system and data architecture, including how the application will integrate with what you already run.
Implementation
Native or cross-platform development in reviewable increments, with source control and code review throughout.
Testing
Automated tests written alongside the code, plus functional testing against the agreed acceptance criteria, with results shared.
Store submission
Preparation and submission to the Apple App Store and Google Play, including the review requirements that commonly cause rejection.
Hand-over
Source code, build instructions, architecture documentation and a walkthrough with whoever will maintain it.
How it is delivered
- Requirements are agreed and signed before implementation starts. Where a requirement is discovered mid-build, it is quoted as a change rather than silently absorbed or silently dropped.
- Testing is specified at the same time as the requirement it verifies, which is the only reliable way to prevent tests being written to match whatever the code happens to do.
- Releases follow a documented process, so the same steps run every time and a release can be repeated or rolled back.
What you receive
- Application binaries and store listings, published under your developer accounts
- Full source code in a repository under your organisation
- Architecture and data model documentation
- Automated test suite and the results of the final test run
- Deployment and release runbook
- Thirty days of defect correction after release at no charge
What is not included
Stated plainly, because unstated exclusions are where disputes begin.
- Apple and Google developer programme fees, which are paid by you directly
- Ongoing feature development after hand-over, unless a support agreement is in place
- Backend infrastructure running costs, which are billed to your own cloud account
- App store optimisation and user acquisition campaigns
Common questions
Native or cross-platform?
It depends on what the application does. Cross-platform with Flutter is usually the economical choice for business applications that are not graphics-intensive. Native Swift or Kotlin is warranted where deep platform integration, performance or platform-specific hardware access matters. We make a recommendation with reasons rather than a default.
What happens if the app is rejected by the store?
Resolving review rejections is included. We prepare submissions against the current review guidelines, which removes most of the common causes, but reviewers do vary and we deal with it when it happens.