Search for a command to run...
Building the frontend architecture, guided journey, and integrations for a new insurance purchasing feature
No comments yet. Be the first to comment.
Detailed breakdowns of real software engineering and AI projects, from problem definition and technical decisions to implementation, trade-offs, and lessons learned.
Building the frontend experiences and integrations behind recruitment, evaluation, offers, and pre-boarding
A long context window sounds like an obvious advantage for an AI agent. The agent can retain more search results, tool outputs, intermediate reasoning, and evidence. Give it enough context, and perhap
Designing the frontend flow and integrations behind a multi-stage insurance experience
Extending an on-demand delivery platform to support fixed vehicles, long-running assignments, and operational oversight
Researching and implementing a Microsoft identity integration for employee synchronization
Disclosure: This case study is anonymized. Product screenshots, source code, client branding, proprietary workflows, and internal metrics have been excluded.
Industry: Health insurance
Project type: New digital product feature
My contribution: Frontend architecture, user-flow implementation, screen development, API integrations, and cross-team coordination
Team:
Buying health insurance can involve more than selecting a plan and entering payment details. Applicants may need to provide personal information, answer eligibility questions, review coverage, submit supporting details, and move through several dependent stages before completing an application.
In the process this project aimed to improve, much of that journey depended on manual handling and repeated coordination. That made the experience slower for applicants and created additional operational work behind the scenes.
The goal was to introduce a digital product feature that could guide users through the application journey, exchange information reliably with backend services, and make each stage easier to understand and complete.
My responsibility was to own the frontend side of that work: shaping the application flow, developing the screens, integrating the APIs, establishing the frontend structure, and coordinating with the backend engineer as the product behavior evolved.
At first glance, the work could be described as building several frontend screens for an insurance application.
That description misses the difficult part.
A multi-stage insurance journey behaves as one connected system. Information entered early in the process can influence later screens. API responses may determine which options are available. Validation must prevent incomplete or inconsistent data from moving forward. Users also need to understand what is happening when information is loading, rejected, incomplete, or successfully submitted.
A collection of attractive forms would not solve those problems on its own.
The frontend needed to coordinate four concerns:
| Concern | What the product needed |
|---|---|
| Journey clarity | Users should understand the current step and what is required next. |
| Data consistency | Information should remain coherent as users move between dependent screens. |
| Integration reliability | API requests and responses should produce predictable interface behavior. |
| Maintainability | New requirements should not turn every change into a rewrite of the entire flow. |
The engineering problem was therefore to build a guided application experience without allowing the growing number of screens, states, validations, and integrations to make the frontend fragile.
I worked across implementation and coordination rather than treating the frontend as an isolated presentation layer.
My responsibilities included:
Structuring the frontend application flow.
Developing the screens used across the journey.
Connecting those screens to backend APIs.
Managing loading, validation, error, and successful-response states.
Keeping the experience coherent as users moved between stages.
Coordinating frontend requirements and API behavior with the backend engineer.
Reducing unnecessary complexity so that later changes could be handled more safely.
This distinction matters. I did not build the entire insurance platform independently, nor did I own the backend underwriting or insurance-domain logic. My contribution centred on translating product requirements and backend capabilities into a dependable user-facing workflow.
The application was approached as a sequence of dependent stages rather than a set of unrelated pages.
That meant each screen needed a clear responsibility:
Collect the information required at that stage.
Validate what could be checked before submission.
send the expected data to the relevant service.
Interpret the response consistently.
Move the user forward, keep them in place, or explain what needed attention.
This structure helped keep navigation, form behavior, and integration logic aligned.
It also reduced the risk of allowing individual screens to develop their own inconsistent rules for loading indicators, errors, validation feedback, or progression.
Engineering principle: In a multi-step product, reliability depends as much on the transitions between screens as it does on the screens themselves.
One of the most important parts of the work was coordinating the relationship between the interface and the backend APIs.
Backend responses are designed around system behavior. Interfaces are designed around what users need to understand. Those two models rarely align automatically.
The frontend therefore had to translate between them.
That included ensuring that:
Requests were triggered at the correct point in the journey.
Screen data was prepared in the structure expected by the backend.
Response states were represented clearly in the interface.
Validation failures did not appear as unexplained technical errors.
Incomplete or unsuccessful requests did not leave the journey in an ambiguous state.
Changes to an integration did not unnecessarily affect unrelated screens.
Regular coordination with the backend engineer was essential. Questions about field requirements, response structures, dependencies, and edge cases were addressed as shared product concerns rather than being discovered only after integration.
This reduced integration ambiguity and made the implementation more predictable.
Multi-step forms tend to accumulate conditional rendering, duplicated state, repeated API handling, and one-off validation rules.
The frontend architecture was intended to prevent those concerns from becoming tightly coupled.
The core separation was between:
What the user saw.
What information the current stage owned.
What needed validation.
What data had to be exchanged with an API.
What should happen after a response.
This made the flow easier to reason about because a change in one responsibility did not automatically require changes everywhere else.
It also supported more consistent behavior across screens. Users should not encounter one style of loading state on one step, a different error pattern on another, and an unexplained failure on the next. Consistency is not only a visual-design concern; it is part of system reliability.
The project delivered a functioning frontend journey for a new digital insurance feature that had previously depended on manual processing.
From an engineering perspective, the work produced several qualitative improvements:
Separating screens, flow behavior, validation, and integrations made the implementation easier to reason about and reduced unnecessary coupling between features.
Closer alignment between frontend requirements and backend contracts reduced ambiguity around data exchange and response handling.
The flow was structured to avoid unnecessary work and provide users with clearer feedback while information was being processed.
Consistent handling of loading, validation, failure, and successful-response states reduced the likelihood of users being left in unclear or broken interface states.
Shared validation and integration patterns helped information move through the journey more consistently.
These outcomes are based on the implementation and delivery experience. No confidential production analytics, conversion figures, cost savings, or insurer-level operational metrics are being claimed in this case study.
The difficult part is rarely drawing inputs on a screen. The real work lies in controlling dependencies, transitions, validation, recovery, and submission across the complete journey.
When interface state and integration behavior are poorly separated, small product changes can produce unpredictable consequences. Clear boundaries make both delivery and debugging safer.
Backend contracts are not only technical details. They determine what information users can provide, when they can proceed, and how clearly the product can explain a problem.
A technically successful request can still feel broken when the interface gives no feedback. Loading, progress, validation, and recovery states are part of the system’s performance from the user’s perspective.
Confirmation messages, disabled actions, retry paths, preserved form state, and understandable errors are not portfolio-friendly hero features. They are, however, what keep a real application usable.
This project was not simply an exercise in turning a manual process into a series of web forms.
It required translating a dependent business workflow into a frontend system that users could navigate with confidence and that engineers could continue evolving without unnecessary fragility.
My main contribution was creating that bridge: shaping the frontend architecture, implementing the journey and its screens, integrating backend services, and coordinating technical decisions across the team.
The most valuable result was not a single interface element. It was a more structured and dependable way for the product to guide users through a complicated process.
What I demonstrated
Frontend architecture · Complex user flows · API integration · Form and state management · Validation and error handling · Cross-functional engineering coordination
All diagrams and illustrations used with this case study should be labelled representative or conceptual. They must not be presented as screenshots, exact architecture diagrams, measured analytics, or reproductions of the client’s product.
