StratoMesh

StratoMesh lifts scattered insurance work into one connected operating layer above client, broker, and insurer workflows.

Comment

Inspiration

Insurance work is not handled by one team or one tool. It moves between client companies, broker teams, and insurance company teams — across emails, spreadsheets, documents, chats, dashboards, and repeated follow-ups.

StratoMesh was inspired by this gap. We wanted to create a higher workflow layer where all three insurance worlds stay connected in one case journey, with requests, documents, broadcasts, blockers, comments, owners, and decisions preserved together.

We also created a visual story of the problem and the product direction here: Why StratoMesh is Different.

What it does

StratoMesh is a multi-layer insurance workflow platform where the client layer, broker layer, and insurance company layer can operate independently while still staying connected through one case journey.

Each layer has its own workspace, teams, data, requests, documents, comments, observations, and status flow. The platform keeps internal work separate from external communication, so brokers, clients, insurers, and managers see the right context without mixing every team’s internal decisions.

The AI layer helps create structure from unstructured insurance work: it reads requests and documents, extracts case data, identifies missing information, suggests the right workflow context, and helps turn broker or client communication into organized case memory.

How we built it

  • We built StratoMesh as a full-stack Next.js application with role-based workspaces for client companies, broker companies, insurance company teams, and managers.

  • The frontend runs on Vercel and includes separate operating views for Sales, Underwriting, Pricing, Finance, Claims, Policy Issuance, Manager, communication flow, and demo journeys.

  • The backend uses Next.js API routes for case creation, document processing, team queues, workflow routing, manager observations, communication flow, and demo scenario selection.

  • We designed the workflow around configurable boxes. Each box represents a real unit of insurance work, such as document intake, underwriting review, pricing handoff, finance check, claim triage, manager observation, or policy issuance.

  • We added AI-assisted email and document extraction so broker/client requests can become structured case data instead of staying as unstructured messages.

  • We separated external communication from internal workflow context. Broker/client communication can be tracked safely, while internal team comments, observations, blockers, and decisions stay connected to the case without exposing every internal detail externally.

  • We built communication flow and comments as part of the case memory, so every team can understand what happened before, what is pending, who owns the next action, and why the case is blocked or ready to move.

  • We used AWS Aurora PostgreSQL as the main workflow memory database, connected through Prisma ORM. Aurora stores cases, teams, documents, workflow blocks, comments, observations, handoffs, and decision history.

  • We created two live demo journeys on Aurora: a Sunrise Foods new policy journey and a Delta Logistics claim settlement journey.

  • The architecture is designed to grow beyond the demo with AI automation, document storage, queue workers, search, cache, external integrations, observability, and access control.

Build timeline

  • Defined the three operating layers: client company, broker company, and insurance company.
  • Designed workflow boxes as independent units of insurance work with owners, status, comments, observations, documents, and routing.
  • Built independent workspaces for Sales, Underwriting, Pricing, Finance, Claims, Policy Issuance, and Manager.
  • Added AI-assisted extraction to create structured insurance case data from broker/client requests.
  • Created internal communication, external request tracking, manager observations, and team-level case movement.
  • Connected the backend to AWS Aurora PostgreSQL using Prisma.
  • Created fresh demo data in Aurora for both policy and claim journeys.
  • Deployed the application flow with Vercel and connected it to the AWS database foundation.

A visual build timeline is available here: StratoMesh Build Timeline.

Challenges we ran into

  • One of the hardest challenges was turning a messy insurance process into a clear structure. Insurance work does not move in a straight line. It moves between client companies, broker teams, insurer teams, documents, approvals, questions, observations, and business deadlines.

  • We had to decide what should become a “workflow box.” A box in StratoMesh is not just a UI card — it represents a unit of insurance work with an owner, status, documents, comments, observations, blockers, and routing logic.

  • Another challenge was keeping the three layers independent but connected. Client, broker, and insurer users should not all see the same internal information, but their work still has to connect into one case journey.

  • We also had to think differently from existing tools. Many products handle email, documents, tasks, dashboards, CRM, policy records, or claims separately. StratoMesh tries to connect those fragments into one case memory where every handoff and decision remains traceable.

  • Technically, we also had to move from local development to a real Vercel + AWS Aurora PostgreSQL setup, create fresh demo data, and build scenario APIs so the demo could use stable policy and claim cases without hardcoded case IDs.

Accomplishments that we're proud of

  • We are proud that StratoMesh became more than a dashboard. It became a working insurance workflow foundation across client companies, broker companies, insurer teams, and managers.

  • We built configurable workflow boxes that can represent real insurance work such as document intake, underwriting review, pricing handoff, finance check, claim triage, manager observation, and policy issuance.

  • We created two working demo journeys: a new policy journey for Sunrise Foods and a claim settlement journey for Delta Logistics.

  • We connected the product to AWS Aurora PostgreSQL through Prisma and used it as the workflow memory layer for cases, documents, blocks, observations, handoffs, and decisions.

  • We deployed the application with Vercel and learned how important clean environment variables, build checks, API routing, and production database connections are for a real full-stack product.

  • We are also proud that we solved demo stability with scenario APIs, so the frontend can pick the right active policy or claim case without hardcoded case IDs.

What we learned

  • We learned that insurance workflow is not only a data-entry problem. The real problem is context: who owns the next action, which document is missing, why a case is blocked, and what decision was made before.

  • We learned that client, broker, and insurer layers must be independent, but the case journey must stay connected. Each user needs the right view without exposing every internal team decision.

  • We learned that AI is most useful when it creates structure from messy work. In StratoMesh, AI helps convert broker/client documents and requests into case data, workflow context, missing checks, and team-ready memory.

  • We learned that “status” is not enough. A case needs comments, observations, blockers, owners, routing, SLA context, and decision history to become truly useful.

  • We learned a lot from the Vercel deployment process: local URLs, environment variables, build-time TypeScript errors, Prisma JSON types, and backend/API routing all need to be production-safe before deployment.

  • We also learned that deployment architecture matters early. Moving from local Postgres to AWS Aurora helped us think about real demo data, stable scenario selection, and production-ready workflow memory.

What's next for StratoMesh

Over the next 3 to 4 months, we want to turn StratoMesh from a hackathon demo into a deeper insurance operating platform.

  • Month 1: Expand all three layers — client company, broker company, and insurance company — with stronger role-based workspaces for every team, including Sales, Underwriting, Pricing, Finance, Claims, Policy Issuance, Manager, and external users.

  • Month 2: Make workflow boxes more configurable. Teams should be able to design custom boxes for important or complex scenarios, add agenda settings, define owners, comments, observations, blockers, approval rules, and decide how each box moves the case forward.

  • Month 3: Strengthen communication and memory. We want internal comments, manager observations, external broker/client messages, chat-style updates, document history, and decision records to become deeply connected to the same case memory.

  • Month 4: Add business and production layers: stronger manager dashboards, business impact views, SLA and premium-at-risk tracking, external system connections, document storage, search, cache, queue workers, and more AI support for workflow suggestions and complex case handling.

The goal is to make StratoMesh a configurable workflow mesh where simple cases move fast, complex cases get the right visibility, and every internal and external action stays connected to one trusted insurance case journey.

Built With

Share this project:

Updates