Background

This idea came from my mother's weekly arisan group. Every week, one person took turns recording payments in a notebook. The problems: frequent miscalculations, missed entries, and end-of-period reconciliation meant starting from scratch. I realized this could be automated. The app lets admins mark PAID/UNPAID, view each participant's payment history, and export Excel reports to share via WhatsApp.

Technical Decisions

• Next.js for frontend + API routes — TypeScript end to end.
• Supabase for PostgreSQL + Auth — minimal infra overhead.
• 3 database tables: pengaturan_arisan, peserta_arisan, setoran_mingguan.
• Unique constraint (peserta_id, minggu_ke) to prevent duplicate payments.
• PWA support — can be installed on mobile for easy access.
• Excel export via ExcelJS for offline recaps.

Challenges

The biggest challenge was maintaining payment data integrity — no duplicate or missed entries. Solved with the unique constraint. UI had to stay dead simple because the users are not tech-savvy. Privacy was also key: payment amounts and winners are not publicly accessible.

Background

This system was originally requested by the local neighborhood head. Resident data was recorded in a single ledger kept at their home. Anyone needing data — for official letters or surveys — had to visit in person, and the ledger was often incomplete or missing pages. I saw this could be solved with a simple system: resident data stored in a database, searchable, filterable, and exportable anytime. Top priorities: data security and limited admin access.

Technical Decisions

• Next.js + Supabase with Row Level Security for data access control.
• Supabase Auth — only registered admins can manage data.
• Public timeline with search + filter blok (A, B, C...) + pagination.
• Admin dashboard for full CRUD operations.
• Excel export for physical reporting needs.
• Unit testing with Vitest + Testing Library.

Privacy

Resident data is sensitive. Public timeline shows only basic info; detailed data is admin-only via Supabase RLS. The public repo is a mirror with no real data.

Context

This was my UKK project — the final competency exam for SMK Software Engineering. The task: build an IoT parking system using ESP32 with RFID, a real-time web dashboard, and automatic billing. This is the most complete project I've built (74 commits, 3 stars).

How it works

RFID cards are scanned by ESP32 at entry/exit. Duration is calculated automatically, fees are rounded per hour. Data flows through MQTT → Supabase Realtime → web dashboard (Vanilla JS with MVC pattern). Two dashboard roles: petugas (monitor + confirm exit) and owner (reports + revenue stats).

What I learned

First end-to-end IoT project — from ESP32 C++ firmware to web frontend. MQTT protocol, Supabase Realtime, MVC architecture in vanilla JS. This project bridges hardware and software, which is exactly where I want to grow.

Context

A RESTful API built to manage object data with full CRUD operations — create, read, update, and delete. Built as part of my focus on deepening Python backend development.

Technical Decisions

• FastAPI for building the API endpoints.
• Pydantic for input data validation.
• HTTP error response message handling.

What I learned

Solidified my understanding of REST API design, request validation, and structured error handling — a strong foundation for backend work with FastAPI.