Some of my earliest experiences with software engineering were about learning how to build things.
I wanted to understand how frontend and backend systems connected, how APIs worked, how databases were designed, and how an application eventually made its way into production.
My experience at Toyota Motor Manufacturing Indonesia gave me a chance to see those pieces come together in a real operational environment.
From September 2024 to March 2025, I worked as a Software Developer Intern, where I developed a fullstack mobile-web attendance system using Laravel, Inertia.js, and React.js. The system supported more than 650 users.
It was one of the experiences that helped me understand that building software isn’t only about writing code. It’s about building something that people can actually depend on.
Building Something People Use
The attendance system was one of the first projects where I had the opportunity to work on a fullstack application from end to end.
I worked across the frontend, backend, API layer, and database.
That was important for me because it changed the way I thought about individual pieces of an application. Before working on a system like this, it’s easy to think of the frontend and backend as separate things.
The frontend displays information.
The backend processes it.
The database stores it.
But when you’re responsible for the whole system, those boundaries become much more connected. A decision in the database can affect an API. An API decision can affect the frontend. A change in the frontend can change what the backend needs to provide.
Seeing those relationships firsthand helped me become more comfortable thinking about software as a complete system.
Learning to Work With Existing Systems
One of the more interesting parts of the project was working with SQL Server and designing database schemas while maintaining backward compatibility.
That requirement taught me something I still find useful today.
In real software development, you don’t always get to start with a blank page. There may already be databases, services, conventions, and systems that other parts of the organization depend on. A technically cleaner solution isn’t always the right solution if it breaks something that already works.
That meant I had to think not only about how I wanted to design something, but also about how my changes would interact with what was already there.
It was an early lesson in engineering trade-offs.
From Development to Production
Another part of the experience that stood out to me was deployment.
I worked with a Windows Server environment, configuring the web server and database services to prepare the application for production.
This was different from simply running an application locally. When something works on your own machine, you know that at least one environment is behaving as expected.
Production is different. There are servers to configure, services to manage, dependencies to consider, and users who expect the application to work when they need it.
That experience made deployment feel like part of development rather than something that happens after development. The application isn’t finished when the code is written. It’s finished when the system can actually run where it needs to run.
Learning Fullstack by Building
Working with Laravel, Inertia.js, and React.js also gave me a better understanding of how different technologies can fit together.
I wasn’t just learning frameworks individually. I was learning how they interacted.
That was valuable because it encouraged me to think about the flow of a feature from beginning to end.
A user performs an action.
The frontend sends information.
The backend processes it.
The database stores or retrieves something.
The response makes its way back to the user.
When something doesn’t work, you need to know where in that chain the problem might be.
That way of thinking became one of the foundations for the projects I worked on later.
Looking Back
Looking back at my time at Toyota, I think the biggest lesson was learning what it means to build software for real users.
Supporting more than 650 users gave the project a different sense of responsibility.
It wasn’t just an exercise to learn Laravel or React. There was a real workflow behind the application, and the software had to fit into that workflow.
That changed how I think about development.
Good software isn’t only about whether the implementation is technically interesting. It also needs to be understandable, maintainable, compatible with its environment, and reliable enough for the people who depend on it.