[TEAM SUPPLIES: client permission pending. Do not publish this post, and do not publish an anonymised version either, until the owner has asked iMDsoft whether we may name iMDsoft and MobileVision in a post about the release pipeline and recorded the answer in owner-inputs.md (client_permissions). If permission is refused, rewrite as "a clinical mobile workflow product" and drop anything that identifies the client. The post is also parked until the CI/CD and test automation service page is live; the one exception is the permission and Clutch review message to iMDsoft, which should go out with the first Clutch batch because Clutch only counts work from the past two years and this work ended on 1 December 2024.]
Short answer. Between August and December 2024 we worked for iMDsoft on test automation and the release pipeline for MobileVision, a clinical mobile workflow product for nurses. We built a full CI/CD pipeline for the Flutter app: it builds the Android and iOS apps and sends them to the stores. We added the tests that were missing, made the whole Flutter test suite run as one batch, and made the tests run on BrowserStack for both platforms, on the triggers the client needs. Those BrowserStack runs found real issues in the existing tests. [TEAM SUPPLIES: one before/after number, if the client allows.]
The product, and why releases are hard here
MobileVision helps nurses work with patient-related tasks and information away from a fixed workstation. When a release breaks a screen, it can interrupt time-sensitive work for clinical staff. So the team needed three things: repeatable builds, automated checks, and fewer manual release steps. And the tests had to cover the UI, workflow logic and integrations without using real patient data.
Our role. Test automation, and the pipeline that builds, tests and ships the app. Our dated record is two engagements with the client between August and December 2024. In the first we connected the Flutter automation tests to device-cloud testing services (BrowserStack, Firebase). In the second we fixed the Flutter tests so the whole suite runs as one batch. We also added the missing tests and built the CI/CD pipeline, with automated test runs and quality gates. This post describes that work. It does not describe the app's clinical features, which are the client's product. The MobileVision case study has the short version.
The three release layers
- Build. The pipeline builds the Android and iOS apps from the one Flutter codebase.
- Test. The automated tests, including the ones we added, run on BrowserStack for both platforms, on the triggers the client needs.
- Quality gates. The automated test runs sit behind quality gates, and the pipeline sends the builds to the App Store and Google Play.
Cleaning up the client's environments and deployment set-up, and writing handover documentation, were not part of our work.
What the BrowserStack runs found
The client's own review says the BrowserStack runs found real issues in their automation tests. That is the case for a device cloud: the same tests run on both platforms, on every trigger the team needs, not only on one engineer's emulator.
What the client said
[TEAM SUPPLIES: quote gate. iMDsoft's reply to the permission message decides which version runs: either the edited home-page text, only if iMDsoft approves that exact wording, or the verbatim Upwork review of 1 December 2024 with its URL. Never a new edit, and never a fragment of the edited text presented as the client's words. If permission to name iMDsoft is refused, delete this section.]
A pre-release checklist for clinical mobile apps
Use it on your own pipeline. If you answer "no" or "not sure" to two or more, the pipeline is where your next release risk sits.
- Can any engineer rebuild the exact release from its commit, on the CI machine, without local steps?
- Do the automated tests run on real devices, not only on emulators?
- Do the test suites run with data that contains no real patient information?
- Can a failed test or a coverage rule actually stop a release candidate, or is it only a warning?
- Do you know how many manual steps sit between a merge and a release candidate?
- Is every manual step there on purpose, with a named owner?
- Could your own team maintain the pipeline if the person who built it left tomorrow?
Two or more "no" answers? Book a 30-minute call and bring this list; it is a good agenda for the first half hour.
Next step
- Book a 30-minute call and bring your current pipeline.
- Want an outside view first? Our free high-level audit checks your app against the current store rules and, with read access, its crash rates. It doesn't review the pipeline itself; bring that to the call.
- See how we run mobile CI/CD and test automation.
- Read the MobileVision case study.
- Check the app store and platform rules for 2026–27 that your pipeline should catch before store review does.
- Building in Flutter? Our native or cross-platform decision matrix explains why one codebase still means testing two apps.