How I shipped Wintura.ai solo — Production B2B SaaS in 6 months

Key Results

TL;DR. Wintura.ai is a production B2B SaaS for service businesses that bill by scope — agencies, consultants, contractors. I shipped it solo in 6 months using Next.js 16.1.6, React 19.2.3, Claude Sonnet 4.6, NextAuth v5, multi-tenant Neon Postgres, Stripe Connect, sealed-PDF audit trails, and 24 Playwright e2e files (including axe-core accessibility across mobile, tablet, and desktop). Live at wintura.ai. This is the same playbook Soatech now sells to founders via the €3,500 Production Lift (1 week) and €9.5K+ MVP Sprint Lite (under 30 days).

What Wintura Does (the verifiable product)

Wintura.ai generates proposals and statements of work for service businesses in 5 minutes instead of 5 days. The wedge audience is small-to-mid marketing agencies (3–15 employees) — the SEO and ICP focus — but the broader market is any team that bills by scope: consultants, contractors, freelance agencies, service teams inside larger orgs.

The flow is concrete:

1. The agency answers a structured intake about the client and the scope.
2. Claude Sonnet 4.6 drafts the proposal — pricing structure, scope sections, deliverables, terms.
3. Claude Haiku 4.5 rewrites the draft in the agency's voice (each tenant has voice profile data persisted).
4. The agency edits in a TipTap-based rich editor, drops a logo, hits send.
5. The client receives a sealed-PDF proposal with audit trail (who viewed, when, IP, e-signature on accept).
6. On accept, Stripe Connect handles payment and triggers HubSpot CRM sync.

It's live. Click wintura.ai and book the demo — public proposal samples are at /samples. The code is closed-source production; the architecture is what I'm describing here.

The Stack (every dependency named + version-pinned)

Verified against /Users/alvilika/WebstormProjects/brevvo/package.json on May 22 2026. No invented versions. No "modern AI stack" hand-waving.

Hosting splits: Vercel for the Next.js app, Railway for the Puppeteer PDF microservice (separating the heavy render concern from the request-response cycle).

Multi-Tenancy: The Hardest Part

Multi-tenant data isolation is the single hardest production concern a Bolt or Lovable export doesn't ship. Generated code defaults to single-tenant, and even when you prompt for multi-tenancy, the isolation lives at the application layer — one buggy query away from a cross-tenant data leak.

Wintura enforces tenant boundaries at the database layer. Every table that holds tenant data has a tenant_id column. The session middleware resolves tenant_id from the authenticated NextAuth session at the edge and threads it into a request-scoped context. All database access goes through /lib/db, never inline in route handlers. Each query in /lib/db is structured so the tenant_id parameter is required at the function signature — TypeScript strict mode enforces it at compile time.

There is no inline SQL in route handlers. There are no barrel files re-exporting database functions, so the import graph stays explicit. There is no scenario where a developer can write SELECT * FROM proposals without going through a function that explicitly takes tenantId: string. This is the same architectural rule Soatech now installs as part of the Production Lift — replacing the application-layer isolation an AI-generated prototype ships with.

The other half of multi-tenancy is the auth flow itself. NextAuth v5 (still in beta as of May 2026) handles email/password and magic-link sign-in. The session callback resolves the user's active tenant, including tenants the user has been invited to but hasn't accepted yet. The cookie domain is locked to the apex (wintura.ai) so the cookie can't leak across subdomains. Session tokens rotate on privilege changes (role upgrade, tenant switch).

None of this is unusual for production B2B SaaS. All of it is missing from a vibe-coded prototype.

The AI Pipeline (Sonnet for structure, Haiku for voice)

The proposal generation is a two-stage Claude chain, not a single call. Sonnet 4.6 takes the structured intake (client name, scope items, pricing tiers, terms) and produces a draft proposal with sections, headers, and a budget table. Haiku 4.5 then takes that draft and rewrites it in the tenant's voice profile — each agency has a saved voice (formal vs casual, dense vs concise, industry-specific vocabulary).

Why two stages: Sonnet is excellent at structure and pricing logic but its default voice is generic-helpful. Haiku at 4.5 is cheap and fast enough to rewrite paragraphs into the agency's tone in seconds. Splitting the concerns means I can swap either model without rewriting the whole pipeline — when Anthropic ships a new Haiku, I update one prompt file.

All prompts live in /lib/ai/prompts/. None of them are inlined into components or route handlers — that was an explicit architectural rule from day one, because prompt drift is the kind of bug you can't catch in code review when prompts are scattered across the codebase.

The Anthropic SDK call goes through /lib/ai/chain.ts, which adds retry-with-backoff, request-id logging, and PostHog event capture. Every Claude call is logged to PostHog with anonymized payload size and latency — useful for cost tracking and for spotting prompt regressions.

I considered OpenAI's structured outputs and Gemini 2.5 Pro for this pipeline. Two factors made Claude the winner: (1) Sonnet 4.6's instruction following on long structured documents is consistently sharper than the alternatives, and (2) Anthropic's Claude API docs have been the most stable across major version bumps. Production AI work needs API stability more than benchmark leadership.

