Sean co-founded Flexitech in 2013 with Kevin, Henry, and Peter — still at university, still figuring out what HTML actually meant in practice, learning to translate our professor’s explanations just to keep up. By 2015 we’d met Marc and Andries, worked together on Slash Pay, and by 2017 what eventually became Slash had taken shape as a software boutique helping startups and businesses build their platforms. When Flexitech merged into Slash, his goal from the beginning: building a place where people could grow and belong, felt, for the first time, more or less realized.
Thirteen years of full-stack engineering later. Seven in a leadership capacity. AWS Certified Solutions Architect. Architecture lead on WFP PRISM, the World Food Programme’s real-time monitoring platform. Financial infrastructure for AXA Singapore, validated against Monetary Authority of Singapore compliance requirements. AWS User Group Cambodia organizer. Tech lead for FileAI. And, as of this year, acting CTO.
Here’s what a decade of building taught him.
Q1: The Flashback
“When you first joined Slash, what did you honestly think this place was going to be, and how far off was your initial guess?”
The journey is a bit different from just “joining.” There’s a history behind it, what Slash was doing back then, and what I was doing.
I co-founded Flexitech in 2013 with Kevin, Henry, and Peter, starting with little to almost no real client web development knowledge, we were still at university, learning HTML and CSS and listening to our professor translate the terms for us. Fast forward to around 2015, we met Marc and Andries and worked together on Slash Pay. Slash itself evolved through a few rounds of discussion and experimentation before landing, in 2017, as a software boutique focused on helping startups and businesses build their platforms.
Slash Pay
Slash Pay Dashboard
My goal with Flexitech was to create a place where people could grow and belong. By the time we merged into Slash, that goal was more or less realized. Since then, across many years and many roles at Slash, I’ve kept rediscovering what I actually want to do, through the challenges, the feedback, and the work itself.
Q2: The Global & Remote Reality
“After years of working remotely across different cultures, languages, and time zones, what’s the biggest lesson you’ve learned about making global teamwork actually work?”
I started learning about different cultures long before this was about tech or client relationships. Right after high school, I taught Khmer at a language school for foreigners, that’s where I first started noticing the real differences between, say, Australian, Dutch, Chinese, Japanese, and Korean people, long before I ever worked with any of them professionally.
Later, I learned a lot from Slash’s leaders about communication, principles, and values. One thing that’s stuck with me clearly: even when you’re silent, you’re still communicating, the other person, the client, reads that silence as a signal, and it often makes them anxious or worried, even if that wasn’t your intent.
That’s the lesson I carry into remote work: everything is communication, staying silent, a quick chat, a call, all of it sends a message. So the biggest lesson is being able to communicate with clarity and empathy, genuinely trying to see things from the other person’s point of view, since you’re not in the same room to read each other directly. Even across time zones, even when everyone’s busy, you can still manage expectations, a small progress update, a “here’s when I’ll follow up next”, and that alone does most of the work.
Q3: Real Talk on AI
“Now on AI. Where do you land on AI right now? How much has it actually involved into your daily routine and workflow?”
I go back to GPT-3, it was a good chatbot, clearly knowledgeable, but I didn’t have a real use case for it at the time. Fast forward to last year, 2025, and I’d shifted from searching Stack Overflow to just talking to Claude and other LLMs to solve problems, first as a consumer.
From there, LLMs got noticeably better at agentic coding, and I moved into using Claude Code as an actual coding agent, first with a team or two, and now we’ve rolled out Claude for developers company-wide to assist with writing code, docs, tests, and building features, migrating the whole company from Windsurf to a Claude subscription.
Beyond being a consumer, I’ve also been building: skills and hooks to support agentic coding, using LLM APIs in product and internal tooling, building MCP servers (including OAuth-based MCP discovery and authentication) for Claude and other agent platforms, and now working with Mastra and the Claude Agent SDK to build chat bots, agent loops, and agent graphs, essentially trying to replicate what a managed agent platform does, to build a true agentic runtime of our own.
Q4: Product Evolution
“What’s the single biggest insight you’ve gained about building products over the years, and how does building something today in 2026 compare to back in 2016?”
The biggest insight: building a product was never really about the code, it’s about closing the distance between “the client has a problem” and “the team understands exactly what to build and why.”
The principle that follows from that: never assume what the client wants. You always have to clarify and manage expectations on what gets delivered, because getting that wrong is costly, in time and, more importantly, in trust.
The other side of it is technical risk. There’s always something unknown, and during a proposal or even early development, you can only prove out so much of the technology within the time you have. If you hit a real blocker deep into the project timeline, that’s critical, it puts delivery itself at risk.
In 2016, closing the client-understanding distance took hours of workshops, hand-written specs, and a lot of re-explaining. Today, technical scoping, quotation, and story-mapping run through Claude skills that turn a requirements doc into structured epics, sized stories, and risk logs in a fraction of the time. That hasn’t made the job easier so much as it’s relocated the effort, the mechanical scoping work got cheap, so now our energy goes into what still needs a human: judgment calls, reading between the lines of what a client actually needs, and catching what the requirements didn’t say.
And thanks to LLMs, we’ve also been able to reduce the other kind of risk, the technical unknowns and the time it takes to prove them out through code. But the thing that hasn’t changed, and probably never will, is understanding what the human or client actually wants to build. That still needs us to align, clarify, and bring value-added suggestions to the table.
Q5: Logic vs. Instinct
“…How have you learned to balance the logical, analytical side of your brain with your gut? As someone who’s both a deeply technical person and a leader, when do you trust the data, and when do you trust yourself?”
In the early stage of my career, everything was new, I was inexperienced, and all I really had was a dream and a goal. To get started at all, I had to trust instinct and just go for it, without overthinking.
I’ve taken a lot of decisions that didn’t look right in the moment but that I trusted would work out later. Choosing my university is one: I had a full scholarship for English Literature, and the other option, IT at RUPP, meant paying full price, which was a real strain given my family’s financial situation. Taking the scholarship would have been the sensible move, but it didn’t feel right, so I chose the harder path: enrolled at RUPP and took a part-time job teaching English to foreigners to make it work.
That same teaching job later offered me a sponsorship, study English on their dime, in exchange for working at their school afterward. I turned that down too, again because it didn’t feel right, even though it would have been the easier, safer choice.
Then before Slash: I’d just graduated and spent about a year to a year and a half at a company with good pay and real potential for growth. I quit anyway, because I felt it wasn’t right for me and I needed to learn something more. I went jobless for months, still living at my parents’ place and relying on their allowance since I had no income of my own, did freelance work to get by, and eventually regrouped with the Flexitech team to start again.
At the moment, none of those decisions made sense, why give up a steady salary for zero income for months? But instinct told me to, and I’ve kept making that kind of call throughout my career, including at Slash, sometimes going against what others or leaders around me thought was right, I’ll follow guidance to a degree, but I also do it my own way.
That said, there’s only so far instinct and luck can carry you. Some decisions can’t be a leap of faith, they need data: working through the problem with clients, consulting with the right people, weighing which technology to bet on, de-risking the project properly, deciding what’s worth learning next. At the end of the day, you need both: the data and the logic to make the case, but also genuine buy-in from yourself. If you’re not fully onboard with a decision, your own resistance will work against you, no matter how sound the data is.
Q6: When the Code Stops Being the Answer
“…When did that happen for you, and what did it force you to develop that a decade of engineering hadn’t?”
I started coding after grade 9, with VB.NET on the .NET framework, and moved through a long list of languages over the years: C, C++, Java, C#, PHP, eventually Node.js, plus various mobile frameworks. Somewhere along the way I realized they’re all fundamentally the same thing: tools to program something. What differs is each language’s specific characteristics and the use cases it fits best.
Once that clicked, I stopped resisting language or framework changes. I’m not going to claim I’m an expert in any single one, but when the moment and the need call for it, I can always go deep. Because at the end of the day, it comes down to what we’re actually building, the right product, for the client’s business or their customers. And often the real problem was never the code at all, it was upstream: unclear expectations, a misalignment that had quietly been papered over instead of resolved.
That’s not an excuse to stop caring about the code, though. It’s the opposite, we still have to keep refining our engineering practices: patterns, best practices, refactoring, automated tests, conventions, those are what let you move fast later without paying for it twice. What a decade of engineering forced me to develop wasn’t a new language, it was the discipline to look upstream of the code before writing any of it.
Q7: The Weight of Accountability at Scale
“…What does it do to the way you think and build when you know the cost of being wrong isn’t a bug report, but something that actually matters to real people?”
I’d say there are two very different degrees of weight here.
When you’re coding to learn, that weight is close to zero, you can build anything, break anything, and the cost of being wrong is just time. When you’re coding or building a product for a client, it’s a completely different story. You have to consider the impact on their business and their users. A client funds a project, small budget or large, it doesn’t matter, with their dream and their vision behind it. It’s completely fair for them to feel anxious, worried, or disappointed at any stage of delivery, because that’s their money and their vision on the line, not just a feature ticket.
That’s what separates a simple bug from something like a misunderstood feature, or the wrong architecture or tech stack choice, the latter are far more costly, because they’re expensive or sometimes near-impossible to refactor or rebuild later.
Working on WFP PRISM, a real-time monitoring platform for the World Food Programme, and later on financial infrastructure for AXA Singapore validated against Monetary Authority of Singapore compliance, put me squarely in that second category at an even higher stakes level: a data pipeline bug there isn’t an inconvenience, it’s a wrong picture of where aid needs to go, or a regulator and real customer trust on the line. It pushes you to stop treating “we’ll catch it in QA” as good enough, and to surface and de-risk unknowns as early as possible, even when that’s slower and less satisfying than just shipping.
Q8: The Hard Lessons
“Is there a specific moment where something went badly wrong, and what did you learn from picking up the pieces? How do you do that?”
Hiapp is a clear one for me. We proved out and chose an architecture and stack that worked and helped in the short term, but it couldn’t scale or adapt to what the client actually needed further down the line. Looking back, the architecture choice itself was only part of the issue, product clarity and resourcing also contributed to how we got there. And in hindsight, it was obvious the choice could have been better; that’s the hardest part of a lesson like this, it’s rarely one clean root cause, it’s a few things compounding, and the tech decision is just the most visible one.
Picking up the pieces meant going back and being honest about all of those contributing factors instead of just patching the architecture, otherwise you fix the symptom and the same pattern shows up again on the next project. That’s the discipline I try to carry forward now: when something goes sideways, look past the obvious technical culprit and ask what else, clarity, resourcing, expectations, quietly makes that outcome more likely.
Q9: The Slash Secret
“After all this time, what do you think genuinely sets Slash apart from every other tech company out there?”
My honest answer, right now: the people.
Slash has always been built around culture and people first. Technology, we can always learn, as long as we have the people, and we nurture them, and they care about Slash the same way Slash cares about them. We’ve survived multiple crises over ten years, and every single time, it’s because of the people, not because of any particular strategy or stack (but to be fair, strategy also helped and directed us). We’ve adapted, changed direction, and iterated more times than I can count, but none of that would have mattered without the Slashers who stuck with it and made it happen.
Q10: The One-Liner
“Ten years in, summarized in a single sentence: What is Slash to you?”
Slash is the closest thing to a family I’ve built outside my own.
