Every Two Weeks, Something You Can Install
The whole process, in order, with the awkward parts included. The measure of progress on a mobile project is not a demo on our screen — it is a build sitting on your own phone that you can hand to somebody.
Mobile Punishes Anything You Leave to the End
On a web project you can ship on a Friday and patch on the Monday. A mobile release goes through a review queue, then out to people who may not update for weeks, and a bad version can sit on somebody’s phone for a long time. That single fact reorders everything.
So testing on real devices happens inside every sprint rather than in a phase at the end. Store accounts, signing and privacy declarations are set up in week one, not the week of launch. And the store listing is drafted while the app is being built, because writing it forces you to say in one sentence what the app is for — which is a useful thing to discover early rather than late.
How we test on devicesFrom First Call to a Live App You Own
Durations describe a typical first version. A bigger app stretches the middle stages; it does not change their order.
01 — Free Quote Call
Thirty to forty-five minutes, no charge, and we are not selling on it. We are working out whether what you want is buildable for the money you have, and whether mobile is genuinely the right shape for it.
What we will ask
- Where is the person standing when they open this? On a sofa, in a van, on a shop floor?
- What must the app still do when the signal drops?
- Which handsets do your users actually carry, and how old are they?
- Does this need one store or two on day one, and why?
- What system does the app have to talk to, and do you control it?
- Budget and date — which of the two is actually fixed?
What arrives afterwards
Within two business days, in writing: the features we heard, a recommendation on native versus cross-platform with the reasoning, an indicative cost range and the assumptions under it, a timeline in weeks, and an explicit list of what we would cut from version one. If we think you should not build this yet, that is in the document too. It is yours to take to another studio.
02 — UX Design and a Prototype You Can Tap
Usually two to three weeks. We map the flows first: what a person does on their first open, what they do on the fiftieth, and what happens at every point where the network, a permission or the battery can betray them. Then the screens.
You get the full screen set plus a clickable prototype installed on your own handset, not a video and not a slide deck. Hold it in one hand on a real phone, in the place the app will actually be used. Almost every project changes something here, and this is the only stage where changing it is close to free.
What sign-off fixes
Approving the prototype fixes three things: the screen inventory, the navigation structure and the user roles. Everything downstream — the estimate, the sprint plan, the QA matrix — is derived from those. After sign-off, changing what happens inside a screen stays cheap. Adding a screen, a role, a platform or an integration becomes a change request with its own estimate, and you approve the number before anything starts.
Also decided here, not later
- Which permissions the app asks for, when it asks, and what the prompt says
- What the app shows with no data, no signal and no account
- The oldest OS versions and the smallest screen we support
- Whether anything in the app has to be sold through store billing
03 — Build in Sprints, With a Real Build at the End of Each
Two-week sprints, each with a written goal agreed at the start and an installable build at the end — TestFlight on iOS, an internal testing track on Android. Not a screen recording. The actual app, on your actual phone, which you can hand to a colleague in a corridor.
Sprint one looks like the least progress and prevents the most damage
It buys project setup in your accounts, the repository, signing and provisioning, the data model, authentication, the crash reporting pipeline and one thin slice that goes from a tap all the way to the database and back. From the outside it looks like three screens. It is the sprint that stops the interesting problems arriving in month four.
By sprint four it accelerates
Features land in the order you ranked them, so anything that gets cut later is what you already said mattered least. Integrations with systems we do not control are scheduled early rather than late, because that is where the surprises live. Anything touching the camera, Bluetooth, background location or push is built and put on real hardware in the same sprint, never stubbed and left.
How change requests work
Ask for anything at any time. Small adjustments inside a screen are absorbed. Anything larger comes back within a day as a short note: what it touches, the cost, and whether it moves the launch date. You approve in writing, and only then does it enter a sprint. Nothing is ever built quietly and invoiced later.
04 — Device QA
Testing is inside every sprint, and then there is a dedicated pass before submission on the things that only break in the real world.
- Real handsets across a spread of ages, screen sizes and OS versions, not just a simulator on a fast laptop
- Throttled and dropped connections, aeroplane mode mid-action, and what happens when the network returns
- Every permission refused, then granted later from settings, which is the path most apps forget
- Interruptions a phone gets and a desktop never does: a call, a lock, a low-battery mode, the app killed in the background
- Largest accessibility text size, dark mode, and screen-reader navigation through the core flow
- Cold start time, app size and battery behaviour over a sustained session
You get a test account and are encouraged to break things. Bugs you find go on the same board we use, with a severity and an owner. Anything critical is fixed inside the current sprint rather than queued behind features.
05 — Store Submission and Review
Release is a piece of work in its own right, not an afternoon. It runs in a fixed order because each step depends on the one before it.
- Developer accounts confirmed in your company name, with the right roles for us to work under
- Signing certificates and the upload key generated and stored where you can reach them
- Privacy and data-safety declarations filled in to match what the app genuinely collects
- Listing, screenshots, icon and a first keyword pass, drafted during the build rather than the night before
- A reviewer account with working credentials and notes, because a reviewer who cannot get in rejects the app
- Submission, then a staged rollout on Android rather than everyone at once
Review is typically quick once a build is clean, but a first submission that trips a policy rule adds time, so we leave room for it in the plan instead of promising a date we do not control. Handling review feedback on what we built is our job, not a change request. Nobody can guarantee approval, and anyone who does is telling you something untrue.
06 — The Post-Launch Window
Every build includes a support window after release, agreed in the contract, during which defects in what we delivered are fixed at no charge. It is for bugs, not for new ideas: if real users reveal something you want built, it is quoted as new work.
The weeks straight after launch are the noisiest of the project. Crash reports arrive from handsets nobody owns, people use the app in an order you did not predict, and the analytics start telling you where the drop-off really is. We watch crash-free rates and the first-session funnel with you and fix what the numbers point at.
Most clients move onto a support plan when the window closes, because the platforms keep moving whether or not the app does.
See support plansWhat We Need From You
Four things. Projects almost never slip on engineering; they slip waiting for one of these.
Store account details
An Apple Developer account and a Google Play developer account in your company name, with us added as a team member. Both take longer to open than people expect, especially when a company verification step is involved, so we start this in week one rather than the week of launch.
Brand assets
Logo in a vector format, your colours and fonts with their licences, and any imagery you own. If you have none of it, say so early — we can work to a clean default and revisit branding later, but discovering there is no usable logo during icon production costs a week.
Test devices
At least one handset per platform you are launching on, ideally including the oldest phone a real user of yours would plausibly still be carrying. New flagship devices hide exactly the problems you most need to find.
Timely feedback
One named person who can decide, and who replies inside a business day. Feedback on each build within a few days of getting it. Two to four hours a week is the honest expectation, with the design fortnight heavier than the rest.
When We Are Reachable, and What Arrives Without Asking
No chasing, no wondering. These are commitments, not aspirations.
Mon–Fri
10:00–19:00 IST working hours, with calls scheduled inside them
Daily
A written update at the end of every working day: done, blocked, next
1 day
A reply to anything you send, within one business day
2 weeks
A new installable build on your phone, every fortnight without exception
How it works in practice
- One shared channel for the project, not five people emailing separately
- A board you can open any time without asking anyone for a status
- A sprint review call every fortnight, scheduled at a time that works on your clock
- Anything that moves the date or the price is raised the day we notice, not at the next meeting
- Bad news arrives early. It is always cheaper than bad news arriving on time
What we do not do
- A daily standup you are required to attend
- Live coverage outside our working hours, unless an on-call arrangement is written into a support plan
- Status reports that describe activity instead of progress
- Silence for a fortnight followed by a large reveal
- Quietly building something you asked about in passing and invoicing for it later
Responsibilities, Written Down Before We Start
Ambiguity here is where most studio relationships go wrong. Read this before you sign anything, with us or with anyone else.
Design, build and release
- Platform recommendation, architecture and technology choices
- UX flows, screen design and the clickable prototype
- App and backend development, plus the admin view you operate it from
- QA on real handsets and the release build pipeline
- Signing, submission, declarations and review correspondence
- Documentation, handover and the post-launch defect window
Decisions, accounts and content
- Approve the prototype, the scope changes and the release date
- Open and pay for the Apple and Google developer accounts
- Provide credentials for any system you or another vendor controls
- Supply logo, brand assets, final copy and your legal text
- Install each build, use it properly, and say what feels wrong
- Decide the business rules that only you can decide
Agreed in the contract
- Writing the in-app copy and the store listing text
- Migrating users and data out of an existing app into the new one
- Running the cloud infrastructure on your behalf after launch
- Ongoing store optimisation once the first listing pass is done
- Training your staff on an internal app we built for them
Things we will not pretend to do
- Guarantee store approval, which is not anyone’s to promise
- Promise install numbers, rankings or reviews
- Pay your developer account fees, paid APIs or cloud hosting
- Give legal advice or draft your privacy policy and terms
- Run paid user acquisition or handle your marketing
What Happens When an Engagement Finishes
The handover is designed so that leaving us is undramatic. That is the only honest way to ask someone to start.
What you receive
The repository with its full commit history. Signing certificates, provisioning profiles and the Android upload key. The backend, its infrastructure and its configuration. Design files in an editable format. A written handover covering how to build, sign and release the app, plus the third-party services it depends on and who pays for each.
What you already owned
The store accounts were in your company name from week one, never ours, so there is nothing to transfer and nothing we can hold. Intellectual property in the work passes to you on final payment. If you want an NDA in place before the first conversation, that is normal and we will sign one.
Then one of three things
You move onto a support plan and we keep the app current. Or your own team takes it on, and we run a handover session and answer their questions for a reasonable period. Or another studio takes over, in which case we hand over properly rather than withhold. We have been on the receiving end of the alternative and it is why this page exists.
Questions About the Process
When do I first get the app on my own phone?
You get a tappable prototype on your handset during design, before any code exists. The first real installable build lands at the end of the first build sprint, usually about two weeks after design sign-off, and there is a new one every two weeks after that. On iOS it arrives through TestFlight, on Android through an internal testing track. Early builds are deliberately thin, because the first sprint buys foundations rather than screens.
What does prototype sign-off actually lock?
It locks the screen inventory, the navigation structure and the user roles for version one. That is what makes a fixed price honest: we are quoting a defined set of screens and behaviours rather than an idea. After sign-off, changes inside a screen stay cheap, while adding a screen, a role, a platform or an integration becomes a change request with its own number that you approve before it starts. Nothing is locked forever, only locked until you decide it is worth paying to move.
How much of my time will this take?
Plan on two to four hours a week from one person who can make decisions. That covers reading the daily written update, testing each build and telling us what feels wrong, answering questions inside a business day, and a call at the end of each sprint. The design fortnight is heavier because that is where your decisions are worth most. Projects rarely slip because of engineering; they slip waiting on an approval, an account or a piece of content.
What happens if the store rejects the app?
We expect it to be possible and plan for it, and fixing a rejection on the build we delivered is our work rather than a change request. Most first-submission rejections have nothing to do with code: a missing way to delete an account, a permission string that does not explain itself, a sign-in option required by policy, a privacy answer that does not match what the app does. We design around the common ones from the first week, and if one lands anyway we respond, resubmit and keep you posted until it is live.
What do I actually walk away with at the end?
The repository with its full history, the signing keys and certificates, the Apple and Google accounts which were in your name from week one, the backend and its infrastructure, the design files, and a written handover covering how to build, sign and release the app. We also run a session with whoever is taking it on. If you move to another studio we hand over rather than withhold, and we will answer their questions for a reasonable period afterwards.
Start With the Quote Call
Forty-five minutes, no charge, and you leave with a written scope and a cost range whether or not you build it with us.