The 5 Technical Decisions That Matter Most at Pre-Seed

At pre-seed, most technical decisions feel equally important. They are not. Most of them are easily reversible later. But five decisions will lock you in for years, either because switching costs are enormous or because the decision shapes everything you build on top of it.

1. Programming language and framework

This is your highest-lock-in decision. Once you have 50,000 lines of code in Python/Django, you are not rewriting in Go. And that is fine, because the language matters less than people think. What matters is: can you hire for it?

Safe choices for SaaS startups in 2025: TypeScript/Node.js (largest hiring pool, full-stack capability), Python/Django or FastAPI (strong for data-heavy applications), Ruby on Rails (excellent for rapid prototyping, smaller hiring pool), Go (great for performance-critical systems, smaller hiring pool).

Avoid: Rust (unless you are building systems software), Elixir (tiny hiring pool), and whatever is trending on Hacker News this week. Boring technology is a feature at pre-seed.

2. Database

PostgreSQL. That is the answer for 95% of startups. It handles relational data, JSON data, full-text search, and geospatial queries. It scales further than you think. Companies like Instagram ran on a single PostgreSQL instance until they had millions of users.

Do not use MongoDB unless you have a specific use case that requires a document database (and even then, PostgreSQL is JSONB type probably handles it). Do not use DynamoDB unless you are sure you will never need to query your data in ways you did not anticipate at design time. Do not use multiple databases at pre-seed. One PostgreSQL instance is enough.

3. Cloud provider

AWS or GCP. Both offer startup credit programs ($5,000-$100,000 in credits). Both are excellent. AWS has more services, better documentation, and a larger ecosystem. GCP has a better developer experience, stronger data/ML tools, and simpler pricing.

Pick one and commit. Multi-cloud at pre-seed is a waste of engineering time. You can always add a second cloud later if a specific service requires it.

Consider: Do your target customers have a cloud preference? If you are selling to enterprises that are mostly on AWS, being on AWS simplifies network peering, data residency conversations, and marketplace listings.

4. Authentication architecture

Build on a third-party auth provider from day one: Auth0, Clerk, Supabase Auth, or Firebase Auth. Do not build your own authentication system. It is more complex than it looks, and getting it wrong creates security vulnerabilities that are hard to fix later.

Your auth provider should support: email/password, social login (Google at minimum), MFA, and SSO via SAML/OIDC (you will need this for enterprise customers).

The auth decision matters because it touches every part of your application. Switching auth providers after launch requires migrating user credentials, updating every API endpoint, and potentially forcing users to reset their passwords. This is a migration you do not want to do.

5. Multi-tenancy model

If you are building a SaaS product, decide early how you will separate customer data:

• Shared database, shared schema: All customers in the same tables, separated by a tenant_id column. Cheapest to operate, easiest to build. Works for most startups. This is the right default.
• Shared database, separate schemas: Each customer gets their own database schema. More isolation, more operational complexity.
• Separate databases: Each customer gets their own database. Maximum isolation, maximum cost and complexity. Only use this if you have regulatory requirements that demand physical data separation.

The multi-tenancy model affects your database design, your deployment architecture, your backup strategy, and your data migration tooling. Changing it after you have 100 customers is a major project.

For most pre-seed startups: shared database, shared schema with tenant_id on every table. It is simple, it is cheap, and it scales further than you think.