CIPAA Payment-Claim & Adjudication Deadline Tracker

What we're selling

A web tool that turns Malaysia's CIPAA 2012 payment-dispute process into a guided countdown. A contractor or subcontractor owed money enters the date they served their Payment Claim; the tool computes every statutory deadline from there — when the other side must respond, when to register at AIAC, when to file the Adjudication Claim, when the adjudicator must decide — and generates the matching government form at each step, with a reminder before each clock runs out.

Who should buy it

• Primary buyer: an SME subcontractor or main contractor's finance lead, chasing an unpaid progress claim right now.
• Channel buyer (who brings us customers): construction lawyers and quantity-surveying (QS) firms who already advise clients on CIPAA — they refer the tool to clients so nobody misses a deadline before the file even reaches them.

Problems it solves

CIPAA gives any contractor a fast, cheap legal right to force a late payer to pay — faster and cheaper than court. But the right is entirely procedural: miss one of six hard deadlines and the right lapses, no matter how valid the underlying claim is. Most SMEs don't track this correctly on their own, and by the time they call a lawyer, a deadline has often already passed.

How the product works

1. Customer enters the claim: who owes them, how much, and the date they served the Payment Claim.
2. The tool instantly shows every deadline from here to a possible adjudication decision — not just the next one.
3. Each deadline shows as on-track, due soon, overdue, or lapsed, with a downloadable, pre-filled government form for that stage.
4. An email (and a tap-to-send WhatsApp message) reminds the customer before each deadline.
5. The customer marks each stage done as they go; the tool never silently skips a stage for them.

Main selling points

• Nobody else builds this. Generic task trackers don't know CIPAA's exact stage sequence; this one is pre-loaded with it.
• The forms are already correct. We reproduce AIAC's own published forms — the same ones a lawyer would use — not an invented template.
• Priced for a real but occasional problem. RM149/month unlimited claims, or RM399 per active case for a customer who only has one dispute right now.

What's included in the first release

• Create and track a claim through every CIPAA stage, with deadlines computed automatically.
• Pre-filled downloads for the most-used forms: Payment Claim, Payment Response, Notice of Adjudication.
• Email reminders before each deadline, plus a one-tap WhatsApp message the customer sends themselves.
• Self-serve signup and monthly billing.

What is not included (yet)

• No automatic WhatsApp sending — the customer taps send themselves at launch, to avoid WhatsApp's paid API before we have paying customers to justify it.
• No multi-client view for referral partners — a lawyer or QS firm can refer customers, but can't yet see all their clients' cases in one screen. That's the first thing we build once the first five customers are paying.
• No direct e-filing with AIAC — the customer still submits the generated form themselves.

Customer onboarding

Sign up with an email link (no password to remember). First thing the customer sees is a prompt to enter their first claim. Enter the date the Payment Claim was served, who owes the money, and the amount — the tool immediately shows the full deadline timeline before they've paid anything, so they can see the value before committing.

Expected delivery timeline

Four weeks to a sellable product, assuming the technical founder works on this full-time and the CHIP payment merchant account is approved within that window (approval lead time is outside our control and unverified — flag this to any pilot customer conversation as a possible launch-date risk). See Document B's roadmap for the week-by-week breakdown.

Important limitations

• This is not legal advice. The tool computes dates from the law as published; it does not replace a lawyer's judgment on a specific case, and ships with a visible disclaimer saying so.
• The deadline calendar depends on Malaysia's public holidays being entered correctly — wrong holiday data means a wrong deadline. This is the single highest-stakes bug class in the product.
• We are not reviewing the legal templates with a lawyer before launch — a deliberate choice to keep startup cost at zero, since the forms are AIAC's own public documents. Revisit before scaling past the first 10–20 paying customers.

Product Requirements Summary

Minimum sellable product (MSP)

A single-user claim tracker: create a claim, get the full deadline sequence computed up front, see a countdown dashboard, download a pre-filled form for the current stage, get an email reminder, mark stages complete manually. No WhatsApp automation, no multi-client view, no in-app payment collection beyond a single subscription checkout. Enough to run the first five pilot customers and learn whether the computed dates match what their own lawyers tell them.

Feature prioritization

Deliberately excluded from P0: anything that isn't needed to prove a referred contractor will pay RM149–399 for a correct, tracked deadline. Multi-client and WhatsApp automation are real features a lawyer partner will ask for early — they're P1 because neither blocks the first sale.

Key business rules

• All deadlines are computed in working days — excluding weekends and Malaysia public holidays — per CIPAA Sections 6, 9, 11, and 12.
• A claim's full stage sequence is computed up front from the claim-served date, not stage-by-stage, so the customer sees the whole picture immediately.
• A missed deadline is recorded as lapsed, never hidden or silently skipped — the product's value is honest status, not forced progress.
• Billing plan is chosen once at signup (unlimited-subscription or pay-per-case) and is not mixed within one account for the MSP.

