The OEM Buyer’s Guide to LED Therapy Device Software Development Lifecycle (SDLC)
We developed a smartphone app for our LED mask. We didn’t have a formal SDLC. The developer wrote code, we tested it, and we released it. Then we found a bug: the app crashed on Android 12. We had to release a hotfix. Users were frustrated. We learned that software development requires a structured process, even for a simple app. Here’s how to manage software development for LED therapy devices.
The Software Development Lifecycle (SDLC) Phases
The SDLC is a structured process for developing and maintaining software.
| Phase | Activities | Deliverables |
| 1. Requirements | Define what the software should do | Requirements document, user stories |
| 2. Design | Design the software architecture, UI/UX | Design document, wireframes, mockups |
| 3. Development | Write the code | Source code |
| 4. Testing | Test the software (unit, integration, user acceptance) | Test reports, bug reports |
| 5. Deployment | Release the software to users | Release notes, deployment checklist |
| 6. Maintenance | Fix bugs, add features, support users | Bug fixes, updates, support documentation |
The requirements phase is where most projects fail. If you don’t clearly define what the software should do, the developer will build something that doesn’t meet your needs. Write down the requirements: “The app should connect to the mask via Bluetooth, display battery level, allow the user to set treatment time, and track usage history.”
The testing phase is essential for medical devices. If your device makes medical claims, the software must be validated (FDA 21 CFR Part 820, IEC 62304). This requires formal testing documentation: test plan, test cases, test results.
The Requirements Document
A good requirements document specifies what the software should do (and not do).
| Section | Content | Example |
| Functional requirements | What the software should do | “The app shall connect to the mask via Bluetooth within 10 seconds of the user pressing ‘Connect'” |
| Non-functional requirements | Performance, security, usability | “The app shall launch within 3 seconds on devices with 2GB RAM or more” |
| User stories | User’s perspective | “As a user, I want to set a treatment timer so that the device turns off automatically” |
| UI/UX requirements | User interface design | “The home screen shall display battery level, treatment time, and a start/stop button” |
| Platform requirements | Which platforms to support | “iOS 14+, Android 10+” |
| Security requirements | Data privacy, authentication | “The app shall not transmit personally identifiable information (PII) without user consent” |
The functional requirements are the most important. Write them as “The app shall [action]” statements. Be specific: “within 10 seconds,” “display battery level as a percentage,” etc. Ambiguous requirements lead to misunderstandings.
The platform requirements affect development cost. iOS only = lower cost. iOS + Android = higher cost (2x development time). Web app (PWA) = lower cost but may not have full Bluetooth access. Choose based on your target users.
The Testing Strategy
Testing is not optional. It’s essential for quality.
| Test Type | What It Tests | Who Does It | When |
| Unit testing | Individual functions/methods | Developer | During development |
| Integration testing | How components work together | Developer/QA | After development |
| User acceptance testing (UAT) | Does the software meet requirements? | Product manager/Business owner | Before release |
| Regression testing | Do new changes break existing functionality? | QA | After any code change |
| Performance testing | Speed, responsiveness | QA | Before release |
| Security testing | Vulnerabilities, data privacy | Security specialist or automated tools | Before release |
| Compatibility testing | Does it work on different devices/OS versions? | QA | Before release |
The compatibility testing is critical for mobile apps. There are thousands of Android devices with different screen sizes, OS versions, and hardware. Test on at least: iPhone (iOS 14, 15, 16), Samsung Galaxy (Android 10, 11, 12), Google Pixel (Android 12, 13). Use a testing service (BrowserStack, AWS Device Farm) if you don’t have physical devices.
The user acceptance testing (UAT) is the final check. Before releasing, have a non-developer test the app. They’ll find usability issues that developers miss (“This button is too small,” “I don’t understand this error message”).
The Deployment Process
Don’t just “release” the software. Have a deployment process.
| Step | Action | Purpose |
| 1. Code freeze | Stop adding new features, focus on bug fixes | Stabilize the code for release |
| 2. Final testing | Complete all testing (UAT, regression, compatibility) | Ensure quality |
| 3. Staging deployment | Deploy to a staging environment (not production) | Test in a production-like environment |
| 4. Production deployment | Deploy to production (App Store, Google Play, or web server) | Make it live |
| 5. Monitoring | Monitor for crashes, errors, user feedback | Catch issues early |
| 6. Hotfix plan | Have a plan for emergency fixes | Be prepared for issues |
The App Store and Google Play have review processes. Apple reviews apps for compliance with App Store guidelines (1-3 days). Google reviews for policy compliance (1-7 days). Plan for this delay when scheduling your release.
The monitoring after deployment: Use crash reporting tools (Crashlytics, Sentry) to detect crashes. Monitor user reviews on the App Store and Google Play. Respond to negative reviews and fix issues quickly.
The Maintenance and Updates
Software requires ongoing maintenance.
| Maintenance Type | Frequency | Cost |
| Bug fixes | As needed | $50-150/hour (developer time) |
| OS compatibility updates | Annually (when iOS/Android release new versions) | $500-2,000/update |
| Security updates | As needed (when vulnerabilities are discovered) | $200-1,000/update |
| Feature updates | Quarterly or as needed | $2,000-10,000/feature |
| App Store/Google Play fees | Annual | $99/year (Apple), $25 one-time (Google) |
The OS compatibility updates are essential. Apple and Google release new iOS/Android versions annually. Your app must be tested and potentially updated for compatibility. If you don’t update, the app may crash or be removed from the App Store.
The bug fix budget: Even after thorough testing, bugs will be discovered. Budget $2,000-5,000/year for bug fixes and minor updates.
What We’ve Learned
1. The Android 12 crash cost us 200+ negative reviews. We didn’t test on Android 12 before release. The app crashed on launch. Users were frustrated. We released a hotfix in 3 days, but the damage was done. Now we test on all major OS versions before release.
2. The requirements document saves time. Our first app project didn’t have a requirements document. The developer built features we didn’t need and missed features we did need. We spent 4 weeks in rework. Now we write a requirements document before any development.
3. The user acceptance testing catches usability issues. Our developer tested the app and it worked. Then the product manager tested it: “This error message makes no sense. A user won’t understand it.” We fixed 15 usability issues before release.
4. The crash reporting tool is essential. We integrated Crashlytics. Within 2 weeks, we detected a crash affecting 5% of users (a specific Android device model). We fixed it and released an update. Without crash reporting, we wouldn’t have known about the issue.
5. The annual OS compatibility update is mandatory. We didn’t update our app for iOS 16. The app started crashing for users who updated their iPhones. We had to release a compatibility update within 1 week. Now we budget for annual compatibility updates.
The OEM buyer’s guide to LED therapy device software development lifecycle (SDLC) requires a structured process: requirements (define what the software should do), design (architecture and UI/UX), development (write code), testing (unit, integration, UAT, regression, compatibility), deployment (code freeze, testing, staging, production, monitoring), and maintenance (bug fixes, OS compatibility, security, features). The Android 12 crash that cost us 200+ negative reviews taught us that testing on all major OS versions is not optional. Software development requires discipline, even for a simple app. Write requirements, test thoroughly, and have a deployment process. The upfront investment saves time and frustration later.