The project at Synergy Codes
I was asked to build a table view using a library I had never worked with before. The feature had already been estimated at roughly 80 development hours, and I didn't have time to spend days researching different implementation approaches. What I didn't know at the time was that another team at Synergy Codes had already solved a very similar problem months earlier. Using CodeQA, I found that implementation, understood the architectural decisions behind it, and reused production-validated patterns instead of rediscovering them from scratch. The result: a feature originally estimated at 80 hours was delivered in under 40.
Synergy Codes was tasked with building a data table component for Processive MedTech Development Services, a company building software and usability solutions for the medical industry. The scope: an alternative view for browsing complex datasets, with sorting, filtering, search, column resizing, and column management, including the ability to select which columns are displayed and reorder them. The component also needed to be flexible enough to accommodate future additions: export, clickable elements within cells, and other features not yet fully defined. Extensibility was a requirement from the start.
The constraint was tight. The client's combined design and development estimation was 80 hours, and they had one key request: they really liked the Figma designs and wanted the implementation to stay as close to them as possible.
Choosing the right library
The team evaluated two options: AG Grid, a leading enterprise grid; and TanStack Table, a headless library that delivers logic and functionality without enforcing any UI.
AG Grid is actually a great library. You can customize a lot of things. But from experience, it can get messy in code, and sometimes you have to adapt to AG Grid rather than the other way around. That takes time.
If I hadn't had an existing implementation from another project, I would have gone with AG Grid, just to have the components out of the box. I didn't have time to research TanStack Table from scratch: how it works, how hard it is to implement. But I found out there was already a working table built with TanStack in another project, extensible, easy to style, with more features than I even needed. And it meant AI had a verified, production-tested source to work from. That's what made the decision.
The challenge with unfamiliar territory
Evaluating a new library takes real time. Reading documentation, testing edge cases, validating integration patterns, then building the actual feature on top of that discovery work. What I didn't know: the research had already been done.
A developer on another team at Synergy Codes had built a TanStack Table implementation for an internal project months earlier. He had evaluated multiple approaches, resolved integration challenges, and shipped it to production. The knowledge existed. The components existed. The engineering decisions had already been made. They just weren't visible across teams.
The implementation: CodeQA + Claude Code + Figma
Using CodeQA's extensive knowledge of internal repositories, I found the existing TanStack Table implementation. I could see how it was structured, what patterns were used, and how it had been integrated in a real production environment.
From there, I combined three tools into a single workflow:
- CodeQA (via MCP server) to search and access the validated implementation from the other team's project,
- Claude Code to adapt those components to the new project's structure and requirements,
- Figma MCP to pull the client's design specs directly, ensuring the output matched the mockups.
I wrote a prompt telling it to take the table logic from the codebase and the designs from Figma. It pulled the components and adapted them to our project.
I worked feature by feature, monitoring the output at each step. Claude was not generating code from scratch; it was adapting production-validated patterns to a new context, with design fidelity enforced directly from the source Figma file. Without the previous implementation, I would still have needed to evaluate the library, validate architectural decisions, and understand edge cases myself. CodeQA didn't remove engineering work. It removed the need to repeat engineering work that had already been done elsewhere in the organization.
Results
Within a week I had a solid basic version in place: column resize, pagination, the ability to select elements, and styles applied according to the designs. The buttons were added but not yet functional.
The client was surprised. The table feature was estimated for 80 hours, and the feature was delivered design-matched, tested, and ready for sign-off, well under that estimate in 40 hours.
" What impressed us was how quickly the team delivered a solution that still matched our design expectations and remained flexible for future development."
Maria Lund Jensen, Co-owner and consultant at Processive MedTech
"What stood out to us was not simply faster implementation, but the ability to build on top of already validated engineering decisions instead of repeating foundational work from scratch. This is something we actively advocate for in our consulting work as well."
Barney Gerrard, Co-owner and consultant at Processive MedTech Development Services
What made the difference - three value dimensions stand out from this case
1. Production-ready as the baseline, not the goal
There is a meaningful difference between AI-generated code and production-validated code. Claude, working from general training data, could have built a TanStack Table, but with uncertain edge cases and untested integration patterns. The CodeQA baseline was code that had been built, deployed, and battle-tested inside Synergy Codes. Claude's role shifted accordingly: instead of library discovery and pattern validation, it handled adaptation and design matching. The hard work was already done.
2. Knowledge reuse without manual coordination
I knew a colleague had worked on something similar. What I needed was to find the exact implementation quickly, understand its structure, and adapt it, without scheduling a meeting to get a walkthrough. CodeQA collapsed that process into a direct query. My colleague could add context at a higher level, pointing to specific files, rather than re-explaining foundational decisions from scratch.
3. MCP integration as the multiplier
Before the CodeQA MCP server was available, I rarely used the tool. Once the integration connected CodeQA, Claude Code, and Figma into a single workflow, adoption was immediate. The compound effect, codebase intelligence feeding directly into an AI coding session, is what made the difference. "Once the MCP server is there, it all just moves fast," I said.
I knew the previous implementation was solid; it had already made it to production on another project. So I didn't have to redo that research. I pulled the components, adapted them for our client, and they were genuinely surprised at how quickly it came together.
The pattern this case reveals
In most engineering organizations, knowledge produced on one project stays on that project. When another team faces a similar problem, they start from zero: redoing research, revalidating patterns, making decisions that have already been made elsewhere.
CodeQA changes where that knowledge lives. Multi-repository search across internal knowledge means that a validated implementation from three months ago, on a different team, is as findable as something you wrote yesterday. The developer working on the new feature doesn't need to know the previous work existed. They just need to ask.
The Synergy Codes case is one instance of a pattern that repeats constantly across engineering teams: hard-won knowledge, siloed by team and project boundaries, rediscovered at cost by someone else.
CodeQA is built to fix that.
See how CodeQA gives your team instant access to your codebase's knowledge.
