"Lorong Product" Podcast Ep 16 - Startup Product Management: Building With Limited Resources
by NUS Product Club Admin • 5 December 2025
Embedded Files
Too busy to listen to our full-length episode? Fret not, this blog recap distils the key parts of Aamuel's journey and the product lessons that student builders and aspiring PMs can take away!
Most people wait until they graduate to start a company — but Aamuel didn’t.
In this Lorong Product episode, we spoke with Aamuel Chua, a self-taught programmer who founded his first company at 15, launched a paid aviation app at 17, and later co-founded OurCodeLab and SurfAlgo, building software, cloud and cybersecurity solutions for real clients — all without a marketing budget.
1. From Infocom Club to First Paid App
1. From Infocom Club to First Paid App
Aamuel’s story starts in secondary school, where he joined the infocomm club and was exposed to:
Block-based programming
Robotics
Early programming languages
He was also part of the second batch in Singapore to take the new O-Level Computing subject. Because the curriculum was new, a lot of what his teachers did was experimental — and that environment encouraged him to explore on his own.
That exploration eventually led to a simple idea:
“I wanted to build a place where I could launch apps that people could download and play.”
His first notable product was an aviation-themed app built in polytechnic, which let players create their own virtual airline. It wasn’t free — it was a paid app — and still managed to get thousands of downloads, boosted by partnerships with polytechnics that used it as part of their curriculum.
That app later became the foundation for his early company and client work.
2. Growing Through Word of Mouth, Not Marketing
2. Growing Through Word of Mouth, Not Marketing
One of the most striking parts of Aamuel’s story is that his company has:
Spent $0 on marketing
Acquired 100% of clients through word of mouth
It started with someone asking, “Can you build something like this for us?” — and saying yes.
From there, referrals kept coming. For many student founders, this is a useful mental model: you don’t always start with a grand product vision. Sometimes you start by solving one problem well, then grow through trust and delivery.
If he had to start again today with zero network, his approach would be:
Build a pro bono product for a large, visible community
Use that project as a case study
Leverage it to approach other organisations: “This community is already using this — here’s how it can work for you.”
3. Affordability, Pro Bono Work, and Undervaluing Yourself
3. Affordability, Pro Bono Work, and Undervaluing Yourself
OurCodeLab positions itself around affordable solutions. That’s not just a tagline — it shows up in how they price and ship.
Some examples he shared:
Providing software close to free or free for non-profits and NPOs
Creating a learning management system so clients only pay for subscription/royalty instead of full development
Absorbing losses in some projects because the priority is usefulness and impact
Over time, though, he realised there’s a trade-off:
In the early days, they heavily undercut their own value — offering projects at ~50% of what they were worth “because we were new”
Looking back, he feels the quality was often on par with larger vendors, and underpricing wasn’t always justified
For student founders, the lesson is simple: Helping people and being affordable is good — but you’re still a business, not a charity. You need to pay your team and keep the company sustainable.
4. Being Self-Taught: Grit, Stubbornness and Learning How to Learn
4. Being Self-Taught: Grit, Stubbornness and Learning How to Learn
Aamuel self-taught programming, starting from Scratch (literally, the visual programming tool) before moving into full languages. Because there was no AI assistant or ready-made cheatsheets when he started, he had to:
Read documentation deeply
Learn how to search effectively
Break problems down and keep digging until he understood them
That built a kind of productive stubbornness. He doesn’t want to give up on a problem until he’s figured it out his way.
The downside? He admits it can make him resistant when others suggest different methods. But the upside is clear — it trained him to be resourceful, persistent, and comfortable dealing with ambiguity, all of which are core skills in product.
5. Over-engineering, Iterations, and Knowing When Not to Reinvent
5. Over-engineering, Iterations, and Knowing When Not to Reinvent
Not every feature or idea worked out. He shared an example of an over-engineered admin feature that seemed brilliant in concept but turned out to have major security issues, and thus ultimately had to be scrapped and replaced with a standard, proven approach
His conclusion:
"...we have to just stick to what other people have and just follow to that because if other people are still using it, it just means that that's the most optimal one. And it doesn't mean that it is something that you create means is something that is super efficient. Usually the best rule of thumb is if it doesn't break, don't fix it."
Similarly, his aviation simulation platform went through five to six major iterations over the years:
Each rebuild showed how much his skills had grown
Launching it into real usage (with both good and bad feedback) taught him more than keeping it as a private side project
6. Prioritisation and Thinking Five Years Ahead
6. Prioritisation and Thinking Five Years Ahead
When scoping projects with clients, Aamuel doesn’t just ask, “What do you need now?”.
Instead, he asks:
“In five years’ time, what do you really want from this product — if we ignore budget and timeline for a moment?”
That question matters because long-term needs affect how you design the foundation.
He shared a case where a client later requested a full transaction history for loyalty points — a feature that wasn’t originally discussed. Because that requirement wasn’t surfaced early, the system structure didn’t naturally support it.
For student PMs and early founders, the takeaway is:
Your discovery phase should surface future expectations, not just launch features
Good product decisions now can reduce painful rework later
7. Testing and Feedback With Limited Resources
7. Testing and Feedback With Limited Resources
As a small team, OurCodeLab doesn’t always have the luxury of large-scale user research.
Some of their testing methods include:
Internal end-to-end testing: developers, testers, and designers sitting together in one room and running through flows as if they were real users
Layered checks:
First pass: internal team tests the whole flow
Second pass: Dev + QA checks
Third pass: client user acceptance testing (UAT) before sign-off
For Aamuel, the hardest PM principle to apply isn’t MVP or prioritisation — it’s getting honest user feedback:
Friends often sugarcoat feedback
Cold audiences may ignore surveys
It’s difficult to reach strangers who will give you honest, critical input
So part of being scrappy is designing processes that still catch issues — even when feedback is hard to collect.
8. Burnout, Scheduling, and Saying “No”
8. Burnout, Scheduling, and Saying “No”
On burnout, Aamuel is candid: it happens a lot. Between late nights, early mornings and overseas clients in other time zones, it’s easy to overload.
His way of coping:
Planning schedules with buffer time, knowing some tasks will slip
Accepting that you don’t have to finish everything today — as long as there is room to shift work without derailing projects
He also emphasises the PM skill of saying no:
Clients may request things that are unrealistic or misaligned with best practices
The team is still responsible for the outcome, even if the spec came from the client
It’s better to push back and suggest a different approach than to build something you know won’t work well
For Aamuel, the hardest PM principle to apply isn’t MVP or prioritisation — it’s getting honest user feedback:
Friends often sugarcoat feedback
Cold audiences may ignore surveys
It’s difficult to reach strangers who will give you honest, critical input
So part of being scrappy is designing processes that still catch issues — even when feedback is hard to collect.
9. The PM Lesson He Wants Students to Remember
9. The PM Lesson He Wants Students to Remember
When asked what PM lesson he’d pass down to the next batch of NUS Product Club members, his answer was clear: Align expectations clearly. Make sure what’s in your head and what’s in the client’s head is truly the same.
That means:
Over-communicating requirements
Clarifying long-term goals
Being upfront when something isn’t feasible
Ensuring both sides share the same mental picture of the product
Because at the end of the day, users judge the product you ship, not the spec you started with.
If you want to dive deeper into his story — including childhood Lego tinkering, aviation dreams, and more on how he juggles roles as founder, engineer, and product builder — the full episode is worth a listen!
About the Author
About the Author
#7A: NUS Product Club Admin
#7A: NUS Product Club Admin
"Modern slave, magical worker" - or so NUS Product Club Admin himself claims to be. As his name suggests, NUS Product Club Admin assists our Operations and Publicity Teams in handling administrative enquiries from our students regarding our various club activities. In addition, he assists in running our social media channels - including Telegram, Instagram and LinkedIn.
Page updated
Google Sites
Report abuse