CheckMySpot did not come to us with a single feature brief. It needed someone to take responsibility for the technology as a whole.
The company had built a consumer mobile experience that helps people send images of concerning skin spots for review by a board-certified dermatologist. It was now preparing to offer that service through employers, with its first pilot conversations already moving forward.
That transition changed the technical question. CheckMySpot no longer needed only a functioning app. It needed employer enrollment, eligibility rules, dependable infrastructure, clearer access control, compliance readiness, operational visibility, and one person who could make decisions across all of them.
I joined CheckMySpot as its fractional CTO in Q1 2025. The healthtech engagement lasted about five months. My job was to bring structure to a fragmented technical estate, keep the existing product operating, prepare the company for its pilots, and leave it with an internal team that could take ownership.
| Project snapshot | Detail |
|---|---|
| Engagement | Fractional CTO leadership |
| Stage | Early product moving into employer pilots |
| Duration | About five months, beginning in Q1 2025 |
| Leadership | Elizabeth Webb, CEO, and Dr. Michael Webb, physician leader and quality assurance |
| Core responsibilities | Product readiness, architecture, security, compliance, operations, vendor transition, and technical hiring |
| Concrete delivery thread | Employer enrollment and eligibility through EDI 834 files |
| Handover | Internal technical hires, documented systems, and continuing SOC 2 work |
The gap was technical ownership
I first met Elizabeth and Michael Webb through the Prosper HealthTech Accelerator, a gener8tor-powered program in Birmingham, Alabama. I had seen the product, understood the founders’ vision, and knew the stage of the business before the formal engagement began.
When we reconnected, CheckMySpot was between early product development and its first employer pilots. Much of its software work had been outsourced over several years. Different people had contributed to different systems, personnel had changed, and knowledge had not always been documented as it moved between them.
There were capable contributors inside and outside the company, but no single technical leader was accountable for the full picture. The founders needed someone who could oversee development, test the mobile experience, coordinate compliance, manage infrastructure, understand technical debt, control access, support deployments, and translate all of that into decisions the business could act on.
This was the gap the fractional CTO role filled.
A consumer product was becoming an employer benefit
CheckMySpot’s original experience was designed around an individual user. A person could submit images through the mobile app and receive guidance from a board-certified dermatologist about the urgency of a concerning spot and the appropriate next step.
The employer model introduced a different set of responsibilities. A company could make CheckMySpot available as a benefit, which meant its administrators needed a reliable way to enroll employees and their covered family members. The product also had to respond when someone joined an employer, left the organization, or moved between employer-sponsored and self-paid access.
Household coverage made the workflow more sensitive. A child may need a parent or guardian involved, while one adult should not automatically be able to see another adult’s health activity simply because they share a household or benefit plan. Enrollment data could establish a relationship, but it could not erase the privacy boundaries around a medical interaction.
These were not isolated interface details. They connected employer administration, identity, authorization, mobile behavior, payment rules, and patient privacy. The move into enterprise pilots therefore required changes to both the product and the way technical decisions were made when building regulated healthcare software.
We had to recover the map before choosing the route
The first architectural task was not rewriting code. It was finding out what existed.
We reviewed applications and services developed across several years, traced who had access to them, identified the people who still held important context, and documented how the pieces were expected to work together. This became more urgent when CheckMySpot decided to end its relationship with a long-term external software agency and bring greater ownership inside the company.
Securing a complete code handover was a project in itself. People had changed over the life of the product, documentation was uneven, and several systems had no obvious current owner. We had to retrieve code, confirm repositories, map responsibilities, preserve operational knowledge, and decide which relationships and resources were still necessary.
The cost of that complexity is not unique to one startup. In a McKinsey survey of 50 CIOs, respondents estimated that technical debt diverted 10% to 20% of budgets intended for new products into resolving existing problems. That research covered much larger companies, so it is context rather than a CheckMySpot benchmark. It helps explain why recovering system knowledge and reducing technical debt were necessary parts of product delivery.
The inherited Azure environment reflected the same history. It contained fragile services and resources that were no longer clearly justified, but were still adding cost and operational complexity. We reviewed that estate, removed or consolidated unnecessary resources, and reduced the number of disconnected moving parts the team had to reason about.
The wider cloud market shows why regular inventory matters. Flexera’s 2025 State of the Cloud research estimated that organizations wasted 27% of cloud spend while exceeding their cloud budgets by 17%. Those figures do not measure CheckMySpot’s savings. They show the broader operational risk created when unused resources remain active without clear ownership.
The restructuring strategy documented a possible route forward. Some recommendations remained proposals, while important foundations were implemented. Authentication was rebuilt as a unified layer for routing and authorizing access. Backup capability was added. Fragile systems were connected and stabilized so the team could continue operating while the longer transition took place.
This distinction matters. An architecture document is not an outcome by itself. The useful work was turning the most urgent parts of that analysis into safer access, better recovery options, and a technical estate the next team could understand.
The EDI 834 workflow made the enterprise challenge concrete
Employer enrollment became one of the clearest product examples of the wider transition.
EDI 834 is used for benefit enrollment and maintenance data. In CheckMySpot’s workflow, an administrator could upload an EDI 834 or CSV file, inspect the parsed records, review validation issues, choose which records to import, and manage employees and dependents from the corporate portal.
An external development team implemented substantial parts of the platform. Our responsibility was to make sure the workflow reflected the business rules, review the implementation, test the edge cases, coordinate fixes, and decide when it was ready to move forward.
We tested more than whether a file could be parsed. We worked through what should happen when an employee joined or left, when an employer paid only part of the service cost, when an individual needed to move to self-paid access, and when a single enrollment record represented several family members with different privacy requirements.
The underlying repository and its history show the practical depth of that work: file parsing and preview, employee and dependent records, selectable import columns, export ordering, and validation fixes for identifiers, dates, postal codes, and phone numbers. The test material also covered varied family structures and enrollment changes.
The result was not simply an uploader. It was an employer enrollment workflow that CheckMySpot could use during its move into pilots, with the internal and external teams contributing implementation and validation under one technical decision process.
Being the support meant owning whatever had no owner
Fractional CTO work often happened outside the codebase.
When CheckMySpot moved its email and collaboration setup into Microsoft, I coordinated the migration, opened support requests, worked with the relevant providers, and kept the process moving. When an Azure deployment failed or a developer needed help inside the cloud environment, I became the connection between the support team, the developer, and the business.
Access control required the same attention. We needed to know who could reach each system, why they had that access, and who should be contacted when something failed. That sounds administrative until a production issue begins and nobody knows who controls a critical account.
The mobile release introduced another kind of ownership. I coordinated with Apple around production requirements, clarified the service and refund flow, and made sure the website terms reflected the relevant policy. None of these tasks was large enough to define the engagement alone. Together, they determined whether the product could operate as a real service rather than a collection of software projects.
The role was not to personally write every line of code. It was to make sure the right work happened, the right people were involved, and important technical decisions did not disappear between teams.
Operational visibility had to be created
At the beginning, CheckMySpot did not have a dependable view of whether its services were functioning normally over time. Without that visibility, conversations about reliability were based more on individual incidents than a shared operational record.
I recommended adding a status page as part of the operational and compliance roadmap. It gave the team a foundation for monitoring services, understanding interruptions, and communicating status with less guesswork.
Monitoring does not prevent an outage by itself, but it gives a team evidence it can act on. In Uptime Institute’s 2024 outage research, four in five respondents said their most recent serious outage could have been prevented through better management, processes, or configuration. The study covered IT and data center outages broadly, not CheckMySpot specifically, but its lesson matched what we found: reliability depends on operational practice as well as infrastructure.
The implementation drew on the open-source project Kener. The image below shows Kener’s public interface, not CheckMySpot’s private status page or uptime data.
We do not present a mock uptime percentage, service level, or status-page screenshot as a business outcome. The outcome we can support is narrower and more useful: operational health became something the team could observe and manage deliberately.
Security and compliance were operating work, not badges
CheckMySpot handles health information, so privacy and security were part of product readiness rather than a final legal review. The company’s public privacy policy describes its handling of protected health information and the rights associated with HIPAA.
The risk was not theoretical. The US Department of Health and Human Services recorded 663 breaches of unsecured health information affecting 500 or more people during 2024. Hacking and IT incidents accounted for 81% of those reported breaches. These are national figures, not a measure of CheckMySpot’s systems, but they show why access, authentication, backups, and monitoring belonged on the pilot readiness roadmap.
Our work included access review, unified authorization, backup planning and implementation, infrastructure cleanup, policy coordination, and evidence gathering. We also managed the SOC 2 program in Vanta.
Compliance readiness also requires sustained operating time. In Vanta’s 2024 research among 2,500 business and IT leaders, organizations reported spending an average of 11 working weeks each year on security compliance tasks. Vanta is a compliance software provider, so we treat that as vendor research rather than an independent benchmark. It still provides useful context for the coordination and evidence work behind a SOC 2 program.
By the end of the engagement, we had completed roughly 80% of the SOC 2 work tracked in Vanta and handed the remaining program to CheckMySpot’s internal team. That is a readiness and handover result. It is not a claim that Sparkable issued an audit opinion or that the company completed SOC 2 certification during our engagement.
This boundary is important in healthcare technology. A checklist can help organize the work, but the real question is whether access, backups, ownership, policies, and operational behavior match what the organization says it does.
The migration we underestimated
One migration took much longer and became more disruptive than we expected.
We scheduled the work outside peak use, but inherited access gaps and incomplete system knowledge complicated the process. The recovery stretched through most of two days. I stayed with it, coordinated the people who held the missing access or context, and kept working until the affected systems were stable.
The service interruption was not a success story disguised as heroism. It exposed a weakness in our preparation. We should have mapped every dependency and account owner earlier, confirmed support availability, rehearsed the migration, and documented a more explicit rollback path before starting.
It also demonstrated why the wider inventory work mattered. A migration plan is only as good as the team’s knowledge of where systems live, how they connect, and who can authorize a change when the original plan fails.
The pilot started, then ownership moved inside
CheckMySpot began its employer pilot and the leadership team regarded it as successful. We do not have a public quantitative evaluation that isolates Sparkable’s contribution, so we will not attach a conversion rate, revenue figure, or causal claim to that result.
What we can describe is the operational transition around it.
- The employer enrollment workflow was tested and approved for deployment.
- Unified authentication and authorization were implemented.
- Backup capability was put in place.
- Unnecessary Azure resources and fragmented services were addressed.
- Operational monitoring became part of the system.
- About 80% of the SOC 2 program tracked in Vanta was completed before handover.
- The company hired internal technical contributors who could continue developing the product.
- Code, system context, and continuing responsibilities were transferred into that internal ownership model.
The new internal team is the most important handover outcome. A fractional CTO should not make a growing company permanently dependent on one external leader. The role was successful because it filled an urgent gap, helped the founders move through the pilot stage, and then helped CheckMySpot replace that gap with people who could own the next stage from inside.
CheckMySpot has since continued developing the product and pursuing further investment. Those later developments belong to the company and its team. Our contribution was to reduce the technical burden during a critical transition, so the founders could focus on the clinical, commercial, and operational work around the pilot while trusting that someone was accountable for the product and security.
What fractional CTO leadership changed at CheckMySpot
The engagement began with scattered code, vendors, resources, access, and responsibilities. It ended with a clearer operating model, implemented security foundations, a concrete employer enrollment capability, better operational visibility, and an internal team positioned to continue the work.
Not every architectural ambition was completed in five months. Some restructuring remained for the next team, and the difficult migration showed where our own process needed to improve. But the company no longer had to discover every system and decision from the beginning each time something changed.
That is the value of fractional CTO leadership at this stage. The work is partly architecture and product delivery. It is also the less visible responsibility of retrieving code, challenging a long-standing vendor relationship, finding missing access, coordinating support, documenting decisions, and keeping the service running while the organization changes around it.
For CheckMySpot, the missing system was not another microservice. It was accountable technical ownership.