My story starts before software, before portfolios, and before I knew how to explain the kind of work I wanted to do. I grew up in Cavite in a family environment shaped by my parents and grandparents, where responsibility, discipline, and resilience were learned through ordinary daily life rather than formal lessons.

One of my earliest memories with technology came from a mistake. When I was still a kid, our family desktop computer had an earphone connected to the system unit. One side of the earphone was broken, with the wire exposed. Without understanding the danger, I plugged that exposed wire into an AC outlet while the computer was running. The motherboard was damaged, the desktop stopped working, and I could no longer play the games I loved.

At the time, it felt like I had only broken something important. Looking back, that moment became one of the first reasons I wanted to understand electricity, computers, and why machines fail. I started paying attention to parts, wires, performance, errors, viruses, slow hardware, and the small decisions that could affect an entire system.

This longer story gives context to the systems I build today. The projects show the output, but the background matters because it explains why I care so much about clarity, discipline, responsibility, resilience, and building things that people can depend on.

My background did not begin with polished applications or finished software. It started with a low-spec family computer, offline games, slow performance, and the habit of asking why something was not working the way it should. Before we had reliable internet at home, I often went to computer cafes to download or copy games, then used a flash drive to transfer them back to our desktop. Those shortcuts sometimes brought viruses, worms, and new problems home with them.

Those experiences made computers feel both exciting and fragile. If the machine lagged, I looked for ways to make it faster. If something broke, I wanted to know what changed. If a virus affected the system, I had to understand what it touched and how to recover from it. Curiosity became tied to responsibility because every mistake had a real consequence.

Over time, that way of thinking became less about fixing isolated problems and more about understanding systems. Before I learned to build software seriously, I was already learning to pay attention to parts, connections, performance, failure points, and how small details can change the result.

Before I had a clear technical identity, I was already learning the value of routine and responsibility. School, family, faith, and daily expectations taught me that consistency matters more than a burst of motivation. Progress usually came from repeating the right habits even when the work was ordinary.

That kind of discipline is not dramatic, but it becomes important later. It teaches patience. It teaches preparation. It teaches that the small things people do every day often decide whether bigger things become possible.

When I look back at my early years, I see the beginning of a pattern that still follows me: I work best when I can stay calm, understand what needs to happen, and keep moving even when the result takes time.

In junior high school, I studied under the Industrial Arts Electronics strand at Tanza National Trade School. That was where technology became more physical for me. I learned soldering, circuit assembly, breadboarding, technical drawing, electrical wiring, repair, testing, and how to use tools like a multitester to understand what was really happening in a circuit.

I built many small projects during those years, including an AC-to-DC converter, and I spent a lot of time working with components, wires, and PCBs. I enjoyed building printed circuit boards because the work felt concrete: the layout, the solder joints, the paths, and the components all had to come together before anything could work.

I also failed a lot. Things burned, sparked, overheated, or stopped working, and I made more mistakes than I could count. I tested appliances at home too, including TVs, washing machines, refrigerators, and fans, often trying to understand what failed and whether it could still be fixed. Troubleshooting was the hardest part for me then because it forced me to slow down, check each connection, and accept that guessing was not enough.

That technical-vocational foundation is important to my story because it taught me that software does not exist apart from the physical world. Everything starts with electronics. A system cannot run without power, components, signals, and hardware doing their part. Before I ever called myself a software developer, electronics taught me to respect details, failure, testing, and the hidden layers that make a system work.

In senior high school, I continued into the Mechatronics strand. That widened my foundation from individual circuits into automated systems: PLC programming, pneumatics, hydraulics, motor control, sensors, actuators, wiring, ladder logic, industrial maintenance, and machine control.

One of the projects I remember most was building a mockup board for a pneumatics system. It looked simple from the outside, but the logic behind it was complex. Every sensor, valve, actuator, relay, and timing condition had to work in the right sequence. I also practiced with conveyor systems, traffic lights, automated doors, sorting systems, robotic arms, and machine simulations using tools like PLC trainers, solenoid valves, air compressors, motors, HMI panels, multimeters, AutoCAD, and FluidSIM.

Building the system was exciting, but finding the issue when something did not work was the hard part. A wrong wire, a missed condition in the ladder logic, a sensor that failed to trigger, or a sequence that fired too early could stop the whole setup. I also had moments where mistakes became serious, including one time when I shorted a PLC and nearly damaged it. Experiences like that taught me to slow down, check assumptions, and respect the system before powering anything.

