Mobile app development An app people open in week two.
iOS and Android, built by the team that ships council finance platforms and marketplace consoles. Your developer accounts, your source code, and the store submission treated as a deliverable rather than a surprise.
Our shipped mobile work is a mobile-first web app for field teams · We have no published store listing of our own, and you will hear that on the first call · Public-sector clients are named by sector and jurisdiction only
Seven ways an app
project goes wrong.
Almost none of these are engineering problems. They are decisions taken early, quietly, by nobody in particular — and each one is cheap to fix in the first week and expensive to fix in the last one.
The app was the answer before anyone asked the question
A large share of the briefs that arrive asking for an app describe a job a mobile website already does. An icon on a home screen is not a strategy, and it is the most expensive way to publish a booking form.
- Would a customer install this, or use it once?
- Is there a reason it has to work with no signal?
- Does it need the camera, the location or the notifications?
Two platforms, quietly costed as one
iOS and Android are two products with two review processes, two device matrices and two release cadences. A budget drawn for one and spent on two is where most app projects lose their contingency.
- Two store accounts to hold and pay for
- Two review queues, each with its own timing
- Two sets of devices that have to be tested on
Store review is a gate, and nobody scheduled it
Both stores can reject a submission, and both do it for reasons that are procedural rather than technical. A finished build is not a released app, and the gap between the two is where launch dates go.
- A rejection sends you back into the queue
- Some categories need paperwork before a human even looks
- The launch email was written for a date nobody controlled
Nobody owns the developer accounts
The Apple Developer Program enrolment and the Google Play developer account are the legal home of your app. When they sit in an agency's name, the app does too, and the day you leave becomes a transfer negotiation.
- Whose company is the enrolment in?
- Who holds the signing keys?
- What happens to the listing if the developer disappears?
Releasing is not deploying
A website ships when you push it. An app ships when a reviewer agrees, then trickles out to people who have to choose to update. Two versions of your app are live at once for weeks, and one of them is talking to the same systems.
- Old versions keep calling your servers
- A bug fixed today reaches some people next month
- Anything that breaks old clients breaks real customers
Push notifications were treated as a channel, not a permission
Notifications are the one durable reason to have an app at all, and they are gated behind a prompt that a person can refuse once and never see again. Asking badly on first launch costs you the channel permanently.
- The prompt appeared before there was any reason to say yes
- Turning it back on means finding a settings screen
- The people who declined are invisible in the reporting
Nobody counted the second week
Installs are the easiest number to move and the least useful one to own. What decides whether an app was worth building is how many people open it again seven days later, and that number is usually measured only after it has already gone wrong.
- An install is a download, not a customer
- The drop-off happens in the first session, not the first month
- Nothing was instrumented, so nobody can say where
Native, or one codebase for both?
This is the choice that sets your cost, your hiring and how the product feels, and it is usually made by whoever is in the room. Here is what actually differs, so you can make it on purpose.
- What you are decidingBuilt for each platformOne codebase, both stores
How it is built
Two codebases, each written in the platform's own language and tools.
One codebase compiled to both stores, with platform-specific code where it matters.
What it costs to keep going
Two teams' worth of maintenance, or one team doing everything twice.
One maintenance stream, plus the occasional platform-specific fix.
Access to new device features
Available the day the platform ships them.
Available when the shared framework catches up, which is usually months.
How it feels to use
Indistinguishable from the operating system, because it is the operating system.
Very close on most screens, and noticeably not on animation-heavy ones.
Who can maintain it in three years
Two specialist hires, or one contractor per platform.
A team that already writes the same language as your web front end.
When it is the wrong call
When the app is a form, a catalogue and a login, and the budget only stretches once.
When the whole product is the interaction — a camera tool, a game, an audio product.
And there is a third answer we give more often than either.
Build a mobile website. It reaches everybody with no install step, it is findable in search in a way an app never is, it ships without a review queue, and it updates the moment you decide to. If your product is a form, a catalogue and a login, that is not a compromise — it is the better build, and we have a whole practice for it.
An app earns its place on three things:
- It has to keep working when the signal drops
- It needs the camera, the location or the sensors
- Notifications are a reason people want, not a channel you want
If none of those three is true for you, we will say so in the first meeting.
FixCare · NSW
8
Weeks, greenfield to live
Customer portal, a mobile-first app for tradies and an admin console
Major Victorian council · finance
14
Weeks, build to user acceptance
Eight modules on one auditable data model
Regional Victorian shire · ERP
8 of 9
Incumbent vendors retired
Designed scope includes offline-capable mobile field apps
These are custom platform engagements, dated in each engagement record, and public-sector clients are identified by sector and jurisdiction only. None of them is a published App Store or Google Play listing — SoudCoh has no store app of its own to point to, and no install or retention figure appears anywhere on this site.
Ten things happen on every app build. Here they are, in order.
The first one is whether you should have an app. It is genuinely first, and it is the step that saves the most money.
Decide whether it should be an app at all
The first meeting is about whether you need one. If the honest answer is a mobile website, we will say so, and the conversation gets much shorter and much cheaper.
- What does the phone do that a browser cannot?
- Will somebody install this, or only use it once?
- Who is going to open it in week two?
Write down what has to work with no signal
Offline behaviour is an architectural decision, not a feature you add later. Field teams lose reception, and what the app does in that minute is the difference between a tool and a frustration.
- What can be read when there is no connection
- What can be created, and what happens when two people edit it
- What is queued, and how the person knows it has not sent yet
Design for a thumb, not a mouse
A phone is held in one hand, in daylight, by somebody standing up. Targets are sized for a thumb, the primary action sits where a thumb reaches, and text stays readable in a car park.
- The main action is inside the bottom third of the screen
- Nothing important depends on a hover state
- It still works at the largest system text size
Choose the stack for whoever maintains it next
The same rule our platform team applies to servers applies here: mainstream, unexciting technology that somebody who has never met us can pick up. A framework nobody else hires for is a dependency on individuals wearing the word innovation.
- Native where the product is the interaction
- A shared codebase where the product is the workflow
- Written down with the reasons, so the choice can be revisited
Build the account and identity model first
Sign-in, roles and what happens when somebody changes phones are decided before the screens. Retrofitting an account model into a shipped app means asking every existing user to do something, which many of them will not.
- How a person proves who they are
- What they can see, and what they can change
- How they delete their account, which both stores now require
Decide what the app is allowed to know
Every permission the app requests has to be justified to a reviewer and to the person tapping allow. Asking for less is both a compliance position and a conversion one.
- Location only while the app is open, unless there is a real reason
- Camera and photo access explained at the moment it is needed
- Every data type declared, because the stores publish that list
Put it on real devices early
Simulators are honest about layout and dishonest about everything else. Test builds go to real phones in real hands during the build, not in a testing phase bolted on at the end.
- Old devices as well as the newest one
- The screen sizes your own customers actually carry
- Battery, heat and a bad connection, on purpose
Instrument the events before the launch, not after it
The measurement plan is written while the screens are being built, because an event you did not add cannot be backfilled. This is the work most app projects postpone and then cannot recover.
- The three actions that mean the app worked
- The step where people are most likely to leave
- Agreed with you in plain English before anything is coded
Treat store review as a deliverable
Listing copy, screenshots, the privacy declarations, the age rating and the reviewer notes are built during the project rather than assembled the night before submission. Most rejections are for things that were knowable in week one.
- Every declared data type matched to something the app really does
- A test account that works, with credentials the reviewer can use
- A written note explaining anything a reviewer would otherwise guess at
Plan the second release before the first one lands
The first version is a hypothesis. What matters is how quickly the second one can answer what the first one taught you, and whether anybody is watching closely enough to notice.
- A support path for the reviews people leave on the listing
- A release rhythm agreed up front, not improvised
- Someone named as responsible for reading the numbers
You hold it in your hand every week.
- Discovery
App, website, or neither
What the phone is genuinely needed for, who opens it and how often, what has to work offline, and what the app must talk to. This is also where we tell you if the answer is a mobile website instead.
- Architecture
Stack, accounts and identity
Native or shared codebase with the reasoning written down, the account and permissions model, the store accounts in your name, and the list of data the app will declare. Agreed before any screen is built.
- Design
Flows on a phone, not a slide
The three or four journeys that carry the product, drawn at phone size and walked through on a device. Accessibility is specified here — text scaling, contrast and screen-reader labelling — rather than repaired after review.
- Build
Test builds on real phones every week
Working software distributed to real devices on a weekly rhythm, so feedback comes from people using it rather than from a document about it. Measurement events go in as the screens go in.
- Store readiness
The submission package
Listing copy, screenshots at every required size, privacy declarations, age rating, reviewer test account and release notes. Prepared as a deliverable with a date, because review is a queue and a queue is not a promise.
- Launch and after
Release, watch, and ship again
A staged release where the platform allows it, the measurement checked against the store consoles in the first week, and a second release already scoped. Reviews on the listing get answered by a person.
We do not publish a duration for an app on this page, and the reason is the store queue: a timeline that ignores a gate neither of us controls is a timeline designed to slip. Scope, budget and the definition of done are agreed in writing before the first sprint instead.
A finished build is not a released app.
Eight things stand between the two, and every one of them is knowable before development starts. This is the part of an app project that is least like building a website.
Two developer accounts, in your company's name
An Apple Developer Program enrolment and a Google Play developer account, both held by your business, both paid by your business. Google Play also requires identity verification of the account holder before anything can be published.
A privacy declaration you have to be able to defend
Apple's privacy labels and Google's Data safety form both ask what you collect, why, and who you share it with. They are published on your listing, and they must match what the app actually does — including anything a third-party tool inside it does on your behalf.
Account deletion, in the app
If people can create an account in your app, both stores expect them to be able to delete it from inside the app as well. It is a common late-stage rejection, and it is an architecture question rather than a screen.
A reviewer who needs to get in
Anything behind a login has to be reachable by a human reviewer with a working test account. Apps gated by a client code, a paid subscription or a physical device are where submissions stall the longest.
The listing itself is a search surface
The name, the subtitle and the description are how people find you inside the store, and screenshots are what decide whether they tap install. They are written as marketing assets rather than filled in from the project brief at the last minute.
Age rating and category, declared honestly
Both stores run a content questionnaire that produces a rating. Overstating or understating it is a rejection in one direction and a restricted audience in the other, and changing it later can reset parts of the listing.
Payments, if money changes hands inside the app
Selling digital goods or subscriptions inside an app generally means using the platform's own payment system and paying its commission. That has to be in the business case before the build, not discovered during review.
The update path, which never ends
Operating systems get a major release every year and the stores follow with new requirements. An app with no maintenance arrangement will eventually stop being distributable, which is why we quote the year after launch alongside the build.
Once it is live, the store console becomes one of three places your install numbers live, and the three will not agree. That argument has its own page, because it is the part of app work that costs people the most money after launch.
What we can show you, and what we cannot.
Most agency pages answer this question by not asking it. Ours asks it in the middle of the page, because the alternative is letting a photograph of a phone imply something that is not true.
What we have shipped for phones
A mobile-first app for field teams, built as a web app rather than a store download.
FixCare's tradies work from a mobile-first app with photo capture on the job, while the dispatch team works from a console built for a desk. It went from Excel, WhatsApp and paper job sheets to live in eight weeks.
- Two audiences, two interfaces, one system underneath
- Photo capture on site, tied to the job it belongs to
- It is a web app, and we would rather name that than blur it
What we have designed but not yet shipped to a store
Offline-capable mobile field apps, inside a larger platform programme.
A regional Victorian shire council's ten-module ERP includes offline-capable mobile field apps in its designed scope, as part of a phased eighteen-month delivery. Designed scope is not a released product, and this page will not present it as one.
- Part of a programme that retires eight of nine incumbent systems
- Delivered in phases, starting with a free working prototype
- Public-sector clients are named by sector and jurisdiction only
What we cannot point you at
We have no published App Store or Google Play listing of our own to show you.
There is no install count, no retention curve and no store case study on this site, because there is not one to publish. If that is the deciding factor for you, it should be, and there are studios who can show you one.
- No shipped store listing, and no number derived from one
- What we can show is platform work, in depth, with sources
- You will hear this on the first call as well as read it here
The accounts and the code stay yours
Your developer accounts, your signing keys, your source code.
The same ownership posture our platform work carries applies to an app build. Source-code escrow is lodged from the first sprint rather than at go-live, and the store enrolments are created in your company's name from the beginning.
- Enrolments in your name, not ours
- Escrow lodged from week one, held by an independent party
- A data exit with a notice period and an agreed format
Accessibility is scoped, not assumed
It is written into the brief, in the same way it is on our public-sector work.
WCAG 2.2 AA is a stated requirement on the platform engagements this team delivers, and the equivalent thinking on a phone is text scaling, contrast, target size and screen-reader labelling. It is specified at design, because retrofitting it into a shipped app is a rebuild.
- Readable at the largest system text size
- Every control reachable and labelled for a screen reader
- Checked on a device, not asserted in a document
We will tell you to build a website instead
When that is the honest answer, which it often is.
If the product is a form, a catalogue and a login, a well-built mobile website reaches everyone, costs less, ships without a review queue and updates the moment you say so. That is a better outcome and a much better reference.
- No install step between a person and the thing they want
- Findable in search, which an app is not
- One release path instead of two, plus a queue
An app build leans on two of the six stages.
Compound is how our team works on any engagement — six stages every change passes through. Shipping to a device somebody else owns puts most of the weight on these two.
Mandate
You set the number before we spend the money.
Scope, budget and the definition of done are agreed and written down before the first sprint — including which platforms are in scope, who holds the store accounts and what the year after launch costs. An app project that discovers its second platform halfway through has already lost its contingency.
Countersign
Nothing reaches a store with one name on it.
Release builds, permission changes and store submissions are checked by a second person before they go. A web page shipped in error is fixed in minutes; a released app version lives on people's phones until they choose to update, which makes the review before the release the cheapest one available.
Four builds. Four real numbers.
These are platform engagements rather than store releases, and they are here because they are what this team has actually delivered. Two of them are government work, so they are named by sector and jurisdiction only.
- Property maintenance · NSW8weeks, greenfield to liveCustomer portal, a mobile-first app for tradies and an admin console · replaced Excel, WhatsApp and paperFixCare
- Local government · Victoria14weeks, build to UATAn eight-module finance platform on one auditable data model · 100% compliance against 194 published requirementsMajor Victorian council
- Local government · Victoria8 of 9incumbent vendors retiredA ten-module ERP whose designed scope includes offline-capable mobile field appsRegional Victorian shire council
- Marketplace · Technology3 → 1SaaS tools consolidatedOne operations console with vendor onboarding, listings, lead routing and an assistant the team uses dailyMsaha
Before you brief anybody
Here is what everybody asks first.
Apps, answered.
Native versus shared, whether you need an app at all, who owns the store accounts, what actually gets a submission rejected, and what happens in the year after launch.
The first call is free and there is no deck.
Book a scoping callYes, and we scope them as two products rather than one, because that is what they are: two review processes, two device matrices and two release cadences. Where the product is a workflow rather than an interaction we will usually recommend a single shared codebase compiled to both stores, which is one maintenance stream instead of two. Where the product is the interaction — a camera tool, an audio product, anything animation-heavy — building for each platform in its own language is the honest answer and we will price it that way.
Not one we can show you. Our shipped mobile work is a mobile-first web app for field teams — FixCare's tradies capture photos on the job while the dispatch team works from a console built for a desk — and offline-capable mobile field apps sit inside the designed scope of a regional Victorian shire council's ERP programme. There is no store listing, no install count and no retention curve on this site because there is not one to publish. If a released store app is the deciding factor for your project, it should be, and we would rather say so on the first call than after you have paid for discovery.
Start with what the phone is genuinely needed for. If the app has to work with no signal, use the camera or the location, or send notifications people actually want, an app earns its place. If it is a form, a catalogue and a login, a well-built mobile website reaches everybody, is findable in search, ships without a review queue and updates the moment you say so. A meaningful share of the briefs that reach us asking for an app describe the second case, and the first meeting is where we say that.
It is scoped per engagement and the scope is written before anything is committed, in the same way our platform work is. What we will not do is quote a duration on this page: an app's timeline includes a store review queue that neither of us controls, and a date that ignores that is a date designed to be missed. For a sense of how this team works to a plan, a property maintenance platform went from Excel, WhatsApp and paper job sheets to live in eight weeks, and a major Victorian council's eight-module finance platform reached user acceptance testing in fourteen.
You do, from the beginning. The Apple Developer Program enrolment and the Google Play developer account are created in your company's name rather than ours, which matters because those accounts are the legal home of your listing. Source-code escrow is lodged from the first sprint rather than at go-live, and the data exit has a written notice period and an agreed export format. Leaving should be a project with a date on it, not a negotiation you enter from a weak position.
Most rejections are procedural rather than technical, and most of them were knowable in week one. A reviewer who cannot get past your login. Privacy declarations that do not match what the app does, including what a third-party tool inside it does on your behalf. No way for a person to delete their account from inside the app. A permission requested with no visible reason. Selling digital goods outside the platform's payment system. We build the submission package as a deliverable during the project for exactly this reason.
Two things you have to plan for. Operating systems get a major release every year and the stores follow with new requirements, so an app with no maintenance arrangement eventually stops being distributable — we quote the year after launch alongside the build. And releases are not deployments: old versions stay on people's phones until they choose to update, so anything that breaks an old client breaks a real customer. A release rhythm and a person named as responsible for reading the numbers are part of the handover, not an afterthought.
Yes, and this is where the platform team's work carries over directly. Two-way integrations with ERPs, payroll, CRM, accounting and payment systems are routine on our platform engagements — a council finance platform runs two-way sync with Oracle Fusion and Aurion or Workday. What we insist on is naming, up front, which direction each field flows and what happens when both sides change, because that is where integrations actually fail rather than where they are expected to.
By deciding, before anything is coded, which three actions mean it worked, and instrumenting those as the screens are built. An event you did not add cannot be backfilled, which is why measurement is a build activity here rather than a launch one. Expect the store console, the ad platform and your own database to disagree about how many installs you got — that is normal and it has causes, and we have written the whole of that argument out on the app install tracking page.
Yes, and it is a large part of what this team does. Those engagements are presented by sector and jurisdiction only, which is a policy we apply to every reference, page and asset on this site. Field tooling is a recurring theme in them: a regional Victorian shire council's ten-module ERP includes offline-capable mobile field apps in its designed scope, and the intake, triage and dispatch work behind those crews is the part that has to be right first.
Text that stays readable at the largest system size, contrast that survives daylight, targets a thumb can hit, and every control reachable and labelled for a screen reader. It is specified at design and checked on a device, because retrofitting it into a shipped app is a rebuild wearing a smaller word. WCAG 2.2 AA is a stated requirement on the public-sector platforms this team delivers, and the same thinking is what we bring to a phone.
Often, yes, and the first question is whether the accounts and the signing keys are actually yours — if they are not, that is the problem to solve before any code is read. From there we assess the codebase, the dependencies and how far behind the platform requirements it has fallen, then come back with an honest answer, including when a rebuild costs less than a rescue. What we will not do is inherit an unsupportable codebase and discover that six months later with you paying for the discovery.
An app is rarely the only piece.
Most of these engagements sit alongside two or three of the following. If you are not sure which order to do them in, that is exactly what the first call is for.
- Custom web app developmentThe platform half — marketplaces, council systems and operations tools, with the hosting, escrow and whole-of-life costing written out in full.
- App install tracking and attributionWhy the store console, the ad platform and your own database never agree on how many installs you got, and what to do about it.
- Website designThe answer when the honest recommendation is a mobile website rather than an app, which is more often than the brief expects.
- The technology division behind these buildsThe engineering team, the stack choices, the escrow and support terms, and the five platforms it has delivered.
- AI systems and automationWhat an assistant inside a product is honestly good at, and where it should never be the last step before a person.
- Council and agency workHow we work with the public sector, including the offline-capable field tooling designed inside those programmes.
- Measuring what a product does once it is liveThe wider measurement practice this sits inside. A product nobody measures is a product nobody can improve.
- Filling it with customers after launchDemand for the thing you have built, and an honest account of which channel paid for itself.
- Turning visits into sign-upsThe page that has to convince somebody to install in the first place, and the form that decides whether they finish.
- Platforms we have built and written upGreenfield-to-live timelines, what replaced what, and what the operational change was worth once it shipped.
Two briefings are worth the time before you commission anything: why designing for accessibility improves the product rather than restricting it, and how to decide what to hire for and what to buy in.
Tell us what the phone is for
Describe who opens it, how often, and what has to work when the signal drops. We will tell you whether it is an app, a mobile website or neither, and put a written scope against whichever it is.
No pitch deck. A real conversation, and an honest answer about app versus website.