In April 2025, we stared at a blank page. By July, we had deployed a completely new, enterprise-grade CRM platform. We didn’t just write code; in three months, we transformed a transaction-heavy legacy environment into a modern, relationship-driven ecosystem. Here is how we built a startup-speed culture inside an enterprise environment.
What began as a focused plan to deliver the core CRM functionalities quickly grew into something much bigger. As the work unfolded across several engineering teams, new needs, ideas, and integrations emerged — transforming the project into a feature-rich ecosystem that went far beyond the original scope.
This wasn’t just a technical project. It marked the beginning of a cultural and architectural shift — one that is moving our company from a lead-centric (transactional) mindset toward a customer-centric (relational) one. We had reached a critical juncture: our previous CRM model, built primarily around leads and phone numbers, made it difficult to connect customer interactions across time, channels, and products.
Agents and teams were forced to manually piece together context for each customer, and our fragmented data foundation limited not only what we could learn, but also what we could automate and improve. This project was essential because we needed a platform that put the customer at the center of everything—a true center of gravity—enabling us to deliver connected experiences, deeper insights, and smarter support throughout the entire customer journey.
We’re not there yet — and the path wasn’t linear.
A few weeks in, we realized that some of our early assumptions around how customer data would flow across systems wouldn’t scale the way we expected. Adjusting course mid-sprint wasn’t comfortable, especially under a tight timeline, but it forced clearer ownership, better boundaries, and stronger collaboration across teams.
As this transition continues, the steps we’ve taken will strengthen how we understand, support, and build long-term relationships with our customers — and ultimately, how we grow as an organization.
Building at Startup Speed in an Enterprise Environment
Delivering a full CRM platform in three months required more than code — it demanded a deliberate breakdown of silos, shared ownership across teams, and a willingness to prioritize progress over traditional handoffs.
We brought together multiple teams — each owning different parts of the customer journey — and aligned them around a single outcome rather than rigid ownership boundaries. Engineers, product managers, and designers worked across domains, unblocking one another directly and making decisions together, with a shared focus on delivering a unified, reliable, and modern experience for agents.
In practice, this meant breaking some familiar enterprise patterns. Instead of long dependency chains and handoffs, teams collaborated directly, resolved design questions early, and took shared responsibility for outcomes that spanned teams and systems. Cross-team empathy wasn’t a slogan — it became a practical necessity that allowed us to move fast without breaking trust or quality.
Our licensed agents talk with customers every day to help them choose the right insurance coverage – so speed and clarity in the CRM directly impact customer experience.
Two choices anchored this transformation:
- GraphQL Federation — a unified API layer across domains, with clear ownership per team.
- Angular-based CRM UI — a modular frontend built for speed, reuse, and long-term maintainability.
Along the way, we built the Customer Profile Service — the connective tissue between legacy systems and the new platform. It became the foundation of our move toward a 360° customer view, linking interactions, product history, and engagement context under a single identity, so agents can see not just a lead, but a person.
As a result, agents now see a customer’s history, including past inquiries and policy choices, not just isolated transactions. All customer interactions, like phone calls or emails, are connected under one profile, making it easier to understand needs and provide consistent support.
With these architectural decisions in place, we were able to execute on a deeper structural shift. Agents can build ongoing relationships, offering tailored guidance and nurturing trust over time. By focusing on the full customer journey, the organization is moving from transactional encounters to meaningful, long-term connections, making every interaction part of a richer customer story.
From Transactions to Relationships — and Smarter Reporting
Shifting from leads to customers wasn’t only about improving the user experience; it also set the stage for better reporting and analytics.
Until recently, our data model was built primarily around lead-level information and phone numbers, which made it harder to connect interactions or see relationships over time.
By introducing a customer-centric foundation, we’ve begun creating the conditions for more connected and insightful reporting — linking leads, multiple products, and interactions to a single customer identity. This unified view is critical for analytics, personalization, and long-term relationship building, but its impact goes far beyond cleaner data. By seeing the full human story behind each customer, agents can better understand evolving needs and provide guidance with confidence and empathy. We’re not just optimizing systems; we’re building the digital foundation that helps people navigate some of the most important healthcare decisions of their lives.
We’re still early in this journey. The structures are forming, and the potential is clear, but there’s much work ahead to make our reporting fully reflective of the customer’s story. This shift will take time, but every step brings us closer to a unified understanding of our customers across systems and teams.
A Shift from Code to Connection
The most important outcome wasn’t just technical.
By moving toward a customer-centric model, we have started to redefine what “engagement” means. Agents can now see customers holistically, understand their past interactions, and provide personalized guidance, all while strengthening trust and relationships rather than just completing transactions.
Internally, this project reshaped how we collaborate.
- Teams learned to share ownership and align on specifications early.
- Product and engineering found new rhythms for faster iteration.
- Developers didn’t just adopt new technologies — they upskilled together under real delivery pressure. Moving to GraphQL Federation and an Angular-based UI wasn’t a top-down mandate; it was a necessary evolution to decouple domains and enable teams to move independently. These choices gave engineers greater autonomy and a shared language across teams, reinforcing our commitment to modern, scalable architecture even under tight timelines.
Building our domain model through GraphQL became a turning point. It wasn’t only a technical framework; it helped us define ownership boundaries, align data across teams, and create a shared language between domains. In many ways, GraphQL became the blueprint for how we collaborate — both in code and in culture.
The experience reminded us that technology isn’t just about systems; it’s about creating meaningful, scalable connections — not only with our customers, but also within our teams.
Lessons from a Three-Month Sprint
Looking back, a few lessons stand out:
- Start with clarity, not perfection. We began with bold goals and refined them through iteration.
- Cross-team empathy drives speed. Alignment across teams was worth more than any tool or framework.
- Quality at speed is intentional. We shipped in thin, incremental slices, delivering value weekly and keeping integration risk small.
- Clear contracts reduce friction. Defining API boundaries early allowed teams to move independently without constant coordination overhead.
- Migration strategy matters. We built bridges to legacy systems while continuing to deliver, rather than freezing progress for a “perfect” cutover.
- Modern architecture reinforces culture. Choosing scalable technologies helps teams collaborate, learn, and take clear ownership under pressure.
- Customer 360° is a journey. The Customer Profile Service gave us a foundation — one we continue to evolve to connect analytics, workflows, and insights across systems.
What’s Next
This new CRM is just the beginning. Because our CRM is designed as a multi-product platform, we’re already envisioning the integration of additional products and solutions beyond Medicare Advantage. The next phase will connect even more systems — from marketing attribution to analytics — strengthening the bridge between business domains and ensuring a consistent, end-to-end view of the customer.
What makes this achievement special isn’t just how fast we built it, but how much we grew together while doing it. In three months, we didn’t just ship a new platform — we redefined how we see our customers, our data, and ourselves.
Shipping a platform this complex in 90 days requires a special kind of team. I’ll remember the late-night debugging sessions that turned into impromptu architecture debates. The message threads that somehow went from “this might not work” to “wait — it actually works,” and the many back-and-forth discussions over schemas where teams challenged assumptions, refined boundaries, and aligned on a shared language for the customer. Those moments — sometimes messy, often intense — are where real progress happened.
This project proved that when we align on a shared purpose, care about craft, and stay open to learning from one another, we don’t just build software — we build a better way of working together.
If building customer-centric platforms, federated APIs, and modern frontends under real constraints sounds like your kind of work, we’re doing more of it next. And if you enjoy working with teams that move fast, debate well, and learn together, you’ll feel at home here.
