Case 01 of 10

AttendEase

Education management and attendance for institutions. I built its mobile app, then took ownership of the product.

• My part: Built (built it as a developer); Owned (owned the product)
• Role: Flutter Developer → Product Manager
• Where: IT Research & Development, Islington College · ING Tech
• 8,000+ students on the portal
• 500+ staff and teachers

Product visuals

Illustrative mockups and conceptual diagrams, not production screenshots:

• Portal & app (illustrative mockup): The student portal on the web beside the mobile app. Layout and figures are sample data.
• Staff view (illustrative mockup): Attendance across an institution for staff and teachers, with reports to export.
• Students (illustrative mockup): Student records as staff manage them, with attendance shown.
• Mobile app (illustrative mockup): The cross-platform app I first built as a Flutter developer.
• Delivery flow (conceptual diagram): How an institution's request travels to a release, and where change control sits.

The problem

Institutions rely on attendance and college records every day, and each one brings its own requests. The product has to keep taking them on while scope, quality and release readiness stay under control.

My responsibility

First as its Flutter developer, building the mobile app; then as Product Manager, owning requirements, scope and delivery.

• Led client elicitation and requirements discovery.
• Translated business needs into SRS documents, PRDs and acceptance criteria.
• Managed scope, change requests and backlog priorities.
• Managed release readiness, weighing security (VAPT) findings before release.
• Planned and scheduled data migrations during server and database moves.

Decisions and contributions

Instead of accepting every institutional request as an immediate development task, I set clearer requirements, acceptance criteria and change-control decisions to protect the shared product roadmap.

• Every requirement written with acceptance criteria, so engineering and QA share one definition of finished.
• Change requests weighed in sprint and PI planning, with in-scope and out-of-scope calls recorded in ClickUp.
• Release dates set by readiness: security (VAPT) findings and data-migration windows.

Working with engineering, QA and stakeholders

• Engineering built the product, QA tested it and the security team assessed it; I coordinated delivery across them.
• Coordinated security risk analysis (VAPT) with the security team and reported progress to stakeholders.
• Used my development background to bridge technical and non-technical stakeholders.

Challenges and trade-offs

Visible change control over quick yeses, even when absorbing a request would have been faster.

• One shared product, many institutions with their own requests.
• Launches depend on security findings and data-migration windows.

Outcomes

• A student portal built from scratch, now used by 8,000+ students.
• 500+ staff and teachers using AttendEase.
• Deployed across 5+ educational institutions.
• Earlier, as its developer: released on Google Play and the App Store, with Spring Boot integration that improved responsiveness and data sync by 35%.