SoloFrame platform
SoloFrame gives SVTech one platform layer for identity, data, AI, safety, content, billing, engagement, and operations. Vertical teams configure shared services through typed manifests and keep product-specific work inside each application.
Founder story
SoloFrame exists because of a workflow problem Mike Sullivan lived every week, not because a platform thesis needed proving.
I started by creating interactive HTML5 course content, then pasting it into an off-the-shelf SaaS. Entering it there was tedious and error-prone, and keeping content current by hand in a world where material dates fast was futile.
So I built my own platform with VS Code and Claude Code and deployed it on Cloudflare. It ran, but I could not get the interactivity, security posture, or depth of AI integration I wanted from that approach.
A move to Google Cloud Platform ended when several sales calls pushed a $1,000/month commitment. Before revenue, that is not a platform decision; it is a tax on building.
VPS hosting with Dokploy and an API-first approach made the process nearly seamless, and it still is: seven verticals plus supporting marketing tools run alongside n8n workflows I configure programmatically. The stack stays deliberately standard and open (Node and Next.js applications, Postgres with pgvector, Redis, Docker), so nothing depends on a proprietary runtime and the whole fleet can be ported to another host if it ever has to move.
One 16-core, 64 GB enterprise-class VPS carries the fleet alongside open-source operational tools such as ERPNext, and a second VPS handles operations and backup. No per-service, traffic, or storage fees means a new service deploys at zero marginal cost, and the 16 cores barely idle.
Every content piece ends with a feedback box. Completion rates, quiz and test scores, forum threads, chat, and monthly research feed continuous signals back into the roadmap, which is why platform updates ship in near real time.
User data lives in a separate database from platform code and content. Deploying improvements does not put learner history or progress at risk.
The compounding effect is deliberate: every signal loop becomes an intelligence moat that widens the gap to competitors still hand-updating static catalogs, while subscribers receive always-current content. AI spend stays deliberately outside that fixed bill: OpenRouter routes each task to a cost-appropriate model, so model costs remain variable and grow with revenue instead of sitting in overhead. And because unit costs keep falling, those savings pass through as subscriptions priced below market rate.
Four layers
Platform code earns its place through repeated use. Product content and buyer workflows stay close to the vertical that owns them.
Brand, routes, content, domain workflows, buyer promise, and product analytics.
Forums, billing, email, storage, CRM, and other providers selected by product need.
Auth, content, contracts, data, model routing, safety, engagement, logging, and voice services.
Postgres, Redis, object storage, Dokploy, containers, health probes, scheduled work, and monitoring.
Manifest-driven variation
A manifest declares the brand, domain, model tasks, safety classifier, compliance posture, forum, billing, storage, and feature flags. The vertical keeps lessons, prompts, personas, forms, and workflow screens.
brand and domain manifest model selection manifest compliance posture manifest billing adapter manifest route and page vertical lesson and prompt vertical buyer workflow vertical shared protocol engine after reuse
Product mechanics
Lessons, assessments, worksheets, roleplay, artifacts, approval gates, and private workspaces.
Product content, user state, and relevant records reach the model through bounded retrieval paths.
Progress, workflow outputs, engagement, usage, safety events, and product-specific results become observable.
Accounts, access controls, billing adapters, entitlements, email, communities, and lead handoff.
Classifier-before-LLM routing, audit records, provider controls, approval gates, and fail-safe behavior where the workflow requires them.
Shared, isolated, or dedicated components can support different risk, buyer, and operating requirements.
Architecture truth
SVTech uses the platform to ship working verticals. New products still require buyer research, domain design, product decisions, validation, and operating ownership.
| Platform supplies | SVTech designs | Buyer validates |
|---|---|---|
| Shared identity, data, AI, safety, content, billing, and operations | The workflow, interface, content model, controls, integrations, and measurement | The urgent job, willingness to adopt, buying process, and success threshold |
Direct answers
A vertical AI platform supplies reusable product services for multiple industry or role-specific applications. Each application still owns its domain workflow, content, brand, and buyer promise.
No. The shared engine handles platform concerns. Each vertical builds its own routes, presentation, content, and workflow components around the buyer's job.
No. SVTech currently uses SoloFrame to build and operate defined vertical products and client pilots. A broad self-service studio is not the current offer.
A vertical can use local provider clients first. Shared adapters graduate into the platform when more than one vertical needs the same integration or a manifest selector must control it.
Start with the buyer job
SVTech will assess whether SoloFrame fits the product, compliance, data, and operating requirements before proposing a build.