Discovery
Validating the Hypothesis Where Other Teams Had Already Failed
Mercantil Seguros is one of Venezuela's largest insurance companies, with decades of operation and a technology core that had gone 10 to 15 years without structural updates. The problem was concrete: users could not quote, purchase, or issue a policy without going through a human agent. Every request depended on manual processes, paper forms, and internal validations that could take days. The opportunity to transform that into a digital self-service flow was obvious. Whether it was technically viable was not.
Two companies before us had attempted to integrate with Mercantil Seguros' core and failed. Not for lack of ambition, but for underestimating the technical rigidity of a legacy system and for lacking experience operating within the specific logic of the insurance business. That shaped our research strategy from day one: before designing any solution, we needed to understand exactly where and why those teams had hit the wall.
Our benchmark focused on markets where similar solutions were already working: the United States and several Latin American countries. The critical difference we found was structural. The North American insurers that had successfully launched digital quoting tools operated on modern cores with open APIs and solid documentation. Mercantil Seguros had the opposite: 15-year-old systems, undocumented business logic, and underwriting rules that lived only in the heads of their internal technical teams. The challenge was not building a polished interface. It was building a presentation layer that could communicate with infrastructure that was never designed for that purpose.
To secure project buy-in, data alone was not going to be enough. We built a functional prototype in Figma that simulated the complete quoting, selection, and policy issuance flow. We presented it directly to the President of Mercantil Seguros. Seeing the flow in motion, with the business logic faithfully reflected, was what unlocked the project. The prototype was not a design deliverable. It was a business argument.
Design
Making Design Decisions Without a Designer on the Team
The team had no dedicated UX/UI designer. That forced a clear priority from day one: usability over aesthetics. Every interface decision was evaluated against one question: does this reduce friction or add it?
The first structural decision was the form format. We evaluated two approaches: a one-page form that consolidates all information on a single screen, or a step-by-step flow where each screen represents one stage of the process. We went with the step-by-step flow. The reason was not visual but technical. Each screen mapped to an integration point with the APIs our backend team was building in parallel. Separating the flow by stages let us validate each integration's logic in isolation, catch errors precisely, and keep frontend and backend development in sync without creating blocking dependencies.
One of the most important insights came early: insurance users do not complete an application in a single session. The process involves gathering documents, consulting with family members, and comparing coverage options. Assuming users would finish in one sitting was a design mistake. We implemented progress saving and an email reminder system that reactivated incomplete applications. That mechanism alone had a measurable impact on completion rates.
The B2B testing sessions were the most revealing. Working with organizations managing group insurance for their employees, we found patterns we had not anticipated: HR administrators needed visibility across multiple simultaneous applications, not just their own. The bottlenecks were not where we had modeled them. They were in how coverage information was presented, in the lack of clarity around which documents were required at each stage, and in the absence of explicit confirmation steps that built user trust. Every testing session translated into concrete changes to the flow the following week.
Delivery
Soft Launch, Same-Day Iteration, and the Scenarios Nobody Modeled
The delivery team was intentionally small: two backend developers, one frontend developer, one technical lead, and a product owner. We ran Scrum with two-week sprints and end-of-sprint demos with Mercantil Seguros stakeholders. The methodology was not a formality. It was the structure that allowed us to move fast in an environment where insurance business requirements kept surfacing as we went deeper into the system.
The launch was a soft launch targeting a single company with over 700 employees enrolled in a group insurance plan. Notification went out by email, no mass campaign, no noise. We wanted controlled volume to monitor real system behavior before opening access more broadly. The stack was React JS on the frontend, Node.js on the backend, with an integration layer that mapped the legacy core's logic to API endpoints our application could consume.
The first 24 hours required production iterations. Scenarios appeared that discovery had not fully captured: coverage combinations that triggered unexpected states in the legacy core, legal validations that Mercantil's legal team had not communicated to the technical team, and exception flows that only become visible when real users make real decisions. None of this was a process failure. It was the reality of integrating a new product with a system that had been running on its own undocumented logic for 15 years.
The rollbacks that occurred were isolated and mostly attributable to misalignment between Mercantil's legal and technical teams, not to product failures. That was a significant signal: the biggest risk in projects like this is not technical. It is internal governance.
Follow-up Post-Delivery
What the Launch Taught Us That Discovery Could Not Have Predicted
The most immediate lesson was about a stakeholder we had displaced without planning to: the insurance agent. By building a digital self-service flow, we effectively eliminated the agent as a required point of contact. That created friction with Mercantil's agent network, who saw the quoting tool as a direct threat to their business model. The fix was to redesign the system to include an agent role: they could register on the platform, refer clients from their existing book of business, and maintain visibility over their clients' application status. The quoting tool shifted from being a replacement to being a productivity tool for agents.
The second lesson was harder to resolve cleanly. In health insurance, users tend to omit or understate pre-existing conditions, consciously or not. Without digital verification mechanisms, we had no way to validate declared information. Rather than trying to solve a problem that required verification infrastructure that did not exist, we chose a shared-responsibility approach: a clear, prominent disclaimer within the flow that spelled out the legal and coverage consequences of submitting inaccurate information. Transparency as a risk management mechanism.
The third lesson was operational and hit Mercantil Seguros' internal teams directly. The volume of applications generated by the quoting tool exceeded the processing capacity of the insurer's back-office. We had solved the acquisition problem and created a logistics problem in the process. That led us to work with Mercantil's internal teams to map their administrative processes and propose automations that reduced the manual validation and issuance workload.
Three foundational takeaways that extend well beyond this project. First, small focused teams consistently outperform larger ones when the work demands creativity, fast decision-making, and tolerance for ambiguity. Bureaucracy is not a function of company size. It is a function of process design. Second, adopting agile methodologies inside organizations with a waterfall culture is not a tooling change. It is change management work that demands as much effort as the product itself. Aligning with stakeholders who operate on quarterly cycles when your team is moving in two-week sprints is a product problem, not a process problem. Third, and most important: the success of a digital product in a regulated sector like insurance depends as much on the client's internal alignment as on the quality of the product. The highest-risk items in this project were not technical. They were human.
