Datamasque wasn’t born from a brainstorm—it was built out of necessity, stubbornness, and a serious security blind spot
Paul Tomlinson didn’t have a grand “aha” moment when he helped create Datamasque. What he had was a mess—a growing one. Back in 2015, inside Spectrum, his Wellington-based tech firm, enterprise clients were suddenly producing dozens of copies of sensitive data across their dev environments. It wasn’t innovation. It was chaos.
So he built a tool to clean it up. Not because it sounded cool in a pitch deck, but because no one else had. And because someone had to.
“We weren’t chasing the shiny stuff,” Tomlinson says now, almost a decade later. “We were solving a real problem that just kept getting worse.”
The masking problem no one wanted to talk about
It started like most operational headaches—quiet, in the background, until it wasn’t.
Around the mid-2010s, data virtualization was gaining steam in large organizations. Technologies like Actifio (since absorbed into Google) and later Cohesity gave teams the power to spin up clones of production databases in seconds. Developers loved it. QA loved it. Business units wanted their own sandboxes. But there was a catch.
Each of these clones contained sensitive, production-grade data—names, addresses, credit card numbers, health records.
And no one was masking them.
Tomlinson watched as some clients went from one live database to 50+ full copies. One client? Ninety. All containing personally identifiable information (PII).
“People were acting like the dev environment was a playground,” he says. “But it had real-world consequences. It was an attack surface explosion, and nobody owned it.”
Then came GDPR, and suddenly, those risks had teeth.
The first fix… and the first faceplant
Spectrum’s initial move was textbook smart: don’t reinvent the wheel. They surveyed third-party masking tools on the market, hoping to integrate them into clients’ workflows. But what they found was discouraging.
“Over-engineered. Expensive. Totally not designed for agile dev cycles,” Tomlinson recalls.
Instead of shrugging and walking away, Spectrum doubled down. They put their own engineers on it. The idea? Build something lightweight, developer-friendly, and cloud-native. Maybe even plug it directly into data marketplaces and pipelines.
That idea ran headfirst into a wall.
Marketplaces weren’t ready. APIs were immature. Clients weren’t buying.
“That could’ve been it,” he says. “We’d spent time and money, and our go-to-market plan just wasn’t happening.”
Here’s where most founder stories would end—with a nice post-mortem PowerPoint and a quiet sunsetting of the project. But that wasn’t what happened.
The second plan was simpler—and stronger
Rather than fold, the Spectrum team regrouped. They took the bits that worked and scrapped the ones that didn’t. The big idea now wasn’t to integrate into a system—it was to stand alone.
Enter Datamasque: a simple, focused, scalable product built to do one thing well—mask sensitive data across non-production environments before it ever became a problem.
It wasn’t flashy. But it worked.
And more importantly, it made sense for the people actually using it—developers, DevOps teams, and data compliance leads trying to sleep at night.
What they got right where others fumbled
The secret to Datamasque wasn’t technology alone. It was how well it fit into real-world workflows. And that wasn’t an accident.
Tomlinson says the team stayed obsessed with one question: “What’s actually getting in the way?”
So they designed Datamasque to:
-
Work across any database or file system without needing complex setups
-
Plug into CI/CD pipelines with minimal config
-
Stay developer-friendly, with clear docs and CLI access
-
Keep pricing sane for mid-market companies
They didn’t chase buzzwords. They chased ease of use.
And it paid off.
The product-market fit nobody talks about
There’s a lot of hype in tech about “finding product-market fit.” But sometimes it’s less about a single moment and more like water finding cracks.
Datamasque didn’t hit a hockey-stick growth curve overnight. What it did have was traction—steady, honest traction.
Here’s what the adoption curve looked like in the first few years:
| Year | Clients Onboarded | Average DBs Masked per Client |
|---|---|---|
| 2018 | 7 | 15 |
| 2019 | 16 | 28 |
| 2020 | 39 | 45 |
| 2021 | 52 | 61 |
| 2022 | 77 | 73 |
The interesting bit? Most clients didn’t come through sales funnels. They came from developers recommending the tool on Slack or LinkedIn.
“Nobody was writing case studies, but they were using it,” says Tomlinson.
New Zealand’s unique edge in long-haul innovation
Building a tech company in New Zealand isn’t like building one in Silicon Valley.
There are fewer VCs, longer sales cycles, and way less room for hype cycles. But Tomlinson argues that’s exactly why Kiwi firms tend to build differently.
“We don’t throw cash at the first shiny thing,” he says. “We test, we fail, we listen. And because of that, we end up with businesses that last.”
He’s not wrong. Companies like Xero and Pushpay didn’t become global players because they raised the biggest rounds. They earned it over time.
Why resilience beats brilliance every time
Tomlinson doesn’t pretend to have cracked some secret formula. If anything, he’s skeptical of how often founders glorify the grind. But he does believe in one thing—showing up when the idea stops being fun.
“Everyone’s got a great idea. That’s not the hard part,” he says. “The hard part is keeping your team focused when it’s not working.”
For Spectrum and Datamasque, resilience wasn’t a value on the wall. It was a practice. A muscle. And it might be the most underappreciated innovation strategy in tech today.
