Independent market-development thesis · 2026
From developer adoption to strategic enterprise revenue.
01 — Executive brief
Modal has earned something most infrastructure companies buy: genuine developer pull. Engineers choose it because defining GPU and CPU workloads in Python, with fast cold starts and pay-for-what-runs billing, removes real friction.
The commercial opportunity is to convert that bottom-up adoption into durable, multi-workload enterprise relationships — without breaking what developers love. That requires a motion that reads product signals, finds the next production workload, proves value on the customer's code, and contracts in a way security and procurement accept.
This brief outlines one practitioner's view of how that motion could be shaped. Where it reasons beyond public information, it says so.
02 — Modal customer proof
The commercial thesis starts with what customers already build. These are customer statements and case-study accounts published by Modal—not independently verified ROI or endorsements of this perspective.
Enterprise AI platform
Modal reports that DoorDash's AI platform team uses Modal to move apps across the company from experiment to production. DoorDash's customer statement also describes building on Modal AI infrastructure as it scales agentic commerce for local businesses.
Discovery angle: connect internal platform adoption to the next customer-facing production workload. [GTM hypothesis]
Reinforcement learning + inference
On Modal's customer page, Cognition states that Modal powers both its reinforcement-learning infrastructure and production inference: millions of sandboxes on one end, real-time serving on the other.
Discovery angle: follow the model lifecycle from RL execution to production serving. [GTM hypothesis]
Agentic execution
Modal's case study describes Ramp Inspect, an internal background coding agent whose sessions run in Modal Sandboxes with full development environments. Ramp had already used Modal for fine-tuning and batch inference.
Discovery angle: an existing compute relationship can expand into agent execution and its security requirements. [GTM hypothesis]
Elastic production inference
In Modal's case study, TypeSafe AI CTO Erik Gafni states that Modal served 1 trillion tokens for Jev within three days of launch, allowing the team to stay focused on shipping rather than managing infrastructure.
Discovery angle: validate launch readiness, burst capacity and serving economics on the customer's model. [GTM hypothesis]
03 — Value-to-revenue motion
Technical selling establishes that the workload works. Commercial selling establishes why it matters, who owns the outcome and how it becomes a durable commitment. Neither substitutes for the other.
01 →
Name the workload, business owner, pain and decision criteria.
02 →
Capture current cost, service quality and delivery time with the customer.
03 →
Run customer code on representative traffic or jobs; compare against the baseline.
04 →
Translate measured outcomes into a funded business priority and agreed risk review.
05 →
Align scope, commitments, governance and procurement with validated demand.
06 →
Use the evidence and internal champions to reach the next workload or team.
Inference: p95 latency, throughput and cost per successful request. Agents: cost per completed task, successful completion rate and environment start time. GPU jobs: job completion time, utilization and cost per run. Business translation: engineering hours required, days to production and the cost of operating the same workload at the same service level.
Agree definitions and the measurement window first; quantify benefits only from observed customer evidence.
04 — Growth thesis
Revenue follows workloads that run every day. A seller's job is to multiply them inside each account.
Expansion requires translating engineering wins into the language of cost, risk and time-to-market for platform, data and finance leaders.
Inference, batch, fine-tuning and agent sandboxes have different shapes. A single programmable surface across them is a durable wedge.
05 — Buyer & use-case segmentation
Model labs, AI application companies, agent startups scaling past seed.
Scaled SaaS, marketplaces, fintech, media and consumer platforms adding AI features.
Financial services, life sciences, healthcare, industrials, retail with established data estates.
06 — Expansion flywheel
Developer adopts for one workload
Usage signal surfaces account
Seller maps adjacent workloads
Validated workload reaches production
Enterprise agreement & governance
New teams onboard via champions
Each turn should leave the developer experience intact. Contracts and governance exist to remove blockers for the next team, not to slow the first one.
07 — Commercial motions
Read usage, team growth, workspace spend velocity and domain patterns to prioritize accounts where adoption is already organic. The seller arrives with context, not a cold pitch.
Map the account's AI workload inventory — inference, training, batch, sandboxes — and identify the next two or three that are compute-constrained or stuck in pilot.
Co-design a bounded production proof: one workload, agreed success metrics (latency, cost per run, time to deploy), measured on the customer's own code.
Translate validated consumption into committed agreements: security review, SSO and governance needs, volume commitments, and procurement alignment.
Land adjacent teams through internal champions, reference architectures and executive business reviews tied to production workloads, not seat counts.
08 — Technical & value narrative
Entry. Land a coding agent or isolated code-execution workload.
Expand. Expand to additional agents, teams and execution volumes; assess VM needs, credential isolation and egress controls.
Entry. Land one custom model endpoint with agreed latency and cost criteria.
Expand. Expand across models, application features and traffic; benchmark real demand and service requirements.
Entry. Land a bounded fine-tuning, training, evaluation or batch job.
Expand. Expand to recurring pipelines and adjacent research or product teams; measure utilization and completion time.
Deploy models as autoscaling endpoints that scale to zero between requests.
On-demand access to a range of GPU types for training, fine-tuning and batch.
Isolated, programmatic environments for running untrusted or agent-generated code.
Capability descriptions summarize Modal's public documentation. See inference , GPU acceleration , Sandboxes and Sidecars . Business outcomes require workload-specific validation.
09 — Ecosystem & partner routes
Let customers apply existing cloud commitments where available, easing procurement.
Bring Modal into delivery work where they own the build but not the infrastructure.
Co-sell with model providers, vector databases, orchestration and observability tools that share the same builders.
Position next to existing warehouse and lakehouse investments as the elastic compute layer for AI.
10 — Alternatives & positioning
Named alternatives are decision context, not a ranking. Each can be a legitimate choice. The comparisons below are evaluation hypotheses: validate workload economics and developer experience on the customer's code, under equivalent security and service requirements.
| Alternative | Decision context | Evaluation hypothesis |
|---|---|---|
| AWS SageMaker / Bedrock | Existing AWS procurement, governance and model-service investments. | Test integration effort, model and code flexibility, and total workload cost within the customer's AWS commitments. |
| GCP Vertex AI | Existing Google Cloud data, ML and governance investments. | Evaluate the path from prototype to production alongside data locality, operational effort and committed spend. |
| Runpod | An alternative for GPU capacity and serverless GPU workloads. | Compare availability, utilization, startup behavior and operational effort on the same workload—not list GPU-hour price alone. |
| Baseten | An alternative for deploying and operating model inference. | Benchmark latency, throughput, model customization and cost per successful request against the actual serving requirements. |
| Self-managed GPU / Kubernetes | Direct infrastructure control and existing platform investment. | Account for idle capacity, orchestration and maintenance alongside control, security and developer experience. |
11 — Market development plan
Days 1–30
Days 31–60
Days 61–90
12 — Enterprise sales scorecard
Targets intentionally omitted — they should be set with leadership against actual baselines.
13 — Commercial market prioritization
Prioritize enterprise and commercial accounts nationwide by production workload potential, organic adoption, consumption trajectory and buying readiness—not by a seller's location. AI-native builders, digital platforms and data-intensive enterprises need different engagement patterns, not geographic limits.
Use remote discovery for reach; invest in field time when it advances a production proof, security alignment or executive decision. Cluster customer visits, partner meetings and focused events around account density in major technology and enterprise hubs. Coverage follows qualified opportunity.
26+ years building and selling enterprise Data & AI — from Netezza and IBM to helping grow a consulting firm to a $40M exit in 2022. Consistent $5M+ annual enterprise software and services results across complex partner and infrastructure sales.
14 — Sources
Next step
I'd welcome the opportunity to compare this perspective with Modal's commercial priorities and explore where my enterprise GTM experience could contribute.