Deterministic work, bounded intelligence
Schedules, compliance, retries, state transitions, and external effects live in deterministic control paths. Models handle interpretation and synthesis inside those boundaries.
Flagship build · Vertical AI operating system
TurnkeyHQ
A company-scale product built from market thesis through deployment, operations, and commercial evolution.
- Role
- Co-founder & Principal Engineer
- Company
- Alchemical AI LLC
- Stage
- Active development · private beta
- Ownership
- Product · engineering · QA · release · operations
The operating problem
Real work crosses system boundaries.
Real-estate operators move constantly between leads, calls, messages, calendars, documents, market data, transactions, and follow-up. Most AI products add another destination. TurnkeyHQ was conceived as the operating layer between those systems: proactive where work is safe to automate, deterministic where guarantees matter, and approval-gated before consequential action.
The difficult part was never a single feature. It was carrying a coherent product through the entire lifecycle—product definition, architecture, implementation, integrations, tenant safety, release machinery, production recovery, unit economics, and continuous evolution.
End-to-end ownership
The lifecycle is the case study.
- 01
Market thesis
Real-estate businesses need an operating layer that can act across communications, CRM, market work, and transactions—not another isolated chatbot.
- 02
Product system
A command center, deterministic workflows, agent skills, persistent memory, integrations, and an application surface built around the work operators already do.
- 03
Trust boundaries
Tenant isolation, approval gates, consent enforcement, quiet hours, suppression rules, cost controls, and explicit boundaries around consequential external actions.
- 04
Release engineering
Reviewed release PRs, semver artifacts, evidence gates, signed images, and a blocking staging canary before production deployment.
- 05
Production operations
Health verification, tenant provisioning, version checks, backup, rollback, and split-fleet detection across shared and tenant-specific planes.
- 06
Commercial lifecycle
Packaging, plans, usage credits, checkout, vendor cost governance, onboarding, product documentation, roadmap decisions, and ongoing release evolution.
Repository-backed scope
A product system, not a prototype.
Structural measures from the current codebase. They show engineering scope, not customer adoption or universal feature enablement.
- 14composed services
- Shared application services plus tenant-specific runtime planes
- 9buildable images
- Independently built and versioned first-party services
- 171SQL migrations
- Deterministic evolution of the production data model
- 244API routes
- Business, orchestration, integration, and operational interfaces
- 73dashboard pages
- A broad operator-facing product surface
- 75agent skills
- Reusable capabilities composed into higher-level work
Product architecture
Two planes, one operating contract.
The deterministic plane owns schedules, workflow state, approvals, compliance, idempotency, and external effects. The bounded agent plane interprets requests, assembles context, selects tools, and synthesizes outputs inside those controls.
ChatEmailSMSVoiceWebhooks
authenticated tenant context
Deterministic planeWorkflows · approvals · compliance · jobs
Bounded agent planeContext · reasoning · tools · synthesis
versioned service boundary
APIDashboardWorkersModel router
RLS + explicit tenant filters
PostgreSQL · tenant runtimes · secrets · audit trail
Load-bearing decisions
What makes the system operable.
Isolation is a system property
Tenant identity scopes reads, writes, jobs, cache keys, secrets, and runtime configuration. Isolation is enforced across application and database boundaries rather than inferred from prompts.
Production evidence travels with the release
Release metadata, validation evidence, candidate images, staging verification, and production tags form one traceable chain. A deploy is not healthy merely because a command exited successfully.
Economics belong in the architecture
Usage credits, per-tenant budgets, vendor caps, model routing, and kill switches make cost behavior visible and governable instead of treating margin as a later finance problem.
Release engineering & Production operations
The path to production is part of the product.
Every production release follows a traceable chain from reviewed change to tagged artifact, candidate verification, staging canary, deployment, and post-deploy health. Recovery is designed in: version drift is visible, split fleets are rejected, and rollback targets immutable artifacts.
- 01Reviewed release PRChange, rationale, validation, rollback
- 02Evidence-bound semver tagRelease identity tied to verified source
- 03Built and signed imagesNine independently versioned services
- 04Blocking staging canaryDisposable tenant through authenticated readiness
- 05Production deploy and verifyCore and tenant planes converge on one tag
- 06Health, backup, rollbackOperability continues after release
Commercial lifecycle
Engineering the business boundary.
Product ownership includes how capability is packaged and paid for. TurnkeyHQ includes plan tiers, usage credits, checkout, per-tenant budget controls, vendor cost accounting, onboarding, feature boundaries, and operational documentation. The goal is not maximum machinery; it is a product whose cost, risk, and customer promises remain legible as it changes.
Claim boundary
TurnkeyHQ is in active development and private beta. Structural counts describe the current repository; individual capabilities may be internal, tenant-allowlisted, staged, or still moving through the roadmap. This case study demonstrates product and operating ownership—not customer count, revenue, or universal deployment.
Product reference