SaaS Architecture in Cloud Computing: What to Build, What to Rent

SaaS architecture in cloud computing is less about choosing a vendor and more about defining which cloud primitives you’ll rent as commodities and which you’ll build to encode your product’s unique value. Get that split wrong, and you’ll either drown in undifferentiated overhead or lock yourself into proprietary APIs that choke your ability to evolve.

When we guide SaaS teams through this at techpotions, we start with a build‑vs‑rent audit of their data, async processing, auth, and intelligence layers. The ReadyShortlist platform — a two‑sided marketplace that vets tech talent and delivers interview‑ready shortlists in 72 hours — is a working proof of what happens when you rent the undifferentiated heavy lifting and build only the capabilities that move the needle. Here’s the litmus test we use, component by component.

SaaS Architecture in Cloud Computing: The Build-or-Rent Litmus Test

Rent every piece of infrastructure that isn’t your product’s secret sauce. Build the logic that interprets, orchestrates, and differentiates. The table below places the core building blocks of a modern SaaS on the rent/build spectrum, anchored by the decisions we made for ReadyShortlist.

The Data Foundation: Managed Postgres and Object Storage

Managed Postgres

Rent it — always. A managed Postgres (AWS RDS, Google Cloud SQL, Neon, Supabase) handles backups, replicas, and failover. The only rule: stay within standard ANSI SQL and the Postgres core. Avoid provider‑specific extensions (e.g., aws_s3 or pg_cron in a proprietary wrapper) that would prevent you from migrating to another managed service later.

ReadyShortlist’s admin portal and candidate funnel rely entirely on a rented Postgres instance. The schema is plain Prisma‑defined tables with foreign keys — no cloud‑native tricks. That portability meant we could develop locally with a container, then point the connection string to a managed instance in production without a single line change.

Object Storage

Rent, but wrap. Object storage is the most commodity of all cloud primitives — any S3‑compatible API will do. However, lock‑in still creeps in through direct SDK calls sprinkled across the codebase. Define one thin interface:

interface ObjectStore {
  put(key: string, body: Buffer, metadata: Record<string, string>): Promise<void>
  get(key: string): Promise<Buffer>
  getSignedUrl(key: string, expiresIn: number): Promise<string>
}

Implement it with AWS S3, MinIO, or Cloudflare R2. If you change clouds later, you swap the implementation, not the business logic. For ReadyShortlist, this abstraction meant we could test resume uploads with MinIO locally and run production on S3 without any dependency spread.

Queues, Cron, and Email: Renting the Asynchronous Backbone

Queues

Rent the conduit, own the logic. Managed queues (SQS, Cloud Tasks, Pub/Sub) decouple services without the overhead of managing Redis, RabbitMQ, or Sidekiq. Keep task handlers as plain functions that receive a payload; never import a provider‑specific client inside your domain code. ReadyShortlist’s 5‑point vetting workflow uses a cloud queue to fan out steps — verify skills, run background checks, score via LLM — so that a single vetting job can complete partially even if one external service times out.

Cron Jobs

Rent the scheduler, build the jobs. A cloud scheduler (Cloud Scheduler, EventBridge Scheduler) that hits a secure HTTP endpoint is all you need. The endpoint runs your application code, so the “job” is nothing but a controller action. No cron daemons, no cron‑inside‑Postgres hacks. ReadyShortlist uses scheduled triggers to push digest emails and recalculate LLM eval‑suite scores after model updates.

Transactional Email

Rent it. There is zero reason to run an SMTP server in 2026. ReadyShortlist uses Resend to deliver vetting result notifications, employer reminders, and candidate status updates. This is a solved, commodity problem — rent it without guilt.

Auth: User Sessions Are Easy — Tenant-Scoped Service Accounts Are the Real Gap

The multi‑tenant vs. single‑tenant decision is foundational, but regardless of model, SaaS architecture means stitching tenant awareness through every layer, including identity and data. Most teams rent a user‑session provider (Clerk, Auth0, Firebase Auth) and call it done. Then they hit the problem: what happens when an external system needs to act on behalf of a tenant without a user present?

Two‑sided platforms like ReadyShortlist face this early. An employer wants their internal ATS to push new briefs automatically. The request must be scoped to that employer, not to an individual user’s session token that expires and is tied to a person. The rented auth provider has no concept of “tenant” that survives outside a user login.

