Developing a Mobile App for Tender Platform
Tender platform on mobile solves specific task: buyer publishes lot, suppliers submit bids, best wins. Practice adds digital signature for documents, NDA before terms access, sealed-bid auction (no one sees competitor bids until close), and real-time notifications. Not form forum.
Two Users — Fundamentally Different UX
Buyer (organizer): creates tender, attaches specification and documents, sets deadlines, verifies participants, opens envelopes, selects winner, generates protocol.
Supplier (participant): sees open tender catalog, submits bid, attaches qualification documents, signs bid digitally, tracks status, receives result.
Role separation — not just UI, it's API-level access rights. Supplier shouldn't see other participants' bids until opening. Sealed bid requires encryption at app or server level — bids encrypted until opening moment.
Digital Signature
This key difference from regular "submit form." For government and corporate tenders need qualified digital signature (QDS) or at minimum reinforced unqualified (UQS).
On mobile options:
- QDS via external token (JaCarta, Rutoken) — NFC or USB-C. SDKs from vendors. Inconvenient but legally strongest.
- Cloud QDS (Kontoor.Signature, Thales DPoD) — key on provider server, signature via API with SMS auth. SDK integrated as WebView or native module.
- UQS via app — key in Keychain/KeyStore, PKCS#7 signature. Legal force depends on party agreement.
For most b2b tender platforms cloud QDS — optimal balance of convenience and legal weight.
Tender Search and Filtering
Tender catalog — not just list. Supplier needs filters: industry, region, NMCK (initial max price), deadline, status (accepting / evaluation / complete). Full-text search.
On mobile — Elasticsearch or Typesense on backend, iOS: UISearchController with debounce 300ms, Android: SearchView + Flow + distinctUntilChanged. Offline mode for loaded tenders (Core Data / Room) — critical if suppliers work with unstable internet.
Document Handling
Tender documentation — PDF/DOCX up to 100 MB. Upload via multipart/form-data with progress. View: PDFKit (iOS), PdfRenderer (Android), or WebView with PDF.js. Preview without download. For NDA-protected docs — disable screenshots (FLAG_SECURE / iOS trick) and watermark with username.
Signing document package: list → user reviews each → signs package once (PKCS#7 enveloped signature with attachment).
Real-Time and Notifications
Tender status update — WebSocket or Server-Sent Events. Critical events: "Your bid accepted," "Tender closed, results in 30 min," "You won / didn't pass." FCM (Android) / APNs (iOS) for offline push.
For sealed-bid: opening timer with countdown — user sees when bids revealed. Opening moment — WebSocket event with new data.
Process
| Stage | Timeline |
|---|---|
| Requirements audit, jurisdiction, signature strategy | 1 week |
| Design: roles, API, document flow | 1 week |
| Development: catalog + bids + documents | 4–6 weeks |
| Signature integration | 1–2 weeks |
| QA, testing | 1–2 weeks |
Timeline — 2–3 months depending on QDS integration complexity and document volume. Custom pricing after requirements analysis.