We consolidated the architecture and built the team. The client's volume grew 4x.

Beyond Finance needed more than code fixes. Their microservices were a mess, their team practices were ad-hoc, and they were scaling fast with no process to support it. We embedded with their team, consolidated the architecture, and built the engineering culture that let them grow 4x.

Beyond Finance and Made In Tandem development team collaborating in person

Technical debt and organizational debt are the same problem wearing different clothes.

Beyond Finance builds customized debt management and consolidation solutions for consumers. Their platform is a constellation of interconnected systems: Salesforce, web and mobile frontends, a Salesforce backend database, backend APIs, a payment and escrow processor, and a task runner. When we joined, that constellation looked more like a tangle.

The codebase had the hallmarks of a company that grew faster than its engineering practices could keep up. Duplicate logic scattered across microservices. Inconsistent patterns that made onboarding new developers painful. Testing that nobody trusted. And a team that, by their own admission, wasn't functioning the way they wanted to.

Our engagement started as technical support and grew into something bigger: rebuilding both the architecture and the engineering culture from the inside. Not by parachuting in with a playbook, but by embedding with the team, earning trust, and showing what "better" looks like in practice. By the time we rolled off, three developers had stepped into team lead roles, and the company had quadrupled its client volume.

Broken code patterns mirror broken team patterns. Beyond Finance had both.

The technical issues were visible: duplicated logic, inconsistent APIs, and testing gaps. But the root cause ran deeper. The engineering team didn't have the practices, the processes, or the shared vocabulary to tackle these problems together. Fixing the code without fixing the culture would've been a temporary patch.

The microservice architecture had accumulated the kind of entropy that happens when a codebase grows faster than a team's ability to maintain coherent boundaries. The same ORM logic lived in three different services. Logging and traffic handling were implemented differently everywhere. New developers faced significant cognitive overhead just figuring out how things were supposed to fit together, let alone making changes without breaking something downstream.

Testing was a sore spot. Both developers and QA found end-to-end testing so difficult that it often didn't happen. Multiple mapping styles made it nearly impossible to draw clean boundaries between services. And the team itself was working in silos: information stayed trapped with whoever happened to write the code, reviews were inconsistent, and retrospectives either didn't happen or happened without structure.

Beyond Finance recognized this. They didn't just want someone to write code alongside them. They wanted someone who could help them build the internal processes that would carry them through their next phase of growth. That's a different ask, and it requires a different kind of engagement.

4x Client volume growth during engagement
6+ Microservices consolidated into shared architecture
3 Developers mentored into team lead roles

The architecture when we arrived

BEFORE · FRAGMENTED MICROSERVICES 01 Service A ORM logic (v1) Logging (custom) DUPLICATE CODE 02 Service B ORM logic (v2) Logging (different) DUPLICATE CODE 03 Service C ORM logic (v3) Logging (yet another) DUPLICATE CODE 04 Payment Svc Own domain model Own error handling INCONSISTENT PATTERNS 05 Task Runner Sidekiq jobs Own config SILOED LOGIC MISSING FOUNDATION NO SHARED PACKAGES NO UNIFIED DOMAIN MODEL NO OBSERVABILITY TESTING: PAINFUL ONBOARDING: SLOW BOUNDARIES: UNCLEAR

Embed first. Earn trust. Then change everything.

We didn't show up with a transformation roadmap and a Gantt chart. We joined the team, paired on real work, and built credibility through consistency and craft. The process improvements came after the trust was established, not before.

01

Team assessment & integration

We started by working alongside Beyond Finance's engineers on their existing codebase, not by auditing it from the outside. Pairing on real tickets gave us a direct view of where the friction lived: which patterns confused new developers, where testing broke down, and which conversations weren't happening. That embedded perspective shaped everything that followed.

Paired programming · Codebase assessment · Process observation
02

Process design & agile coaching

Beyond Finance's team self-identified that their day-to-day practices weren't working. Sprint planning felt like guesswork. Code reviews were inconsistent. Retrospectives either didn't happen or produced no action items. We worked with the team to refine their working approach, centered around de-siloing information and encouraging genuine communication. A rotating retro moderator gave everyone a voice. A weekly developer forum built camaraderie and sharpened technical presentation skills.

Sprint refinement · Retro guidelines · Developer forums · Documentation coaching
03

Technical consolidation

With the team aligned on how to work together, we tackled the architecture. Consolidated duplicated ORM, logging, and traffic-handling code into shared packages that any microservice could use. Then came the bigger judgment call: showing Beyond Finance the benefits of a majestic monolith over their fragmented microservice sprawl. Better developer experience, consistent frameworks for talking to external systems, unified error handling, and complexity managed through feature flags instead of service boundaries.

Shared packages · Domain consolidation · Majestic monolith · Feature flags
04

Mentorship & leadership development

Three developers on Beyond Finance's team had the instincts and the drive to lead. What they lacked was the scaffolding: how to build processes, how to partner with stakeholders, how to make technical decisions that balance pragmatism with craft. We mentored them through the transition, building up their technical savvy alongside the soft skills that make the difference between a strong individual contributor and a team lead who multiplies everyone around them.

