Subcontractor & Vendor Pre-Qualification Scorecard

A web tool that lets a main contractor or GLC procurement team vet subcontractors before awarding work — replacing the paper form or one-off spreadsheet that currently gets filled in per tender and then thrown away. The buyer sets up their own scoring criteria once (financial standing, past performance, safety record, whatever matters to them); subcontractors fill in a self-service form; a reviewer scores and approves or rejects; and every past result is kept, so the next tender starts from a record instead of a blank page.

Buyer

Procurement manager at a main contractor or GLC (government-linked company) who runs vendor/subcontractor vetting before awarding tenders

Company size

Vets roughly 20–100 subcontractors a year — too much volume for an ad-hoc spreadsheet, too small to justify an enterprise vendor-management platform

Who else touches it

The subcontractors themselves, who fill in the self-submission form — they are a user, not a paying customer

Right now this is done on paper or in a spreadsheet copied fresh for every tender. There's no running history: a subcontractor who failed on safety last year can slip through again because nobody remembers, or because the person who remembers has left. Enterprise vendor-management software exists, but it's priced and built for large corporates running thousands of vendors — nothing is sized for a contractor doing this 20–100 times a year.

1. The procurement team builds their scorecard once — the questions and weightings they care about (e.g. financial statements, safety certifications, past project references).
2. When a tender opens, they invite subcontractors by email/link to fill in the self-submission form.
3. A reviewer on the procurement side scores each submission against the scorecard and marks it approved, rejected, or needs more info.
4. Every decision is saved against that subcontractor's profile, so the next tender shows their history at a glance instead of starting from zero.

• Built for this scale. Not a stripped-down enterprise tool — sized and priced for a contractor running dozens, not thousands, of vendors a year.
• A record that survives staff turnover. The scorecard and history live in the system, not in one person's inbox or memory.
• The subcontractor does the data entry. Nobody on the buyer's side re-types anything from a paper form.

• No automatic verification of what a subcontractor submits — a claimed safety certificate isn't checked against the issuing body, only recorded and scored by the human reviewer
• No payment or contract-management features — this stops at the approve/reject decision, it doesn't manage the resulting contract
• No multi-reviewer consensus workflow at launch — one reviewer makes the call, which may not fit a buyer who requires joint sign-off

1. Procurement team walks through scorecard setup with us (hands-on for the first few customers, since a wrong first template is a bad first impression)
2. They send their first tender's subcontractor list — a CSV import, not manual one-by-one entry
3. Subcontractors receive an email/link and fill in the form themselves — no account needed to submit, only to review
4. First live tender cycle runs end to end with us watching, to fix anything that breaks before it's a pattern

6–7 weeks from kickoff to a pilot customer running one real tender cycle through the tool — assuming the scorecard stays to the single fixed-template scope above. This is a build estimate for one developer working solo with AI-assisted tooling, not a contractual date; it hasn't been tested against a real customer's actual tender calendar, which may force the timeline around their own schedule rather than ours.

• This is a procurement-involved sale — expect an 8–12 week sales cycle, longer than a self-serve SaaS signup, because the buyer is evaluating a process change, not just buying software
• The product earns its value over multiple tender cycles (the history compounds) — a single-tender pilot proves the workflow works, it won't yet prove the long-term value of the historical record
• Pricing is annual (RM4,800/yr per procuring company), not monthly — cash lands in a lump at signing and renewal, not smoothed out month to month

Problem

Subcontractor vetting runs on paper/spreadsheets with no persistent history across tenders

Target customer

Main contractor / GLC procurement team, 20–100 subcontractors/yr

User roles

Procurement Admin (configures scorecard, manages tenders), Reviewer (scores submissions), Subcontractor (external, submits — no login required to submit, only to view status)

Core value

A scorecard the buyer owns, a submission the subcontractor self-serves, and a history that persists after the tender closes

MSP

One fixed scorecard template per buyer account, subcontractor self-submission by link, single-reviewer approve/reject/needs-info, subcontractor profile with past decisions visible

Key business rules

• A procuring company's data (scorecards, submissions, decisions) must never be visible to another procuring company — multi-tenant isolation is a hard requirement, not an enhancement
• A subcontractor is a single identity that can submit to multiple different procuring companies — their submissions and history must stay scoped per procuring company (Buyer A never sees how Buyer B scored the same subcontractor), even though the subcontractor record itself is shared
• A submission, once approved or rejected, is immutable — corrections happen via a new submission, not an edit, so the history stays honest

Feature priority (carried from Document A)

A modular monolith is the right call here — the feature set (accounts, scorecards, submissions, reviews) is small enough that splitting into services would only add deployment and debugging overhead for a solo developer, with no scaling need that justifies it yet.

Frontend

Next.js (App Router) — server-rendered pages for the subcontractor's no-login submission form (must work with zero JS assumptions for a one-time external visitor), client-side dashboard for the Procurement Admin/Reviewer side

Backend

Next.js API routes / server actions — no separate backend service needed at this scale

Database

Postgres via Neon or Supabase — relational fits this domain naturally (buyers, tenders, subcontractors, submissions, decisions)

ORM

Drizzle — matches this team's existing house stack

Auth

