The startup dev stack
The dev stack is the set of tools a startup uses to build, ship, and run its product. The decisions span source control, hosting, database, observability, internal tools, and (for AI-native teams) the model and compute layer. Most founders pick the shape of this stack in the first month, and most of them regret at least one choice because they picked for flexibility they did not need or simplicity they outgrew.
This guide walks through each layer in the order founders typically adopt it, explains when to buy and when to wait, and links to the current verified programs on FounderDeals that cover each piece. The discipline worth practicing here is almost the opposite of the one on the marketing side: resist the urge to build the mature version of the stack before the product actually needs it.
What most founders need first
The minimum-viable year-one dev stack, in adoption order, before the product has real users.
Dev-stack mistakes are expensive because they compound into hiring decisions and architecture choices. Picking AWS when Vercel would have worked locks you into operational patterns a small team cannot maintain efficiently. Picking Kubernetes before you have the load that justifies it is a tax on every subsequent deploy. The founders who get this right share one discipline: simplest defensible choice per layer, revisited only when the product actively demands more.
A practical sequence for year one:
- Week 1: GitHub, a deployment platform (Vercel for web-first, a hyperscaler for custom infra), a managed database (Supabase or Neon), and Sentry for error tracking. Every one of these is free or near-free at startup stage.
- Week 2 for AI-native products: a closed-weight model provider (OpenAI or Anthropic). This is typically before the open-weight or fine-tuning layers because closed-weight APIs are fastest to activate.
- Month 1-3: Linear for issue tracking if the team has more than two engineers. Product analytics belong in the marketing stack rather than the dev stack, but the decision lives in the same week.
- Month 3-6: Retool if you have an ops or support hire who needs admin tools. Before then, SQL queries and spreadsheets are typically faster than building a Retool app for a one-off workflow.
- Month 6+: Datadog when you have multiple services, real production traffic, and the beginnings of on-call rotations. Sentry alone covers most teams' needs for longer than founders expect.
Everything below is organized by layer with callouts that sanity-check whether you actually need a tool yet. Use the "when you need it" line as a gating question before buying.
Development platform
The development platform is where code lives, gets reviewed, and ships. For almost every startup in this decade the answer is GitHub, with Linear or a similar tool handling the issue-tracking and planning layer on top. These two decisions are low-risk and rarely revisited; most teams pick them in week one and stay there.
When you need it
Day zero. You commit the first line of code to a real remote, not a local folder, and you set up issue tracking the same week so the backlog has a home.
What to look for
- Whether the platform covers code hosting, pull-request review, CI, and packages in one surface or whether you will stitch tools together.
- Access controls: SSO, audit logs, and role-based permissions start mattering once the team crosses a handful of engineers, not before.
- AI assistance: Copilot or a similar in-editor assistant is now table stakes; the question is what plan tier it comes on.
- Integration with your deployment platform, observability tool, and issue tracker; the graph of who opened the PR, what it changed, and what it broke should be one click each direction.
Hosting and deployment
Where the product actually runs is the decision with the most long-term blast radius. Most web-first startups now default to a PaaS that handles deploys, edge, and scaling as a single surface (Vercel, Cloudflare); teams with custom infrastructure needs or who want credit-heavy programs go to a hyperscaler (AWS, Google Cloud, Azure). The decision shapes hiring, architecture, and the cost of leaving later.
When you need it
Week one. You cannot ship a product without somewhere to host it. Start with the simplest defensible choice and only adopt complexity when the product actually demands it.
What to look for
- Whether the platform is a PaaS (deploys, edge, and scaling as one surface) or a hyperscaler (maximum flexibility, steeper operational overhead).
- Startup credit size at your current stage; hyperscaler programs tend to offer the largest headline numbers but require more setup work to use well.
- Graduation cost: what your monthly bill looks like the day after the credit window ends.
- Edge and global distribution: how the platform handles multi-region latency, DDoS protection, and caching once you have international users.
Programs covering this layer
- Vercelfrontend PaaS with edge, preview deploys, and first-class Next.js support
- Cloudflareedge compute, Workers, R2 storage, and the full security and DNS stack
- AWS Activatelargest hyperscaler credit programs, best when you need full infrastructure control
- Google for Startups CloudGCP credits plus AI service access, strong fit for AI-native teams
- Microsoft for Startups Founders HubAzure credits and Microsoft 365 access, bundled with Azure OpenAI credit
Database and backend
The database is the second-most consequential infrastructure decision. Most early-stage startups pick a managed Postgres platform rather than running their own; the choice sits between a backend-as-a-service (auth, storage, and realtime bundled with Postgres) and a pure serverless Postgres host. MongoDB remains the canonical pick for document-first workloads where schema flexibility is genuinely the primary concern.
When you need it
Week one, before the first production write. Use a managed service; self-hosting a database in year one is a distraction that pays off only for teams with deep ops experience and regulatory constraints.
What to look for
- Whether you want a bundle (Supabase: Postgres + auth + storage + realtime) or pure serverless Postgres (Neon) with auth and storage layers you bring yourself.
- Branching and preview-environment support; database branches make migrations and preview deploys dramatically less painful.
- Scale-to-zero billing and how the free tier actually works in production.
- Document vs relational: Postgres is the right default for most apps; MongoDB shines when you genuinely need schemaless document storage.
Observability and debugging
Observability is where most early-stage teams under-invest. The two practical decisions are error tracking (what broke, for which user, in what code path) and full observability (logs, metrics, traces across services). Most small teams need error tracking from day one and can defer full observability until they have multiple services, real traffic, and the beginnings of on-call rotations.
When you need it
Error tracking: day one. Full observability: when you have more than one service in production, or when you have to debug something that crosses service boundaries more than once a week.
What to look for
- SDK coverage across your language and framework stack; a tool with great Node support and flaky Python support is not a match if your AI workloads are Python.
- Free tier or startup program scope; both matter because observability bills scale with traffic and can surprise at the wrong moment.
- Session replay and user-path reconstruction for frontend bugs that only reproduce for one user.
- Alerting surface: which alerts wake up which humans, and how easily you can silence noisy ones.
Internal tools
Internal tools are the admin panels, ops dashboards, and one-off workflows a team builds around its own product. For the first few months, founders handle these through SQL queries and spreadsheets; by the time the team has a customer-support person or an ops hire, a dedicated internal-tools platform pays for itself within the first few workflows it replaces.
When you need it
Month three to six, or the week you make your first non-engineering ops or support hire. Before then, SQL and spreadsheets are typically faster than a Retool app for one-off needs.
What to look for
- How the platform connects to your database, APIs, and third-party sources; internal tools are only as good as the data plumbing underneath them.
- Seat count and free-tier limits; internal-tools platforms price per seat, which starts mattering fast as non-engineering hires multiply.
- Permissions and audit logs; internal tools often touch production data, so role-based access is load-bearing past a handful of users.
- Whether the tool generates React or JavaScript under the hood, or stays in its own visual-editor environment; exit strategy matters for critical workflows.
Programs covering this layer
- Retooldrag-and-drop internal tools on top of your own databases and APIs
AI stack
For AI-native startups the stack is wider than just a model provider. There is a closed-weight inference layer (OpenAI, Anthropic), an open-weight inference and fine-tuning layer (Hugging Face, Together AI, Modal), a training compute layer (hyperscalers via their startup programs, or NVIDIA Inception), and a model-ops layer for experiments and evaluation (Weights & Biases). Most AI teams end up layering two or three of these; the shape depends on whether you are primarily consuming closed-weight models or training and serving open-weight ones.
When you need it
Day one if the product is AI-native. The closed-weight model provider is usually fastest to activate; open-weight and training layers enter the stack once you have a specific model you need to tune, host, or run at scale.
What to look for
- Whether you need closed-weight API access, open-weight hosting, training compute, or all three; most AI teams end up with more than one of these.
- Credit amounts and durations on model-provider programs; these shift frequently and credit size varies significantly by whether you come in through an accelerator.
- Compute platform model: serverless GPU (Modal) vs dedicated GPU instances (hyperscaler) vs managed inference (Together AI, Hugging Face).
- Model-ops tooling: experiment tracking and LLM evaluation start mattering as soon as you fine-tune a model or run meaningful evaluations against production traffic.
Programs covering this layer
- OpenAI Startup Creditsclosed-weight inference credits; fastest path for GPT-family model access
- Anthropic Claude for Startupsclosed-weight credits for the Claude family
- Modalserverless GPU compute for AI inference, fine-tuning, and batch workloads
- Together AIfast inference and fine-tuning for open-source models
- Hugging FaceInference Endpoints and Enterprise Hub for open-weight hosting
- NVIDIA Inceptiontiered benefits program for AI and deep-tech teams, non-dilutive
- Weights & Biasesexperiment tracking (Models) and LLM evaluation (Weave)
What can wait until later
Parts of the mature dev stack founders often copy too early; the actual trigger that justifies each one.
The pressure to match the stack of a Series B startup is specific to engineering and strong. Most of it is premature. A few layers that can safely wait:
- Kubernetes and custom orchestration. Vercel, Cloudflare, or even hyperscaler PaaS options cover early-stage apps without the operational overhead of K8s. Revisit orchestration when you have a real reason: multi-region latency requirements, cost consolidation at scale, or specific compliance controls.
- Full observability (Datadog, Honeycomb, etc.). Sentry alone is usually enough for the first year. Upgrade to full metrics, logs, and traces when the system crosses multi-service complexity and debugging starts taking real time.
- Data warehouse and BI stack. Snowflake, BigQuery, and dbt are powerful but premature until you have real event volume and at least one person whose job is to analyze it. Product analytics in the marketing stack covers most early questions.
- Dedicated feature-flag infrastructure. PostHog or Split are useful once you run real experiments; most year-one teams manage feature flags through a config file or environment variable without meaningful loss.
- Custom CI/CD pipelines. GitHub Actions cover the CI/CD needs of almost every early-stage team. Jenkins, CircleCI at a dedicated tier, and custom build-system work only pay off at a scale early-stage startups have not yet reached.
- Self-hosted anything. Self-hosted databases, self-hosted search, self-hosted queues, self-hosted auth: each of these is a distraction until the managed alternative becomes genuinely expensive or the product's compliance needs demand it.
Common mistakes founders make
The most common dev-stack failure modes we see, each one an instance of optimizing for a future problem instead of the current one.
- Over-engineering before product-market fit. Picking a stack that would work at 10 million users for a product with 10 weekly actives. Every piece of complexity is an ongoing tax on the team's velocity. Pick for now; migrate later when the product's real constraints demand it.
- Rolling your own auth, storage, or email. Supabase auth, S3-compatible storage, and Resend or one of the other transactional email providers cover these better than a small team can. Building your own version is almost always a mistake disguised as control.
- Optimizing AI infrastructure before the model decision stabilizes. Teams sometimes stand up GPU clusters or complex open-weight hosting before they know which model or fine-tune actually works for their use case. The closed-weight providers exist precisely so you can iterate quickly before committing to infrastructure choices.
- Skipping error tracking to save $20 a month. The reason this shows up often is that production errors without error tracking are invisible until a customer complains, which means you discover them the slowest possible way. Sentry's free tier is generous; turn it on week one.
- Building admin tools before you need them. Retool is powerful, but spending a week building an admin panel for workflows that happen twice a month is a tax on engineering capacity. Adopt internal tools when there is a real non-engineering user doing real repetitive work, not before.
- Mixing development data with production. Running a development branch against the production database is the most preventable data incident there is. Use database branches (Neon, Supabase) or separate managed instances from day one.
The startup dev stack is almost entirely a discipline problem, not a tools problem. The right tool at each layer is mostly legible from the outside; what separates well-executed stacks from stuck ones is whether the founders bought each layer when they needed it, not when they thought a mature company should have it. Pick the simplest defensible tool, adopt the next layer only when the current one hurts, and resist the urge to build the Series B version of the stack before you have the Series B problems.
Frequently asked questions
Common questions founders send us about sequencing the dev stack and when each layer actually becomes necessary.
What do I actually need on day one to ship a product?
Four things: a Git host (GitHub), somewhere to deploy (Vercel for web-first, a hyperscaler for custom infra), a managed database (Supabase or Neon), and error tracking (Sentry). For AI-native products, add a closed-weight model provider (OpenAI or Anthropic) on day one. Everything else can genuinely wait until the product has users.
Should I use a hyperscaler or a Vercel-style PaaS?
PaaS by default. Vercel or Cloudflare covers 80 percent of early-stage web-first startups and removes the devops overhead that slows you down. Pick a hyperscaler (AWS, GCP, Azure) when you need custom infrastructure, the largest credit headlines matter for your use case (typically training workloads or heavy batch processing), or your team has the operations experience to use the flexibility well.
When do I need Sentry or Datadog?
Sentry on day one. Error tracking costs almost nothing and catches failures you would otherwise hear about through an angry customer. Datadog when you have more than one service in production, or when debugging something that crosses service boundaries happens more than once a week. Many teams run Sentry for the entire first year and add Datadog only during the second.
Managed database versus rolling my own?
Managed, always, in year one. Running your own Postgres or MongoDB in production is a distraction that pays off for teams with deep ops experience and regulatory constraints, not early-stage startups. The time saved running Supabase, Neon, or MongoDB Atlas is better spent on product. Revisit the build-vs-buy calculation only if managed pricing becomes genuinely load-bearing at scale.
How should AI-native startups think about infrastructure?
Decompose the AI stack into four layers: closed-weight inference (OpenAI or Anthropic), open-weight inference and fine-tuning (Together AI, Modal, Hugging Face), training compute (hyperscalers through startup programs, or NVIDIA Inception), and MLOps (Weights & Biases). Most AI startups layer two or three of these rather than picking one. Closed-weight providers are fastest to adopt; the open-weight and training layers enter only when you have a specific model to tune or serve at scale.
How do I avoid building what I should buy?
Three rules. First, never build auth, file storage, or email sending yourself in year one; managed services cover these at quality levels a small team cannot match. Second, default to the simplest defensible hosting choice and only adopt Kubernetes or custom orchestration when the product has real demand for it. Third, if a managed service costs less than one week of engineering time per year, use the managed service. Rebuilding what you could have bought is the most common waste in an early-stage dev stack.
When does my dev stack stop looking like this?
Usually around Series A, or once the team crosses roughly 15 engineers. The shape that changes first is hosting: teams consolidate onto a hyperscaler for cost and flexibility, often with a Kubernetes or similar orchestration layer. Observability deepens from Sentry-only to Sentry plus Datadog. Internal tools expand from Retool to dedicated ops applications. Until you are at that stage, the year-one stack described here is usually correct.