WiFiFacil
WiFiFacil explores the intersection of captive portals, local operations, PIX payments, voucher management and connectivity as a service.
What this work proves.
Context
WiFiFacil is a SaaS and field-operations concept for selling paid Wi-Fi access in beaches, events and remote public areas. The idea connects captive portals, vouchers, local network equipment, PIX payments and the practical work of operating connectivity outside a controlled office environment.
Problem
The product challenge is not only building a web dashboard. The system has to survive weak connectivity, temporary locations, on-site operators, payment confirmation, customer support and simple access recovery. The MVP needed to start lean while leaving a path toward automation.
Constraints
- The first version must work even when operations are semi-manual and payment confirmation is not fully automated.
- Field operators need simple flows for voucher creation, lookup, activation and support without technical network knowledge.
- Customers need fast access and clear expectations in places where connectivity may already be unstable.
- The architecture should support a future transition from manual PIX checks to automated provisioning.
Technical decisions
Separated field operation from customer access
D-01The concept treats the operator workflow and the customer captive portal as different surfaces. Operators need controls, lookup and recovery; customers need minimal friction, clear pricing and fast access activation.
Designed a manual-to-automated payment path
D-02Instead of requiring full payment automation on day one, the MVP can begin with manual PIX validation and voucher activation. The data model still needs to preserve payment references and access states so automation can replace the manual step later.
Kept the MVP centered on vouchers and access state
D-03The first useful system is a clean voucher lifecycle: created, pending payment, active, expired, blocked or refunded. That state model gives operators a concrete source of truth before expanding into advanced analytics or multi-site management.
Mapped infrastructure as product risk
D-04Network equipment, captive portal behavior and location constraints are part of the product, not implementation details. The interface needs to expose enough operational state to help people act when hardware, signal or payment timing creates friction.
Outcomes
- A clearer MVP boundary for a connectivity SaaS that starts operationally realistic.
- A product architecture that can evolve from manual validation to automated access provisioning.
- A stronger narrative around building software for environments where the browser is only one piece of the system.
Learnings
- Field products need interfaces for operators as much as for end customers.
- The right MVP may deliberately include manual steps when the architecture preserves a path to automation.
- SaaS ideas get sharper when pricing, support, hardware and connectivity constraints are treated as first-class design inputs.
Impact
- Designed the first MVP architecture.
- Mapped field operation constraints and pricing.
- Defined a path from manual PIX validation to automated access.
fastapi
sqlite
captive portal
omada
pix