Email/password or magic-link for Procurement Admin and Reviewer accounts (Supabase Auth or Auth.js); subcontractors authenticate via a signed, expiring submission-link token — no account, no password

Authorization

Row-level scoping by company_id on every tenant-owned table, enforced in the query layer (Postgres RLS if using Supabase directly, or an explicit WHERE company_id = ? guard on every query if using Drizzle without RLS) — this is the single most important thing to get right given the no-cross-tenant-visibility rule

File storage

Object storage (Supabase Storage or S3-compatible) for subcontractor-uploaded supporting documents, referenced by URL from the submissions table — never stored as blobs in Postgres

Background jobs

Minimal at P0 — reminder emails (P1) and renewal-date checks can run on a daily cron (Vercel Cron or a scheduled Supabase Edge Function); no queue infrastructure needed yet

Hosting

Vercel for the app, managed Postgres (Neon/Supabase) for data — matches the team's stated stack and needs no dedicated ops time

Security

Signed, time-expiring tokens for subcontractor submission links (so a leaked link can't be reused indefinitely); uploaded documents scanned or at minimum type/size-restricted on upload; all tenant queries scoped by company_id as above

Monitoring/backups

Managed Postgres's built-in automated backups are sufficient at this scale; basic uptime/error monitoring (Vercel's built-in logs plus a lightweight error tracker) — no custom observability stack justified yet

flowchart TB
  subgraph Client
    PA[Procurement Admin /
Reviewer dashboard]
    SF[Subcontractor
submission form]
  end
  subgraph "Next.js app (Vercel)"
    API[API routes /
server actions]
    AUTH[Auth: email/password
+ signed link tokens]
  end
  DB[(Postgres
Neon / Supabase)]
  FS[(Object storage
for documents)]
  MAIL[Email provider
invites + reminders]

  PA --> API
  SF --> API
  API --> AUTH
  API --> DB
  API --> FS
  API --> MAIL
    

erDiagram
  COMPANY ||--o{ USER : employs
  COMPANY ||--o{ SCORECARD_TEMPLATE : owns
  COMPANY ||--o{ TENDER : runs
  TENDER ||--o{ SUBMISSION : receives
  SCORECARD_TEMPLATE ||--o{ SUBMISSION : "scored against"
  SUBCONTRACTOR ||--o{ SUBMISSION : submits
  SUBMISSION ||--o| DECISION : "resolved by"
  USER ||--o{ DECISION : makes

  COMPANY {
    uuid id PK
    string name
    string plan_status
  }
  USER {
    uuid id PK
    uuid company_id FK
    string role
    string email
  }
  SUBCONTRACTOR {
    uuid id PK
    string company_name
    string registration_no
  }
  SCORECARD_TEMPLATE {
    uuid id PK
    uuid company_id FK
    jsonb questions
  }
  TENDER {
    uuid id PK
    uuid company_id FK
    uuid template_id FK
    string name
    string status
  }
  SUBMISSION {
    uuid id PK
    uuid tender_id FK
    uuid subcontractor_id FK
    jsonb answers
    string status
    timestamp submitted_at
  }
  DECISION {
    uuid id PK
    uuid submission_id FK
    uuid reviewer_id FK
    string outcome
    string reason
    timestamp decided_at
  }
    

Key constraints

• SUBMISSION.status is one of pending / needs_info / approved / rejected; once approved or rejected, the row is immutable — a correction creates a new SUBMISSION row linked to the same tender and subcontractor
• SUBCONTRACTOR is deduplicated by registration_no (the company registration number) so the same real-world entity isn't scored under two different profiles across buyers
• Every query against SCORECARD_TEMPLATE, TENDER, SUBMISSION must filter by the requesting user's company_id — enforced at the query layer, not just the UI

API endpoints (P0)

Two distinct front ends: an internal dashboard (Procurement Admin + Reviewer) and an external, no-login submission form (Subcontractor). Design them as if they're two different products that happen to share a database.

Internal dashboard sitemap

• Tenders — list, create, view one tender's submissions and their statuses
• Scorecard templates — list, create/edit (P0: one template per company, so this is closer to a settings page than a builder)
• Subcontractors — searchable list with each one's cross-tender history
• Submission review — one submission's answers + uploaded documents + the approve/reject/needs-info action
• Account settings — users, billing status, renewal date

External submission form

• Single-page form, no account creation, accessed via the signed invite link
• Progress is saved as the subcontractor fills it in (a half-finished form on a bad connection shouldn't lose their work)
• Confirmation screen after submit, with a status-check link they can bookmark

Empty and error states

• No tenders yet → prompt to create the first one, not a blank table
• No scorecard template yet → block tender creation until one exists, with a clear "set up your scorecard first" prompt
• Expired or already-used invite link → plain message explaining the link expired, with a way to request a new one, not a generic 404
• Upload failure (file too large/wrong type) → tell the subcontractor exactly what's wrong and the accepted format, inline, before they lose their other answers

Responsive requirements

The internal dashboard is desktop-first — procurement staff review on a desk, not a phone. The subcontractor submission form must work well on mobile, since many subcontractor-side staff will open the invite link from WhatsApp on a phone.

This gets one pilot customer through one real tender, not a finished platform. Multi-reviewer workflows, reminder emails, and CSV export (P1) come after that pilot proves the core loop, not before.