Sealed PDF Audit Trail (the proposal proof)

Generic AI proposal tools produce a downloadable PDF and call it done. That PDF is throwaway — there's no record of whether the client actually read it, no signature provenance, no audit trail.

Wintura's proposals are sealed PDFs with an audit trail. pdf-lib generates the document structure (cover page, scope sections, pricing table, terms, signature block). The Railway Puppeteer microservice renders the final visual layer — Puppeteer is overkill for plain HTML→PDF, but it's the right tool when proposals need to match a tenant's brand exactly (custom fonts, logos, gradient headers).

The audit trail records every view event: timestamp, IP (with consent), user-agent, viewport, scroll depth. When a client clicks "Accept," they sign with a typed-name + check-box-consent flow that's logged with a SHA-256 hash of the proposal content. The signature is bound to the document hash — if the proposal content changes after signing, the signature record shows it was for a different document.

This matters for service agencies because their entire revenue is built on signed scope. A proposal that says "5 page rebuild" can be re-litigated three months later when the client claims they expected "5 sections." The sealed-PDF audit trail with content hash makes that argument unwinnable. It's the kind of feature that takes a weekend to ship but only matters to the few buyers it matters to — exactly the architecture-decision pattern I now help Soatech clients navigate at Blueprint kickoff.

Why 24 e2e Test Files for a Solo Project

The standard objection: 24 Playwright spec files is overkill for a solo founder project. The standard answer: it's exactly the right number, and the reason becomes clear the third time a refactor breaks a flow you forgot existed.

The test matrix is structured by concern, not by feature:

• Flow specs: flows-proposal.spec.ts, flows-onboarding.spec.ts, flows-invoice.spec.ts, flows-settings.spec.ts — end-to-end happy paths across the full user journey.
• Surface specs: proposal-flow.spec.ts, proposal-invoice-flows.spec.ts, invoice-flow.spec.ts, full-proposal-flow.spec.ts, estimates.spec.ts, settings.spec.ts, dashboard.spec.ts, analytics.spec.ts — surface-level interactions on each major page.
• Auth + onboarding: auth.spec.ts, onboarding.spec.ts — separate from flow specs because auth regressions are the most expensive.
• Visual + a11y: visual-audit.spec.ts, audit-a11y.spec.ts, visual-audit-themes.spec.ts, visual-audit-live.spec.ts, mobile.spec.ts, public-pages.spec.ts — accessibility (axe-core 4.11) and visual regression across mobile, tablet, desktop viewports.
• API + external: api.spec.ts, outbound-demo-api.spec.ts, outbound-demo-page.spec.ts — API contract surface, including outbound demo flows that drive marketing-site conversions.
• Live smoke: live-flows.spec.ts against the production URL on every deploy — catches infrastructure-layer regressions Vercel won't surface (DNS, CDN, third-party API outages).

The Playwright config defines explicit projects per viewport so a single npm test runs the full matrix. The trade-off is honest: tests cost time to write and maintain. The alternative — shipping a regression that costs a client trust — costs more. For a solo founder building B2B SaaS, the test suite IS the QA team.

The Production Hardening That Bolt Skips

Reading what's in Wintura makes the gap with AI-app-builder output concrete. Everything below ships in Wintura; none of it ships out-of-the-box from a Bolt, Lovable, v0, or Cursor export:

• Multi-tenant Row-Level Security enforced at the /lib/db layer (every query function requires tenantId parameter at compile time)
• NextAuth v5 magic-link + password with apex-locked cookie + session rotation on privilege change
• HubSpot CRM lead sync with deal-stage updates on proposal-accept
• Stripe Connect with payout schedules + webhook signature verification
• Cloudflare R2 signed-URL document storage with expiry
• 24 e2e tests including axe-core a11y across mobile / tablet / desktop viewports
• pdf-lib sealed audit-trail PDFs with content-hash signature binding
• Railway Puppeteer microservice (PDF rendering off the main request path)
• Vercel Analytics + Speed Insights + PostHog with typed event facade
• React Compiler enabled (production-grade React 19.2.3 — auto-memoization)
• Tailwind v4 CSS-first design tokens (single source of truth: /brand/design-tokens.json)
• Linear-grade motion: cubic-bezier(0.16, 1, 0.3, 1), Y + opacity + blur only, prefers-reduced-motion honored
• Const-as-const enums (const X = {} as const — never TypeScript enum, which produces runtime overhead)
• null over undefined for intentionally empty values (consistent JSON serialization)
• No barrel files (explicit import graph — refactoring stays predictable)

This list is what production-grade actually means in 2026. It's also what Soatech's Production Lift (€3,500, 1 week) installs onto a Bolt/Lovable prototype — without rebuilding from scratch.

