0%
A pre-submission service for students checking their own academic writing. It offers one service, the automatic report (the free scan was removed on 2026-10-25, and every account now gets one free full report a day instead, see freeReport in config/app.ts; Writing Refinement was removed on 2026-10-26, its paid orders refunded as credits and its open orders cancelled by migration 0022):
| Service | What it is | Where the result comes from |
|---|
| AI-Writing Risk Report (automatic, 1 credit per 1,000 characters, minimum 2 credits, first 8,000 of every 20,000 characters charged and the rest free, 500–100,000 characters) | Our own reviewer (DeepSeek) reads the whole pasted text in pieces and the answers are stitched into one report | Overall level, paragraph map, marked sentences, grammar spots and a PDF. Not a Turnitin result and no Turnitin-like percentage |
The UI keeps these apart everywhere: the report is labelled as our own reviewer's guidance. Older hand-made Turnitin reports still display as the observed result of that run.
Turnitin is a third-party service. This platform is independently operated and is not affiliated with, endorsed by, or operated by Turnitin. The app contains no Turnitin branding, UI, credentials, scraping or automation.
The brand name is "0%". Rename it in config/app.ts (brand); nothing else hard-codes it.
Before launch: two things to confirm
- Licence (only for the older hand-made reports; the automatic report does not use Turnitin). Turnitin educator/institutional licences usually limit use to the licensee's own courses and students. Screening documents for paying outside customers through that account may breach the licence and the institution's agreement, regardless of disclaimers on this site. Get written permission from Turnitin or the institution first. The provider sits behind the
ScreeningProvider interface, so a properly licensed source can be swapped in without touching the frontend.
- Repository storage. If a paper is submitted to an assignment that stores papers in the standard repository, the customer's real submission later matches itself at close to 100%. The admin workflow blocks moving an order to Screening until the "no repository" checkbox is confirmed, and the FAQ explains this to customers.
Architecture
USER ─► NEXT.JS (App Router)
└─ Paid orders ─ Stripe Checkout ─► webhook ─► queue
└─ Admin workflow (human) ─► TURNITIN (outside the app)
└─► screening_results + private report ─► user dashboard
Supabase: Auth · Postgres (RLS) · private Storage
- Next.js 16 (App Router, Turbopack,
proxy.ts instead of middleware), TypeScript strict, Tailwind v4, Framer Motion, react-three-fiber (hero only, lazy-loaded, desktop only, respects reduced motion).
- Supabase for auth, Postgres and storage. The browser only ever reads its own rows through RLS. All writes to orders, files, results and payments happen in server actions with the service role, after the server checks identity, role and recomputes prices.
- Stripe Checkout, confirmed only by a signature-verified webhook that also checks the amount against the stored order price.
Key modules
| Path | Purpose |
|---|
config/pricing.ts | All prices (HKD cents). Nothing else hard-codes a price. |
config/app.ts | Brand, daily limit, upload limits, retention periods. |
config/services.ts, config/faq.ts | Service copy, disclaimers, FAQ. |
lib/orders/status.ts | The order state machine: labels, flows, allowed transitions. |
lib/network.ts | Salted hash of the visitor's network address, for the daily free report's per-address cap. |
lib/screening/ | ScreeningProvider interface and ManualTurnitinProvider (human-in-the-loop). |
lib/payments/ | Stripe client and markOrderPaid (idempotent, amount-checked), used by the webhook and by admin claim confirmation. |
config/payments.ts | Alipay / PayMe / bank transfer payee details, QR paths and instructions. |
app/actions/ | Server actions: orders, admin, account. |
app/api/files/[kind]/[orderId] | Access-checked 60-second signed URLs for source files and reports. |
app/api/stripe/webhook | Marks card orders paid (signature- and amount-checked). Manual payments are confirmed by an admin; see Payments. |
app/api/cron/retention | Scheduled deletion of old documents and reports. |
supabase/migrations/0001_init.sql | Tables, constraints, indexes, RLS, storage buckets and policies. |
lib/local-model/, app/api/model-worker/, tools/local-model-worker/ | Optional local writing model: job queue, worker API and the worker program. See Local writing model. |
Order statuses
Report (automatic): awaiting_payment → paid → screening → completed (or cancelled with credits returned if it fails). The order page calls /api/reports/[id]/advance while open; lib/auto-report/ cuts, reviews and stitches. Older hand-made reports used queued → screening → report_ready → completed.
Refinement: awaiting_payment → paid → queued → under_review → processing → completed (or cancelled)
paid is set only by the verified Stripe webhook or by an admin confirming a manual payment claim. Customers see results only when an order is completed (enforced by RLS, not just the UI).
Local setup
npm install
cp .env.example .env.local # fill in values
npm run dev
Without Supabase variables the marketing site runs and the app pages show a "not configured" notice.
Environment variables
See .env.example. SUPABASE_SERVICE_ROLE_KEY, STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET and CRON_SECRET are server-only and must never be prefixed with NEXT_PUBLIC_ or committed. There is intentionally no Turnitin variable.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
