Back to work

AI/SaaS / 2024–Present / Live in production

Sellavie AI

Multi-tenant conversational commerce infrastructure connecting social messaging, business knowledge, guarded AI, human handoff, orders, billing, analytics, and operations.

Role

Co-founder, Sellavie LTD / Full-stack developer, Sellavie AI

Organisation

Sellavie LTD

Disciplines

AI Integration / Backend Systems / Full-Stack

Status

Live in production

This project is private because it is an actively deployed commercial SaaS platform.

Sellavie AI preview

What this system solves

Businesses lose revenue when social enquiries are answered late, business context is fragmented, and follow-through depends on manual coordination. Automating replies alone is not enough: the platform must preserve business boundaries, understand catalogue and policy context, hand conversations to people, and keep commercial actions predictable.

System overview

I build Sellavie AI across channel ingestion, business-context resolution, conversation state, AI orchestration, catalogue knowledge, human takeover, commerce, subscriptions, reporting, web and mobile surfaces, compliance, deployment, and reliability. Generated language is separated from deterministic actions that change orders, payments, access, or subscription state.

Architecture

System flow

WebhookTenantStateAI + GuardrailsAction
  • A multi-tenant backend coordinates accounts, business context, connected channels, conversations, AI orchestration, commerce, billing, reporting, and administration.
  • Inbound customer events are resolved to the correct business context before AI or commerce processing begins.
  • AI requests combine business knowledge, catalogue state, recent context, policy rules, and deterministic guardrails behind a provider boundary.
  • Customer-visible text and server-side actions are separate outputs; generated language cannot directly alter orders, billing, access, or integrations.
  • Business-scoped records and role checks keep owners, team members, dashboards, integrations, and operational queues aligned.
  • Provider events are reconciled with internal state before sensitive commerce or subscription outcomes change.
  • Background work handles notifications, reports, scheduled communication, and documents without blocking the main customer-response path.

Engineering decisions

AI writes language; domain services perform actions

A model can interpret intent and draft a response, but order, payment, billing, account, and integration changes pass through deterministic services with their own validation and authorisation.

Business context comes before intelligence

The connected business, authorised account, catalogue, settings, and conversation state are resolved before building an AI request. Generation is never used as a substitute for tenancy.

Human takeover is a durable workflow

Handoff includes pause, acknowledgement, assignment, notes, follow-up expectations, and resolution so the business can operate the conversation after automation stops.

Provider failure is expected

Stable internal contracts, bounded retries, fallbacks, and operational visibility prevent one external service failure from corrupting the wider workflow.

What I built

  • Co-founded the company and translated the product proposition into its technical and operational architecture.
  • Built backend services, the business dashboard, administrative surface, mobile application, and shared workflows.
  • Implemented inbound social-event handling, business-context resolution, conversation state, guarded AI responses, and outbound delivery.
  • Developed catalogue, business knowledge, bookings, customers, handoffs, orders, invoices, notifications, analytics, and team collaboration.
  • Built subscription lifecycle, plan limits, renewal recovery, promotional access, usage reporting, and administrative controls.
  • Led provider integration, deployment, failure investigation, production hardening, and staged modularisation.

Engineering highlights

  • Built deterministic business and integration routing before AI generation.
  • Created catalogue-recovery, purchase-stage, variant, shipping, booking, business-hours, and handoff guardrails.
  • Modelled pause, manual reply, acknowledgement, assignment, follow-up, and resolution as durable handoff states.
  • Added reviewable AI learning flows rather than automatically promoting every correction.
  • Built provider fallback, shared subscription lifecycle rules, audit visibility, usage monitoring, and launch-readiness tooling.

Validation and results

  • Validated onboarding, account verification, channel setup, catalogue configuration, and live conversation handling.
  • Exercised event verification, duplicate delivery, business routing, provider failure, fallback response, and outbound delivery paths.
  • Tested purchase, variant, shipping, booking, invoice, handoff, and manual-reply behaviour around AI conversation.
  • Validated subscription checkout, renewal recovery, expiry, downgrade, promotional access, and plan-limit enforcement.
  • Reviewed owner and team-member boundaries, compliance flows, account lifecycle, backend tests, frontend builds, and live diagnostics.

Limitations

  • Customer, conversion, revenue, prompt, provider, and business-specific metrics are intentionally not disclosed.
  • Channel capability remains subject to external platform review, policy, permissions, and availability.
  • The codebase is being modularised in stages while production behaviour remains stable.

What would come next

  • Continue extracting focused domain modules while preserving live behaviour.
  • Expand conversation-quality review and business insight using operating data.
  • Move more cache, queue, and data workloads to distributed services as scale requires.

Security and privacy

  • Inbound platform events are validated before downstream processing.
  • Business data and integrations are scoped to business and role context.
  • Web, native, administrative, and provider paths use separate trust boundaries.
  • Sensitive configuration is protected and omitted from ordinary client responses.
  • Public copy omits internal routes, schemas, prompts, credentials, thresholds, provider configuration, and incident procedures.