Morigro — GTM Growth Tracker

Every parent worries about the same thing: is my child growing properly? Morigro’s GTM Growth Tracker turns that anxiety into actionable insight — and makes the whole process feel less like a medical exam and more like a game.

The context

“GTM” stands for “Gerakan Tutup Mulut” — the Indonesian term for when kids refuse to eat. It’s a universal parenting struggle. Morinaga (the brand behind Morigro) wanted a tool that would help parents understand their child’s growth status and receive personalized nutrition advice.

The tool needed to feel friendly and approachable — not clinical. Parents input their child’s weight, height, and head circumference, and the system compares it against WHO growth standards.

My role

I joined as a frontend developer working closely with a PM and QA. The project was already in production when I came in, which meant the work was less about building from scratch and more about keeping things running — handling change requests from stakeholders, fixing bugs that slipped through, and iterating on the UX based on real user feedback.

The daily reality was: QA finds a bug → PM prioritizes it → I fix it. Stakeholder wants a UI tweak → PM scopes it → I implement it. It wasn’t glamorous, but it taught me how to work fast without breaking things.

What I built

The core application is a Next.js app that handles the entire growth tracking flow:

Data collection — a playful form with gender selection icons, date pickers, and measurement sliders. The UX was critical here — parents shouldn’t need a manual to use this.

Growth analysis — the system calculates percentiles and determines whether a child is growing normally, is underweight, or needs nutritional attention. The results come with playful labels (like “Si Pejuang Nutrisi Ekstra” — Extra Nutrition Fighter) that make the data feel encouraging, not alarming.

Personalized recommendations — based on the child’s growth status and nutritional needs, the system suggests healthy recipes and meal plans.

Shareable results — a visual growth card with QR code that parents can download and share with family members or pediatricians.

I also contributed to the parenthings feature (the results engine) and tumbuh kembang section — working alongside PM, backend developers, and QA to ship these features. The team dynamic was collaborative: PM scoped the requirements, BE handled the API and data processing, and I focused on the frontend implementation and UI polish.

The parenthings layer

The results engine lives at parenthings.morigro.id — a separate service that receives growth data via URL parameters, processes the analysis, and renders the results. It’s embedded in the main Morigro site via iframe, keeping the growth tracking experience self-contained.

What surprised me

Bug fixes in production hit different. On personal projects, you can take your time. On a live product with real users, every fix needs to be tested, scoped, and shipped fast. I learned to ask the right questions before touching code: What’s the impact? Who reported it? Can I reproduce it? What’s the quickest safe fix?

What I learned

This project taught me that maintenance is a skill. Building new features is fun, but keeping a production app stable while iterating under pressure — that’s where you learn discipline. Working with QA also changed how I write code: I started thinking about edge cases before they became bug reports.