Bottom Line
Vertiva treats getting a new capability live inside a customer's environment as seriously as building the capability itself. We've developed a seven-workstream playbook — provisioning, identity, data onboarding, security sign-off, pilot-to-GA, operations handoff, and commercials. The playbook is itself a product asset: automated wherever possible, hardened after every engagement, and executed in a fraction of the time for every enterprise thereafter.
This isn't ad hoc project delivery. It's a defined, automated, and repeatable motion — and critically, it's a motion Velastegui Ventures runs on the customer's behalf, not a set of internal capabilities the customer has to build and staff themselves.
One Playbook, Run Every Time
Every rollout executes the same seven workstreams:
| Workstream | What It Covers |
|---|---|
| 1. Provisioning | Stand up the customer environment under the agreed deployment model — shared multi-tenant SaaS, dedicated single-tenant, or BYOC in the customer's own cloud account — via a Terraform/Terragrunt customer stack, an ArgoCD app-of-apps deployment, and externally managed secrets. |
| 2. Identity federation | Wire the customer's identity provider via enterprise SSO connections, mapping identity-provider groups to the platform's org/team/workspace structure and to access-clearance levels. |
| 3. Data onboarding | Connect the customer's document sources, run the initial bulk ingestion, map their data-classification taxonomy, and validate access controls against real data — with a signed BAA as a hard precondition before any regulated data is onboarded. |
| 4. Security & compliance sign-off | Security review and penetration test, data-residency and key-management review, execution of required agreements, sharing of the relevant compliance report, and support for the customer's own audit — run in parallel with provisioning. |
| 5. Pilot → GA | A limited pilot cohort with explicit success criteria, followed by phased expansion to general availability, with change management, admin and end-user training, and a documented rollback plan. |
| 6. Operations handoff | Customer-scoped dashboards and service-level objectives, alerting, on-call and escalation runbooks, support tiers, and an incident process the support team actually owns. |
| 7. Commercials & metering | Usage metering, billing and chargeback, and renewal/expansion hooks — riding on the platform's token-economy tooling once it is available. |
Automation Is the Backbone, Not an Afterthought
The deployment process is explicitly architected to be fully automated end to end, with no hand-patching of production systems. This is already built into the platform's operating model:
- CI/CD by default: GitHub Actions pipelines, containerized services (Docker), and Argo CI/CD drive every deployment, with infrastructure defined and provisioned through Terraform and Terragrunt.
- Staged validation before production: a change moves through a staging/beta environment inside the client's own cloud footprint first, using a mix of automated and manual testing — including forwarding real production prompts to staging for realistic validation without ever writing to production data stores.
- Pilot before general rollout: once a change is validated in staging, it moves to a small pilot client group before reaching full production — the same pilot-to-GA discipline used for entire new capabilities is applied to ordinary changes as well.
- Documentation generated as a byproduct, not a separate task: every rollout produces the milestone tracking, user/system/admin documentation, training materials, and deployment checklists needed to operate the change going forward — deployment isn't considered complete until these exist.
One Motion, Three Deployment Models
Because enterprise customers have different infrastructure and data-residency requirements, the provisioning workstream supports shared multi-tenant SaaS, dedicated single-tenant, and BYOC (deployed directly into the customer's own cloud account) — all through the same Terraform/Terragrunt and ArgoCD automation. Choosing a deployment model is a configuration decision within the standard playbook, not a separate engineering effort, which is what keeps the rollout timeline consistent regardless of which model a given customer requires.
You Don't Have to Hire the Team That Would Otherwise Build This
Standing up a platform like this internally normally means hiring — and retaining — a specific mix of hard-to-find talent: data engineers to build and maintain ingestion pipelines, MLOps/LLMOps engineers to run embedding and inference infrastructure, platform/DevOps engineers to operate Kubernetes and CI/CD, and increasingly specialized roles like vector-database and retrieval-evaluation engineers. This talent is scarce and expensive even for well-funded technology companies, and the ramp-up time before a newly hired team can deliver production-grade results is measured in quarters, not weeks.
Velastegui Ventures' rollout model absorbs that hiring burden entirely. The specialized skill sets required to build, operate, and evolve the platform sit with Velastegui Ventures' team and are reused, refined, and hardened across every customer engagement — rather than being re-recruited, trained, and retained from scratch inside each enterprise that wants the capability.
Velastegui Ventures Handles Data Source Connectivity and Ingestion
Connecting an enterprise's actual data sources — shared drives, SharePoint, Slack, databases via change-data-capture, and other line-of-business systems — and then building and maintaining the ingestion pipelines that keep that data current, is normally a standing internal engineering responsibility, not a one-time project. As part of the Data Onboarding workstream (and continuing through Operations Handoff), Velastegui Ventures does this work directly on the customer's behalf: connector implementation, the initial bulk ingestion and backfill, classification-taxonomy mapping, and the ongoing governed parse-chunk-index pipeline that keeps retrieval current as source documents change. Adding a new data source later is a connector configuration Velastegui Ventures runs, not a new internal engineering project the customer has to staff and manage.
A Partner Network for Cloud Environment Setup
For customers choosing a dedicated or BYOC deployment without a well-architected cloud infrastructure, Velastegui Ventures works with an established partner network that can stand up and configure the underlying AWS, GCP, or Azure environment on the enterprise's behalf — account structure, networking, identity foundations, and security baseline — so the customer does not need dedicated in-house cloud architects just to prepare the environment before the platform lands. This plugs directly into the Provisioning workstream and keeps the rollout timeline consistent regardless of which cloud provider a given customer standardizes on.
Velastegui Ventures Can Build the Data Lakehouse Itself
Beyond the retrieval and search layer, Velastegui Ventures can design and build the enterprise's underlying data lakehouse as a deliverable in its own right — governed ingestion, a medallion-structured storage layout (bronze/silver/gold), catalog governance, and the connector framework that feeds it. This gives an enterprise a proper, AI-ready lakehouse foundation it can also use for its broader analytics and data needs, without needing to build or staff a dedicated data platform team to design and stand it up from scratch.