SmartTaxApp

First, what is SST?

SST (Sales and Services Tax) is Malaysia's consumption tax — comparable to VAT in Europe or GST in Australia. Businesses above a revenue threshold must register for it and charge it on qualifying transactions.

Here's where it gets complicated: the rate you apply depends on three things at once — what you're selling, what kind of business you are (your MSIC code), and whether your revenue crosses the registration threshold. MSIC is the government's industrial classification: a cafe, a software company, a law firm, and a clothing retailer all hold different codes, and the same item can be taxed differently under each.

The problem

Startups don't know what tax to charge on their invoices. Cafes don't know whether their items qualify. Established SMEs reclassify products inconsistently across invoices. And when someone typed an item nobody had classified before, the old workflow had no process — the item simply went unresolved.

Underneath the confusion sat a data problem: the product depends on a reference database of items and MSIC codes that was never going to be complete on day one. Every unrecognized item was a data gap — and unhandled gaps accumulate until the system stops being useful.

What I built

Database & access control

• Designed the full PostgreSQL schema from scratch — profiles, purchases, invoices, msic_codes, items, sst_rules — structured for multi-tenant isolation.
• Implemented Supabase Row-Level Security: owner-only access on user-scoped tables, read-only on shared reference tables. The constraint is enforced inside PostgreSQL itself — it holds no matter what the frontend or any API client sends.

SST resolution engine

• A database-driven query chain: item lookup, then MSIC match, then MSIC category fallback, then the SST outcome.
• Zero hardcoded tax rates anywhere in application code. When a tax rule changes, it's a database update — no redeployment.
• Validated against a 12-case acceptance checklist covering different combinations of item type, MSIC code, and expected outcome — with screenshot evidence per case.

The self-improving classification pipeline

This is my favorite part. When a business owner keys in an invoice item that doesn't exist in the database yet, the system doesn't error — it quietly captures and queues it. Then, every Monday:

The admin is a tax specialist, not a developer. They work in a spreadsheet in a shared folder — territory they already know. No database access, no developer involvement, and the reference data improves automatically every week.

Authentication

Email login, password reset, and session handling — with redirect URLs configured correctly across development and production. A reset flow that breaks in production pushes users toward duplicate accounts and weak passwords, so getting this right wasn't optional.

Why I built it this way

Stack