What I enjoyed most was planning the system: deciding what should happen first, what condition should trigger the next action, and how each part should respond when the state changed. That is the lesson that stayed with me. Mechatronics trained me to think in logic, sequences, inputs, outputs, failure states, and dependencies. Later, when I started building software, that same systems thinking became useful for workflows, permissions, records, user actions, and edge cases.

My turn toward software did not happen all at once, and I did not enjoy coding immediately. In junior high school, programming felt harder and less natural to me. In senior high school, I encountered code more seriously through Mechatronics, especially through PLC programming and control logic such as Ladder Diagram, Structured Text, Function Block Diagram, Sequential Function Chart, and Instruction List. At that stage, code still felt close to machines, signals, and sequences.

College changed the meaning of software for me. When I started learning Java and building applications, I began to see that software was not only logic running behind a system. It was also the part people actually touched: the screens, buttons, records, forms, dashboards, and flows that helped them complete work faster and with less confusion.

The first project that made that shift feel real was Techfinity, a Java desktop application for browsing PC parts, managing a cart, checking out, and printing receipts. It was not perfect, but it showed me that code could become something usable. A program could turn a manual or traditional process into something faster, more maintainable, and easier to audit.

Learning programming was still difficult. Remembering syntax was one of the hardest parts for me, and I learned from many sources instead of one straight path. But the more I experienced real problems that software could fix, the more the direction made sense. Mobile and web applications became practical choices because they were mainstream, accessible, and close to how people already work. That is where software became more than code for me. It became a way to improve processes people depend on.

At NU Dasmariñas, I took B.S. in Information Technology with specialization in Mobile and Web Applications because I wanted a direction beyond a general IT foundation. The specialization gave me a clearer path toward the kind of systems I wanted to build: web platforms, mobile apps, databases, interfaces, and software that people could actually use.

The adjustment was not easy. NU Dasmariñas felt very different from my earlier school environment. The grading was stricter, the standards were more demanding, and the schedule often felt tight. It was a zero-based environment where deadlines, performance, and consistency mattered every week, not only during major submissions.

College exposed me to programming, databases, web development, mobile development, networking, cybersecurity, artificial intelligence, systems analysis, and research. It also introduced pressure from many directions at once: group work, project defenses, new frameworks, academic requirements, organization responsibilities, and the expectation to perform even when the timeline was not ideal.

HireKita became one of the first major projects that made me feel more serious as a developer. It pushed me beyond simple coursework because I had to think about users, authentication, records, jobs, bookings, screens, and the structure behind the app. Later, Uniserve, my capstone project, raised the standard even more. Unlike projects that felt finished after a defense, Uniserve required monitoring, evaluation, revision, and stronger accountability from start to finish.

Through project defenses, I learned that being calm matters, but being calm is not enough. I had to know my system deeply, explain decisions clearly, and defend the work with confidence. College also sharpened my expectations for implementation. I wanted projects to be polished, not only functional, and I learned to plan, document, communicate, and adapt even when deadlines felt unrealistic.

A large part of my growth came from learning how to keep standards high while carrying pressure from many directions. I became a consistent First Honor Dean's Lister, maintained a strong academic record, often earning perfect 4.0 term grades, and received consecutive Gawad Nationalian Academic Excellence Awards. I was also trusted to represent my university in competitions, conferences, research work, and other academic opportunities.

That recognition came with responsibility. I received the Doña Miguela M. Jhocson Blue Scholarship, which covered 100% of my tuition and miscellaneous fees, and I understood that maintaining that support required consistency. At the same time, I had to balance classes, projects, organization roles, capstone work, research, competitions, certifications, and side projects.

Capstone became one of the hardest periods because many responsibilities were happening at once. I had to keep moving even when the schedule was heavy, the expectations were high, and the work demanded both technical depth and presentation readiness. I rarely relied on complex productivity systems. Most of the time, I carried the plan in my mind, stayed focused on the goal, and tried not to waste time on things that did not move the work forward.

Even under pressure, I did not want to lower the standard of the output. Polish, documentation, testing, UI quality, complete features, and presentation readiness mattered to me because high quality was part of being reliable. I learned to make ways around overload before it became failure, and to treat discipline as more than personal effort. For me, discipline means being true to my words and making sure the result matches the responsibility I accepted.

