Maintainability
A codebase teams can actually understand
Normal changes no longer require navigating a maze of disconnected services. The codebase is logical, understandable, and easier to grow with the business.
Cadence Case Study
How Cadence Replaced a Fragile Healthcare Platform With a Strong New Foundation in Six Weeks
Cadence’s prior-authorization platform is how they deliver their service. Normal changes had become slow, costly, and risky. We learned how the business worked. We decided more patches would make things worse. We rebuilt the platform in about six weeks on a foundation that is easier to maintain. We still support it.
About 5 minutes. No sales call required.
Built with Cadence, a medical prior-authorization service for hospitals, clinics, and payers.
“Cadence” is a pseudonym used at the client’s request. The engagement, work, and outcomes described here are real.
~6 Weeks
Full platform rebuild
90%+
Lower monthly hosting costs
Days → Minutes
Many support needs: days of waiting → about 30–45 minutes
Ongoing
Senior support continues today
Support timing describes typical experience after the rebuild and is not a contractual service-level agreement.
Client snapshot
Client
Cadence — a medical prior-authorization service for hospitals, clinics, and payers.
Industry
Healthcare technology / medical prior authorization.
Challenge
A working custom platform had become slow, costly, and risky to maintain or expand.
Solution
A complete rebuild on a right-sized, easier-to-maintain setup, followed by ongoing senior technical support.
Outcome
Faster development, improved reliability and usability, much lower hosting costs, and continued involvement from the senior team.
The business: prior authorization cannot run on fragile tech
Cadence handles medical prior authorizations for hospitals, clinics, and payers. Their service uses AI-supported workflows plus expert staff for phone calls, faxes, paperwork, research, and follow-up. The platform puts all of that work in one coordinated process.
This is not a side tool. The app is how the service is delivered. Requests usually must turn around in 24 to 48 hours. When software for a critical workflow becomes hard to change, the whole business feels it.
Phone calls with payers and providers
Inbound and outbound fax handling
Documentation and record gathering
Research on requirements and criteria
Expert specialist review
Follow-up within tight turnaround windows
Building custom software was the right call
Cadence was right to build custom software. Generic tools could not give them the workflow, control, ownership, or flexibility they needed. Custom healthcare software was the right choice — and it stayed the right choice through the rebuild.
Generic software did not match the workflow
Cadence wanted control over its intellectual property
Years of healthcare knowledge had to be encoded in the product
The product needed to evolve as the company learned
Custom development was not the mistake. The first version turned a founder’s idea into a real business. The later question was not whether to build custom software — it was how to structure it.
The challenge: software that worked but could not change
The first version was built by an overseas team found through a trusted referral. It used React, AWS, and many small connected services (microservices). It worked at first and helped launch the business.
Problems showed up later — not at launch, but as Cadence tried to maintain and grow the platform. Every fix, feature, and release cost more than it should. That is technical debt: a complexity tax on every future change.
Small changes took a disproportionate amount of engineering effort.
Bugs were difficult and slow to trace across disconnected services.
Hosting costs kept rising.
More developers and junior handoffs made the codebase harder to understand.
Communication required extensive written specifications.
Time-zone and healthcare-domain differences added friction.
“Anyone can get software to work once. The question is what it costs to change it on the hundredth or thousandth day.”
Eventually Cadence stopped requesting changes and built manual workarounds inside their own platform — because changing the system had become too hard.
Architecture built for scale they did not need
On paper, the microservices design looked advanced and scalable. In practice, it solved a problem Cadence did not have. It was built for huge scale, not for Cadence’s real business and small engineering team.
Multiple deployment and debugging paths
Expensive hosting
Greater coordination burden
More places for changes to fail
A codebase that became harder to navigate as more engineers touched it
Architecture should let a small team ship reliably and affordably — not copy Netflix. Fancy is not the goal. Fit is the goal.
The technical deep dive
Cadence first hired 21 Solutions to understand, host, support, and slowly improve the existing app — not to sell a rebuild. Our first instinct was to make the current system work.
During review, that plan hit reality. Even a simple field change meant tracing logic across many apps, controllers, services, and databases. A minor change could use up most or all of a small monthly support budget because of the broken-up architecture.
We told Cadence honestly that taking money to keep patching the platform would not be a responsible use of their budget. Senior tech judgment includes telling a client what they do not need.
“Architecture decisions are business decisions in technical clothing.”
The decision to rebuild
The tension was real. Cadence had already spent years building and running the platform. Starting over felt risky. Sunk cost is real, and no one wants to walk away from years of investment.
But the cost to build is not the same as the cost to own over time. After looking at the real cost and ability to keep maintaining the platform, Cadence concluded that rebuilding was cheaper and more responsible — the option they could actually carry out.
The 21 Solutions approach: understand the business first
Before choosing a tech stack, 21 Solutions worked to understand how the business actually ran. A development partner should understand the business before picking an architecture.
- How prior-authorization specialists worked day to day.
- Where they actually spent their time.
- How information entered and moved through the platform.
- What had to happen within the 24-to-48-hour service window.
- Which workflows were genuinely essential.
- Which technical complexity was unnecessary.
The right setup is not the one that sounds most advanced. It is the one that lets the business operate, change, and grow reliably.
With that understanding, the team chose a straightforward setup — a well-structured monolith (one unified app) that matched Cadence’s stage, team, workflow, and development needs. This was not saying monoliths beat microservices everywhere; it was the right fit here.
Rebuilding a two-year platform in about six weeks
A platform that had been running and changing for about two years was rebuilt and relaunched on a clean, well-structured monolith in about six weeks, using the team’s established app patterns. The work went well beyond rewriting screens.
Learned an unfamiliar healthcare workflow
Identified essential functionality
Recreated the operating platform
Simplified the architecture
Improved the user experience
Reworked the AI-output presentation
Stabilized fax workflows
Migrated to a more economical hosting setup
Prepared the system for continuing feature development
The results
Reliability
More confidence work completes correctly
Cadence gained more confidence that requests moving through the platform would finish correctly. Previously troublesome fax workflows became dependable after the transition.
User experience
Clearer, easier-to-navigate information
Information and AI-supported responses became easier to sort, understand, and navigate for the specialists doing the work.
Support speed
Days of waiting to a short conversation
Requests that previously waited days can often be handled through direct communication in about 30–45 minutes, depending on complexity. This describes typical experience, not a contractual service level.
Hosting cost
More than 90% lower monthly hosting
The right-sized setup and hosting migration reduced monthly hosting expenses by more than 90%.
Senior technical support
Business needs, not product documents
Cadence no longer needs to translate every business need into a detailed technical product document. They can share the business need and rely on 21 Solutions to determine the right implementation.
Founder advice
Founder advice
“Find someone who will tell you what you don’t need.”
Technical complexity is easy to sell because complexity is billable. A good tech partner asks about the business before picking an architecture — and recommends less when less is what the business needs.
Before and after the rebuild
Before
- A working but increasingly hard-to-maintain platform
- Many small connected services (microservices)
- Expensive hosting
- Small changes requiring too much effort
- Bugs and fax processes that could stall
- Multi-day support turnaround
- Long product documents required to communicate changes
- Manual workarounds inside a custom platform
- Technology becoming a limit on growth
After
- A clean, right-sized app setup
- Full platform rebuild completed in about six weeks
- More than 90% lower monthly hosting costs
- Easier feature development and troubleshooting
- More reliable workflows
- Improved usability and AI-output presentation
- Direct access to responsive senior developers
- Business needs turned into technical execution by 21 Solutions
- Ongoing support from the senior team that rebuilt the platform
The senior team stayed involved
“21 Solutions is our in-house engineering team at this point. I can communicate the business need, and they understand what has to happen technically to execute it.”
Is your software becoming harder to change every time the business grows?
A platform does not have to be fully broken to become a business risk. If normal improvements are slow, costly, or unpredictable, 21 Solutions can help you decide whether to stabilize, modernize, or rebuild responsibly.