PesantrenQu — Rebuilding a Parent-School Product for Real Clients

PesantrenQu is a parent-school mobile product for Islamic boarding schools. It gives parents one place to handle tuition, savings, donations, student updates, and school communication without juggling spreadsheets, transfers, and WhatsApp threads.

I worked on the newer Flutter version as the lead mobile engineer. This was not just feature work. It was a product rewrite from the older React Native app into something easier to maintain, easier to configure, and much easier to ship for real school clients.

---

Overview

At the product level, PesantrenQu helps parents stay connected to their children's schools.

They can sign in, view their children, check balances and bills, pay syahriah and installments, manage savings, make donations, and follow school updates from one app. Some schools also unlock more advanced flows depending on their subscription plan.

What changed in the newer version is not only the UI stack. The product became more mature operationally. The Flutter app is already live on the Play Store and the white-label setup now supports two real school clients with different plan tiers:

• A Gold-plan deployment for Pondok Kwagean
• A Platinum-plan deployment for MQ Mobile, the client app for Manhajulquran Ploso

That matters because it turns the rewrite into a business-ready system, not just a cleaner codebase.

---

What Changed

The older app was a large React Native super app with a very broad surface area. It tried to cover many school roles and modules at once, which made school-specific behavior, branding, and release work harder to manage over time.

The Flutter rewrite took a more focused approach.

Instead of carrying forward the full sprawl, I helped reshape PesantrenQu around the parent and guardian experience first: student visibility, school updates, tuition, installments, savings, donations, verification, and security. The goal was not just to modernize the stack, but to turn the product into something easier to ship, easier to configure per client, and more reliable in production.

The result is a product that is narrower in the right ways and stronger where it matters most:

• The parent-facing journey became more coherent
• Plan-specific behavior became easier to manage across Gold and Platinum clients
• School branding became part of a structured system instead of ad hoc app variation
• Releasing a client build stopped feeling like a custom one-off process

---

My Role

On this project I worked as the lead mobile engineer for the Flutter rewrite.

My work covered four broad areas:

• Reframing the product from a broad legacy super app into a more focused parent-school experience
• Designing the Flutter architecture and the cross-cutting services the app depends on
• Building and refining core product flows such as guardian finance, donations, student views, verification, and security
• Creating the internal tooling and guardrails that made white-label delivery and day-to-day development faster

I was not only responsible for shipping screens. I was responsible for making the app easier to evolve, easier to configure per client, and easier for the team to work in.

---

What PesantrenQu Does

PesantrenQu is built around a connected parent loop rather than one isolated feature.

Parents can authenticate, connect to the right school context, view their children, follow school updates, review financial obligations, pay tuition and installments, manage savings, and make donations. The app also includes supporting areas like profile, verification, biometric access, and Islamic content.

A few parts matter especially much:

• Guardian finance, because parents need a reliable way to see bills, balances, and payment history
• Student views, because the product is not only about money but about staying connected to the child and school
• Security and verification, because parent-facing financial products need stronger trust than a simple content app
• Plan-aware access, because different schools do not buy the same product tier

What mattered most was making these flows feel like parts of one operational product instead of a collection of unrelated modules.

---

The Rebuild

The main technical shift was moving from a legacy React Native app into a more deliberate Flutter architecture.

In the old codebase, school variance was heavily tied to large app-level settings and scattered configuration. In the Flutter version, I helped turn that into a clearer model:

• A feature-first Flutter codebase with cleaner domain, data, and presentation boundaries
• A dedicated brand configuration layer for school-specific identity and behavior
• A plan and entitlement layer so features depend on capabilities, not hardcoded plan checks
• Runtime configuration that separates boot values from public brand and environment assets

That structure made the app easier to reason about, but more importantly, it made new client delivery less fragile.

I wrote deeper case studies on two of the most important systems:

• Capability-Based Entitlement System
• Biometric Enrollment & Verification

---

Multi-Client Delivery

One of the biggest improvements in the Flutter version is how much faster it is to ship for different school clients.

The newer app has an explicit white-label setup with brand-specific assets, runtime config, build versioning, and release tooling. That means adding or updating a client is no longer a messy process of patching app settings and hoping every environment lines up correctly.

This became real in production:

• The base PesantrenQu app remains live on Play Store
• Pondok Kwagean runs as a Gold-plan client
• Manhajulquran Ploso runs as a Platinum-plan client

That is the point where the rewrite stopped being an internal improvement and became a delivery system.

---

Internal Tooling

Some of the most valuable work I did on this project was not visible in the UI.

I built internal tools and guardrails to make the mobile codebase faster to work in and safer to scale:

• A client build tool that resolves brand, environment, version, icon generation, splash generation, and build entrypoints in one flow
• Runtime config rules that keep secret boot values separate from public bundled brand config
• API probe tooling that reuses the app's own config and networking assumptions for backend debugging
• Verification scripts for brand matrix coverage, asset consistency, and UI guardrails
• Engineering docs that make architecture and team conventions explicit instead of tribal knowledge

This matters because multi-client products usually slow down as delivery complexity grows. I wanted the opposite: as branding and plan variation increased, the process should become more systematic, not more fragile.

---

Impact

The rewrite changed PesantrenQu in two ways.

Externally, it produced a more mature parent-facing product that is already being used beyond a single baseline app. The Flutter version is live, supports real financial and school flows, and is already deployed across two schools with different plan tiers.

Internally, it changed how the product can be operated. Client-specific branding is more structured. Plan behavior is easier to manage. Configuration and release are faster. Debugging is more repeatable. The team now has a stronger foundation for adding schools without each new deployment feeling like a custom fork.

---

What I Learned

This project changed how I think about rewrites.

A rewrite is only worth it when it improves more than code quality. It has to improve delivery, configuration, reliability, and the team's ability to support real clients without turning every release into custom work.

PesantrenQu taught me to treat brand systems, plan entitlements, and release workflows as part of the product itself. Once those systems became more deliberate, the app stopped being just a rewrite and became a platform the team could actually operate.