Hi, my name is Ferdian, and im undergrads at Dian Nuswantoro University, my major is Informatics Engineering, im interested at AI Engineering so im minoring at it.
My interest started at young and corious me when i was in middle school, i had my first really dumb question and its like the butterfly effect that shaping my career until now. and my question was “why tupperware tumbler and box always appear at lunch time with my friends?” like everyday, every occasion they love and proud to use it. Asked my friends why and i got zero conclusion since their answer are very subjective to the other. At that time i think the answer is simple, maybe because the product is good, maybe the lunch boxes were well designed, maybe the brand looked promising and appealing. That question kept bugging me so i had to borrow my brothers laptop to exploring design on my own. Spent hours on making logo and experimenting different ideas. Without even noticing, i became familiar using a software and more comfortable working with computers.
later in high school i won several design, photography and even some cinematography competition held by my school. By then, i had quite confident with my creative fields. However, as i spent more time in my computers, explored different tools and software as i started questioning more about how this technology really made and how computers really worked. This curiosity led me to pursue Informatics Engineering, where i discovered my passion for software development and artificial intelligence.
Later, as a freshman. I wrote my first line of code. What fascinated me was programming felt surprisingly familiar. Looking back, all those years of curiosity, experimenting with design and spending countless hours on computer quietly prepared me for this. Thanks to my curious young Ferdian, i learned to approach every project with a question in mind, how can i make this better, more usable, or more useful for the people who use it. Since then, I have treated every project as more than just an assignment. Whether it involves design, software development, or artificial intelligence, I try to give each project its own personality and purpose.
Artha Manager App
My first year at university introduced me to a problem. I kept running out of money, yet I never consider myself as a big spender guy. This is make me frustated so i tried simple solution to track every expenses in excel and spreadsheet, and it was terrible. Using these tools was painfully difficult since the overall UI is not built to be great at this spesific task. So i move onto Android Apps and try bunch of them. Although its did all the jobs i needed, some were filled with intrusive ads, some were packed so many features that even basic expense tracking felt unnecessarily complicated. man, i just want to see what things i spent on. This made me realize that i didn’t need a finance app with hundreds of features. I just needed something simple, intuitive, and build the way i wanted. Instead of continuing to search for the perfect finance apps, i committed myself to building one.
The first thing to do is i fire up Figma and experimenting some prototype. My goal was simple, create an expense tracker app and do the job as easy as it can. Every screen i design is based on few simple questions:
“do i or user can use easily and intuitively?”
“what if the user is in a hurry and only has few sec to record and expense?”
“do this feature geniuly help user, or its justs adding unnecessary efforts to build and just adding complexity”
and so on
because tracking some expense should be easy, simple, and fast, not become antoher task to manage. After some explorations and experimentations. I got my first prototype. However, the prototype against the questions i had, i realized there was still rom for improvement. So i made several design and prototype. i even asked my friend if they will using this app what prototype would the choose, major of them pick that the prototype v2.
later i decided to build the logo of the app
the logo was inspired of chicken shaped coin bank, its reminded me of the excitement of saving small amount of money and getting heavy over time back when i was a kid. it has major improvement to the UI, it has more legibility and the button more clear, and user friendly. As its ready to built and confident, i fired up Android Studio and began learning Kotlin, Jetpack Compose, and Room Database from scratch. This was my first experiencce turning a problem to a product into a fully functional apps. It was both challenging and rewarding at the same time, as i had to learn not only to write code, but also how to structure a data, manage application state, and translate design decisions into real user experiences.
The most rewarding part of the entire process was seeing the apps installed on my own phone. After weeks of designing, prototyping, learning, and building, the idea had finally become something real that I could use every day. After sometime my friends start to use it too, and what surprise me even more is my app got 16 active users in the first week. Hearing that they genuinely found it useful was one of the most satisfying moments. Although they were satisfied, the app itself still has a lot room of improvement to be made.
Looking back, i build Artha Manager during semester break, and i realized that i spent far more time understanding the problem, designing solutions, and iterate on ideas than i did writing code. After then i realized that coding is not the hardest part. It is simply a tool for bringing solution to life.
LELESEGAR.COM
after the semester started again, we was assigned to build a fully functional website as part of a unversity project. Instead of creating fictional bussiness, i decided to work on my family’s business. The timing was perfect, most of our operationns relied heavily on WhatsApp for communication and ordering with hundreds of daily customers. While this worked, it became increasingly difficult to organize as customer grow from normal customer into business to business. Customer information, orders, and transaction records were scattered across deep chat conversations. This issue became more serious when we experiencing inconsistent records and miscommunication with customer and led to unnecessary losses. We knew we need it ASAP.
Before the designing the website, i spent time understanding how our customers interacted with the business. I even reviewed customer conversations, observed how orders were placed and recorded, and identified the information during a typical transaction. I come up with conclusion that most orders is talking about few key pieces of information like
Quantity (usually in kilograms)
pickup date and time,
customer informations,
estimated number of catfish per kilogram,
or even special requests or notes.
At first i mapped how information is related to the other and flow through the business, so i designed an ERD to model how customers, orders, and transactions would interact. ERD giving me crystal clear picture of the business process from system perspective and helped me make better architecural and technology decision before even coding and designing. at the same time, i also studied that most of them primarily used smartphones, and many were older adults and long-time customer were more comfortable using WhatsApp than navigating modern websites. This insight significantly give me more direction to design decisions later.
Rahter than focusing on flashy visual or complex interaction, i priorized simplicity, familiarity, and accessibility. I adopted mobile-first approach since the vast majority of our customers accessed information by their phones. After putting the pieces togehter, i started to make designing and prototyping. interestingly i found myself to the same question i had asked while building Artha Manager App. Although the project was very different, the design philosophy remain the same. The goal was not to create the most visually impresive website, but to build system that felt familiar, accessible, and system that our customer wouldn’t suffer. Big buttons, straight-forward, minimal color palette, clear information hierarchy. After some testing and get reviewed from our family, i finaly confident with the prototype
Once the design system was finalized, i moved on to choosing the stack. since the system dealing with customers, orders, and transaction records, i choose relational database architecture to ensure data consistency. For the backend, i pick Laravel as a choice becauses of its mature ecosystem and strong support for business-oriented apps. I also utilized Filament to accelerate the development of the administration dashboard, allowing me to focus more on solving the problems rather than building all interface from scratch. The development time took significantly less than research and design phase. By the time i started writing most of the difficult decisions had already been made. As a result, the development phase felt much moer straightforward than the research and planning stages. One unexpeceted challenge came during shipping the website, since this my first time deploying a Laravel apps into production environment, i had to learn about configuring server, cPanel management, and adapt to hosting-spesific deployment requirements. Although it took a while, but it made me understand about production environment, versioning, and maintaining a website.
When we finally shipped our website and make it production, it was really relieving moment after some trials and errors. The impact is immediately noticable. Customer informations, orders, and transaction records were no longer scattered across WhatsApp conversations. Instead, they were stored our systems. Orders become easier to track miscommunication significantly reduced, the system also provided valuable business insight. Now we were able to identify demand patterns, and better understanding which fish sizes and quanitites were ordered most frequently. So every business decisions now supported by actual data rather than assumptions.
More importantly, it changed the way i think about engineering. I stopped seeing software as a collection of tech, programming, and frameworks, in this period i began seeing it as a way to transform messy problems into structured, practical solutions. The real challenge lies in understanding people, identifying problems, and connecting all the pieces before even touching the code.
Oxidraw
Later in next semester we were assigned to make real-startup with clear business model, this assignment was group project, my role in this project is Backend Developer and Frontend Developer, also i was choosen to led the team of five. Although i had worked on group projects before, this experience felt very different. The project was far more serious, involving extensive research, validation, documentation, and business planning in addition to software development. This time i was responsible not only technical decisions but also for coordinating a team, managing responsibilities, and ensuring everyone moved toward the same goal. While this an university assignment, i wanted to give my best effort and treat it as real startup rather than just another academic project.
The problem we eventually identified was quite unexpected. as the team leader, one of the first decisions i made was to hold up every development entirely and focus on brainstorming and research first. I believed, skipping this part only lead us to create solutions that nobody needed. for the first four weeks, we brainstormed ideas, studied existing industries, analyzed competitors, and explored potential customer pain points. This might be slower than the other student but this build ourself stronger fundamental of problems that we try to solves.
Ironically, while searching for a problems and gathering them in one places, we encountered one ourselves. Our team constantly jumped between different platforms. Notes were stored in Notions, reference images live in Figma, AI conversations were buried in separate chat histories. As the amount of information grew, it became increasingly difficult to keep everything organized and accessible. The more we worked, the more we realized that knowlegde management itself had become our biggest bottleneck. This experiences led us to ask a simple question, what if notes, images, sketches, prototype, and AI assistance could exist within a single workspace?
Once we gained confidence and agreed on the problems we choose, we began translating our research into product requirements. We mapped user workflows, defined core features, and designed how information, notes, images, AI conversations could exist within a single workspace. After documenting our findings and defining the proposed solution, we presented our business model, product concept, and technical approach to our lecturer for evaluation and feedback. With some critics and suggestion, it came out with approval of our lecturer but with some notes. Once we got approved and had a clearer direction, we began evaluating the technologies and frameworks that would fit the best to support the product vision. We straight up fire up figma and made protoytpe with organized system design that building the foundation design language of our brands and initial MVP of our product. Countless testing and reviewing with each other.
Later when we finally confident and commit, we starting to move our focus on development process. As the technical lead, i made a shortlist of potential technologies and frameworks from both backend and frontend. Since we working as a team, i also considered each member’s familiarity with the technologies and learning curve involved. We held several discussions, and i encouraged to challenge the proposed stack, share their concern, and suggest alterantives. My goal is to find the balance between the best practices and and familiarity. After hundreds of coffee shop we hoppin, we concluded the tech stack we will used later, we selected React for its component-based architecture. Backend side we pick Node.js, Shadcn for UI library, TanStack Query to simplify server-state management. When development is done we even presentating it on another classmate in different subject to a different lecturer.
after that, we made a proposal to registered to HAKI of our product and its ACCEPTED! we were so happy to hear when we got notified.
The most valuable part of Oxidraw was not the product itself, but the experience of leading a team through uncertainty. For the first time, I had to make decisions that affected not only the technical direction of a project but also the way a team worked together. I learned how to divide responsibilities, manage different opinions, resolve disagreements, and keep everyone aligned toward the same goal. There were moments when progress felt slow, especially during the research phase. As a team leader, I often had to balance patience with urgency, making sure we spent enough time understanding the problem without getting stuck in endless discussions. Through this project, I realized that leadership is not about having all the answers. It is about creating an environment where people can contribute their ideas, challenge assumptions, and move forward together. Oxidraw taught me that building products is ultimately a team effort. No matter how strong the technology is, success depends on communication, trust, and the ability to bring different people together around a shared vision.
Arces
This project started when me with my friend reach out our lecturer, asking if he got any problems with their website or system, for the first time in my experience we looking project with my lecturer. He say “yeah you can come in and built” we were so excited at the first, so me with my friend contacting our 2 friends to collaborate this project. My goal was when there is many people to collaborate the project is easier to be done and deliever faster. After our team of four got green light from out lecturer, we made discussion group with our lecturer. As project lead and fullstack, i initiated google meet with our supervisors and Lecturer, i want we have know each other first and starting to collaborate and giving suggestion, arguments, idea along the way of building this. In the first metting we were still introcuding our team and discussed about the initial raw concept, the first meeting was smooth. We were assinged to build the branding first before Web Development even begin, after write down every brief we had, the first decision i made is that i recommend my friend to handle initial exploration and design the logo, this because he had strong foundation in graphic design and we mapped out the design system and brand vibes.
After hearing their feedback and making several revisions, we finally got approval for the branding direction. It was relieving because we spent quite a lot of time discussing small details, especially around color choices, typography, and how the brand should feel to future users. With the branding and design system becoming more clear, our focus slowly shifted toward the product itself. Me and my other two friends started discussing the user experience, user flows, and how the website should work from the first click. At this stage, we didn’t want to jump directly into development yet. Instead, we spent our time creating wireframes and prototypes to validate our ideas first. The goal was simple, before writing any code, we wanted to make sure both our lecturer and supervisor agreed with the direction we were taking. So after several iterations and internal discussions, we prepared our first website prototype and scheduled another presentation session to gather more feedback.
Later, i contacted our lecturer and supervisors to ask when they were available for another presentation session. Since i was leading the project, i usually handled most of the communications and made sure everyone knew what needed to be prepared before the meeting. At the same time, me and my friends kept improving the prototype based on the feedback we got before. Sometimes we had different ideas about the design and user flow, so we spent quite a lot of time discussing and reviewing it together. After around two meetings with our lecturer and supervisors, we finally agreed on the latest version of the prototype. They were satisfied with the direction we took, and we also felt confident enough to move forward with the next phase of the project. In total, we spent almost a month exploring ideas, designing, testing, and refining the prototype before committing to the final design. What a month, we spent most of our time in Figma, Illustrator, pinterest, etc. countless meeting at burjo, we were happy and tired at the same time but its so flawless because we were in good environment so there is no friction while developing the brand.
After this phase, i deciced to hop on in burjo and talk about technologies we would use later in development in this phase i hands them shortlist of technologies and discuss them and guided them what it means and for. Talk about React in general, how CMS work in broadway, talk about the problem we would encounter and so on. In this burjo we were spent almost 5 hours of discussion and getting home with agreement of technologies we would use, it consist of PayloadCMS, React, Next.JS, and Vercel as a hosting. This technologies made us faster building CMS because of PayloadCMS already provides many features that we needed out of the box. Instead of spending weeks building authentication, role management, content management, and admin dashboard from scratch, we could focus more on developing the features that were actually important for the product. React and Next.js also gave us flexibility to build interactive interfaces while maintaining good performance, and Vercel simplified the deployment process so we could ship new changes much faster.
What i liked the most from this phase was not the technologies itself, but the discussion behind every decision. Rather than choosing tools because they were trending, we tried to understand the trade-offs of each option and whether it fit our product requirements and team’s capabilities. Since some of my teammates had never worked with several of these technologies before, i also spent time explaining the basic concepts and how each piece would work together in the overall architecture. After we agreed on the stack, we finally started breaking down the work into smaller tasks and distributing responsibilities to each member. At this point, months of research, brainstorming, validation, prototyping, and planning had finally turned into something more concrete. For the first time, it felt like we were no longer just discussing ideas, we were actually building the product.
The trade off was the website was heavy to build in the first time so we had some bottleneck in the first feature we work on to. It was because PayloadCMS require ton configure every data and type in the first place, so i deciced for all of my friends to focus on this problem and breaking em into small piece of work by work. When this is ready the entire development until shipping is straight-forward and smooth. We were worked ourself well, and our communication in groups was great.
When we shipped the our website, everything was fine until the profile picture in Kepengurusan won’t load. i digged to internet and forum discussion, it was because simply the way image get rendered in Next.JS was different. They using <Image> as a syntax, the goal is they reduced and load faster because that image converted WebP format, and having CORS related problem so our website cannot access other website unless we allowed them, later i decided to make the image rendering to <img>. We solve this problem and focus more on delivering the product with our lecturer and they happy with the result. After several revisions, bug fixing sessions, and discussions with our lecturer, the website was finally stable enough to be presented in the final review meeting. In the last meeting, we walked through the system together, explained the features, and demonstrated how everything worked. It was relieving seeing months of planning, designing, discussing, and development finally come together into a working product. Thankfully, our lecturer was satisfied with the result and gave us approval to move forward.
It was my first experience leading a team while working closely with a real stakeholder throughout the entire process From the initial discussions, branding exploration, prototyping, technology decisions, development, debugging, until the final approval, i learned that building software is rarely just about writing code. Most of the work happens through communication, collaboration, and making hundreds of small decisions that slowly shape the final product.
InvenTel
On May 9, 2026, i started my internship at PT Telkom Indonesia as an AI Engineer. Unlike my previous projects where i was usually working on academic assignments or personal projects, this time i had the opportunity to contribute to an internal enterprise system used by employees on a daily basis. Before touching the AI side, most of my early work focused on understanding the problem and designing the solution first. Together with the team, i spent time discussing user requirements, exploring possible user experiences, and creating prototypes to visualize how employees would interact with the system. Since the goal was to make inventory information easier to access, we wanted to ensure the experience felt natural and simple before moving into development. Looking back, this phase reminded me once again that building software is rarely about jumping directly into code. Understanding the problem and validating ideas often takes much longer than implementation itself.
Once we had a clearer direction, development started. The project was called InvenTel, an inventory management system used internally to manage and monitor company assets. One of the problems we identified was that employees still had to navigate through multiple pages and interfaces just to check inventory information. While the system worked, retrieving simple information often required several manual steps. To solve this, i worked on fine-tuning FunctionGemma 270M and integrating it into an internal chatbot connected to the inventory system. The idea was simple, instead of navigating through menus and forms, employees could simply ask questions using natural language and receive inventory information directly through chat.
A large part of my work involved understanding how inventory data was structured, preparing datasets, experimenting with prompts, evaluating model responses, and integrating the model into the existing system. Since this was my first experience working with LLM fine-tuning in a production-oriented environment, there were many things i had to learn along the way. As development progressed, i was also trusted to lead a team of three members. Besides working on the AI features, i coordinated between developers and UI/UX designers to make sure everyone stayed aligned with the project goals. I often facilitated discussions, clarified requirements, and helped bridge communication between design and development.
We also held weekly progress presentations with our supervisors. In these meetings, i was usually responsible for presenting our progress, explaining what we had completed during the week, discussing any technical challenges we encountered, and communicating our plans for the following sprint. At the same time, i tracked our development timeline and made sure every member understood their responsibilities and deadlines. One thing i learned quickly was that communication becomes just as important as technical skills when working in a team. There were many moments where different perspectives needed to be aligned before implementation could move forward. Because of this, a significant part of my role involved translating ideas between stakeholders, designers, and developers.
After multiple iterations, testing sessions, and integration work, the chatbot was successfully connected to the inventory system. Employees were able to check inventory information simply by chatting with the system using natural language. By reducing manual steps and unnecessary UI interactions, the process became significantly faster and more convenient for users.
This internship gave me my first experience building AI features inside a real enterprise environment. Beyond model fine-tuning and AI integration, i learned how products are planned, how teams collaborate across different roles, how to communicate progress to stakeholders, and how AI can create meaningful value when integrated into existing business workflows rather than existing as a standalone feature.
what i see is
Every project left me with different lessons. Some taught me about design, some about software engineering, some about leadership, and some about artificial intelligence. But if there is one thing they all have in common, it is that technology is only a small part of the solution. Most of the work happens before writing code, understanding people, defining problems, discussing ideas, and making countless small decisions. I still have a lot to learn, but every project along the way has helped me become a better engineer than i was before.
Lastly, i want to see how far can i push myself harder and further to my beloved country. Indonesia.
Thanks, in advance.