Lean AI Platform 2026: 10-Person Team vs $2M Enterprise Build

Q: Is the lean AI platform really enough for a startup with paying customers?

Yes — provided three components are non-negotiable: an evaluation harness, LLM observability, and per-customer cost attribution. With those in place from day one, the rest of the platform components (orchestrator, registry, feature store, gateway, governance suite) can be replaced with the lean equivalents documented in this article without harming product capability or auditability. The startups in our composite dataset operated at production scale with paying enterprise customers using exactly this shape; what they did not have was the coordination and shared-tooling problem that justifies the enterprise versions. The lean platform fails only when the underlying assumptions stop holding — typically when you have multiple internal product teams sharing models, when you cross specific scale thresholds documented per component, or when regulatory pressure forces a formal artefact you do not yet produce.

Q: Why is pgvector listed as the lean choice when dedicated vector databases exist?

Two reasons: operational simplicity and the fact that the migration trajectory across funded startups is overwhelmingly toward pgvector and almost never away. Every additional database is an additional vendor relationship, an additional backup story, and an additional source of consistency bugs at exactly the moment a startup cannot afford them. pgvector handles up to roughly ten million vectors at acceptable latency on a modest Postgres instance, which is more than most startups will see before Series B. Dedicated vector stores like Pinecone, Weaviate, and Qdrant become genuinely better at very large scale or with multi-region requirements — but those triggers fire later than founders typically expect. The trigger to evaluate a dedicated store is when you have measured pgvector and found it insufficient for a specific workload, not when you read about a competitor using one.

Q: Should we adopt a feature store like Feast or Tecton?

Almost certainly not, especially if you are an LLM-first startup. Feature stores solve a coordination problem — multiple teams, multiple models, shared features, train-serve consistency — that startups by definition do not have. Two startups in our dataset adopted Feast or Tecton in their first year; both spent three to four engineer-months on integration and removed the feature store before Series A. If you have classical ML features (lead scoring, churn, recommendations), compute them with materialised views in your application Postgres or with a nightly batch job. The trigger to revisit feature stores is when you have at least three teams shipping ML models that share features and a measured train-serve skew problem hurting model quality; until then, the feature store is solving a problem you do not have.

Q: When should we build a custom inference orchestrator instead of using Modal or Replicate?

Three conditions must hold simultaneously: monthly inference spend exceeds $50,000, you have measured that managed-platform overhead is more than 25% of unit cost, and you have a workload pattern (high-volume embedding, low-latency classification, on-premises deployment) where the optimisation knobs actually matter. Three startups in our dataset attempted custom inference orchestration before all three conditions held; all three abandoned the project within nine months and migrated to managed inference. The total time lost was roughly twenty engineer-months across the three teams — the equivalent of one founding engineer for nearly two years. Custom inference is a powerful tool. It is not a Day-1 tool, and it is not a Day-100 tool for most startups.

Q: What is the smallest viable evaluation harness for a startup?

Promptfoo with fifty hand-crafted prompts and expected outputs, run on every commit, gating merges on regression. Add ten LLM-as-judge prompts for the dimensions that matter most for your product (helpfulness, accuracy, format compliance) with a numeric threshold below which the build fails. Output the scores to an evals/ directory committed to git so you can grep historical scores. Total build time: two days. Total ongoing maintenance: one engineer-day per week. This is enough to catch the prompt regressions that bite teams without one. Graduate to Braintrust, LangSmith eval, or a Pytest-based custom harness when you have more than three production prompts to evaluate in parallel, when you start shipping multi-step agents that need intermediate scoring, or when a customer catches a regression you missed.

Q: How early should we start the SOC 2 process and what tools should we use?

Start when you have your first paying enterprise customer or a credible enterprise prospect in active conversation. Vanta or Drata are both well-suited to startups; the choice between them is largely cosmetic. They provide pre-built controls, automated evidence collection, and templates for the common security questionnaires. SOC 2 Type 1 takes about three months from signing; Type 2 requires an additional six to twelve months of audit period. None of the startups in our dataset reached Series A without at least an active Type 1 process, and most had Type 2 in flight or complete by close. Combine the tooling with a governance/ folder in your repo containing model-risk classification documents, bias evaluation artefacts from your eval harness, and a data flow diagram. That is the lean governance posture; it satisfies the questionnaires and ships the report.

Q: What multi-tenancy model should a B2B AI startup pick?

Row-level isolation with Postgres Row Level Security policies. Every table that holds customer data has a tenant_id column, every query has a WHERE tenant_id filter enforced by RLS policies, and tenant context is set on every request at the API boundary. This is twenty lines of Postgres setup and a hundred lines of middleware. It scales comfortably to hundreds of tenants and is auditable enough to satisfy SOC 2 and most enterprise security questionnaires. Schema-per-tenant and database-per-tenant are sometimes appropriate as upgrades for a small subset of demanding enterprise customers — typically when a healthcare or financial services customer demands physical separation — but those are exceptions handled as extensions to the base architecture, not as a re-architecture. Pick one model, apply it consistently from day one, and only deviate when a specific customer requirement forces the deviation.

Q: What does it cost to operate a lean AI platform at each stage?

Pre-seed: $200-$1,500 per month, mostly model API calls and Postgres, with self-hosted Langfuse adding about $50/month. Seed: $2,000-$12,000 per month as users scale, Postgres graduates to a paid tier with read replica, Vanta or Drata adds $400-$800/month, and Modal or similar managed inference contributes variable cost. Series A: $20,000-$80,000 per month with the platform layer typically representing under 15% of total infrastructure spend; the rest is application-layer inference and serving. By Series A, multi-provider routing has typically shaved 20-40% off model spend if implemented correctly. For comparison, a Fortune 500 AI platform team running the same product complexity typically burns $1.5M-$3M annually — the lean stack delivers equivalent product capability at one-tenth to one-twentieth the cost, not because the engineers are better but because the constraints honestly reflected lead to a smaller correct shape.

Q: What is the single most expensive mistake founders make when building an AI platform?

Skipping evaluation infrastructure and observability because "we will add them when we need them." Both are cheap to add on day one and irreplaceable when missing on day three hundred. Without an eval harness, every prompt change is a guess and every model change is a leap of faith; without observability, cost surprises happen via the monthly bill rather than via the dashboard. The teams in our dataset that wired both on day one shipped faster and slept better; the teams that delayed paid the price exactly when they could least afford it — usually a runaway-cost incident in month four or a quality regression caught by a customer in month six. There is no acceptable version of "we don't have evals yet" past your first paying customer. The second most expensive mistake is over-investing in platform engineering at exactly the moment the company needs to invest in product engineering — usually committed by founders with strong infrastructure backgrounds who instinctively over-build.

Q: How does the lean AI platform compare to your enterprise AI platform blueprint?

The two are designed to map onto each other component by component. The enterprise blueprint (referenced in this article) has eleven discrete capabilities — inference orchestration, model registry, feature store, vector database, evaluation, observability, model gateway, data pipelines, governance, multi-tenancy, FinOps. The lean platform has lean equivalents for the same eleven capabilities, but the equivalents are radically smaller and replace several enterprise components with "skip" or "use the application." This is not because the enterprise blueprint is overbuilt — it is because the enterprise blueprint serves coordination, multi-team scale, and regulatory diversity that startups do not face. When the constraints change (multiple internal teams, multiple regulatory regimes, scale beyond pgvector's comfort zone), the lean platform graduates component by component toward the enterprise shape. The trigger conditions in this article tell you which component graduates next; you almost never graduate them all at once.