A vertical PaaS for AI-native healthcare and revenue products
SVTech is building SoloFrame - a multi-tenant vertical PaaS with compliance, tenant isolation, and AI orchestration built in. We're extracting it from DWA (HIPAA-aware healthcare) and GTM-OS (revenue operations) - the two vertical SaaS entering beta on it today - and the platform is designed to scale from a single node to a multi-server deployment without a rewrite.
Why SoloFrame is the engine we're extracting
Three properties of the architecture we're pulling out of the two verticals. Each one is a direct consequence of the design decisions made from day one - and each translates into how fast future verticals ship, how safely we operate, and how the portfolio compounds.
Launch a new vertical in weeks, not quarters
A vertical is defined as configuration - not code. New products compose from shared primitives instead of duplicating systems. The first flagship took months; the second took days.
Compliance as a setting, not a rewrite
Healthcare verticals set phi: true and inherit HIPAA-aware behavior. Non-healthcare verticals get none of that overhead. The manifest wires up retention, guardrails, and classifier sidecars; the engine enforces it.
Every vertical sharpens the next
Shared classifiers, shared assessments engine, shared analytics pipeline. The safety model a healthcare vertical trains today improves every future clinical deployment. Longitudinal data compounds into a moat competitors can't buy.
Vertical AI portfolios fail in three predictable ways
Every studio we've watched try to build multiple AI products has hit the same three walls. SoloFrame was designed against each of them from the beginning, because we're the studio too.
Each new vertical becomes a new codebase
By the third product, you're maintaining three stacks - each with its own auth, tenancy, billing, and AI wiring. The platform vision collapses into backlog.
Manifest-driven verticals. Each product is configuration, not a forked codebase. One engine, many outputs. An admission rule keeps the core small: no package lands without ≥2 consumers.
Application-code isolation is a breach waiting to happen
When isolation lives in WHERE clauses and middleware instead of the database, one missed condition in one query can expose another tenant's data.
Database-enforced isolation. Postgres row-level security at the data boundary, keyed on a per-request tenant GUC. A tenantLeakHarness runs in CI and blocks the build on any regression.
Off-the-shelf moderation misses domain-specific risk
The signals a healthcare deployment needs to catch are not the signals a forum moderator needs to catch. LLM-provider safety filters were trained to catch different things.
Pluggable safety layers. Verticals that need a purpose-trained classifier attach one (DWA's MAIA); verticals that don't get none of the overhead. Wired in by manifest flag, not app code.
A vertical is configuration, not a codebase
A typed JSON manifest describes everything the engine needs to know about a vertical: compliance posture, AI model choices, adapter wiring, assessments, branding, roles, billing plans. Twelve primitives. All validated. All version-controlled.
Changing a vertical means editing configuration. Adding a vertical means composing primitives. Neither requires changing the engine.
{
"id": "dwa",
"compliance": {
"phi": true,
"retentionDays": 2557,
"guardrails": [
"never-diagnose",
"always-988-on-crisis"
]
},
"ai": {
"classifier": "maia",
"coachingModel":
"claude-haiku-4-5"
},
"adapters": {
"forum": "flarum",
"payments": "polar"
}
}Two vertical SaaS built. One vertical PaaS in extraction.
DWA and GTM-OS shipped first as standalone vertical SaaS products. SoloFrame is the shared spine we're now pulling out of them - identity, tenancy, AI orchestration, adapters, manifests. As the extraction completes, both verticals run on the same vertical PaaS; neither is a fork, because there's nothing to fork yet.
A HIPAA-aware mental-health education platform that psychiatric practices license to extend patient care between sessions. Clinical assessments, a purpose-trained safety classifier, and provider coordination tooling.
A B2B learning platform for tech founders and teams. Structured curriculum, AI coaching with founder context, DISC-based peer pod matching, and AI-moderated community with named persona facilitators.
An unclaimed middle between two well-served markets
Foundation-model providers ship models, not products. Vertical SaaS companies ship products, not platforms. AI-native point products ship one use case. The middle - a platform that builds and operates vertical SaaS with a shared AI-native core - is largely unclaimed.
OpenAI, Anthropic, Google, Mistral. The infrastructure every AI product runs on - but none of them ship vertical SaaS, and none have visibility into a vertical's data flywheel.
Veeva, Toast, Procore and the rest. Excellent at one industry vertical. Rarely AI-native at the core. No reusable spine for the next vertical; each new category is a fresh raise.
A vertical PaaS that builds and operates its own vertical SaaS. Each vertical's real-world usage feeds the shared data flywheel - sharpening the platform that powers every future vertical.
Modular monolith. Horizontally deployable. Redundant by design.
SoloFrame is being built as a horizontally deployable modular monolith - one codebase, stateless app replicas, shared state in Postgres / Redis / object storage, tenant routing resolved at request time. It runs comfortably on one node today and scales to a multi-node deployment under Dokploy + Traefik + Docker Swarm as workloads grow. Multi-node isn't just for scale - it's redundancy: stateless replicas behind Traefik mean a failed node doesn't take the platform down, and rolling deploys don't require maintenance windows.
One codebase, multi-tenant, stateless replicas behind Traefik. Today's beta footprint fits on a single node.
Dedicated app replicas, dedicated DB, dedicated storage - a deployment topology choice, not a code fork.
Model retraining (MAIA, ClinicalBERT, sentiment, risk) runs on GPU instances out-of-band. Inference on the safety path stays CPU-bound for reliability.
Root-server deployment, not Vercel-style per-invocation pricing
We deploy to VPS and root-server infrastructure via Dokploy, not to managed-PaaS hosts that bill per request, per function invocation, or per bandwidth unit. That matters for AI-heavy workloads: a single thoughtful LLM session can fire dozens of inference calls and streaming tokens, and per-invocation pricing converts engagement into variable cost that fights margin.
Running on root servers gives us predictable capacity at a predictable price. The modular-monolith-on-Swarm pattern adds redundancy and horizontal scale by adding nodes - not by paying a hosting vendor more per user. That structural advantage compounds as usage grows.
Questions we hear a lot
Fast answers to the things clients, partners, and investors most often ask.
What is SVTech Consulting?+
What is SoloFrame?+
What is a vertical PaaS, and how is it different from a foundation-model provider or a vertical SaaS company?+
What vertical SaaS are running on SoloFrame today?+
How does SoloFrame ensure tenant isolation?+
BYPASSRLS. Every DB-touching engine obeys a withTenant(ctx, fn) contract. A tenantLeakHarness runs in CI and blocks the build on regression. Dedicated-DB deployment is available as a paid SKU for licensees who require it.What is MAIA, the distress classifier?+
How does SVTech engage with clients?+
Why a monolith instead of microservices?+
Three reasons to reach out
A custom vertical built for your organization. A licensed deployment of an existing one. An investor conversation. Pick the one that fits.