Dex Bennett / Stylenecy

Case 03 · 2025 — present

Sowan

Elderly Indonesians with knowledge and no route to income

A marketplace where elderly people are the paid experts, not the beneficiaries. It won a national business plan competition, and the backend I later wrote for the thesis version assumes I will make mistakes.

Status
Live demo · thesis build in progress
My role
Platform builder in a three-person student team · thesis build author
Built with
Next.js 16 · TypeScript · Tailwind v4 · PostgreSQL · Supabase RLS · Postgres RPC
Sowan — screenshot of the live site, 6 Oct 2026
1stplace, national business plan competitionKSE Juara 2026, announced 2 May
8server functions hold every writethe browser holds none
10security holes found and closedbefore the backend ever ran
30 / 70platform / mentor revenue splitcomputed server-side

(01) The problem

What was actually in the way

An older Indonesian may hold a regional language, a craft, or three decades of professional judgement — and no way to turn any of it into income. The usual framing puts elderly people on the receiving end of a programme. This one puts them on the earning end.

That inverts the design problem. If the expert is 65, the interface is the barrier, not the subject matter. Small text, dense navigation and low-contrast greys are the reason the person cannot work, not their age.

And the moment money enters a marketplace, the browser stops being a place you can trust with anything.

(02) Decisions

What I chose, and why

01Accessibility as a hard constraint, not a nice-to-have

The design rules were fixed before layout: minimum 18px text, touch targets of at least 56px, contrast of at least 4.5:1, and navigation that never needs more than one click to reach the next step. These are constraints the rest of the design has to fit around.

02The browser is given no write permission at all

In the thesis build, the client has no insert, update or delete grant on any table — not blocked by policy, revoked at the grant level. The only way to write anything is through eight server-side functions. Reads are limited by row-level security: the mentor catalogue and reviews are public, bookings, transactions and balances are yours only.

03Price is read from the database, never from the request

When a booking is created, the function reads the price and tier from the mentors table itself. It checks that a slot remains, that you are not booking yourself, that the time does not collide, and that you do not already hold five active sessions. It takes a per-mentor lock so two people cannot take the same slot in the same instant. The 30/70 split and the mentor balance are computed by database trigger, not by anything the browser can influence.

04The privileged key is never created

This build deliberately has no all-access database key anywhere — not in the environment, not on the host, not in the repository. A key that does not exist cannot be committed by accident. That decision came directly from what I found in my own workshop project a month earlier.

05Ten real holes, found by auditing my own schema

The audit was against my own earlier code, and it was not a clean bill of health. The purchase amount was being sent from the browser, so a session priced at Rp350,000 could be paid at Rp1. Learners could update transaction rows, so cycling a payment from released to held and back minted mentor balance on every loop. Payouts were never checked against the available balance. The profile table was readable by anyone, which would have exposed the real name of every research participant, elderly mentors included. Account role was taken from signup metadata, so anyone could register as a mentor. And a permissions gap meant every booking would have failed silently in the first place — the likely reason the backend appeared never to work.

06Write the rules twice on purpose

The same rule exists in the browser for a fast, kind error message and in the database for safety. The browser copy is treated as untrusted by design. When they disagree, the database wins.

(03) Result

What is true now

  • 1st place — Business Plan Competition, KSE Juara national level 2026 (Karya Salemba Empat, Universitas Sumatera Utara), announced 2 May 2026 in Medan.
  • Top 15 semifinalist — Business Plan Competition EURECA 2026, Universitas Prasetiya Mulya.
  • Top 10 finalist — Solve-It Challenge 2026, UKRIDA, final round 13 June 2026.
  • The demo build is public and runs in five languages.

(04) Not done

What is unfinished or untrue yet

  • Escrow is simulated. There is no payment gateway and no real money moves — that boundary is set by the thesis scope, and I am not going to blur it.
  • The thesis backend is written and reviewed but not yet running: its database project has not been created, so none of it has served a real request.
  • Session times are still text labels rather than real timestamps, so collision checking only holds within a single day. That is logged as phase-two work, not hidden.
  • Payout state is advanced manually. There is no admin panel, because there is exactly one operator.
  • The competition results belong to a team of three. I built the platform; the business case was not mine alone.

(05) Sources

Where these claims come from

Working documents on my own machine, not marketing copy. Listed so the numbers above can be challenged.

— Semester 7/Tugas Akhir/sowan-skripsi/BACKEND.md — architecture, the eight functions, the ten-hole audit, the stated limits— All of SOWAN Business Plan/Informasi-Biro/Draft-Artikel-Prestasi-Dex_16Jun.md — competition results with certificate numbers— All of SOWAN Business Plan/Competition-KSE/Info-Detail_KSE.txt — organiser and competition scope— All of SOWAN Business Plan/Competition-PNB/PROJECT_MASTER.md §5 — gerontechnology design rules, 30/70 split— All of SOWAN Business Plan/PETA-SOWAN_1-Ags-2026.md — which build is which
Animations are off on this device