Key facts
- Role: Customer Support SME
- Background: Systems Analyst and Programmer
- Impactful project: CS Global Toolbox
Paultre is originally from Haiti, where he trained as a systems analyst and programmer. Some of his early work stuck with him more than anything else: he was part of the team behind a computer center built with support from the Orphaned Starfish Foundation in Les Cayes, a project that gave kids and young people in the area their first real hands-on exposure to computing.
After that, and a stretch working in the restaurant industry, he went looking for a bigger challenge and better job opportunities. That search led him to move to Argentina, a decision he describes almost casually now, in the way people tend to talk about the ones that actually took a lot to make.
He started working at Holafly about three years ago as a Customer Support agent, moved up to Advocate, and is now an SME, one of the team’s “seniors”, as he puts it with a laugh.
A small daily frustration that sparked an idea
The project that eventually became the CS Global Toolbox started with something many would overlook: agents needed to calculate coupon values, and the team was doing it in an Excel sheet that kept falling apart. “It would get all messed up, reset, and we’d have to go back to a previous version”, Paultre says. It was the kind of daily annoyance most people just learn to work around.
But the day came when a coworker said something out loud in the middle of a meeting: wouldn’t it be great if someone built this as an actual webpage instead, something that wouldn’t fall over every time someone touched it? Paultre took it as a challenge rather than a passing comment. He built it, on his own time, and shared it with his colleagues.
It caught on faster than he expected: first his own team started using it, then word reached the wider Americas team. Soon people who had nothing to do with the original spreadsheet problem were relying on this tool; everything thanks to a coworker’s offhand comment that happened to land on the right ears.
That’s when the idea stopped being about coupons. “If I can build one, I can build two or three,” Paultre remembers thinking, “and I can bring more people in too, if there are people who are good with code or with AI-assisted programming”.
Don’t wait for an invitation to get started
Once the coupon calculator had spread on its own, turning that into something bigger, an actual toolbox, meant facing a choice. The traditional next step would have been to go to a manager and ask for a tool to be built through the usual channels: a request, a queue, a wait.
But Paultre went a different way: instead of asking for something to be developed, he built a working mockup first, an MVP, and brought it to leadership already halfway finished. “You skip all those steps”, he says. “You make a proposal, a model, and you show it to your manager. They check it’s all in order, security requirements and everything, it gets approved, and you start using it.”
It’s a shortcut that’s only realistic now, he points out, because of how much AI has changed what one person can build alone. What used to take a small team almost six months, he says, a single developer can now put together in about a month.
But speed wasn’t really the hard part; it was whether anyone would say yes. “We can propose a thousand things”, Paultre says, “but if we don’t have a team or a leader backing us, giving us room for those initiatives, it’s almost impossible.”
How a simple idea can become an impactful project
When the first idea came to life, there wasn’t really a designated place to pitch something like this, so Paultre raised it in the channel his team used to reach leadership, unsure if it even belonged there.
“Sorry, I know this might not be the right channel,” he remembers writing, “but here’s the idea: a toolbox for the team, here’s roughly how it would work. What do you think?”
The response came the same day, and one CS Manager cleared the runway for everything that came after: he followed up asking for something more than a working mockup. He wanted an actual proposal. “It’s great to have all the enthusiasm to build an MVP and present it”, Paultre remembers being told, “but a project needs structure”.
He was asked to clearly define what the problem was, how he planned to solve it, what the benefits were and the return on investment. “Things I hadn’t really thought of as concepts before”, he admits, “but over time you realize it matters, because it’s not just about doing things because you can or because you want to. You have to see whether it’s actually worth doing.”
Putting that structure together took the first month. His team leader at the time helped him track down the information he needed along the way. It took about a month and a half in total before the first version of the Toolbox actually shipped, and it’s been running ever since.

Bringing a project to life also requires learning when to let go
Once the project had real backing, the challenge shifted somewhere Paultre didn’t expect: his own ambition. “I wanted to take on too much”, he says, “and the time just wasn’t there to deliver on schedule”. He’d get an idea for one more feature, one more tool, and the scope would quietly expand past what he could realistically finish.
His manager became the person who kept pulling things back into focus by narrowing the question. “He let me imagine all the things I wanted to do”, Paultre says, “but then he’d call and say, look, this is the time we actually have, this is what matters right now, and the rest comes later”. So Paultre went back to the data, figuring out what was actually needed most, and forcing himself to stick to the plan instead of chasing every new idea as it came up.
How a tiny fix can have a huge impact
Ask Paultre to explain what the Toolbox actually does and he reaches for a concrete example: installing an eSIM used to mean copying and pasting manual activation codes by hand whenever the QR code failed to scan. Now it’s a single link, sent in a single message.
What used to take four or five separate steps, now takes one. On any individual chat, that might only save a minute. “But multiplied by 50,000 or 100,000 conversations”, Paultre says, “we save a lot”. It’s the kind of fix that looks small at first glance, until you see it at scale.
Taking the initiative can open doors for others
The tangible time saved is one part of the story; the other part is what people on the team now see as possible for themselves. One outcome Paultre didn’t see coming, but had quietly hoped for, was watching a small crew of coders start forming inside Support who hadn’t been coders before.
A fellow SME on his team is now building his own addition to the Toolbox, a coverage finder, expected to ship this month. “He saw that I got room to be creative, and thought, if Paultre did it, I can do it too,” Paultre says. He’s been supporting him through the build ever since. “It opens things up for everyone. If you have skills you can offer, the company is going to give you room to use them.”
Teach the fix, don’t just hand it over
Somewhere in that process, Paultre picked up a lesson that had nothing to do with code. When his manager already sees a bug and knows exactly how to fix it, Paultre noticed, he doesn’t just hand over the answer.
“He’ll tell you, try asking this, see what it says, and let you find your own way there instead of giving you the solution directly.” Paultre calls it the sensei approach, and it stuck with him enough that he started using it himself.
When that same fellow SME needed to build a logger for his coverage finder, Paultre pointed him toward where to look instead of writing the code for him. A week later, the problem was solved, entirely on his own. “It was kind of a flashback moment for me,” Paultre says. “I loved it.” For him, that’s the real return on a project like this: not just the tools themselves, but the people who go on to build their own.
What makes the balance possible
None of this runs on willpower alone, and Paultre is upfront about what actually holds it together. “Honestly, I don’t think I could do it without my wife”, he says, the first thing he credits when asked how he keeps building on the side without burning out.
The second is knowing when to stop before he needs to be told. “Today’s my day off, I’m not opening the laptop, because I know if I open it, I’ll get pulled back in, I’ll start looking at things, wanting to build things.”
The recharge itself looks a lot like the same restless energy that drives the Toolbox, just pointed somewhere else. He plays guitar, sings (his team may remember the Holafly jingle he wrote for an internal contest), and has recently gotten into 3D printing and ceramics. “I stay connected to technology”, he says, “but I try to set a mental block: work isn’t coming in today”.

Are you still sitting on an idea? Dream big.
Paultre’s answer is short. “We already have the ‘no,’” he says. “So what’s there to actually be afraid of?” If an idea isn’t quite right as pitched, he says, the team will say so and help refine it rather than shut it down outright.
“You dream big, and then you bring it back down to earth when you actually need to, toward where it’s really needed.” Asked which of Holafly’s values best describes what pushed him to build the Toolbox in the first place, he doesn’t hesitate: being brave, paired with making things happen.

If you are also ready to make things happen, or if you are sitting on an idea of your own, Paultre’s story might sound familiar. Check out our open roles on the Careers Page.