For a long time, I thought of software engineering as the process of turning an idea into an application.
You start with a problem, design a solution, write some code, and eventually you have something that works.
My current role at DeltaHQ has been teaching me to think about what happens after that.
Since May 2026, I’ve been working as a Software Engineer, primarily around backend services, automation, and cloud infrastructure. I currently maintain four Python services built with Django that support more than 10,500 users across 600+ companies, while also working with AWS infrastructure and background jobs.
Working with systems at this scale has made me more interested in a different question.
What does it take for software to keep working well as more people depend on it?
Learning From Systems That Are Already Running
One of the first things I noticed in my current role is that maintaining software can be just as interesting as building it.
When you’re starting a project from scratch, you get to make many of the decisions yourself. When you’re working on an existing system, the questions are different.
Why was this designed this way?
What might depend on this behavior?
What happens if I change it?
Can I improve something without introducing a new problem somewhere else?
Maintaining multiple backend services has made me more comfortable with that kind of thinking.
The goal isn’t always to rewrite something into the design I would choose today. Sometimes the better engineering decision is to understand what already exists, identify the real problem, and make the smallest change that improves it.
When Two Seconds Matter
One of the projects that made me think about performance differently involved a Playwright-based automation service.
The service was taking roughly 13–15 seconds to complete. I worked on improving it until the execution time was around 2 seconds, while using caching to reduce rate-limit errors.
The interesting part wasn’t simply getting a smaller number. It was figuring out where the time was actually going.
Performance problems can be tempting to solve by immediately changing code. But meaningful optimization usually starts with understanding the system first. In this case, caching became part of the solution.
That experience reinforced something I’ve learned across different roles, performance is often less about making everything faster and more about removing work that doesn’t need to happen.
Thinking About Infrastructure
Another part of my current role has been managing AWS infrastructure for Python services and background jobs, including ECS and ElastiCache.
This has been another step in broadening how I think about software.
Earlier in my journey, I mostly focused on the application itself. Now I’m increasingly interested in the environment that allows an application to operate reliably. Deployment, background processing, caching, and the way different services communicate all become part of the engineering problem once a system starts to grow.
Working with infrastructure has made the boundary between “developer” and “operations” feel much less distinct to me. The code is only one part of the system. How that code is deployed, how it runs, and how its surrounding services support it are just as important to the experience of the people who depend on it.
The software and the environment it runs in are part of the same system.
Building for More Than One User
Supporting more than 10,500 users across 600+ companies has also changed how I think about responsibility in software.
When you’re building a small personal project, a bug might affect you and a handful of people around you. When a service is used by thousands of people, the same bug can become a very different problem.
A small performance issue can be repeated thousands of times. A deployment problem can affect many customers. A background job that fails unexpectedly can create problems somewhere else in the system.
This doesn’t mean every decision needs to become complicated. It means the consequences of those decisions become easier to see.
That has made me more deliberate about reliability, maintainability, and understanding the systems I work on.
Looking Back at the Journey
When I look at my previous experiences, I can see a progression that I didn’t necessarily notice while it was happening.
At Toyota, I was learning how to build a fullstack application for real users.
At NTT DATA, I started looking deeper into databases, queries, and data systems.
At Traveloka, I explored automation, architecture, observability, and cloud services.
Now at DeltaHQ, I’m learning what it means to maintain and improve backend systems that people depend on every day.
Each experience added another layer. Frontend taught me how people interact with software. Backend taught me how applications work underneath. Data taught me to look at information and performance differently. Automation taught me to think about reliability in systems that interact with the outside world.
And working at DeltaHQ is teaching me to think about all of those pieces together.
What I’m Learning Now
I don’t think I’ve reached a final answer to what good software engineering looks like.
If anything, working on larger systems has made me realize that good engineering is less about finding a perfect solution and more about learning how to make thoughtful decisions as a system grows. Performance, reliability, maintainability, and simplicity all become connected, and improving one part of a system often means understanding the others first.
For me, engineering has gradually become less about collecting technologies and more about understanding systems.
There will always be another framework to learn or another tool to experiment with. But the deeper challenge is learning how to use those tools thoughtfully, knowing when they help, when they add complexity, and how they fit into the bigger picture.
That’s the part of the journey I’m most interested in continuing.