← Back to bot

Input:

Write 250–350 characters to bid for a dev job. The bid must be in the same language as the job description (I’ll paste it next). Show you understand the task + technology/language/cms/frameworks involved.

Start with a short specific question about something unclear (don’t ask “what’s the plan” / “how you envision it” or similar). Keep it super informal and funny, simple words, short sentences. Prefer technical questions.

No “Hi/Hello”, no hype about the project, no talk about my experience. Focus on the current task. Don’t ask about colors/branding. Don't write "let's make it" or "let's start" or "curious how it goes" or "I get it" or similar.

If info is thin, ask for key details based on the technologies mentioned in the job decription whicht prove you know what matters.

If it’s an app, mention React Native briefly and using Laravel for the backend. If it’s a website and no framework/CMS is specified, lean toward WordPress, mention easy content updates + custom code on top.
        
        Job description:
        1. Project Summary
We are looking for a senior full-stack developer or a small senior team to build the SFD platform: a production-ready webapp for self-service car wash and related vehicle service locations, including payments, wallet/credit logic, role-based admin dashboards, support/manual review workflows and integration with ESP32-based field devices. This is not a simple website or UI-only task. The project requires strong backend architecture, secure payments, role-based permissions, database/ledger integrity, device communication, deployment and QA discipline.
Important: Detailed functional specifications and UI references are already prepared. The selected developer/team will receive the full handoff package after the initial screening stage.

2. What Must Be Built
• Customer webapp: QR-based service flow, guest checkout, login/sign-up, personal wallet, top-up, subscription visibility gating, payment/credit confirmation, transaction history, map, support, settings and legal pages.
• Business / Fleet system: Company wallet, business/fleet top-up, vehicles, drivers, assigned limits, company-scoped transactions, reports, exports and billing-related flows.
• Fleet Driver mobile flow: Simplified driver flow with assigned vehicle/company credit, QR scan, credit use, transaction history, map/support and no access to full company wallet or billing.
• Operator Admin dashboard: Operator-scoped dashboard, own locations, sessions, payout summaries, settlement/reporting and support/contact flows. No global SFD revenue/provider fees/internal device diagnostics.
• Operator Staff validation flow: Mobile-first Portal/Tunnel QR/manual code validation, assigned requests/history and Mark as Served workflow.
• Super Admin / internal console: Global dashboard, operators, operations, accounts, revenue, support, settings, manual review, device health, exports, audit logs and permission-controlled internal actions.
• Backend and infrastructure: Secure API, relational database, RBAC/permissions, wallet ledger, payment webhooks, device registry, session/device command logic, MQTT/HTTPS device gateway, staging/production deployment, monitoring and backups.
• Device simulator and integration testing: A device simulator for command, heartbeat, ACK/EXEC, timeout, offline/degraded and failure scenarios before and during hardware rollout.

3. Important Business and Product Rules
•	The platform must be production-ready integrated v1, stable enough for real pilot/production use.
•	Documents/specifications are the source of truth. Stitch screenshots are visual references only.
•	Personal wallets and Business/Fleet wallets are separate and must use backend-enforced ledger logic.
•	Payment, wallet reservation or company credit activation must be confirmed before service fulfilment or device command dispatch.
•	Guest/direct payment flows use payment wording such as Payment Confirmed; wallet/company-credit flows use credit wording such as Use Credit / Credit Confirmed / Credit Activated.
•	Each paid/wallet/fulfilment session must have a customer-safe Transaction Reference linked internally to payment, wallet, session, support, manual review and payout context where applicable.
•	Role visibility is critical: Business/Fleet Admin sees own company only; Operator Admin sees own operator only; Fleet Driver sees assigned driver/vehicle context only; Operator Staff is validation-only.
•	Provider fees, SFD margin, platform revenue, risk/watchlist data, internal support notes, audit logs and device diagnostics must be visible only to authorized internal roles.
•	Exports, refunds, credit releases, manual adjustments, payout corrections, settings changes and sensitive actions must be permission-controlled and audit-logged.
•	Legal pages and policy text are structure-ready; final legal text will be provided/reviewed separately before production launch.