Outside coursework, leadership became another place where I learned how systems affect people. My main focus was my role as Director of Records in NUD Student Government, the highest governing student body in my university, where I handled documentation, official records, minutes, request workflows, file organization, templates, and information that other people needed to trust and access clearly.

The work often went beyond the title. In student government, I also carried responsibilities connected to events, coordination, documentation, and support work that helped the organization operate. That taught me that leadership is not only about having a role. It is about being reliable when people depend on the process, the record, the communication, and the outcome.

I also served in different roles across organizations such as Computer Society, JPCS, ComEx Brigade, PEER Facilitators, and JBEC, including committee, representative, and technical responsibilities. Because those roles were different, I saw many kinds of operational problems: event needs, student concerns, technical issues, documentation gaps, coordination pressure, and work that had to be finished while balancing academics, projects, and capstone responsibilities.

Across those organizations, I often found myself improving the technical side of the work. When a process was slow, unclear, scattered, or repetitive, I looked for ways to use technology to make it easier. That is where leadership and software started connecting more clearly for me. A system is not only code. It is also service, trust, accountability, communication, reliability, empathy, and order. Leadership taught me that good systems should help people organize, decide, and move together with less confusion.

The projects I build now come from observing people, processes, and the problems that keep repeating around them. I usually start by looking at what people experience directly: where they wait, where records get lost, where meetings become hard to follow, where small businesses miss opportunities, or where a workflow depends too much on memory and manual effort.

Uniserve is one of the clearest examples because it came from issues I saw in community engagements and outreach initiatives. Proposals, approvals, partners, volunteers, evidence, reports, and monitoring all needed clearer structure. Building Uniserve helped me connect my technical work with service, accountability, and the real operational problems behind community extension work.

Other projects came from different kinds of pressure. Cyvello came from my own problem with meeting recordings: I did not have a good way to summarize meetings, extract decisions, and track follow-ups, so I built a system around that need. Go Local and LeadSync PH came more from market thinking and opportunity, where I looked at small business workflows, customer management, local selling, and how technology could make those processes faster and more organized.

That pattern shows up across most of my projects. I see a problem, think about why it exists, and start looking for a system that could make the process clearer. I care about product thinking because software should not only prove that something is technically possible. It should help people act, decide, record, monitor, and improve. Right now, that direction is leading me toward enterprise systems and AI: tools that can handle serious workflows, support better decisions, and reduce the confusion people face in real operations.

Today, I describe myself as a full-stack product engineer, but I try to stay flexible because the work often asks for more than one role. Sometimes I need to think like a developer, sometimes like a product builder, sometimes like a systems analyst, and sometimes like someone responsible for turning a problem into something people can actually use.

My current direction is moving more toward startups, agentic AI, and automation. I am interested in systems that can reduce repeated work, support better decisions, and help people act faster without losing clarity or accountability. Because of AI, I see my path expanding beyond traditional software engineering into tools that can automate workflows, reason through information, and make complex processes easier to manage.

The problems I care about are still grounded in real life, especially problems experienced by Filipino people, students, organizations, workers, communities, and small businesses. Each project I build reflects a different kind of issue: community extension work, queues, local services, meeting records, lead management, marketplaces, document processing, forecasting, risk review, and other workflows where people need clearer systems.

I still aim to grow as a software engineer, but I am also building toward a future where AI, automation, and product thinking become central to my work. I want to work with reliable people who carry the same level of grit, responsibility, and follow-through. The values that guide me are still human values: discipline, service, trust, accountability, empathy, resilience, and the desire to build useful things without losing sight of the people they are meant to help.

I do not see my background as a finished story. I see it as a foundation that is still being built on. Every project, leadership role, research task, and technical challenge adds another layer to how I understand people, systems, and responsibility.

The next chapter I am working toward is becoming a startup founder. I want to build with a wider purpose: not only to create useful products, but to contribute to work that can make life better for people at a larger scale. I know that kind of impact takes time, humility, discipline, and the willingness to keep learning from real problems.

I am open to many opportunities and collaborations because good ideas can come from many kinds of people. I want to work with people who care about responsibility, service, and building things that are useful beyond presentation. My faith, family, discipline, and desire to serve continue to shape how I think about the work ahead.

The direction is still being written, but the pattern is clear: when there is a problem, there is also a possible solution. My goal is to keep finding those problems, understand them deeply, and build systems that help make the world a little better than it was before.