ABDS · Auckland, New Zealand
ABDS provides mobile app development for iOS and Android, with screens and workflows shaped around your customers or team. Start with who will use the app, the task it should make easier and any existing systems it needs to connect to.
What we can help with
Start with one task your customers or team need to complete. Define who can do it, the information involved and what a successful result looks like. A focused Free Demo can help review the direction before we agree the features and checks for a production release.
Map the steps from entry to completion, including user permissions, missing information and errors. Separate essential features from later additions. Review the proposed screens and agree what must work for the first release to be accepted.
Choose the platform approach around device needs, features and maintenance. User accounts, notifications, backend services and connections to existing systems are defined in the agreed scope.
Agree target devices, checks for the main workflows and release responsibilities before production development begins. The scope covers account ownership, any store-submission tasks and handover, with platform fees and ongoing maintenance identified separately.
Choose the right starting point
Start with what people need to do, how often they will return and the devices they use. The format should follow that task.
Discovery & first contact
A mobile-friendly website helps people find your business, compare services and enquire. Booking and checkout can also run in a browser.
Can customers complete the task through a simple link?
Repeat tasks in a browser
Consider customer accounts, order tracking or staff tools accessed through a link. Plan user roles, shared data and the systems involved.
Which tasks should people return to and manage?
An installed experience
Consider iOS and Android when an installed experience fits regular use. Check device features, release requirements and ongoing maintenance.
What does installation make more useful for the user?
Some web apps can also be installed, work offline and send notifications. Support varies by browser, device and implementation, so we check the required features before recommending an approach.
Tell us who needs to complete the task, the devices they use and which system holds the information. Describe what happens before and after the action, including who handles exceptions. You can start with a sketch or a written outline.
What the quote separates. Planning, interface design, development, integrations and testing are defined for your release. Developer accounts, hosting, external services and ongoing maintenance are identified separately. App-store review can affect the public launch date.
What you will review. Agree the main workflow, supported devices and user roles, then confirm the release checks and handover. See how project reviews and delivery work.
Based in Auckland. Working entirely online with businesses in New Zealand and around the world.
Before we start
Start with the task, frequency of use and required features. A website can support discovery and transactions, while web and mobile apps can support more involved workflows. We assess the actual devices and workflow before recommending an approach. Compare website and app options
Yes. We can scope both platforms and consider a cross-platform approach where it fits. The choice depends on device features, performance needs, integrations and the work required to maintain the app.
A focused demo explores key screens or one core workflow so you can review the direction. A complete production app, integrations, migration, platform costs and ongoing support are scoped separately.
We can scope connections to systems such as booking tools, customer accounts or stock records where the provider offers suitable, authorised access. Tell us which system holds the data, what the app needs to read or update, and who can approve access. We review API availability, permissions, data synchronisation, failure handling and any provider fees before agreeing the integration.
Yes. We can scope a minimum viable product (MVP) around one useful workflow and defer features that are not needed initially. We agree essential user roles, integrations and acceptance checks, while identifying ongoing costs and later work separately. A smaller scope still needs the security, reliability and testing appropriate to its intended use.
Before development, we agree the screens, user roles, integrations, supported devices and checks needed for your main workflows. We also identify what will be handed over and what depends on third-party services. Features outside that scope are discussed separately.
ABDS quotes each app project for its agreed scope. The main cost factors are the screens and user roles, iOS and Android requirements, integrations, data migration and testing. The quote separates design and development from platform fees, third-party subscriptions and ongoing maintenance. We can discuss a smaller first release when only part of the workflow is needed initially.
Timing depends on the agreed features, integrations and testing, plus content readiness, account access and feedback. We agree milestones and responsibilities before development. Any app-store review is a separate dependency, so a submission date is not a guaranteed public release date.
Describe who will use the app and one task they need to complete. Include the devices they use, essential screens, existing systems, any data to migrate and your preferred launch date. Sketches or example workflows are useful; a finished specification is not required for the first conversation. Share system names rather than passwords or customer records.
Before development, we agree who owns and controls developer and service accounts, who prepares and submits releases, and what code, access and documentation will be handed over. We also agree responsibility for later fixes, platform updates and feature changes. Ongoing support is scoped separately.
Connected services