What I Learned (and why this is now Soatech's playbook)

The honest reflection: the hardest 30% of the build wasn't the AI pipeline or the multi-tenancy. It was the boring parts — making the auth flow handle every edge case, making the PDF render survive every weird character a client might paste into a proposal, making the accessibility tests not flake. Those are the parts AI app builders never finish.

Wintura was the proof-of-concept for what Soatech now offers. The playbook is the same:

• Architect-led: one senior engineer makes the architectural decisions and reviews every PR. No junior pass-through, no contractor handoffs.
• AI-accelerated: Claude generates the boilerplate. The architect designs the rails the boilerplate fits within. AI never makes architectural decisions.
• Production from week one: the test suite, the multi-tenant boundaries, the security headers, the audit trails — all of it is week-one work, not a "we'll harden it later" task.

If you have a Bolt or Lovable prototype that needs production, that's exactly what the Production Lift (€3,500, 1 week) is for. If you're starting clean and want to ship a V1 in under 30 days, that's the MVP Sprint (from €9,500). If you want to see the playbook before committing, the Technical Blueprint (€2,000, 5 days) walks through the architecture for your specific build.

The Wintura case study isn't aspirational. It's verifiable — go look at wintura.ai, use the demo, see the samples. The same engineer who shipped it is the architect on every Soatech engagement.

Frequently asked questions

What stack did Wintura use?

Next.js 16.1.6 (App Router), React 19.2.3 with the React Compiler, TypeScript 5.x strict, Tailwind CSS v4 with CSS-first @theme tokens, NextAuth v5 beta.30 for auth, Neon Postgres (serverless 1.0.2) for the database, Claude Sonnet 4.6 + Haiku 4.5 via the Anthropic SDK 0.78.0, Stripe Connect 20.4.0, TipTap 3.20 for the proposal editor, pdf-lib 1.17.1 with a Railway Puppeteer microservice for sealed PDFs, Cloudflare R2 for document storage, HubSpot API 13.4 for CRM sync, Playwright 1.58.2 plus axe-core 4.11.3 for e2e and accessibility testing, PostHog 1.372 for product analytics.

How long did Wintura take to ship?

Six months from zero to live production at wintura.ai. A comparable B2B SaaS built by a traditional hand-coded agency takes 12 to 15 months by Q2 2026 benchmarks. The 2× velocity comes from AI handling boilerplate generation while the architect (8+ years senior) designs the rails and reviews every PR before merge.

Why Claude over GPT for the AI pipeline?

Two reasons. First, Sonnet 4.6's instruction-following on long structured documents is consistently sharper than GPT-4o or Gemini 2.5 Pro for the kind of multi-section proposal generation Wintura needs. Second, the Anthropic SDK's API stability across major version bumps has been the best in the market — production AI needs stability more than benchmark wins.

Why pay €3,500 for Soatech's Production Lift when Bolt costs $20/mo?

Bolt is excellent for the validation phase — proving your idea works fast. Production Lift is for when you have validation and need to ship to real paying users. The €3,500 buys 1 week of architect-led work installing exactly the production hardening listed in this case study: multi-tenant Row-Level Security, NextAuth-grade auth, e2e tests, security audit, deployment hardening. Bolt and Soatech are complementary, not competing — Bolt builds the prototype, Soatech ships it.

Is Wintura's source code open?

No. Wintura is production-closed-source. The architecture and decisions are documented publicly here (and across Soatech's blog) because the value isn't in the code — it's in the architectural pattern. Anyone can read this case study and implement the same playbook themselves. Soatech's offer is doing it for you, with the same architect who shipped Wintura, in 1 week instead of 6 months.

Can Soatech build something like Wintura for me?

Yes — that's exactly what the MVP Sprint (from €9,500, under 30 days) is for. The flagship build engagement gives you a production V1 using the same playbook described in this case study. Start with the €2,000 Technical Blueprint for a 5-day architecture sprint, then commit to the Sprint.

What's the difference between Production Lift and MVP Sprint?

Production Lift (€3,500, 1 week) takes an existing prototype — usually from Bolt, Lovable, v0, or Cursor — and ships it to production-grade. MVP Sprint (from €9,500, under 30 days) is a clean-slate V1 build with no prototype required. If you have an AI-generated prototype, start with Production Lift. If you're starting from scratch, start with the Blueprint then MVP Sprint.

How does Soatech's architectural rigor scale beyond one founder?

Each Soatech engagement is delivered by an Architect (8+ years senior, on-record). Today that Architect is the founder, Alvi Lika. As the studio grows, additional Architects join the roster — the engagement model and architectural playbook stay identical. You always get the same level of senior review whether your project is the studio's first or its hundredth.

Where is Alvi Lika based and what time zone?

Tirana, Albania (Central European Time / EU). Full overlap with European business hours, 5–6 hour overlap with US East Coast. EU-jurisdiction, GDPR-aligned, EU Standard Contractual Clauses available for data processing agreements.

How can I see Wintura live?

Visit wintura.ai. The public homepage explains the product. Use the live demo at wintura.ai/demo to walk through the proposal flow without signing up. Public proposal samples are at wintura.ai/samples. The whole product is live in production right now.

What if my prototype is in a framework Soatech doesn't list?

Production Lift covers any AI app builder that emits standard React, Next.js, or TypeScript output — Bolt.new, Lovable, v0 by Vercel, Cursor, Replit Agent, Mocha. If your prototype is in another framework or language, book a Blueprint call and we'll scope the path forward.

Technology Stack