Before joining Traveloka, I mostly thought about software in terms of the thing being built.
An API had to work. A frontend had to behave correctly. A deployment had to be reliable. When something was slow, I looked for the part of the code that needed to be optimized.
My internship at Traveloka changed the way I looked at those problems.
From September 2025 to March 2026, I worked as a Software Engineer Intern on automation systems, internal tools, and the infrastructure behind them. It was an opportunity to work on software that had to operate beyond a single application or a single user. That experience made me think more carefully about maintainability, scalability, observability, and the small engineering decisions that become important when a system grows.
Getting Into Automation
One of the first things that stood out to me was the scale of the automation work.
I worked on more than 40 automation services supporting authentication workflows across B2B platforms, using Puppeteer. At first, the work seemed straightforward, automate a workflow that would otherwise require someone to do it manually.
But automation has an interesting property. When a human performs a process, they can usually recognize when something looks different and adapt. Software cannot do that unless we explicitly design it to. A small change in a website, an unexpected response, or a timing issue can turn a working automation into a broken one.
That made me appreciate that automation is not simply about making something run automatically. It is about building something that can continue to run reliably when the environment around it changes.
That distinction stayed with me throughout the internship.
Learning to Think About Structure
As I worked more with the existing systems, I started to see another challenge, legacy source code can become difficult to maintain surprisingly quickly.
I eventually worked on refactoring a large-scale Chrome extension system using Domain-Driven Design (DDD). The goal wasn’t simply to rewrite existing code. It was to give the system a structure that would make future changes easier to understand and safer to make.
This was one of the experiences that changed how I think about architecture.
A system can work perfectly and still be difficult to work with. Good architecture isn’t always visible to the person using the software. Sometimes its biggest benefit is felt by the engineer who has to modify the system six months later.
Working on that refactor taught me to pay more attention to boundaries, responsibilities, and how different parts of a system relate to one another. It also reminded me that maintainability is something you have to design for rather than something that automatically appears as a project grows.
When Performance Becomes a Developer Experience Problem
Another lesson came from something that seemed much smaller, the frontend build system.
I worked on moving the build system from Webpack to Vite, reducing build time from roughly 13 seconds to 8 seconds.
Five seconds might not sound significant when looking at a single build. But developers don’t run a build just once. The same operation happens again and again throughout a day. A small improvement repeated hundreds of times can become a meaningful improvement in how quickly a team can experiment, develop, and iterate.
That experience made me think about performance differently. Performance isn’t always about making the final product faster for users. Sometimes it’s about making the people building the product faster too.
Making Systems Easier to See
As the number of automation services grew, another problem became important, knowing what was happening inside them.
I worked on improving observability through structured logging and monitoring integrations with Datadog.
This was another shift in perspective for me. When a system works, you don’t always need to know exactly what every component is doing. When something breaks, that changes immediately. Good observability gives you a way to understand a system without having to guess.
Logs, metrics, and monitoring aren’t just operational tools. They are part of the software itself. They help turn an unfamiliar failure into something that can be investigated and understood.
That became an important part of how I think about backend systems today.
Seeing the Other Side of the System
My work at Traveloka wasn’t limited to backend automation.
I also developed internal frontend tools using Next.js to support RPA integrations, and deployed automation workloads using AWS Lambda and S3.
Working across these different parts of the system was valuable because it made the boundaries between frontend, backend, automation, and infrastructure feel less rigid.
A feature doesn’t really end at the API. Someone has to interact with it. Something has to execute it. The infrastructure has to support it. When something goes wrong, someone needs enough information to understand why.
Working across those layers helped me become more interested in the system as a whole rather than only the part of the stack I happened to be working on.
Looking Back
Looking back, the most valuable part of my time at Traveloka wasn’t any particular technology.
I learned Puppeteer. I worked with Next.js, AWS Lambda, S3, Datadog, and DDD. I worked on automation services, internal tools, frontend builds, and a large Chrome extension system.
But the bigger lesson was learning to think about software beyond whether it works.
I started asking different questions.
Will this still be understandable when the system gets larger?
What happens when the environment changes?
How will we know when something fails?
Can another engineer safely change this later?
How does this piece fit into the rest of the system?
Those questions have stayed with me beyond the internship.
What Comes Next
Traveloka was one chapter in a larger journey of learning how I want to build software.
Since then, I’ve continued working across backend services, automation, cloud infrastructure, and fullstack applications. Each experience adds another perspective to the way I approach engineering.
That’s what I enjoy most about software engineering. There is always another system to understand, another problem to explore, and another opportunity to build something a little better than before.
Traveloka gave me six months to experience that at a larger scale.
I’m still carrying those lessons forward.