Flowcharts

graph TD
  A[Contractor has an unpaid progress claim] --> B{How did they hear about it?}
  B -->|Referred by lawyer or QS firm| C[Visit signup page]
  B -->|Found via contractor association| C
  C --> D[Sign up with magic link]
  D --> E[Create first claim]
  E --> F[Dashboard shows full CIPAA deadline timeline]
  F --> G[Act stage by stage, reminded before each deadline]
  G --> H{Outcome}
  H -->|Payer settles before adjudication| I[Claim marked resolved - paid]
  H -->|Goes to adjudication, decision delivered| J[Claim marked resolved - adjudicated]
  H -->|A deadline is missed| K[Stage marked lapsed - shown as advice to consult a lawyer]
  I --> L{Active claims remain?}
  J --> L
  K --> L
  L -->|Yes| F
  L -->|No| M[Renew monthly or cancel]

graph TD
  A[Land on signup page] --> B[Enter email]
  B --> C[Receive magic link by email]
  C --> D[Click link, session created]
  D --> E{First login?}
  E -->|Yes| F[Prompt: add your first claim]
  E -->|No| G[Go to dashboard]
  F --> H[Enter counterparty, amount, claim-served date]
  H --> I[System computes every stage deadline]
  I --> J[Show full deadline timeline before saving]
  J --> K[Confirm - claim saved, reminders scheduled]
  K --> G

graph TD
  A[Claim-served date entered] --> B[Compute Payment Response deadline: +10 working days]
  B --> C{Response received in time?}
  C -->|Admits and pays| D[Stage complete - claim resolved]
  C -->|Disputes| E[User elects to refer to adjudication]
  C -->|No response by deadline| F[Deemed disputed by law]
  E --> G[Serve Notice of Adjudication]
  F --> G
  G --> H[Compute AIAC registration deadline: +7 days]
  H --> I[Register claim at AIAC]
  I --> J[Adjudicator accepts appointment]
  J --> K[Compute Adjudication Claim deadline: +10 days from acceptance]
  K --> L[Serve Adjudication Claim]
  L --> M[Compute Adjudication Reply deadline: +5 days after Response]
  M --> N[Compute decision deadline: +45 working days]
  N --> O{Decision delivered on time?}
  O -->|Yes| P[Binding decision - pending final resolution]
  O -->|No| Q[Decision void by law - adjudicator forfeits fees]
  B -.missed.-> X[Stage marked lapsed]
  H -.missed.-> X
  K -.missed.-> X
  M -.missed.-> X

