┌──────────────────┐
│ SERVICE SEEKER │
└────────┬─────────┘
│
▼
CREATE TASK
│
▼
BIDDING
│
┌──────────────┼──────────────┐
▼ ▼ ▼
BID A BID B BID C
│ │ │
└──────────────┼──────────────┘
▼
NEGOTIATION
│
▼
ACCEPT BID
│
▼
PAYMENT
│
▼
┌───────────┐
│ ESCROW │
└─────┬─────┘
│
▼
TASK ASSIGNED
│
▼
TUKTAKER
│
"I HAVE ARRIVED"
│
▼
TASK COMPLETED
│
▼
SERVICE SEEKER ACCEPTS
│
▼
RELEASE ESCROW
│
┌───────────┴───────────┐
▼ ▼
COMMISSION TUKTAKER
│ WALLET
│ │
▼ ▼
VAT REDEEM
│
▼
BKASH/NAGAD/QR
┌───────────────────────┐
│ RATING │
│ Service Seeker ↔ │
│ TukTaker │
└───────────────────────┘
CUSTOMER │ │ 1. Purchase Service │ ▼ SSLCOMMERZ │ │ 2. Payment Collection │ ▼ MARKETPLACE │ │ 3. Order/Service Processing │ ▼ FREELANCER │ │ 4. Service Completed │ ▼ AVAILABLE EARNING │ │ 5. Freelancer Requests Withdrawal │ ▼ PAYOUT / DISBURSEMENT PROVIDER │ │ 6. Send Money │ ▼ FREELANCER'S bKash / Nagad / Bank Account
Recommended answers are proposals for the founders to confirm, except items marked Decided. Legal and VAT items need an expert's sign-off. The blank “Founder decision” column is for the decision meeting (print this page).
| ID | Section | Topic & issue | Recommended answer | Status | Founder decision |
|---|---|---|---|---|---|
| D01 | §1 | Seeker NID rule can't be checked ContradictionThe Seeker must use a mobile number registered under their NID, but Seekers never provide an NID. | Drop the check for MVP. OTP plus a checkbox: “I confirm this number is registered in my name.” NID checks for Seekers can come later. | Proposed — awaiting decision | |
| D02 | §1, §2 | One mobile number for both roles? ContradictionThe database allows one user with several profiles; the requirements describe two separate sign-ups. | Decision: one unique mobile number per account, and one role per account (Seeker or TukTaker), to avoid complexity. Database: iam.users.mobile unique + iam.users.account_role. | Decided | |
| D03 | §1, §13 | Password policy: “standard” vs “strong” ContradictionSection 1 says standard passwords; Section 13 says strong passwords. | One rule everywhere: at least 8 characters with upper case, lower case, a number and a special character. | Proposed — awaiting decision | |
| D04 | §1, §2 | OTP expiry and retry limits Gap / TBCNot defined (TBC). | 6 digits, expires in 3 minutes, 3 attempts, resend after 60 seconds, at most 5 per hour. | Proposed — awaiting decision | |
| D05 | §1 | Business account fields Gap / TBCExtra Business fields are TBC, but the schema already has business profiles (trade licence, BIN, TIN). | Company name, trade licence number, BIN (optional), contact person, invoice email. Manual, optional verification, needed only for invoices. | Proposed — awaiting decision | |
| D06 | §1 | Seeker DOB and gender stored but not required Contradiction seeker_profiles stores DOB and gender; the requirements never ask for them (age check for Seekers is also TBC). | Remove them, or make them optional. Collecting less personal data is safer. | Proposed — awaiting decision | |
| D07 | §2 | Rejected TukTaker flow Gap / TBCRejection, re-submission, review time and which edits need re-verification are TBC. | Reject with a reason from a list (kyc_rejection_reasons); allow 3 resubmissions; review target 24–48 h. Re-verify after changes to name, DOB, NID, selfie or mobile; address and work-location changes don't need it. | Proposed — awaiting decision | |
| D08 | §2 | Work location: one vs many ContradictionThe requirements give a TukTaker one work location; the schema stores many service upazilas plus a radius. | The schema's version wins (several upazilas + radius). Update this section to match. | Proposed — awaiting decision | |
| D09 | §4 | Pet question has no “No pets” option ContradictionThe pet question is mandatory but only offers Cat or Dog. | “Any pets at the location?” — No / Cat / Dog / Other. | Proposed — awaiting decision | |
| D10 | §4 | “All steps mandatory” vs “photo where applicable” ContradictionThe photo step can't be both mandatory and optional. | Photo is optional, except where a category requires it (e.g. measurements for Small Construction). | Proposed — awaiting decision | |
| D11 | §4, §6 | Payment method chosen at posting ContradictionThe method is picked when posting, but payment happens after a bid is accepted. Bangla QR is missing from the posting options but listed in Section 6. | Choose the method at the payment step: bKash, Nagad or Bangla QR, all through SSLCommerz. | Proposed — awaiting decision | |
| D12 | §4, §8 | When does bidding close? Gap / TBCCancellation fees, auto-reopen and task statuses depend on it, but it isn't defined. | Decided: tasks.bidding_closes_at is added. Proposed: Seeker picks 2, 6, 24 (default) or 48 h, ending at least 2 h before the job; bidding also closes when a bid is accepted; no bids → task expired. | Partly decided | |
| D13 | §4, §5 | Budget, counter-offers, editing bids and tasks Gap / TBCThe budget's role, counter-offer limits, bid edit/withdraw and task editing are TBC. | Budget is a guide shown to bidders. At most 3 counter-offer rounds, each offer expires after 12 h. Bids can be edited or withdrawn until one is accepted. Task editable until the first bid. | Proposed — awaiting decision | |
| D14 | §4, §6 | Escrow auto-release Gap / TBCIf the Seeker never accepts completion, the TukTaker is never paid. | Seeker has 48 h after “job done” to accept or dispute; reminders at 24 h and 44 h; then automatic release. A dispute freezes the escrow. | Proposed — awaiting decision | |
| D15 | §4, §6 | Payment timeout after a bid is accepted Gap / TBCIf payment fails, the assignment would stay pending forever. | Decision: 15-minute payment timeout (assignments.payment_due_at). If it lapses, the bid is released and the task reopens. | Decided | |
| D16 | §4, §5, §6 | Task, bid, assignment, escrow and payout statuses Gap / TBCThe status lists in the schema didn't cover the flow (draft, withdrawn, arrived, refunded, failed…). | Decision: adopted the expanded lists — see the database dictionary Status reference. | Decided | |
| D17 | §5, §8 | “I have arrived” can be abused Gap / TBCArrival decides the call-out fee, but nothing verifies it. | TukTaker GPS must be within 200 m of the address; if GPS fails, the Seeker reads out a 4-digit code shown in their app. | Proposed — awaiting decision | |
| D18 | §5 | “Confirm payment received” step ContradictionMoney goes to the wallet, not into the TukTaker's hand, so there is nothing to confirm. | Replace with an automatic “Earnings added to your wallet” notification. | Proposed — awaiting decision | |
| D19 | §5, §8 | No-show handling Gap / TBCNot defined (TBC). | If the TukTaker hasn't arrived 30 min after the scheduled time, the Seeker can cancel with a full refund and the TukTaker gets a penalty. | Proposed — awaiting decision | |
| D20 | §5, §13 | Chat and off-platform deals ContradictionThe retention policy mentions chat history, but no flow describes chat. Once parties talk, they can skip the platform. | Text chat inside the task opens once a bid is accepted; phone numbers stay masked; chat kept for 1 year. | Proposed — awaiting decision | |
| D21 | §5, §12 | “Set app to ready mode” Gap / TBCListed in the sheet with no description. | Not discussed yet — owner to describe what it means or drop it. | Open — not discussed | |
| D22 | §6 | Redemption cap period Gap / TBCThe 10,000 BDT cap has no period (per transaction, day or month?). | Min 500 BDT; max 10,000 BDT per transaction and 25,000 BDT per day; 5 BDT fee. | Proposed — awaiting decision | |
| D23 | Overview, §6 | Payout destinations ContradictionThe payout diagram shows a bank account; the sheet lists bKash, Nagad and Bangla QR. Bangla QR is a pay-in method, not a payout. | MVP payouts to bKash or Nagad only; remove QR from payouts; bank payouts in phase 2. | Proposed — awaiting decision | |
| D24 | §6, §14 | Legal check on holding money Gap / TBCEscrow and wallet balances may fall under Bangladesh Bank digital-commerce escrow / e-money rules. | Hold funds in a PSP/bank-held escrow or trust account, not the operating account. Wallet is withdraw-only (no top-ups, no spending). Needs written confirmation from SSLCommerz and a lawyer. | Needs expert sign-off | |
| D25 | §6, §9 | Gateway fees and “tip fees” ContradictionWho pays gateway fees is undefined; the schema's fee_schedules lists tip fees while the rules say no commission on tips. | The platform absorbs pay-in gateway fees, including on tips, so tips reach the TukTaker in full. | Proposed — awaiting decision | |
| D26 | §6 | Failed or double payments Gap / TBCTBC in the sheet. | Failed payment → 15-minute timeout (D15). Duplicate charges are caught by the existing idempotency keys and refunded automatically. | Proposed — awaiting decision | |
| D27 | §6, §13 | Stored balances duplicate the ledger Gap / TBC ledger_accounts.balance, total_spent and total_earned repeat what the ledger holds and can drift. | Update them in the same DB transaction as ledger entries (row locking) and run a nightly check against the ledger. | Proposed — awaiting decision | |
| D28 | §7 | Commission: 20/18/16 vs 17/15/13 ContradictionThe sheet gives two different commission schemes. | Flat 17% at launch; add tiers 17/15/13 after 3–6 months of data (tier thresholds set then). | Proposed — awaiting decision | |
| D29 | §7, §11 | Who bears VAT, and on what Gap / TBCWho pays the 15% VAT, and whether cancellation, invoice and refund fees are VAT-able, is TBC. | TukTaker bears 15% VAT on the commission (effective 19.55%), shown on their statement; VAT also on the platform's other fee income. Needs a VAT consultant to confirm. | Needs expert sign-off | |
| D30 | §8 | TukTaker 2-hour cancellation window and penalty Gap / TBCThe 2-hour window has no anchor; the penalty amount is TBC. | Free within 2 h of accepting, if the job starts at least 6 h later. Otherwise a penalty of 10% (100–300 BDT). | Proposed — awaiting decision | |
| D31 | §8 | Seeker cancellation fees vs payment timing Contradiction“10% after bidding closes” needs money in escrow, but the Seeker may not have paid yet. How the 10% and call-out fee combine is TBC. | Before accepting a bid: free. After accepting and paying, before arrival: 10%, split 50/50 platform/TukTaker. After arrival: 250 BDT call-out fee instead. Fees never stack. | Proposed — awaiting decision | |
| D32 | §8 | Unpaid penalties Gap / TBCA penalty comes out of the next payment — what if there is none? | Carry forward; the wallet never goes negative. Unpaid for 30+ days blocks new bids until paid or waived by admin. | Proposed — awaiting decision | |
| D33 | §9 | Who pays the 5% refund admin fee Gap / TBCTBC. | Whoever was at fault. If the TukTaker was at fault, the Seeker pays nothing. | Proposed — awaiting decision | |
| D34 | §9, §12 | Refund approvals, disputes, credit limits Gap / TBCRefund approval steps, how a dispute is raised, credit expiry and the max credit limit are TBC. | Proposed: disputes raised in-app during the 48 h acceptance window; refunds/credits above a limit need a second approver (Finance). Open: credit expiry and the max credit amount. | Partly decided | |
| D35 | §10 | “Mandatory” ratings can't be forced ContradictionRating is mandatory for both sides, but nothing enforces it; blocking adds friction. | Don't block; send reminders. 7-day window, blind until both rate or 7 days pass. Average below 3.5 after 10 tasks → admin review. | Proposed — awaiting decision | |
| D36 | §11 | Invoice period and TukTaker invoice content Gap / TBCMonthly or quarterly is TBC; the TukTaker invoice text is copied from the Seeker version. | Not decided yet. TukTaker invoice should show earnings, commission, VAT and net payout. | Open — not discussed | |
| D37 | §12 | Admin spec and roles ContradictionThe admin tab is empty, yet KYC, refunds, credits, disputes and payouts all need admin screens. Super/General roles don't map to these jobs. | Roles: Super Admin, Operations/Support, Finance. Screens: dashboard, KYC queue, users, tasks, disputes, refunds & credits, payout approval, settings, the 4 reports, audit log. | Proposed — awaiting decision | |
| D38 | §13 | Retention: profiles forever, NID images Gap / TBC“Profiles forever” is risky; NID image retention and encryption are undefined. | Profiles kept while active, then 5 years after closure (financial records per NBR). NID images encrypted, every view logged, deleted 1 year after closure. | Proposed — awaiting decision | |
| D39 | §13, §16 | Backups can't stay TBC Gap / TBCBackup is TBC for MVP. | Daily automatic DB backups kept 30 days, weekly copy in a second location, monthly restore test. External drive only as an extra copy. | Proposed — awaiting decision | |
| D40 | §2, §13 | NID hash can be reversed Gap / TBCNIDs are 10/13/17 digits, so a plain hash can be brute-forced. | HMAC with a server secret for duplicate checks, plus an AES-encrypted copy for staff review. | Proposed — awaiting decision | |
| D41 | §14 | Blank disclaimer rows Gap / TBC14 disclaimer rows in the sheet are empty. | Not discussed yet — content needed (ideally reviewed by the lawyer in D24). | Open — not discussed | |
| D42 | §15 | Hotline, hours, slogan, emergency engagement Gap / TBCAll TBC. | Not discussed yet. Support hours proposed in D44 (9am–9pm). | Open — not discussed | |
| D43 | §16 | MVP scope cut Gap / TBCThe schema has 134 tables, including much future scope. | Keep the design, but postpone marketing, certifications, report schedules, reconciliation automation, legal holds and backup KYC providers to later migrations. Nursing, Maid and Driver still need a compliance review. | Proposed — awaiting decision | |
| D44 | General | Non-functional requirements missing Gap / TBCPlatforms, languages, notifications, uptime and support hours aren't specified. | Android app + web for Seekers, web admin panel; iOS in phase 2. Bangla and English. Push by default, SMS only for OTP, verification and payments. 99.5% uptime. Support 9am–9pm. | Proposed — awaiting decision | |
| D45 | General, §15 | Safety features Gap / TBCOnly the 999 button is specified. | Add “share live task with a contact” and a “Report user” button (trust.user_reports exists). | Proposed — awaiting decision |