Archived

QRaten — Offline QR Attendance System (Archived)

Full-Stack Engineer / Sole Developer · 2024 · Iterative dev (late 2024 - late 2025) · 4 people · 4 min read

Functional product with landing page in production. Implemented a TOTP-based QR system enabling offline attendance registration; project archived while preparing a PWA rewrite.

Overview

QRaten is an attendance tracking application based on QR codes designed to work even without an internet connection using TOTP-style codes. It originated from a real classroom problem: quickly registering attendance for large classes without relying on connectivity. I built the entire application end‑to‑end, leading architecture, development, infrastructure, and product decisions while collaborating with two designers for the UI. The solution was developed as a complete ecosystem with functional parity across a Vue.js web application, a Flutter mobile client, and an early React Native prototype.

Problem

Professors with large classes (90+ students) lose significant time manually taking attendance. Existing solutions mostly behave like spreadsheets and require internet connectivity. None provided a reliable offline-first system capable of registering attendance instantly during class while keeping infrastructure costs low.

Constraints

  • Attendance registration needed to work without internet connectivity for both professor and students.
  • Infrastructure costs had to remain extremely low to make the product viable for universities.
  • The UX needed to be simple enough for non‑technical users.
  • Initial business requirement included distribution through app stores (Play Store / App Store / Microsoft Store).

Approach

I iterated through several architectural designs to find the right balance between reliability, cost, and scalability. Early versions used traditional client‑server validation with caching layers, but infrastructure costs were too high. Eventually I redesigned the core mechanism around TOTP-based QR codes, allowing validation to happen primarily on the client side. This drastically reduced server load and removed the need for Redis. In the final iteration I moved the backend toward Supabase and began planning a PWA rewrite to simplify distribution and avoid regional payment infrastructure limitations.

Evolution

v1 — Client/Server Prototype

Late 2024

Backend with Nest.js and PostgreSQL, mobile client with React Native. QR validation required internet connectivity.

v2 — Redis Caching Layer

Early 2025

Added Redis and local storage to tolerate partial offline operation; however infrastructure costs increased significantly.

v3 — Flutter Rewrite

Mid 2025

Rebuilt the mobile client using Flutter for better stability, faster iteration, and improved UI implementation.

v4 — TOTP Architecture

Late 2025

Replaced Redis with a TOTP algorithm allowing QR generation and validation directly on the client. Backend migrated to Supabase for authentication and data management.

v5 — Web Platform & Subscriptions

Late 2025 — archived

Developed a full-featured web application with Vue.js, maintaining functional parity with the mobile clients. Included a super‑admin dashboard to manage subscriptions manually due to Stripe limitations in Bolivia.

Key Decisions

Adopt TOTP for offline QR validation

Reasoning:

Using TOTP allows QR codes to be validated on the client or with minimal backend verification. This drastically reduces server calls and infrastructure requirements, making the product commercially viable for universities.

Alternatives considered:
  • Centralized validation using Redis
  • Fully online validation

Rewrite the mobile client in Flutter

Reasoning:

React Native introduced friction due to frequent updates and breaking changes. Flutter provided more stability and built‑in UI components, which accelerated development.

Alternatives considered:
  • Continue with React Native
  • Build fully native apps for each platform

Adopt Supabase and move toward a PWA strategy

Reasoning:

Supabase provided authentication, row-level security, and realtime capabilities out of the box. A PWA reduces distribution friction and allows faster MVP deployment without relying on mobile app stores.

Alternatives considered:
  • Self‑hosted Docker infrastructure on DigitalOcean
  • Firebase-based backend

Tech Stack

  • Web Platform: Vue.js (Full Web Application)
  • Mobile Frontend: Flutter
  • Archived Mobile: React Native (Functional Prototype)
  • Backend: Nest.js (early versions), Supabase (final iteration)
  • Database: PostgreSQL
  • Hosting: Vercel (landing), DigitalOcean (prototypes), Supabase Edge Functions
  • Authentication: OAuth (Google), Magic Links, Email/Password

Result & Impact

  • ~30 downloads during limited release
    Play Store downloads
  • No large-scale deployment — product remained in negotiation/demo stage
    Production usage

Demonstrated a technically viable solution for offline QR attendance systems and validated interest with institutional stakeholders.

Learnings

  • For early-stage products, minimizing distribution friction (for example via PWA) is often more valuable than native apps.
  • Infrastructure decisions should prioritize cost predictability before extreme scalability.
  • Payment infrastructure compatibility with the local market must be validated early.

Challenges & Pivots

  • Initial architecture optimized too early for scalability using Redis, increasing infrastructure complexity and cost.
  • Stripe dependency for subscriptions failed due to regional availability restrictions in Bolivia.

Engineering Leadership

Most impactful technical decision

Adopting TOTP-based QR validation drastically reduced infrastructure requirements and made large-scale attendance registration feasible at low cost.

Most significant mistake

Choosing Redis too early for scalability; later corrected by redesigning the architecture around TOTP.

Trade-offs

Skipped automated tests initially to iterate faster and reach a working demo for stakeholders.

Senior-level responsibility

Full ownership of architecture, infrastructure, product direction, and coordination with design collaborators.

Timeline Highlights

  • Initial idea and prototype — Late 2024
  • Architecture experiments and Redis scaling tests — 2025
  • Flutter rewrite and TOTP architecture — Late 2025
  • Project archived and planned PWA redesign — 2026

Additional Context

This archived version of QRaten represents a year of iterative development and architectural experimentation. Screenshots and UI designs (Figma) are included in the repository for visual reference.

This document outlines the technical and product decisions behind the system, as well as the architectural approach taken during its development.

Throughout the project, I collaborated closely with two product/UX designers on the UI and dashboard experience:

The archived source code of QRaten are available in the public repository: qraten-archived

Next Steps (Planned)

  • Build a PWA MVP focused on offline attendance registration.
  • Implement a payment flow compatible with Bolivia.
  • Introduce automated tests and monitoring infrastructure.

*Note:- Sensitive details about potential clients or negotiations have been intentionally omitted for confidentiality reasons.

All projects