Final Year Project: Building a Tourism App for Singapore

I was sitting in the Nanyang Technological University engineering lab, staring at the screen of my laptop, running a test case for the mobile app my team had built over the past year.

The app worked. It loaded maps correctly. It processed user input. It handled edge cases I'd spent weeks anticipating.

But something felt different from all my other projects.

For the first time, I wasn't building this to solve an immediate, tangible problem. I wasn't automating game economies for real money. I wasn't flipping broken hardware for profit. I wasn't trying to squeeze efficiency out of a business process.

Instead, I was building something for a structured process-for coursework, for grades, for the completion of a four-year degree in Electrical and Electronic Engineering.

And it forced me to think differently about what I'd already learned.

The Project: Formal Structure Meets Entrepreneurial Thinking

For my Final Year Project at NTU, my team developed a mobile tourism application for Singapore visitors - a cross-platform app built on Ionic, targeting both iOS and Android from a single codebase. The app helped tourists discover and navigate Singapore's attractions: location-based recommendations, itinerary planning, points of interest, and contextual information served up based on where you were standing. The project was formally published in NTU's digital repository - academic record of something that felt very different from my usual builds.

The tech stack was Ionic with Angular - HTML5 and TypeScript compiled into native-looking mobile apps. For someone who'd spent years writing Python automation scripts and JavaScript workflows, the cross-platform mobile paradigm was genuinely new. One codebase. Two app stores. That elegance appealed to the same part of me that built five game accounts from one script.

What was strange about this project-compared to everything I'd done since age 18-was the process, not the technical execution. I'd already written complex automation scripts. I'd already designed systems to handle edge cases. I'd already debugged under pressure.

What was new was the documentation. The requirements gathering. The formal design reviews. The comprehensive testing protocols. The project management methodology.

By 2017, I'd been building automated systems for nine years-longer than I'd been in formal education. But university was teaching me something those nine years had taught me informally: how to formalize what you know.

The Contrast: Entrepreneurial Speed vs. Academic Rigor

Game automation taught me to move fast. Identify a problem. Build a minimal solution. Refine based on real-world feedback. Iterate again.

That approach worked. It made SGD 2K monthly by age 18. It created a sustainable income stream that ran for years.

But it had gaps. I didn't have formal design patterns. I didn't document assumptions clearly. I didn't build for handover to someone else. I optimized for getting it working now, not for someone maintaining it later.

University forced the opposite. Before writing a single line of code, we spent weeks in the design phase. We created user personas. We documented non-functional requirements. We designed the system architecture before implementation.

This felt slow. Inefficient. Unnecessary when I could just build and iterate.

And then, halfway through the project, I realized: my approach worked for solo projects running forever. Academic projects needed to be handed off and understood by others.

The rigor wasn't bureaucracy-it was scalability of knowledge, not just code.

Building Something That Outlasts Your Involvement

The game automation scripts I built at 18 existed in my head. If they broke, I fixed them. If I wanted to explain them, I'd show you the code. No one else needed to understand them-I was the sole beneficiary.

The tourism app was different. My team members needed to understand my modules. The NTU examiners needed to evaluate the system based on documentation, not just whether it worked. The university needed evidence that I understood software engineering principles, not just that I could code.

This was the key transition: building for yourself vs. building for deployment.

At NTU, I learned:

• Requirements documentation: What the system must do, formally specified
• Design specifications: How those requirements are met, architecture-level thinking
• Testing protocols: Systematic proof that the system works, not just "it seems to work"
• Handover documentation: Making knowledge portable

These weren't new concepts to me intellectually. But formalizing them-writing them down, structuring them clearly, building to someone else's specifications-that was new.

The Unexpected Insight

Halfway through the project, something clicked. I realized that what felt like bureaucratic overhead at first was actually craft.

The game automation was craft-building something elegant that solved a problem efficiently. But it was craft for an audience of one.

The tourism app forced craft for an audience of many. That required rigor I hadn't needed before.

Both types of craft matter. Solo projects need to be elegant and efficient. Team projects need to be clear and handover-able.

Enterprise projects-which I'd move into within three years-need both. They need to be efficient and maintainable, elegant and documented, optimized and understandable.

University was teaching me how to build systems that other people could scale, not just systems I could run.

Validation Through Structure

What surprised me most was how validation through structure felt different from validation through results.

Game automation validated itself: Make SGD 50, problem solved. Hardware reconditioning validated itself: Repair succeeds, profit realized.

Academic projects validate through process. Not just "does it work?" but "did you follow engineering principles? Can you explain your choices? Does your documentation match your implementation?"

I'd learned those principles by doing, but university formalized them. My professors weren't asking me to re-prove that I could code-they were verifying that I could engineer.

Looking back at the game automation at 18 vs. the tourism app at 21, the difference is striking. The game automation was sophisticated-it had risk management, image recognition, market arbitrage. But it was sophisticated to solve a problem, not to be understood.

The tourism app was simpler in scope but more carefully architected. Not because I was a better engineer at 21 than 18, but because I was building for different constraints.

The Real Value of Formal Education

For me, university wasn't about learning to code. I'd been doing that since age 17 in polytechnic. It wasn't about learning problem-solving-I'd been doing that since age 18 with real money at stake.

University was about learning vocabulary for what I'd already figured out, and structure for thinking about problems systematically.

The game automation taught me that "risk management matters." University taught me to formalize it as "failure mode analysis" and "mitigation strategies."

I learned arbitrage opportunities existed. University taught me to approach them through "market analysis" and "competitive positioning."

Both were true. Both were useful. But one was knowledge from doing, and one was knowledge from studying how others think about doing.

The Lesson: Informal and Formal Are Complementary

By 2017, I'd built successful systems through entrepreneurial learning. Fast iteration. Real-world feedback. Quick pivots.

University taught something different but equally important: how to think about systems formally, how to document thinking, how to hand knowledge off.

Nine years later, both matter. My corporate role at a global medical aesthetics and technology company uses formal engineering thinking-SOPs, regulatory documentation, change control. But the speed of iteration comes from entrepreneurial thinking-rapid prototyping, failing cheaply, iterating fast.

The game automation was pure entrepreneurship. The tourism app was pure academics. The best work I've done since combines both.

That Final Year Project wasn't a distraction from what I'd already learned. It was the missing piece-the formalization that made everything else scalable.

Looking Back

I spent four years at NTU, but the most valuable learning came in the last year. Not because the content was harder, but because it forced me to integrate informal and formal thinking.

At 18, I learned systems thinking by building game automation.

At 21, I learned how to engineer those systems.

At 33, I realize both were essential.