Regiforte

Regiforte is designed around an environment where:

• Students attend classes several days a week
• Students may also come to the school outside scheduled class times
• Students may come specifically for self-learning
• The school needs to know who is currently inside the premises
• Attendance and presence shouldn't depend entirely on paper
• Students need a reliable way to identify themselves
• Internet connectivity can't always be assumed
• The system needs to work around real school schedules and holidays

Regiforte is built around presence, not just attendance as a yes/no classroom checkbox. A student might arrive for a scheduled class, arrive for self-learning, visit for another reason, leave the premises, or return later — and the app is meant to record what's actually happening rather than force every visit into a single "attended" or "absent" state.

Each student has a digital identity inside the app — profile information, a profile photo, and a QR-based credential that represents them. That credential is what gets scanned to identify a student and record the relevant presence event.

Physical ID cards or dedicated scanning hardware are possible extensions later, but right now the digital credential inside the app is the primary form of identification.

A student uses their digital credential to identify themselves when entering or leaving the school. The scanning flow is meant to be quick, clear about what just happened, and straightforward for staff to understand and rely on — without overstating how secure any particular mechanism is until it's actually been hardened.

This is one of the more important engineering decisions in the project. Connectivity in a school building isn't guaranteed, and a presence event shouldn't fail just because a phone temporarily has no internet connection.

The app is being designed with an offline-first approach: relevant presence data can be stored locally and synchronized once connectivity returns, rather than depending on a live connection for every scan.

• Local presence storage
• Connectivity awareness
• Synchronization once back online
• Reliable event handling
• Avoiding duplicate events

Regiforte is also designed around real school operating schedules rather than treating every day the same way. The app needs to understand things like opening hours, class schedules, when the last class of the day ends, school and public holidays, and that some visits are for self-learning rather than a scheduled class.

That schedule and calendar context is what lets the app give a student more meaningful feedback than a plain confirmation.

After a scan, the app tries to say something useful rather than just confirming success. What it shows depends on what's actually happening — whether the student is arriving or leaving, and whether it's during a scheduled class or outside of it. A few examples of the kind of feedback it's designed to give:

• You're checked out.
• You're back at Regiforte.
• Today's classes have ended. You're welcome to stay and keep learning.

The profile experience holds information like a profile photo, date of birth, gender, emergency contact, and identity details. This isn't just a settings screen — it's part of what makes the digital identity behind the QR credential meaningful, since that identity is what staff and the system rely on when a student is scanned in or out.

I wanted the presence system to stay independent from the UI, so the app separates the presence domain, the repository layer, synchronization logic, and the presentation layer. That makes it easier to change how data is stored or synchronized later without having to rebuild the interface around it.

Underneath that sits the usual foundation a Flutter app needs to stay maintainable as it grows — routing, authentication, design tokens and theming, environment configuration, and a profile and schedule layer that the presence system reads from. None of it is meant to be clever; it's meant to still make sense once a backend and an admin dashboard are attached to it.

• Reliable presence events — recording one is easy when everything works; the harder part is keeping it accurate when connectivity changes or a student scans more than once.
• Offline behavior — the app has to keep working with no signal, without losing or duplicating presence data.
• Schedule context — a scan at 9am and a scan at 2pm can mean different things depending on the day's schedule, so the app needs to understand that rather than treating every scan identically.
• Student identity — reliably connecting a physical person to their digital identity, quickly enough that it doesn't slow anyone down.
• User feedback — a scan shouldn't just return "success"; the student should understand what happened and what their presence status actually means.

Regiforte isn't just a screen with a QR scanner attached to it. It has to account for real school operations, the different reasons a student might show up, unreliable connectivity, scheduling rules, identity, clear feedback, and data that stays consistent once a backend and synchronization are added — while remaining something I can keep building on rather than rewrite.

I'm currently building the mobile foundation and core presence experience. The system is being developed incrementally, with the architecture designed so backend services and administrative functionality can be introduced without having to rebuild the mobile application from scratch.

Planned, not yet built:

• Backend integration
• Administrator web dashboard
• School management tools
• Richer attendance and presence analytics
• Notifications
• Expanded reporting
• Production deployment