Torus, the cyber insurance platform architecture built by Cyber-Logica with SynthWeb as the engineering partner, is one of three production-grade fintech products we have shipped. This post walks through the major architecture decisions made during the MVP build — what we picked, what we rejected, and where we deliberately deferred complexity to ship faster. If you are a fintech or insurtech founder building a v1, the decision tree here transfers directly to your build.
The constraint set we inherited was harder than a typical MVP. Cyber insurance underwriting requires processing technical telemetry from a customer’s infrastructure (security posture data, vulnerability scans, third-party risk indicators), making real-time underwriting decisions, and then producing a binding policy document with regulatory implications. The product had to do this for SME customers who would not tolerate a long onboarding flow, and the platform had to scale horizontally because each customer’s data ingestion volume varied wildly.
Stack: boring chosen deliberately
Frontend: The frontend layer of the Cyber Insurance Platform Architecture was built with React 18 and TypeScript, served as a single-page application. The decision to go SPA over Next.js was made because the application is gated, dashboard-heavy, and does not need SEO — the marketing site is a separate static build. Less infrastructure complexity, faster build times, simpler deployment.
Backend: The backend of the Cyber Insurance Platform Architecture used Node.js with Express on Postgres 15 with Redis for session storage and queueing. We considered Go for the underwriting engine specifically — the performance argument is real for that subsystem — but the cost of a polyglot codebase early in product life outweighed the marginal performance gain. We could rewrite the underwriting engine in Go later if it became a bottleneck. It has not.
Infrastructure: The cloud infrastructure powering the Cyber Insurance Platform Architecture was built entirely on AWS, with the entire production stack defined in Terraform. Application Load Balancer in front of an ECS Fargate cluster, RDS Postgres, ElastiCache Redis, S3 for document storage, KMS for encryption keys. We rejected serverless (Lambda) for the core API because cold starts on a fintech product with unpredictable traffic patterns introduced too much latency variability.
Security Posture Decisions
Three decisions defined the security posture from day one. First, end-to-end encryption of all customer data at rest, with KMS-managed keys. Customers in cyber insurance platform architecture have higher than typical data sensitivity — they are buying the product because they take security seriously. Second, network-level isolation of the underwriting engine from the public-facing API; the underwriting service runs in a private subnet with no internet egress, accessible only via internal service mesh architecture. This improved the overall security model of the Cyber Insurance Platform Architecture while reducing external attack surfaces. Third, full audit logging of every read and write operation on customer data, retained for 7 years to align with regulatory requirements.
The audit log alone added 15% to the engineering effort of the MVP. Worth it. Three of Torus’s first 20 customers asked to see the audit log architecture during their procurement review. Having it in place was a deal-closing signal.
The underwriting engine: deliberately simple
The underwriting engine could have been built as a machine-learning system from day one. We chose to build it as a deterministic rules engine instead. The reasoning was operational: a deterministic rules engine is auditable, explainable to regulators, and debuggable when an underwriter disagrees with a decision. A machine-learning system would have been faster to ship a “good enough” underwriting decision in v1 but slower to iterate on once customer feedback came in.
The rules engine is a YAML-based DSL that the underwriting team at Cyber-Logica edits directly. They added 47 rules in the first six months without an engineering ticket each time. This is the kind of decision that pays off in year two of a product’s life, not week six.
What we deferred (deliberately)
Multi-region deployment, advanced fraud detection, real-time webhook integrations to customer ticketing systems, white-label dashboards for broker partners. All deferred topost-v1 because they did not change whether the product could close its first 10 customers. Every deferred feature was logged in a “v2 backlog” with a clear trigger condition for when to build it. Multi-region deployment got built at month nine when the first international customer needed it.
What broke during build
Two things, both worth documenting. First, the integration with a third-party vulnerability scanner returned data in a format their docs did not match — the actual API response was nested differently. We spent 2 days writing defensive parsing logic before realising the cleaner solution was to write our own canonical schema and a thin adapter layer per third-party source. The adapter pattern saved us four times in the next six months as we added more data sources.
Second, the deployment pipeline broke at the third production release because of a Terraform state-locking issue we had not anticipated. We added a CI step that warns on uncommitted Terraform changes and a Slack alert on state-lock conflicts. Boring infrastructure work; eliminated an entire class of production incident.
FAQ
How long did the Torus MVP take? 14 weeks from contract to first customer in production.
What was the team size? Pod of 4 engineers plus engagement lead, plus part-time DevOps and security review.
Can SynthWeb build other fintech MVPs? Yes — the architecture patterns transfer to insurtech, lending, payments, and most regulated SaaS domains.
Did Torus continue with SynthWeb after v1? Yes — Cyber-Logica converted the MVP Sprint into an ongoing Engineering Pod, which is the typical conversion path.
Also Read: Why Cursor AI is the most powerful IDE You Need in 2026
