Eko Replaces HubSpot Integration Roadblocks with Stacksync’s MySQL Sync
Learn how Eko replaced fragile HubSpot API work with a MySQL sync using Stacksync, keeping CI/CD intact and reducing ops overhead. Read the case study.
- Author
- Ruben Burdin · Founder & CEO
- Published
- January 22, 2026
- Read time
- 11 min read
Eko needed HubSpot to become the source of truth for operational entities, but HubSpot API based integration repeatedly broke their engineering workflow and amplified operational overhead as the company scaled.
With Stacksync, Eko synced HubSpot into a standard MySQL database, kept CI/CD and branching practices intact, and removed HubSpot specific code from the product so teams could ship faster with less risk.
Key Results
Outcomes Eko prioritized
- 01Preserve engineering velocity while making HubSpot operationally reliable
- 02Reduce cross-team overhead created by manual CRM to platform handoffs
- 03Standardize entity IDs across systems so operations can scale predictably
What changed after adopting Stacksync
- HubSpot became usable without embedding HubSpot SDK logic in the codebase
- Development environments stayed production-like by cloning a database mirror
- Manual spreadsheets and coordination noise dropped as systems moved toward consistent sync
Company Profile
Eko builds interactive product visuals for e-commerce, connecting physical capture workflows to a cloud platform that powers content, testing, and optimization. As Eko expanded enterprise partnerships and scaled factory operations, CRM data became tightly coupled to billing milestones, onboarding, and downstream workflows.
The Problem: Growth Turned Manual Handoffs Into a Systemic Risk
For years, Eko ran two parallel tracks:
- A homegrown platform built by engineering to deliver the core product
- HubSpot CRM used by business teams to manage marketing, sales, and deal terms
When Eko had fewer customers and larger custom deals, onboarding after a deal was signed was manageable. Teams would copy a few fields from HubSpot into an internal admin interface.
As volume and complexity increased, the manual handoff stopped being a small task and became a coordination system with real failure modes.
The real cost of manual processes
It was not only copy and paste. It was the operational management layer required to keep two systems aligned:
- 01Tracking work across spreadsheets
- 02Reviewing and validating what was completed
- 03Reconciling mismatches between CRM terms and operational reality
- 04Coordinating across Slack channels, tickets, and checklists
Before vs after Stacksync
| Area | Before Stacksync | After Adopting Stacksync |
|---|---|---|
| Data Flow | Manual data entry from HubSpot into internal admin tools, creating delays and inconsistencies. | Real-time, automated synchronization between HubSpot and a MySQL mirror. |
| Team Overhead | Heavy reliance on spreadsheets, frequent reviews, and coordination loops across teams. | Fewer handoffs, clearer ownership, and reduced operational noise. |
| Engineering Workflow | CRM treated as an external dependency that disrupts standard development practices. | Database-first workflow fully aligned with CI/CD pipelines and branching strategies. |
| Testing Reliability | Incomplete data, mocked records, and gaps in end-to-end testing. | Production-like datasets enabled through simple database cloning. |
====== KEY TAKEAWAYS (Stacksync blue theme) ======
Key Takeaways
Before Stacksync, teams struggled with manual processes, fragmented ownership, and CRM-driven constraints that slowed development and increased operational risk.
After adopting Stacksync, HubSpot becomes a real-time data source mirrored in MySQL, allowing teams to work with familiar database patterns instead of brittle CRM integrations.
The shift to a database-first model reduces coordination overhead, preserves CI/CD workflows, and enables reliable testing with production-like data, turning integration from a bottleneck into infrastructure.
Why HubSpot API Integration Broke Eko’s Engineering Workflow
Eko tried to automate onboarding with the HubSpot API. The first attempt was painful enough that the lesson stayed with the team.
""Hubspot is a pain in the ass because you rely on Hubspot and there's no easy way to get the data into the different environments."Yuval Hofshy, CTO at Eko"
The core issue was not that APIs are bad. It was the mismatch between HubSpot constraints and the development standards Eko had built over years.
Eko’s development model depends on production-like data
Eko invested heavily in infrastructure that helps teams ship safely and quickly:
- Branching workflows that spin up environments fast
- Production data cloning for realistic testing
- Repeatable migrations and automated tests
Databases fit this model naturally. HubSpot does not.
HubSpot sandboxes did not solve the problem
To safely test write-back flows, developers need a sandbox. In practice, sandboxes create gaps:
- 01They can be expensive at scale
- 02They rarely contain the full connected entity graph needed for realistic testing
- 03Moving production CRM data into a sandbox is not straightforward or automated
That mismatch forces engineers into mocks and partial testing, then pushes risk into production.
The Breaking Point: CRM-Centric Operations Needed Real Sync
As Eko’s business expanded, operations and commercial terms became tightly coupled.
What made the process more complex
- 01Deals shifted from a small number of custom customers to many customers with many products
- 02Billing included setup fees tied to factory work per product
- 03Subscription billing started only when content went live
- 04Factory workflows depended on payment milestones
The business terms lived in HubSpot, while execution happened across internal systems.
Eko’s architectural decision
Eko chose a CRM-centric model:
- HubSpot is the source of truth
- Core entities and IDs originate in HubSpot
- Every downstream system uses consistent identifiers
This is where the HubSpot API problem returned, now as a mission-critical scaling constraint.
The Solution: Sync HubSpot to MySQL and Keep Standard Dev Practices
Eko adopted Stacksync to work with HubSpot through a standard database interface.
""In our code base there is no Hubspot SDK or package or anything. It just doesn't exist."Yuval Hofshy, CTO at Eko"
The database-centric approach
Instead of wiring HubSpot API calls into product code, Eko synced HubSpot objects into MySQL and treated that mirror like any other internal database.
What changed in the codebase
- 01Application logic reads and writes using SQL against MySQL
- 02Stacksync handles sync with HubSpot in the background
- 03Developers keep using the same tooling and patterns they already trust
Production-only sync model
Eko configured sync for production, then cloned the database containing HubSpot data for dev environments.
This removed several recurring pain points:
- Developers do not modify real CRM data while building features
- Testing happens with production-like data without requiring a HubSpot sandbox
- CI/CD stays consistent because tests run against databases
Why Stacksync Won the Evaluation
Eko evaluated multiple options and focused on what matters when integration becomes operational infrastructure.
Evaluation criteria that mattered for Eko
| Evaluation Question | Why It Mattered | What Eko Needed |
|---|---|---|
| Does it work quickly during evaluation? | Early failure is a strong signal of hidden complexity that will surface later in production. | A solution that syncs reliably without weeks of setup or heavy implementation effort. |
| Does it fit our CI/CD and branching model? | Engineering speed compounds, anything that slows delivery becomes a long-term competitive drag. | A database-first workflow with production-like development data that fits existing CI/CD and branching. |
| Can we avoid embedding CRM complexity in product code? | Embedding CRM logic increases maintenance burden and makes the system more fragile over time. | No HubSpot SDK dependency in the codebase; engineers work with familiar database patterns. |
| Will the vendor be responsive when issues happen? | Operational systems break, when they do, teams need accountability and quick resolution. | High-touch support, rapid troubleshooting, and fast iteration when edge cases appear. |
====== KEY TAKEAWAYS (Stacksync blue theme) ======
Key Takeaways
Eko’s evaluation focused on one thing: protecting engineering velocity while making HubSpot integration reliable enough for daily operations.
They prioritized solutions that worked fast during evaluation, matched their CI/CD and branching model, and avoided pushing CRM complexity into product code.
Finally, they treated support as a core requirement, because for operational sync, responsiveness and accountability matter as much as features.
Eko’s perspective was simple: the solution should remove the problem, not create a new engineering project.
Executive Takeaways: The Business Impact Behind the Technical Story
Engineering friction is visible. Operational risk is often hidden until scale makes it expensive.
When CRM terms drive operations, mismatches create real risk
If deal terms affect billing milestones, factory work, entitlements, or provisioning, misalignment between systems can cause:
- Incorrect invoicing
- Delays in fulfillment
- Wrong entitlements or onboarding steps
- Reactive coordination work that slows the business
Manual sync scales coordination, not output
As the company grows, manual sync adds:
- 01Review cycles
- 02Follow-ups
- 03Communication noise
- 04More opportunities for things to go out of sync
Reducing manual sync is not only about efficiency. It is about building a calmer operating system for growth.
What’s Next: From Sync to Event-Driven Operations and Production Observability
Eko shared two forward-looking needs that appear when sync becomes mission-critical.
Triggers and workflows with secure webhooks
Real-time sync is the foundation. The next layer is reacting to events safely, such as:
- 01Deal stage changes that trigger provisioning
- 02Payment milestones that unlock factory steps
- 03Record updates that trigger downstream processing
DevOps-grade monitoring and alerting
Teams need sync health to integrate with the same observability stack they use for other production services.
""Instead of struggling with the Hubspot... we can focus on our core technology."Yuval Hofshy, CTO at Eko"
A practical starting point is routing logs and failure signals into centralized monitoring so incident triage follows existing DevOps workflows.
How to Apply This Pattern in Your Company
If your team is feeling HubSpot integration pain or CRM-driven manual overhead, this approach is replicable.
A pragmatic rollout sequence
- 01Identify the core entities where HubSpot must be the system of record
- 02Sync those objects into a database mirror used by internal systems
- 03Remove HubSpot SDK and direct HubSpot API logic from product code
- 04Make dev environments production-like by cloning the database mirror
- 05Add observability so sync issues behave like first-class production incidents
Turn HubSpot From a Bottleneck Into Scalable Operational Infrastructure
If HubSpot integration is slowing product development, forcing spreadsheet-heavy coordination, or blocking CRM-centric operations, a database-centric sync model can remove the friction without sacrificing engineering standards.
Stacksync makes HubSpot usable through the database patterns your team already trusts, so you can scale operations while keeping engineering focused on differentiated work.
Book a demo to see how this integration pattern would apply to your HubSpot objects, write-back flows, and operational systems.
FAQ
Frequently asked questions
