On a short project there is no room for a test phase at the end. If the build takes four weeks and testing starts in week four, you find the bugs when there is no time left to fix them. QA on a short project has to start before the first line of code and run alongside every feature.
The plan below is for founders and product owners with a 2-8 week build, such as a first version, a new module or a fixed-scope project. It starts with week zero and ends with the numbers to hold at launch. For the difference between assurance and control, see our guide to QA vs QC.
On a long project, the process can grow over months. On a short one you get one chance to set it up, usually with one QA engineer, often part-time. Three things follow from that:
| When | What QA does | What you get |
|---|---|---|
| Week 0 (setup) | Repository, automated builds, test environments, test devices, a bug template, the definition of done | A setup where every change gets the same checks |
| First sprint | Acceptance criteria for each story; each feature tested in its own environment before it’s merged | Bugs found while the developer still remembers the code |
| Middle sprints | Automated tests for the flows that touch money or accounts; a regression run before each demo | Old features keep working while new ones arrive |
| Last week | Integration testing of the whole product, real devices, store submission, a release checklist | A release candidate you can sign off |
| After launch | Crash and error monitoring, a short list of fixes for the first week | Problems seen in numbers, not in reviews |
The definition of done is the rule that holds this together. The Scrum Guide Expanded, updated in January 2026, renames it the Definition of Output Done and calls it “the overall quality standard for the whole Increment”. Write it down before the first sprint. It should say that a feature isn’t finished until it has passed its acceptance criteria and a code review.
When this article first ran, Igor Starcheus, a project manager and business analyst at Rocketech, described the process we set up on short projects. It still works, with small changes.
At the start of each sprint we create a sprint branch from the main branch, the one that goes to production. Each feature gets its own branch from the sprint branch. When a feature is ready and another developer has reviewed the code, the build system creates a separate test environment for that feature alone. QA tests it there. Only when the feature passes is it merged into the sprint branch.
In the second half of the sprint, when the features are merged, QA tests them together to make sure they work as one product. Then comes the demo. Once you approve it, the sprint branch goes to production.
The benefit is simple: when a bug shows up, you know which feature caused it. When the front end and back end of a story depend on each other, we test the whole user story in one branch instead of each part. Two more lessons from running it:
Mobile works the same way, except each feature becomes a separate app build that QA installs on real phones, through TestFlight for iPhone and Firebase for Android.
You won’t automate everything in four weeks, and you shouldn’t try. Screens change daily early on, so automated tests for them break as fast as they’re written. Automate what is stable and expensive to get wrong:
Test the rest by hand against the acceptance criteria and a checklist. Keep one master checklist, split by feature, and mark each test as passed or failed for every release.
If part of the code is written with AI tools, give it the same review and tests as the rest. The 2025 DORA report found 90% of nearly 5,000 respondents use AI at work, and 30% have little or no trust in the code it generates.
App stores add waiting time that a short plan has to absorb:
On Traza, an Australian booking app for tattoo artists, the client had already promised a launch date. App Store review can take one to two weeks, so we sent the app to review early instead of polishing it until the last day. It was approved on the App Store and Google Play. The team was two React Native developers, a delivery manager and a QA engineer.
Set the launch bar in numbers you can check. For an Android app, Google publishes the crash rates that hurt you on Google Play. Its Android vitals page sets the bad behavior threshold for the user-perceived crash rate at 1.09% overall and 8% on any single phone model, and 0.47% overall for apps that freeze (ANR). If an app goes over, Play may reduce its visibility and show users a warning on the store listing.
Set your launch bar below those numbers and switch on crash monitoring before release, not after the first bad review. For a web product, set a load target too. On Babystep, a learning platform with paid video calls, load testing showed the platform could process up to 10,000 requests at the same time.
Our project estimate turns your brief into user stories. You confirm what is in scope, and every hour in the budget traces back to a story you kept. We check the hours the model suggests against what our team actually books on finished projects, then multiply by our published rate of $39-55 an hour. QA and release get their own lines, so testing is planned from the start instead of squeezed in at the end.
Here is an example run of our estimate’s math with sample inputs: a dating app for iPhone and Android with profiles, matching, chat and a subscription. QA came to 24 of 200 hours and the store release to 8. The budget came to $6,600-13,600 over 5 weeks. Every input in that run was an assumption; only the arithmetic is ours. To get the same breakdown for your product, see what your idea costs to build.
If your own team is short on testing, a QA engineer can join your team at $39-55 an hour, starting in 3-5 days, or within 2 weeks if we hire someone new.
Write the definition of done first, then test every feature in its own environment as soon as it’s ready, with a regression run before each demo. Integration testing of the whole product happens in the last week, on real devices.
Before development starts. QA needs a week zero to set up test environments, devices and the bug process, and to write acceptance criteria with the product owner.
Only the stable, high-cost flows: sign-up, payments, the main task and calculations. Screens change too often in the first weeks for automated UI tests to pay off.
Your first TestFlight build for external testers needs App Review approval. On Google Play, personal accounts created after 13 November 2023 need a closed test with at least 12 testers for 14 days before production access.
Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.