Illustrative example. The client, product and findings below are fictional. The structure, level of detail and pricing basis are what a real assessment looks like.
Discovery sprint assessment · 2 weeks
Technician app and payments roadmap
- Client
- US home-services scheduling platform (fictional)
- Sprint team
- One senior engineer, one engagement lead
- Question asked
- Can a pod take over the mobile app and ship in-app payments and offline mode this year?
01
Summary
Yes, but not in the order on the roadmap. The mobile release process is the real blocker, not the features. Fix that first, and payments and read-only offline mode are realistic within three months.
- Recommendation: a three-month pod starting with the release pipeline and React Native upgrade, then payments and read-only offline mode.
- Biggest risk: nobody on the current team can ship a mobile release today.
- What we'd push back on: offline editing in the same quarter. It needs its own design work first.
- Cost: $9,000 a month for the pod. $24,500 for the first three months after the sprint credit.
02
What we looked at
- Web app (React), technician app (React Native) and API (Node.js, PostgreSQL on AWS)
- Build and release process for web and mobile
- The product roadmap and the specs for payments and offline mode
- Interviews with the head of product, the three in-house engineers and two support staff
03
What's solid
- The data model. The PostgreSQL schema is clean, and every migration is in version control.
- API test coverage. The core booking service has good automated tests, so changes there are low risk.
- Product clarity. The team knows its users, and the roadmap is prioritised with reasons.
- Web payments. Stripe is integrated correctly on the server, so mobile can reuse it.
04
What's risk
| Severity | Finding | What we recommend |
|---|
| High |
Mobile releases depend on one departed engineerStore builds were made by hand on a single laptop. The signing certificates aren't in shared storage, and the last store release was four months ago. |
Recover the certificates, move builds into CI and ship a store release before any new feature work. |
| High |
React Native is three major versions behindSeveral dependencies are unmaintained at this version, and upcoming store requirements will block releases. |
Upgrade first. We estimate two to three weeks, done in small steps behind the existing tests. |
| Medium |
No staging environment for mobileThe mobile app is tested against the production API, so testers create real bookings. |
Stand up a staging API with seeded data, and point test builds at it by default. |
| Medium |
Offline mode is underestimatedThe spec assumes technicians can edit jobs offline. Resolving edits made on two devices isn't designed yet and is the hardest part. |
Ship read-only offline first. Treat offline editing as a separate, later piece of work with its own design spike. |
| Low |
In-app paymentsWeb payments already use Stripe correctly on the server side. |
Reuse the same server-side flow from mobile. Low risk once releases are working again. |
05
The working slice
Something real, built during the sprint and kept by the client whatever they decide next.
- Mobile builds restored in CI. We recovered the signing certificates, moved them into shared storage, and produced a signed test build from the main branch through the pipeline.
- One backlog item shipped end to end. Photo attachments on technician job notes, behind a feature flag, reviewed and merged by the in-house team.
06
Delivery plan
Month 1React Native upgrade, staging environment, and the first store release in four months. Releases every two weeks from here.
Month 2Read-only offline mode for technicians. In-app payment screens designed and reviewed with the product team.
Month 3In-app payments live. A design spike on offline editing, with a written recommendation.
07
Team shape and cost
- Lead — senior engineer, owns delivery and the release process
- Two engineers — one mobile, one full-stack
- Fractional QA and design — for release testing and the payment screens
- Overlap — four hours a day with the client's team, in the contract
| Pod, three months at $9,000 a month | $27,000 |
| Half the $5,000 sprint fee, credited against month one | −$2,500 |
| First three months | $24,500 |
After month three, the pod runs on 30 days' notice.
08
If you don't hire us
Do month one anyway, with whoever builds your app. Until a second person can ship a mobile release, every feature on the roadmap is at risk. If budget is tight, the release pipeline and the upgrade alone remove the most urgent problem.
09
What we'd need from you
- A product owner available for two hours a week
- Access to the app store accounts, AWS and Stripe test mode
- A decision on offline editing scope by the end of month two
Want one of these for your product?
Two weeks, from $5,000. If the sprint tells us we're not the right team for the work, we'll say so, and you'll still have the assessment.
Talk to us