Accounts in your name, from the start
Apple Developer and Google Play Console registered to your business, with you as the owner and me added as a member. If they already exist in someone else's name, the transfer happens before anything else does.
CASE STUDY
Example buildApp LaunchGetting an App Through Both Stores
The two or three weeks between the app being finished and people being able to install it — rejections, signing keys, store listings and the paperwork.
- Type
- Publishing + consulting
- Build time
- 3–5 weeks
- Platforms
- App Store, Google Play
- You own
- Accounts and keys
This is an example build. Tavzuran is a new studio with no client work to show yet. This page describes how the project would be scoped and built — the same thinking you would get on a real one. Nothing here is a past client, and no number on this page is a result.
The price follows the feature list. The number above buys everything scoped on this page. Take features out and it comes down — the shortest route to a smaller number is a shorter list, and deciding what to drop is what the free call is for.
THE SITUATION
What's actually broken.
The build is done. It works on the phone in your hand. And that turns out to be somewhere around three quarters of the journey, because both stores sit between the finished app and anyone installing it, and each has a review process with opinions of its own.
This is where a lot of first apps stall for weeks. Not on code — on an Apple rejection quoting a guideline number, a Google data safety form nobody knows how to answer truthfully, a certificate that expired, or a keystore that belonged to a developer who has moved on.
It is also where an expensive mistake gets made quietly: the developer publishes under their own account because it is faster. The app is then not yours in any way that matters, and moving it later is a negotiation.
The app is finished and has been rejected twice with no clear reason
Nobody is sure which account or key the last developer used
The privacy policy and the data safety form disagree with each other
Screenshots, ratings and descriptions were left to the last day
VERSION ONE
What we'd build first.
Every item here earns its place by being something a real user would miss on day one.
A pre-submission review
The app checked against the guidelines that actually cause rejections — account deletion, permission prompts that explain themselves, sign-in with Apple where required, payment rules for whatever you sell, and whether there is enough here for Apple to consider it an app at all.
Keys and certificates, held by you
Android upload and signing keys generated and backed up somewhere you control. Apple certificates and provisioning set up so they can be renewed without me. Written down, because in two years nobody remembers.
The store listing
Screenshots at the sizes each store demands, a description written for someone deciding whether to install, the content and age ratings answered honestly, and a data safety declaration that matches what the app sends.
Submission, and the replies
The upload, the review notes, the demo account reviewers need, and — when a rejection arrives — the reply. Most are answered rather than rebuilt, and knowing which is which is the job.
DELIBERATELY NOT IN V1
What we'd leave out.
Not because these are bad ideas. Because each one is designed better once the first version has told you something.
- Building the app. This is the publishing half; if the app also needs work, that is scoped separately.
- Paid user acquisition and store-listing experiments. Get it live first, then find out what people search for.
- Promises about review timing. Neither store publishes one, and anyone who guarantees a date is guessing.
UNDER THE HOOD
How it's put together.
- Apple
- Developer Program membership, App Store Connect, TestFlight for the build reviewers and you both test.
- Play Console, Play App Signing, and closed testing where the account's age requires it.
- Builds
- Signed release builds produced from a repository rather than a laptop, so the next one is reproducible.
- Paperwork
- Privacy policy hosted at a stable URL, data safety and nutrition labels filled from what the app actually sends.
- Handover
- A short document: where every account and key lives, and how to ship the next version.
HOW IT RUNS
Week by week.
-
01
Week 1
Accounts, keys, the pre-submission review, and fixing whatever that review finds.
-
02
Weeks 2–3
Listing, screenshots, ratings, privacy paperwork, and submission to both stores.
-
03
Then
Answering reviewers. Apple usually replies within a day or two; Google's closed-testing window, where it applies, is a fortnight and cannot be shortened.
THE HARD PART
The rejection loop is the whole cost
Every build has one problem that decides whether the rest of it matters. This is that problem, written out.
A store rejection is not expensive because of the fix. It is expensive because of the wait. You submit, wait a day or three, get a paragraph that names a guideline number and little else, guess at what it meant, resubmit, and wait again. Three rounds of that is a fortnight gone, and the launch date you gave people has passed.
So the work is front-loaded. The submission is built to survive the reviews that actually get failed, and there are only a handful of those. Apple 5.1.1 for collecting data you did not justify, or for having no way to delete an account. Apple 4.2 when the app is a website in a wrapper with nothing native about it. Apple 4.8 when you offer Google or Facebook login and not Apple's. 3.1.1 when you sell something digital outside their payment system. On Google's side: the data safety form contradicting what the app actually sends, a target API level below the current floor, and — for newer personal accounts — the closed testing requirement that needs real testers running the app for a fortnight before you may apply for production.
The other half is the part nobody warns you about: the signing keys. Lose the Android upload key and you cannot ship an update to your own app under the same listing. Let an agency hold the Apple account and your app is legally theirs. Both are recoverable only with difficulty, or not at all. So accounts get created in the business's name, and keys get backed up somewhere the business controls, before a single binary is uploaded.
BEFORE A PRICE EXISTS
What we'd ask you first.
A quote given without these answers is a guess. These are the questions that actually move the number.
- 01Do you already have an Apple Developer account and a Play Console account, and whose name are they in?
- 02Does the app collect anything about a person — even an email address?
- 03Is there a login, and does it offer sign-in with Google, Facebook or Apple?
- 04Do you sell anything inside the app, and is it a physical thing or a digital one?
- 05Has it been rejected before, and do you still have the message they sent?
AFTERWARDS
How we'd know it worked.
Agreed before the build starts, so there is something to judge it against other than whether it looks nice.
- Live on both stores, with the accounts in your name and the keys in your possession.
- The listing answers the questions a buyer has before installing, not after.
- The data safety form and the privacy policy say the same thing the app actually does.
- You can ship an update yourself, and know what to do when a review fails.
BEFORE YOU START
Worth knowing.
Store fees are separate and paid by you directly: Apple charges 99 USD a year, Google a one-off 25 USD. Those go on your own cards, which is the point — the accounts stay yours. What moves the price here is whether the app already meets the guidelines or needs changes to pass, and whether there is an existing listing to rescue rather than a new one to create.
Websites and apps start at ₹20,000*. Final pricing depends on features and project scope. Third-party costs — cloud hosting, domains, external libraries, APIs, app-store fees and any other paid service — are billed separately and are not included.
KEEP LOOKING
Other example builds.
Website
A Product Showcase You Can Send Anyone
Your catalogue lives on Instagram, and you cannot send that to a corporate buyer or a bank. This is the address that is actually yours.
Read the case study Mobile AppRestaurant Ordering App
Menu, cart, live order tracking and a simple kitchen dashboard for a multi-outlet restaurant.
Read the case study Web AppCoaching Management Platform
Batches, attendance, online tests and fee payments in one dashboard for students and staff.
Read the case studyWant this built for your business?
Tell us what you're thinking. We'll figure out the next step together.
Free 20-min idea call · No obligation