About
An engineer who got tired of watching GTM stacks leak.
Ruslan Starikov · Senior engineer · founder of GTM Plumber
GTM Plumber is one person. I’ve spent 20+ years building production systems — software engineering, infrastructure and systems administration, and SaaS platforms — the last several of them inside go-to-market stacks: Salesforce and CRM integrations, enrichment and outbound pipelines, and automation and AI-assisted workflows.
The pattern was always the same: a team buys capable tools, wires them together in a hurry, and then spends the next year wondering why pipeline is short. The tools aren’t the problem. The architecture between them is.
GTM Plumber is the consultancy I wished existed when I was the one inside the stack. Senior, fixed-scope, teardown-first. I don’t write your copy or pick your channels. I make the machine your channels run on actually run.
I’d rather ship a working system on a Tuesday than a perfect deck on a Friday.
Credentials
Two decades, in shorthand.
20+ years
Building production software — infrastructure and systems administration through to the application layer.
Former CTO
Owned the engineering org, the architecture, and the hard trade-offs.
Founding GTM engineer
Built a go-to-market stack end to end, from list to mailbox to CRM.
Infrastructure, not growth
I don’t write copy or chase channels. I make the machine the channels run on.
Selected systems work
Representative systems, anonymised where required.
Much of my work has been completed inside operating SaaS companies, so client and employer details are sometimes anonymised. The systems, constraints, and outcomes described here are real.
Vendor-agnostic enrichment pipeline
B2B SaaS · outbound-driven GTM
The problem
Multiple enrichment providers bought separately, the same records paid for more than once, and no single view of coverage or cost.
What I built
One enrichment pipeline integrating multiple data providers behind a common interface — deduplication, caching, Salesforce synchronisation, filtering, instrumentation, and scheduled batch processing.
High-volume contact & account processing
Operating SaaS platform
The problem
Contact and account data moving between product, CRM, billing, and support at a volume where manual handling and ad-hoc scripts kept breaking.
What I built
Laravel queue and job pipelines processing contacts and accounts at high volume, with deduplication and caching, integrated across Salesforce, Intercom, Stripe, and analytics.
Reporting, monitoring & reliability
SaaS data stack
The problem
Pipeline health was anecdotal — nobody could put a number against a stage, so failures surfaced as missed targets weeks later.
What I built
Data-warehouse workflows on Redshift, plus monitoring and instrumentation across the pipeline, so each stage reports a number and failures surface when they happen — not at the end of the quarter.
How I work
Four rules I don't bend.
- 01 Teardown before build. You can’t fix what you haven’t measured.
- 02 Systems over tables. A motion that composes beats a sheet that breaks.
- 03 Downside, capped. The week-one exit isn’t a discount — it’s the point.
- 04 Leave it readable. The runbook matters as much as the result.
If your stack should be producing more, let’s look at it together.
Two observations, not a pitch.