Jonas Mets

Jonas Mets's public voice is that of a builder who keeps returning to one obsession: data quality inside HubSpot, specifically the twin problems of invalid emails and duplicate records. Across his posts this shows up again and again, not as an abstract principle but as a concrete operational claim. He cites Ryan Gunn's answer to what to check first in a messy portal, "Invalid email addresses" and "Duplicate records" , and builds his entire product narrative around the idea that these two issues "compound everything downstream in HubSpot" . His own product, Koalify, is pitched directly at this problem: "Catch bad and invalid emails before they clog up your CRM, so you're not fixing the mess later" . The consistency between what he says other RevOps people should watch for and what he actually builds is one of the clearest threads in his output.

A second recurring theme is that data hygiene is not a one-time cleanup but an ongoing process. He is explicit that fixing a backlog once doesn't solve anything, because "neither one stays fixed on its own" as new form fills, integrations, and sync tools keep generating fresh mess . This same logic drives his framing of a messy CRM more broadly: rather than treating disorder as failure, he argues "a messy CRM isn't always a failure," that early on "duct tape and good intentions is usually the right call," and that the real skill is spotting "the moment it flips... when the shortcut starts costing more than the fix" . This is a notably forgiving, almost operational-maturity view of RevOps work, distinct from a purist's insistence on constant tidiness. He credits Sarah Lane-Hawn for crystallizing the idea that operations becomes a priority "when the efficiency gap is what's holding back scaling," not before .

On the technical and product side, Mets is precise about mechanics rather than vague about outcomes. Describing Koalify's merge rules, he explains the core problem plainly: "Merging feels like a gamble on which data survives" when HubSpot's default keeps the primary record's value and drops the rest . His fix, letting users set rules like "Latest / Earliest" or "Highest / Lowest" per property, is described in the same practical register he uses throughout: solve it once, apply it everywhere, "on every merge manual, bulk, or running automatically in the background" . He extends this same instinct for depth-over-surface thinking to integrations generally, endorsing Sarah Lane-Hawn's framing that the real evaluation questions are "at what level" a tool integrates, which objects it covers, how often it updates, and "who owns the association logic" . His conclusion, that integration depth mattered more than features or price in a real vendor decision, reflects a broader distrust of surface-level claims like "It integrates with HubSpot" .

He is also attentive to the mechanics of trust and visibility inside client portals, not just data. Praising Christian Baun's habit of mapping every workflow on arrival at a new HubSpot portal and presenting back "what's broken, what's disconnected, and what needs to change," he calls it a "simple habit" that produces "immediate trust" . This dovetails with his own observation that most portals have a workflow problem nobody names: automations silently chain into each other until "a new admin inherits the whole thing and has to make sense of it from scratch" . He's skeptical of static documentation tools like Miro or Lucidchart for this reason, since they "always go stale" , favoring instead the idea of continuous visibility over one-time diagrams.

On building product specifically for HubSpot, he shows a clear opinion about what counts as good citizenship inside someone else's platform: building with native components so an app "doesn't feel like a third-party app bolted onto HubSpot," but instead "feels like HubSpot" . This extends into a broader appreciation for the ecosystem itself, less about tools and more about people, as when he reflects that "Building in the HubSpot ecosystem has been the best decision we've made at Koalify... mostly because of the people in it" .

Finally, his account of his own working style, drawn from the RevOps500 podcast, adds a personal throughline to all of this: an admitted mistake of overcommitting across freelance project work, building the Qualify app, and family responsibilities at once, followed by a deliberate narrowing, stopping freelance work and hiring a dedicated RevOps person so he could concentrate solely on the product ¹⁶. That arc, from scattered focus to concentrated execution, tracks closely with the operational philosophy he preaches to others: identify the moment the old approach stops working, and change it before it costs more than the fix . The takeaway across his public statements is consistent: clean data and clear systems are not moral virtues to chase at all times, but operational necessities to install at the right moment, and matched by an equally deliberate focus in how he runs his own work.