It started as a problem, not a plan

Was building Nodegraph in-house your call, or were you handed it?

I wasn’t handed a finished product or a perfect plan. What I received was a problem: a very complex support structure and a CSV with “simplified” policies. To understand them, I built a small dashboard to load the CSV and visualise the flows. That was the first seed of Nodegraph.

Then it grew through collaboration. Álvaro Mata built the engine that runs the chatbots, while I built the service layer that provides the policies and operational logic behind them. Once those two pieces came together, we realised we weren’t building a small internal tool — we had the foundation for a full support automation platform. So I saw the problem, started building a way to solve it, and it grew into something much bigger than the original idea.

Explain Nodegraph like we’re not engineers.

Nodegraph turns operational knowledge into automated support. We use nodes as building blocks — questions, answers, actions, forms, conditions, decisions — and connect them into flows that guide a customer, a merchant or an agent through a support process. Instead of FAQs in one tool, decision trees in another and bots separated from all of it, everything lives in one platform we own and can evolve ourselves.

Replacing Zingtree

You replaced an outside vendor with something built in-house. What did that actually take?

It wasn’t just a technical migration — it meant understanding years of support logic that had grown inside a very complex tree. Their API didn’t give us all the wiring we needed, so I had to reverse-engineer parts of the structure and use it almost like an API to extract the knowledge. Then we simplified hard: the old process had a huge number of refund outcomes, and we cut that down to a small set of clear ones.

What started as a way to power support agents with that knowledge became the full Nodegraph platform — and eventually let us replace Zingtree completely.

Speed over comfort

What did you put live before it was fully “ready,” and what did going live teach you?

The intake forms. We needed them to replace Zingtree and had about three days. Nodegraph didn’t yet have a way to bridge internal Groupon endpoints and configurable forms, so we built the structure fast — not the polished long-term version, but something real the team could use. The day before the replacement, we also had to inject those forms into public FAQ pages, which Nodegraph didn’t support. It wasn’t comfortable, but we made it work, and it still works.

The lesson: when the business needs something urgently and the risk is controlled, build the structure that lets the process move forward, then improve it with real usage. Ship the useful version, learn from how people actually use it, then polish it.

You’ve got a reputation as one of the fastest builders here. What does “fast” actually look like?

Fast doesn’t mean careless. It means understanding the problem well, defining clearly what needs to be built, and removing unnecessary friction between the idea and the result. I read the code, define the specs, then launch several coding agents in parallel and review their work properly.

“AI can help you move very fast, but the responsibility is still yours.”

If you don’t understand what’s being built, the AI can hallucinate and you’ll pay the price. AI doesn’t replace the engineer — but it gives a good engineer much more leverage.

What the numbers actually mean

Deflection went from 45% to 72.5% in six months. In human terms, what changes?

For customers, help comes faster, with fewer unnecessary steps. For agents, the repetitive work starts to disappear from the queue, so they can spend more time on the complex cases where empathy, judgement and human context really matter. The queue gets lighter, answers get more consistent, and people reach a resolution faster.

And this impact isn’t only mine — a platform doesn’t create deflection by itself. The Knowledge Management team, led by Samuel García Río, turned policies into flows customers could actually use, and Zeph Buck led the product vision so we were solving the right operational problems. My role was to build the platform; theirs was to turn it into better support experiences.

Bringing this in-house takes roughly $500K a year off the table. Beyond the money, what changes?

Saving around $500K a year matters, but the bigger win is ownership. When you depend on a vendor, you depend on their roadmap and their limits. When we own the system, we can move faster, connect it to internal tools, and build exactly what Groupon needs instead of adapting Groupon to a vendor.

“The real value isn’t only spending less money — it’s becoming much more capable.”

Off the org chart

You’re one of Groupon’s top customers in Spain. Does that change how you build?

Definitely. I use Groupon a lot, especially in Madrid, so I see what works, what feels good and what creates friction. It also makes me care more — I’m not building for an abstract customer in a report, I’m building for people like me. It makes the work less theoretical and much more personal.

What’s one thing about how you work that people wouldn’t guess from your title?

That I enjoy getting into the mud a bit. I don’t mind messy problems — actually, I like them. A broken process, disconnected systems, unclear ownership: that’s usually when I’m most motivated. My title says engineering, but a lot of what I do is connecting boxes — business needs, support, customer pain, internal tools, AI, code and people. The part I enjoy most is taking something messy, getting into it properly, and making it simple enough for other people to use.

And — thank you. Seeing Nodegraph grow from something we built to solve a messy problem into a platform more teams are starting to use is something I’m genuinely proud of.