KonektBarangay

Overview

KonektBarangay moves common barangay transactions online. Residents sign up, confirm their email with a 6-digit code, and verify their identity by uploading a valid ID. Once verified they can request documents such as a Barangay Clearance or Certificate of Indigency, choose a date and time to claim them, file blotter reports, and follow barangay news and events. Staff get an admin side to verify residents, process requests and reports, and publish announcements.

The problem

Getting a barangay document usually means going to the hall, lining up, and coming back or calling to ask whether it is ready. Residents have little visibility into their requests or reports, and staff track everything by hand. Moving this online also means making sure the person requesting a document really is a resident.

Goals

• Let residents request documents and book a claim schedule without a first visit
• Confirm each resident's email and identity before they can make requests
• Show a clear status for every request and blotter report
• Give staff one place to verify residents, process requests and post announcements
• Keep admin tools and approvals locked to staff accounts

Approach

I built it on Next.js with TypeScript and used Supabase for authentication, the Postgres database, file storage and realtime updates. A shared app shell gives residents and staff the same navigation on phone and desktop. Access is enforced in the database with row-level security, so the rules hold even if someone calls the API directly. The request flow stays split into three short steps (choose a document, pick an appointment, review the summary), and a request is only written to the database once the resident confirms the summary.

Key features

• Email verification codes

  New residents confirm their email with a 6-digit code before they can sign in, and forgotten passwords are reset with a code as well. Codes expire after 15 minutes.

• Resident ID verification

  Residents upload a photo of a valid ID after signing in. Staff review it from the admin side and approve or reject it with a reason the resident can see, and document requests unlock once the resident is verified.

• Guided document requests

  Nine document types, from Barangay Clearance to First-Time Job Seeker, plus an "Other" option, in a three-step flow that ends with a summary the resident reviews before submitting.

• Appointment calendar

  A month calendar with hourly slots inside office hours (Monday to Friday, 8 AM to 5 PM). Fully booked and unavailable days are marked.

• Blotter reports

  Residents file incident reports with the type, date, location and a written statement. Staff move each case through filed, under review, scheduled, resolved or dismissed, and can set a hearing date.

• News & Events

  Staff publish news, events and advisories. Residents see upcoming events on their dashboard and the full list on the News & Events page.

• Resident dashboard

  Request totals by status, quick links to common documents, the next appointment, upcoming events and recent requests on one screen.

• Admin tools

  Staff verify residents, filter and search requests, update blotter cases and manage announcements, with live updates and notifications.

Challenges & solutions

1. Anyone could register as an admin

   Problem

   The sign-up trigger copied the account role from sign-up data that the browser controls, so a crafted request could create an admin account.

   Solution

   I rewrote the trigger so every new account is created as a resident. Staff roles can only be granted from the database, never from the sign-up form.

2. Residents could approve their own requests

   Problem

   The update policy let residents change their own request, which meant a direct API call could set it to approved.

   Solution

   I added a database trigger that only lets residents cancel their own pending requests. Every other status change has to come from staff.

3. Verifying residents without exposing their IDs

   Problem

   ID photos are sensitive, but staff need to see them to verify a resident.

   Solution

   Uploads go to a private storage bucket. Residents can only add their own photo, staff view it through short-lived signed links, and residents who are not yet verified can't submit document requests.

4. Admin pages had to be protected, not just hidden

   Problem

   Removing admin links from the menu does not stop someone from typing /admin in the address bar.

   Solution

   A Next.js proxy runs before any protected page loads. It reads the Supabase session from cookies, checks the user's role, sends signed-out visitors to login with a link back, and redirects non-staff to their own dashboard.

Outcomes

• The full request lifecycle works end to end: submitted, pending, approved or rejected, then completed, with a notification at each step.
• Every account is email-verified, and residents are identity-verified before they can request documents.
• The layout adapts from phone to desktop, since most residents are expected to use a phone.
• Deployed on Vercel with automatic deploys on every push to GitHub.

What I learned

• Authorization belongs in the database. Hiding UI and checking roles in the app are only conveniences.
• Never trust data the browser sends at sign-up, including fields that look internal.
• Designing related tables (profiles, requests, reports, announcements, notifications) before building screens saved rework later.
• Realtime features need cleanup as much as setup.

What I'd improve next

• Send an email or SMS reminder before an appointment
• Add automated tests for the request and verification flows