graph TD
  subgraph Claimant
    A1[View own claims]
    A2[Create and edit own claims]
    A3[Download own forms]
  end
  subgraph "Referral Partner (P1)"
    B1[View referred clients' claims - read only]
    B2[Generate a referral link for a new client]
  end
  subgraph Admin
    C1[View all claims]
    C2[Process billing and refunds]
    C3[Inspect deadline-calculation audit log]
  end

graph TD
  A[User selects a plan: Starter RM149/mo or Per-case RM399] --> B[Redirect to CHIP checkout]
  B --> C{Payment successful?}
  C -->|Yes| D[CHIP webhook confirms payment]
  D --> E[Account activated / case unlocked]
  E --> F[Monthly auto-renewal via CHIP]
  F --> G{Renewal successful?}
  G -->|Yes| F
  G -->|No| H[7-day grace period]
  H --> I{Paid within grace period?}
  I -->|Yes| F
  I -->|No| J[Account downgraded to read-only]
  C -->|No or abandoned| K[Return to pricing page]

graph TD
  A[Support request or dispute flagged] --> B[Admin opens case in admin console]
  B --> C[Review claim timeline and deadline audit log]
  C --> D{Issue type}
  D -->|Billing dispute| E[Process refund via CHIP dashboard]
  D -->|Deadline looks wrong| F[Re-run engine against the claim's stored inputs]
  D -->|Bug report| G[Log issue, patch, notify affected users]
  E --> H[Resolve and close]
  F --> H
  G --> H

Technical Architecture

Modular monolith, managed infrastructure throughout, chosen to fit a solo developer at near-zero cost: every piece below runs on a free tier at pilot scale, with a named upgrade trigger for when that stops being true.

graph LR
  Browser[Browser / mobile web] -->|HTTPS| Worker[Cloudflare Worker - Hono app + API + Cron]
  Worker -->|SQL queries| D1[(Cloudflare D1)]
  Worker -->|send reminder| Resend[Resend - email API]
  Worker -->|create checkout session| CHIP[CHIP - payment gateway]
  CHIP -->|webhook: payment confirmed| Worker
  Worker -->|renders| Forms[Bundled AIAC form templates]
  Cron[Workers Cron Trigger - daily] --> Worker

Data Model

erDiagram
  USERS ||--o{ CLAIMS : owns
  USERS ||--o| SUBSCRIPTIONS : has
  CLAIMS ||--|{ CLAIM_STAGES : contains
  CLAIM_STAGES ||--o{ REMINDERS : triggers
  REFERRAL_PARTNERS ||--o{ REFERRAL_LINKS : refers
  USERS ||--o| REFERRAL_LINKS : "referred via (P1)"

  USERS {
    int id PK
    string email UK
    string name
    string phone
    string auth_provider
    datetime created_at
  }
  SUBSCRIPTIONS {
    int id PK
    int user_id FK
    string plan
    string status
    string chip_customer_id
    date current_period_end
  }
  CLAIMS {
    int id PK
    int user_id FK
    string counterparty_name
    string contract_name
    date claim_served_date
    decimal claim_amount
    string status
    datetime created_at
  }
  CLAIM_STAGES {
    int id PK
    int claim_id FK
    string stage_key
    date deadline_date
    datetime completed_at
    string status
    datetime form_generated_at
  }
  REMINDERS {
    int id PK
    int claim_stage_id FK
    string channel
    datetime scheduled_for
    datetime sent_at
  }
  REFERRAL_PARTNERS {
    int id PK
    string name
    string firm_name
    string referral_code UK
  }
  REFERRAL_LINKS {
    int id PK
    int referral_partner_id FK
    int user_id FK
    datetime created_at
  }

Constraints worth stating explicitly

• claims.user_id — NOT NULL, FK → users.id, ON DELETE CASCADE
• claim_stages.claim_id — NOT NULL, FK → claims.id, ON DELETE CASCADE
• UNIQUE(claim_stages.claim_id, claim_stages.stage_key) — a claim has exactly one row per CIPAA stage
• subscriptions.user_id — UNIQUE — one active subscription per account in the MSP; no plan-mixing
• stage_key ENUM: payment_response · notice_of_adjudication · aiac_registration · adjudicator_appointment · adjudication_claim · adjudication_reply · adjudication_decision
• claim_stages.status ENUM: upcoming · due_soon · overdue · lapsed · completed

No multi-tenancy layer: each user owns their own claims directly. The referral-partner tables are an attribution join, not a tenant boundary — a partner never writes to a client's claim, only reads it.

API endpoints

Every /api/claims/* route checks claims.user_id = session.user_id before returning or mutating anything — the only authorization rule the MSP needs.

UI/UX Plan

Sitemap

Navigation

Flat, not hierarchical: Dashboard, Billing, and Settings are the only top-level destinations. Claim detail is reached only from the dashboard list, never bookmarked as a separate navigation item — there's no need for deeper nesting at this scope.

Key screens

• Dashboard: one row per claim, status shown as a colored chip (on-track / due soon / overdue / lapsed), soonest deadline sorted to the top.
• Claim detail: a vertical timeline of the six stages, each with its computed date, a countdown, a "download form" button once its stage is current, and a "mark complete" action.
• New claim: the deadline preview renders live as the claim-served date is typed, before the user commits — this is the moment that proves the product's value.

Empty and error states

• No claims yet: dashboard shows "No claims yet — add your first payment claim" with the new-claim button front and center.
• All stages lapsed on a claim: a visible banner — "This claim's CIPAA rights may have lapsed. Consult a lawyer about other remedies." — never hidden or softened.
• Payment failed: a persistent banner showing days remaining in the grace period.
• Form generation failure: explicit error with a retry action and a support contact, never a silent blank download.

Responsive requirements

Mobile-first: a contractor checking a deadline is more likely to be on a phone on a job site than at a desk. The dashboard list collapses to stacked cards under 640px; the claim-detail timeline becomes a single column; "mark complete" and "download form" are large tap targets, not small inline links.

Visual direction

Clean legal-utility minimal: generous whitespace, one accent color reserved for primary actions, status communicated through both color and a text label (never color alone), dates and countdowns set in a monospace face so they align and read as data, not prose.

Development Roadmap

Dependency to flag: Week 3's form auto-fill needs accurate AIAC form templates sourced in parallel during weeks 1–2 — a research task, not an engineering one, so either founder can own it without blocking the build. Week 4's billing go-live depends on CHIP merchant account approval, whose lead time is unverified — don't promise a launch date to a pilot customer until that approval is confirmed.

This assumes one developer working full-time with AI-assisted development; a part-time pace would roughly double every phase above.

Parallel Founder Execution

Commercial assumptions to validate before building further than the MSP