Robust SaaS Platform Development

I am looking for a senior full-stack engineer or a very small team to architect and build a multi-tenant SaaS platform designed for organizations that operate across unreliable networks and multiple devices. This is not a standard CRUD web application. The system must support simultaneous changes from web clients, mobile clients, and backend services, including periods where some clients are completely offline. The core challenge is designing a reliable synchronization architecture that prevents silent data corruption when conflicting changes are made independently. Core Requirements The platform must include: -Multi-tenant architecture with strict tenant isolation -Role-based and resource-level permissions -Web application -Mobile-responsive interface -REST or GraphQL API -PostgreSQL database -Background job processing -Redis or equivalent caching/queue infrastructure -Real-time event delivery -Offline-first client behavior -Incremental synchronization -Conflict detection and resolution -Idempotent API operations -Distributed audit logging -File/document attachments -Versioned records -Soft deletion and restoration -Full-text search -Rate limiting -Authentication with refresh-token rotation -Session/device management -Administrative dashboard -Automated database backups The Difficult Part: Synchronization Engine A client may perform operations while completely offline. For example: Device A 08:14:02 — changes customer status → ACTIVE 08:16:44 — changes assigned representative → USER_17 08:18:11 — adds note At the same time: Device B 08:15:31 — changes customer status → SUSPENDED 08:17:03 — deletes the customer Both devices may remain offline for several hours. When they reconnect, the system must determine: 1. Which operations occurred? 2. Whether operations are causally related 3. Whether they conflict 4. Which changes can be automatically merged 5. Which conflicts require user intervention 6. How the final state should be calculated 7. How the complete history can be reconstructed A simple updated_at comparison is not acceptable. The implementation should use an appropriate combination of: -Operation IDs -Client-generated IDs -Server sequence numbers -Record versions -Idempotency keys -Causal metadata -Tombstones -Synchronization cursors -Deterministic conflict-resolution rules The exact architecture should be proposed by the developer and justified technically. Auditability Every meaningful state transition must be reconstructable. Given a record's current state, an administrator should be able to determine: Who changed it When they changed it Which device made the change What the previous state was What the new state was Which operation caused the change Whether the operation originated offline Whether the operation was subsequently merged or rejected Audit records must be append-oriented and protected against ordinary application-level modification. Expected Deliverables The successful developer will be responsible for: 1. Technical architecture document 2. Database schema 3. API specification 4. Authentication/authorization system 5. Synchronization protocol 6. Conflict-resolution mechanism 7. Web application 8. Responsive UI 9. Automated tests 10. Integration tests 11. Load/concurrency tests 12. Docker-based development environment 13. CI/CD configuration 14. Production deployment documentation 15. Database migration strategy 16. Monitoring/error-logging strategy 17. Security documentation 18. Developer documentation Mandatory Technical Exercise Before awarding the project, shortlisted candidates may be asked to implement a small prototype demonstrating: > Two independent clients modify the same dataset while disconnected, reconnect at different times, submit operations in different orders, and eventually converge on the same deterministic state without losing valid operations. The prototype should also demonstrate duplicate request handling and recovery after partial synchronization failure. Security Requirements The application will handle potentially sensitive organizational information. The implementation must therefore consider: OWASP application-security principles SQL injection XSS CSRF where applicable Broken access control Tenant-isolation failures Token theft Replay attacks Rate limiting Secure file uploads Secrets management Secure logging Database access controls Security cannot be treated as a final-stage checklist. What I Am NOT Looking For Please do not apply if your experience is primarily: WordPress Elementor Basic landing pages Simple CRUD dashboards Template customization Basic Firebase applications Copy/paste SaaS projects Generic “full-stack development” AI-generated boilerplate without architectural understanding I am specifically looking for someone who can explain why their architecture will remain consistent under concurrency, offline operation, retries, duplicated requests, and partial failures. Proposal Requirements Generic proposals will be ignored. Your proposal must include: 1. Architecture Describe the synchronization architecture you would use and why. 2. Conflict Resolution Explain how you would handle the example where two offline clients modify and delete the same record. 3. Idempotency Explain how your system behaves when the same synchronization request is accidentally submitted five times. 4. Failure Recovery Explain what happens if the connection drops halfway through synchronization. 5. Experience Provide 2 relevant projects involving at least one of: Offline synchronization Distributed systems Event-driven architecture Multi-tenant SaaS Conflict resolution Real-time collaborative systems For each project, explain specifically what you personally implemented. 6. Technical Stack Recommend your preferred stack and briefly justify each major technology choice. Important I am looking for someone capable of taking responsibility for the architecture rather than simply implementing tickets. Please do not send a generic proposal such as: > “Hello sir, I have read your requirements and I can do this project perfectly. Please message me.” Those proposals will be rejected without further consideration.

Project ID: 40734073