Most first-app budgets have three lines: design, development and a launch date. A coaching institute in Lucknow that wants recorded lectures, a test series and fee reminders before the next academic session will usually draw it up that way. The time that decides the schedule sits somewhere else: testing on the phones students actually own, store review, and the weeks after release when the first batch starts using it.
Six stages, and what each hands on
- 01Planningscope, platform
- 02Designflows, prototype
- 03Buildapp, API, gateway
- 04Testfeatures, cheap phones
- 05Releaselisting, beta batch
- 06Iterateanalytics, feedback
Next version
Release is a stage with its own lead time, and iteration feeds back into planning.
Every stage produces something the next one cannot start without. Planning produces a scope that can be cut. Design produces flows you can test before anyone codes them. Build produces a version somebody can install. Testing produces a list of what is known to be broken. Release produces real usage, and iteration turns that usage into the next scope.
When a stage skips its output, the next one starts on guesswork. That is usually where the weeks go, and it rarely shows up as one big delay. It shows up as a design review that reopens scope, or a test cycle that finds a payment flow nobody specified.
Planning means deciding what to leave out
Start with who the app is for and what they do today. For the institute: students, parents, or both? Today it is probably a Telegram group and PDFs forwarded on WhatsApp, and that tells you what the app has to beat. Look at the two competitor apps the students already have installed and note what each does badly.
Then split must-have from nice-to-have and keep the second list out of version one. Fee reminders can wait a release. Recorded lectures that play on a budget Android phone cannot.
Planning also fixes the platform. iOS, Android or both, and native or cross-platform. A coaching audience in Uttar Pradesh is mostly on Android, which changes the budget and the team you need. Settle it before design starts; our post on choosing between native and cross-platform covers how. Write the plan as a list of versions: one in time for the session, the next after the first test series has run.
Design with real content, not mockup data
Wireframes show screens and flows at low fidelity. A clickable prototype lets ten real students try the main flow before anyone writes code, and it is the cheapest usability test you will ever run. Visual design then applies the institute's brand, and someone checks that the menus make sense to a student who has never opened the app.
Test the designs with content that looks like real accounts. A student with a long name. A batch with no lectures uploaded yet. A fee payment that failed halfway. A lecture buffering on a weak 4G connection. A design that only works with the sample data in the mockup breaks on the first real login.
Build in pieces someone can install
There are three parts to build. The app is what students see. The backend holds the APIs, the database and the business rules. Integrations connect the payment gateway, analytics, push notifications and anything else the app depends on.
Ask for the integration list in week one. Each integration brings its own account setup, keys and sandbox, and the gateway's merchant onboarding often takes longer than coding the checkout. Short sprints only help if each one ends with a build someone can put on a phone and try. A sprint that ends with "the API is done" has not shown anybody anything.
Put analytics into the first sprints. If they go in after launch, the first month of real use, the one you most want to understand, is not recorded anywhere.
Testing on the phones students own
| Test | Question it answers |
|---|---|
| Functional | Do the features do what the spec says? |
| Performance | Does it stay responsive on slow phones and networks? |
| Security | Are accounts, payments and personal data protected? |
| Usability | Can a new student finish the main task without help? |
| Device and OS | Does it work across screen sizes and Android versions? |
Device testing is the one that gets skipped. The team's phones are recent flagships. The students' phones are four-year-old budget Androids with 3 GB of RAM, cracked screens and storage full of WhatsApp videos. The app that was smooth in the office stutters in the classroom, or gets killed in the background when the student switches to the calculator mid-test.
Test it on the cheapest phone your users have. Fill its storage nearly to the top, turn on battery saver, and play a lecture on a throttled connection. Then start a test, lock the screen, and come back. If the answers are gone, you have found your first release blocker.
Release has its own lead time
Developer accounts have to exist on the App Store and Google Play, and a company account's verification paperwork can take a couple of weeks on its own. The listing needs a name, a description, screenshots and often a short video. App store optimisation, meaning the words and images that help people find the app in search, deserves an afternoon of thought rather than the night before submission.
Both stores review every submission, and a rejection adds days. Submit an early build for review well before any date you have promised, so the first rejection, and there usually is one, lands on your calendar and not the principal's. Run a beta with one batch of students first. They will find the problems before every batch does.
What eats the schedule, and the first step
Here is where these builds usually slip:
- The budget ends at launch, so nothing is left for the fixes the first week needs or the Android update that arrives in month two.
- Testing happened on two or three recent phones.
- The store listing was written the night before submission.
- Analytics went in after release, so nobody knows what early users did.
- The scope was never cut, so version one tried to be version five and missed the session.
The first thing to do is write the must-have list and cut it until it fits one release. Then choose platforms, prototype the main flow with a handful of real students, and get an early build into store review. A short scope the institute can defend to its own faculty makes every later stage cheaper, and it is the one cut a vendor cannot make for you. If you want to see how we run these stages with a client, how we work lays out the process.
