Case study 03
Chat startup ~30 seconds → ~5 seconds (~1 second when cached)
Overview
The platform helps groups of people coordinate responsibility for caring for an elderly person.
A Huddle can contain multiple caregivers who coordinate responsibilities, schedules, shifts, spending, care-related information, one-to-one communication, and group communication.
The platform also used a Stripe-based membership model, where the number of Huddle members was controlled through the subscription/paywall system.
Business challenge
The existing platform had three major issues.
The chat problems needed to be addressed within approximately 7 days. That meant the task wasn’t simply to gradually refactor the application — I first had to understand how the existing system actually worked, identify where the latency and delivery problems originated, and then make the changes without breaking the existing product.
Impact
Caregivers rely on timely, reliable communication to coordinate real-world care responsibilities.
A ~30-second chat startup and unreliable delivery undermined trust in a production elder-care product.
A ~7-day constraint meant safe architectural change inside an unfamiliar system — not a greenfield rewrite.
Engineering
Technical constraints that shaped the architecture and delivery approach.
01
The most difficult part wasn’t writing a new chat component. It was understanding an unfamiliar production system quickly enough to make a safe architectural change under a 7-day delivery constraint.
02
The previous implementation relied on an iframe-based integration. Diagnosing latency and delivery failures required untangling the flow between the application and the chat services.
Ownership
What I personally delivered:
Solution
I investigated the existing communication implementation and moved the application toward direct service integration with the Angular and mobile applications — addressing loading and delivery as related but distinct problems.
I untangled the flow between the application and the chat services, replacing the iframe-based integration with direct service integration.
The revised implementation introduced improved loading and caching behavior. Initial chat startup moved from approximately 30 seconds to approximately 5 seconds. When the relevant data was already cached, entering the chat experience took approximately 1 second.
The rewrite also addressed the underlying message-delivery problems rather than treating the issue purely as a loading-time problem. Fast chat isn’t useful if messages don’t reliably arrive.
I investigated and corrected problematic backend queries contributing to application performance, and dockerized the backend for a more consistent deployment and runtime environment.
Architecture
From iframe-based chat embedding to direct service integration with Angular and mobile clients.
Comparison
| Area | Before | After |
|---|---|---|
| Chat startup | ~30 seconds | ~5 seconds |
| Chat entry with cache | — | ~1 second |
| Message delivery | Reliability issues | Delivery issues addressed |
| Integration | iframe-based | Direct service integration |
| Backend deployment | Existing environment | Dockerized |
| UX | Confusing areas | Targeted UI improvements |
Results
Chat startup
~30s → ~5s
Cached entry
~1 second
Delivery window
~7 days
The communication experience went from a roughly 30-second initial startup to approximately 5 seconds, with cached entry taking approximately 1 second.
The work also addressed message-delivery problems, improved parts of the UI, corrected problematic queries, and moved the backend toward a more consistent containerized deployment model.
The existing platform was improved without requiring a complete rebuild.
Technology
Listed last on purpose — technology supported the business outcome; it was not the story.
More work
Case 02
~85% reduction in worst-case runtime: 6 hours → ~45 minutes
E-commerce / Data Analytics
Case 01
Publishing → distribution → commerce → payment → reading in one production system
Digital Publishing / E-commerce
Case 05
New HR capability inside OfficeAnyWhere — not a disconnected HR product
Enterprise / HR
Next step
Talk to Solastia Systems about the business outcome you need — architecture, delivery, and measurable results follow from that.