The Pre-Seed Stack: What to Build Yourself, What to Buy, What to Skip Entirely

The first engineering decision at most startups is made wrong. Not because the founders are inexperienced, but because the framing is off. "What should we build?" is the wrong question. The right question is: what is the smallest set of things we must build to prove the hypothesis, and what does building anything else actually cost us?

I have co-founded four companies and served as fractional CTO for more than twenty SaaS and SMB startups from pre-seed through Series A. The pattern I see most often is the same: a founding team, usually technical, spends the first three months building infrastructure that a $49/month SaaS would have covered, while leaving the actual differentiated problem barely touched.

This article is the decision framework I now hand to every new founding team on day one.

The Boring Reality

At pre-seed, your time is the only non-renewable resource. You have roughly six to eighteen months before you need to raise or reach profitability. Every hour spent building something you could have purchased is an hour not spent on the core loop: build, learn, iterate.

The math is usually not close. A mid-level engineer costs a startup approximately $8,000 to $12,000 per month all-in (salary, benefits, equity at fair market, recruiting cost amortized). If you spend four weeks building an auth system, you have spent roughly $10,000 of engineering time to avoid a $25/month SaaS. That is a 400:1 ratio against you.

The counterargument I hear most often is control: "We do not want to be dependent on a vendor." This is a Series B concern being applied pre-product. You have no users. Vendor lock-in is not your constraint. Proving that someone will pay for your thing is the constraint.

The Decision Framework

Before you categorize anything, run it through this three-question filter:

1. Does this directly encode the insight that makes your startup worth building? If yes, build it yourself. This is your moat.
2. Is this table-stakes infrastructure that dozens of companies sell well? If yes, buy it.
3. Is this something that only matters at scale you have not reached and may never reach? If yes, skip it entirely.

Most decisions fall cleanly into one of these buckets. The hard cases are in the middle, where a technical founder has an opinion about doing it better than the vendor. The right response to that opinion, before you have product-market fit: noted, and skipped for now.

What to Build

The rule is narrow: build the thing that is the product. Everything else is a candidate for buying or skipping.

Your core domain model. The data structures, business logic, and workflow engine specific to your problem. If you are building a B2B tool for property managers, the lease abstraction, the payment-schedule logic, and the maintenance-request state machine live here. No SaaS sells this.

Your differentiating UI surface. If you are competing on experience (not just features), the interface that directly demonstrates that differentiation needs to be yours. Do not template it from a generic component library if the interaction model is the hypothesis.

Your integration layer (when integrations are the product). If your startup's value is that it connects two systems that do not talk to each other, the integration logic is the product. Build it.

That list is deliberately short. At pre-seed, most teams that think they need to build six things actually only need to build one or two.

What to Buy

The buy column is long. Here is the version I use with every founding team:

Combined cost for the full stack above: roughly $100 to $200 per month for most pre-seed usage levels. That is less than two days of an engineer's time.

The Stripe objection is worth addressing directly. Yes, the fees look significant at scale. At pre-seed you have no scale. If you are spending engineering time building a payment gateway integration instead of learning whether your pricing model is correct, you have confused a future problem for a current one.

What to Skip Entirely

This column is where I see the most variance. Technical founders often want to build things in this category because they are interesting, not because they are necessary.

Data warehouse and BI tooling. You do not have enough data yet for a warehouse to matter. Export to Google Sheets. Return to this at $1M ARR.

Custom marketing automation. Loops, Customer.io, or even a simple Resend sequence covers 95% of pre-seed lifecycle email needs. Do not build your own.

Self-hosted LLM infrastructure. If your product uses AI, call the OpenAI or Anthropic API. The economics of self-hosted inference do not favor you until you have predictable, high-volume workloads. At pre-seed you have neither.

Customer support platform. You should be doing support yourself via email or Intercom's free tier. If you need a ticketing system before you have fifty customers, something else has gone wrong.

Any form of custom infrastructure orchestration. Use Railway, Render, or Fly.io. Kubernetes is not your problem right now.

What I Got Wrong

In my first company, I built our own authentication and user-management system because I was convinced we would need fine-grained permissions that off-the-shelf tools could not support. We spent six weeks on it. We shipped to our first five customers and discovered they did not care about permissions at all. The feature that drove conversion was a one-click CSV import we had de-prioritized to make room for auth.

I lost six weeks and validated nothing about the actual business. The lesson: your technical intuitions about what you will need are not evidence. Treat them like hypotheses and validate them cheaply.

The second mistake: I judged the quality of our pre-seed quarter by the elegance of the infrastructure we had built. Clean code, well-tested auth, a beautiful deployment pipeline. Zero paying users. Engineering quality and business progress are not the same metric.

When NOT to Do This

There are legitimate cases to build more than usual at pre-seed.

Regulated industries. Healthcare (HIPAA), finance (SOC 2 required by the first enterprise customer), or defense. Compliance constraints sometimes require custom infrastructure sooner than the default playbook suggests.

Deep tech. If your startup is the infrastructure: a novel database engine, hardware, a proprietary ML model trained on a unique dataset. The build column is larger by definition.

Technical differentiation is the product. A small number of startups genuinely compete on infrastructure performance. If latency or throughput is the core thesis and you can demonstrate it cheaply, building lower in the stack earlier may be justified.

For everyone else, the buy and skip columns are longer than you think.

The Annotated Checklist

Before starting any engineering work, run this check:

# Pre-Seed Engineering Decision Checklist
decision:
  is_core_domain_logic: false        # If true: strong candidate for build
  solvable_by_saas_under_50_per_month: true  # If true: buy it now
  only_matters_at_scale: false       # If true: skip it
  building_because_interesting: false  # If true: honest red flag
  past_500k_arr: false               # If false: skip all data-infra scaling work

The best version of the pre-seed stack is boring. The differentiation lives in your domain logic, not your infrastructure choices. Every hour you spend building the boring parts is an hour you are not spending on the interesting parts, and the interesting parts are the only thing that determines whether you survive the next eighteen months.