Leadership mentoring · Stakeholder partnering · Technical decision-making
05

Handoff & sustained autonomy

The goal was never to become a permanent fixture. We built templates for documentation, turning what the team dreaded into something painless. We established the forums and retro cadences that would run without us. By the time MiT rolled off, the team had the practices, the leaders, and the confidence to keep improving on their own. That's the real deliverable: a team that doesn't need you anymore.

Documentation templates · Self-sustaining processes · Team independence

Embed-to-handoff process

Five phases, each building trust and capability. We didn't prescribe changes from outside; we earned the right to suggest them by doing the work alongside the team.

01 Team Assessment Pair on real work Map friction 02 Process Design Retros & pairing De-silo the team 03 Technical Consolidation Shared packages Majestic monolith 04 Mentorship & Coaching 3 new team leads Leadership skills 05 Handoff & Autonomy Self-sustaining Team independence

A majestic monolith, a shared language, and a team that could run without us.

The work split into two tracks that reinforced each other: technical consolidation that made the codebase simpler to reason about, and cultural changes that gave the team the practices to maintain that simplicity long-term.

Shared packages across services

We consolidated the duplicated ORM, logging, and traffic-handling code into reusable packages that any microservice could pull in. A change to logging no longer meant making the same edit in six different places. Developers could write it once and apply it everywhere, which sounds simple until you've worked in a codebase where "everywhere" meant something different in each service.

The majestic monolith

This was the judgment call that defined the engagement. Beyond Finance's microservice architecture wasn't serving them; it was slowing them down. We showed them what a consolidated domain model and unified framework could look like: consistent error handling, easy-to-understand patterns for interacting with Salesforce and other external systems, and complexity managed through feature flags rather than service boundaries. The monolith wasn't a step backward. It was a recognition that their team size and their problem domain called for simplicity, not distributed complexity.

Observability with New Relic

We integrated their systems with New Relic, giving the entire organization visibility into application performance and post-release behavior. Before this, "is the deploy working?" was answered by customer complaints. After, it was answered by dashboards. That shift in feedback loops changed how the team thought about shipping code.

API automation and rules engine

Manual processes that ate developer hours got replaced with APIs and automated workflows. We introduced an extensible rules engine that could handle the business logic variations across Beyond Finance's growing client base without requiring custom code for each new scenario. The API layer we maintained served Salesforce, web, and mobile clients through a single, consistent interface.

BEFORE SILOED DEV DEV DEV ? ? Siloed work · Ad-hoc reviews Tribal knowledge · Cowboy coders NO RETROS · NO DOCS EMBED · COACH · CONSOLIDATE AFTER CONNECTED LEAD LEAD LEAD Paired programming · Structured retros Living docs · Weekly forums COHESIVE · SELF-SUSTAINING

Consolidated architecture

Shared packages extracted, domain model unified, and observability added. The same team that struggled with six inconsistent microservices now works in a coherent system with clean boundaries.

AFTER · CONSOLIDATED ARCHITECTURE CLIENTS Salesforce CRM integration Web Frontend Browser SPA Mobile Apps iOS + Android PLATFORM Majestic Monolith RUBY ON RAILS · SIDEKIQ · UNIFIED DOMAIN Shared ORM Unified Logging Rules Engine Consolidated Domain Model + Feature Flags New Relic Observability APM · LOGS DOWNSTREAM Payment / Escrow Regulated processor Task Runner Sidekiq workers UNIFIED API LAYER · GRAPHQL + REST · NODE.JS + EXPRESS

The team leveled up. The client volume followed.

By the end of the engagement, Beyond Finance's engineering team had gone from what they themselves described as "cowboy coders struggling to manage timelines" to a cohesive group actively improving their own practices. The business results tracked with the cultural shift.

4x Client volume growth
6+ Microservices consolidated
3 New team leads developed from mentorship
100% Retro participation with rotating moderators

The technical improvements were real and measurable. Shared packages eliminated the duplicated code that made every change a multi-service ordeal. The consolidated domain model gave new developers a single, coherent system to learn instead of six inconsistent ones. New Relic integration meant the team could ship with confidence, watching performance data instead of waiting for customer complaints.

But the cultural work mattered just as much. Beyond Finance's developers weren't stuck anymore. They had structured retros with rotating moderators where every voice counted. They had a weekly developer forum for sharpening technical skills and building trust across the team. They had documentation templates that turned a chore into a habit. And three of their developers had grown into team leads who could carry the engineering culture forward without external support.

The 4x client volume growth wasn't something we built in code. It was a business outcome that became possible because the engineering team could finally ship fast enough, reliably enough, and confidently enough to support it. That's the connection between code architecture and organizational health: fix both, and the business can grow.

Bring this pattern to your organization.

Code architecture and engineering culture aren't separate problems. When senior engineers embed with your team, both improve at the same time.