4. Device / IoT Integration Facts
•	ESP32-based devices communicate with backend through secure MQTT/MQTTS and/or HTTPS over TLS.
•	Default v1 assumption: 1 device = 1 bay/unit/service; Output Channel 1 by default, with future extensibility.
•	Device heartbeat is available and used for Online / Degraded / Offline / Maintenance / Disabled / Unknown status.
•	ACK and EXEC are separate states. ACK confirms command receipt/acceptance; EXEC confirms execution result where supported.
•	Devices can report executed pulses where supported, but there is no guaranteed physical confirmation that the customer actually pressed START or that the bay physically ran.
•	Customer-facing UI must never promise that the machine is already running unless the system can prove it. Use safe wording and clear START instructions.
•	Retry/idempotency is essential: duplicate webhooks or duplicate device messages must not duplicate wallet debits, refunds, payouts or device execution.
•	Offline, unsafe or unavailable device/bay/service states must block customer payment/session activation where required.
•	OTA / firmware update flow, test mode, device logs, alerts and maintenance mode are expected where supported by firmware/hardware.

5. Required Skills
•	Senior full-stack architecture for production web applications.
•	React / [login to view URL] or equivalent modern frontend stack.
•	Node.js / NestJS / Express or equivalent backend stack.
•	PostgreSQL or equivalent relational database with strong data modeling.
•	Secure authentication, RBAC, permissions and role/scope enforcement.
•	Payment provider integration, webhooks, idempotency, refunds and reconciliation logic.
•	Wallet/ledger-style financial logic and audit logging.
•	MQTT / Mosquitto or similar device communication experience.
•	IoT/device integration or embedded-connected platform experience is a strong advantage.
•	Admin dashboards, server-side filtering/sorting/pagination and secure exports.
•	Deployment, staging/production setup, CI/CD, monitoring, backups and rollback planning.
•	QA mindset: integration tests, payment sandbox tests, device simulator tests, permission tests and launch readiness.

6. Expected Deliverables
•	Complete responsive webapp for customer, fleet, operator, staff and internal admin roles.
•	Backend API and database with documented schema and permission model.
•	Payment integration with sandbox/live readiness and secure webhook handling.
•	Wallet/ledger, subscription/top-up/credit logic and transaction traceability.
•	Device registry, command lifecycle, MQTT/HTTPS device integration and simulator.
•	Support, manual review, transaction lookup and issue lifecycle workflows.
•	Staging and production environments with SSL/HTTPS, domain/DNS, environment separation and secure secrets handling.
•	Monitoring, structured logs, alerts, backups, restore process and rollback plan.
•	API documentation, admin setup guide, payment setup guide, device integration guide and operations runbook.
•	Test evidence: automated tests, payment sandbox tests, device simulator tests, permission QA and launch readiness checklist.
•	Post-launch warranty/support period, recommended minimum 30 days after production launch, covering bugs/defects in agreed scope.

7. What Candidates Must Include in Their Proposal
1.	Relevant examples of production platforms with dashboards, payments, wallets, RBAC or IoT/device integration.
2.	Recommended technical stack and why it fits this project.
3.	Experience with MQTT/Mosquitto, device gateways, ESP32/IoT or hardware-connected web platforms.
4.	How they would handle payment confirmed but hardware execution failed or uncertain.
5.	How they would implement wallet ledger, audit logs and Transaction Reference traceability.
6.	How they would enforce role/scope permissions in backend and frontend.
7.	Proposed milestone plan and estimated timeline for a production-ready first release.
8.	Whether they can deliver development + deployment + monitoring + backups + device simulator.
9.	Post-launch support/warranty availability and response times for critical/high bugs.
10.	Who will own Git, cloud/hosting, database, payment provider, device gateway and production credentials after handoff.

8. Important Notes for Applicants
•	Generic copy-paste proposals will be ignored.
•	Do not apply if you only do frontend/design and cannot handle backend, database, payments and integration work.
•	Do not apply if you cannot work with strict specifications, role permissions, audit logging and QA requirements.
•	Full functional specifications, UI references, taxonomy files and Stitch screenshots will be shared only with shortlisted candidates.
•	The selected developer/team must be comfortable signing an NDA/confidentiality agreement if required.
•	All final code, infrastructure, repositories, domains, database, payment provider setup, documentation and production ownership must belong to SFD/platform owner.

Public candidate-facing job brief. Full SFD functional specifications, Stitch screenshots and developer handoff materials should be shared only with shortlisted candidates under appropriate confidentiality / NDA conditions.
        
        Related skills:
        Software Architecture, Embedded Software, Node.js, PostgreSQL, React.js

Check balance

Bid:

Client from: No encontrada

View Project