Pulsy

Pulsy is the portfolio's primary final-year project and the clearest current example of applying a complete software-engineering process to a mobile product.

The project is still labeled Finalizing. Publishing this case-study structure does not change that product status or imply that every planned feature and evidence item is complete.

The confirmed material describes a multi-part engineering problem: turn product requirements into a coherent mobile workflow while keeping each user's data isolated, synchronized, and available through a usable interface.

The final content source has not yet supplied the exact user-domain problem statement, so this draft deliberately avoids inventing users, scenarios, or product outcomes.

As a final-year project, Pulsy provided a practical way to connect requirements, interface decisions, application development, backend integration, testing, and documentation rather than treating them as separate academic exercises.

It also created a focused setting for applying Flutter and Supabase to a system with authenticated, user-specific data.

The confirmed solution is a Flutter mobile application connected to Supabase services for authentication and database-backed workflows.

Its approved scope includes user-specific access, cloud synchronization, reminders, and AI integration. This draft records that scope without claiming that every item has reached final production status.

The available project record confirms the following implementation areas. Final feature names and screenshots remain intentionally absent until they can be verified.

The implementation combines a Flutter and Dart client with Supabase authentication and database services. Requirements and user flows guide the interface, while application logic coordinates authenticated data access and synchronization.

Row Level Security is part of the confirmed data-access approach. It supports the requirement that users interact only with records intended for them.

The confirmed architecture keeps the mobile experience in Flutter and uses Supabase for the connected authentication and data layer. This gives the case study a clear client, identity, and persistence boundary.

The exact alternatives considered, rejected options, and final interface rationale have not yet been documented in the approved content source.

Connecting interface behavior, authentication state, database access, synchronization, and validation creates integration work across several parts of the application.

The current source does not identify specific failures or troubleshooting outcomes. Those stories will remain pending instead of being reconstructed from assumptions.

Software testing and user acceptance testing are confirmed parts of Pulsy's project scope. They are presented here as activities, not as proof of a particular success rate or quality metric.

No test counts, participant numbers, pass rates, quotations, or measured results are available in the current approved material.

Pulsy connects academic software-engineering practices with a working mobile stack. The strongest confirmed learning theme is managing the relationship between requirements, interface behavior, authenticated data, integration, and validation.

More specific lessons will be added when they can be tied to documented decisions and test evidence.

Pulsy is currently Finalizing. The portfolio therefore presents it as substantial ongoing final-year work, not as a completed or deployed production product.

No user totals, performance claims, public deployment, or outcome metrics are claimed in this draft.

The next improvement list should be decided from the project's remaining completion work and validated testing evidence. Until that review is complete, this case study does not invent a product roadmap.