The fix: build a tenant‑scoped service account layer — and nothing more.

1. Generate a cryptographically random API key per integration, store its hash alongside tenant_id and a JSON scopes list.
2. Require all machine‑to‑machine endpoints to accept an x-tenant-api-key header.
3. Verify the key on every request and inject req.tenantId.

// Verify tenant-scoped API key middleware
const tenantApiKey = req.headers['x-tenant-api-key'];
if (!tenantApiKey) throw new UnauthorizedError();

const hashedKey = hashApiKey(tenantApiKey);
const record = await db.apiKey.findUnique({ where: { keyHash: hashedKey } });

if (!record || record.disabled) throw new ForbiddenError();

// Attach tenant context and permitted scopes
req.tenantId = record.tenantId;
req.scopes = record.scopes;

This 40‑line addition plugs the most common multi‑tenant auth gap. Once in place, employer integrations submit briefs via API, the LLM screener processes them under that tenant’s identity, and no rented auth provider had to understand the concept of a tenant.

Search and AI: Rent the Index, Build the Evaluator

Full‑Text Search

Rent the index. Algolia, Elastic Cloud, or Typesense host a lightning‑fast search index; all provide relevance tuning and typo‑tolerance out of the box. ReadyShortlist indexes candidates by skill tags, location, and experience level so that an employer can type “React Lahore” and get immediate results. There is no business advantage to building your own inverted index.

Ranking and Evaluation

Build it. The secret sauce is not the raw search — it’s how you rank the results. ReadyShortlist’s rubric‑driven LLM screener ingests a job description, turns it into a structured rubric, scores every candidate per criterion with quoted evidence, and produces a ranked list. That logic is built from scratch; it lives in a Next.js API route with no lock‑in to any search provider. The LLM API is rented, but the evaluation framework — a 380‑case golden set — is entirely owned. That set is re‑run after every prompt or model change to guarantee precision doesn’t silently drift. The result: 84 % precision vs. human shortlists, 6× faster screening per role, and a cold‑start screen that completes in under 30 seconds on Vercel.

Putting It All Together: The ReadyShortlist Validation

The ReadyShortlist platform we designed at techpotions is a working demonstration of what “rent the table stakes, build the differentiator” looks like in practice:

• A rented Postgres instance powers the entire data layer, from candidate profiles to brief submissions, with zero lock‑in.
• A cloud queue orchestrates the 5‑step vetting process, decoupling the admin UI from third‑party verifications.
• Object storage holds resumes via a thin abstraction; the same code works against S3 and local MinIO.
• User sessions are handled by a rented auth provider, while a hand‑built service‑account layer lets employers programmatically inject briefs without a user session.
• An LLM API (rented) feeds the screener, but the promise of consistent ranking is kept by the 380‑case eval suite (built) that catches regressions before they hit a single employer.
• Transactional emails flow through Resend, cron through a cloud scheduler, and full‑text search through Algolia — all rented, all replaceable.

The lesson: every decision in SaaS architecture in cloud computing traces back to one question — “If I change cloud providers next year, does my product’s secret sauce survive untouched?” For ReadyShortlist, the answer is yes.

FAQ

What’s the biggest lock-in risk in SaaS architecture in cloud computing?

Proprietary APIs that lack an abstraction layer are the biggest lock‑in risks — especially in auth (session‑provider‑specific session tokens) and queues (vendor‑specific DLQ, retry, and FIFO semantics). Wrap every rented service in a thin interface that owns your business‑logic boundaries, and avoid database‑specific extensions that prevent a future migration.

How do you handle tenant-scoped service accounts in a multi-tenant SaaS?

Use a managed auth provider for user‑to‑app flows (Clerk, Auth0), but build your own tenant‑scoped API key store for machine‑to‑machine integrations. Each key is tied to a tenant and a set of scoped permissions, letting external systems act on behalf of the tenant without a user session — essential for two‑sided platforms with automated brief submissions or resume ingestion.

Should we use a multi-tenant or single-tenant architecture for our cloud SaaS?

For most startups without strong compliance isolation requirements (e.g., HIPAA, FedRAMP), use a logical multi‑tenant model with a single application instance and database that isolates data by a tenant ID column. Only consider single‑tenant dedicated instances if regulation demands physical separation or if customers will pay a premium for it — and be prepared for higher operational overhead.