Robust SaaS Platform Development
Budget / Salary$5,000–15,000
TypeFreelance project
LocationRemote
Posted1 hour ago
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.
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.
Apply on Freelancer →
Project sourced from Freelancer.com. Applications happen directly on the original platform — we never collect your data.