How to Evaluate a SaaS Developer: 8 Technical Checks

A SaaS application can look simple from the outside while having a surprisingly complicated system underneath.

A signup form might involve authentication, database transactions, email verification, permissions, subscriptions, and background jobs. A "team" feature might require organizations, memberships, roles, invitations, and authorization checks across every API endpoint.

That's why evaluating a SaaS developer shouldn't stop at their portfolio or hourly rate.

Before hiring someone, you want to understand how they think about the parts of the system that become difficult to change later.

Here are eight technical areas worth discussing.

1. Ask Them to Draw the Architecture

Don't start with:

"Which framework will you use?"

Start with:

"How would you structure this application?"

For example, a relatively simple SaaS might look like this:

Browser / Mobile App
        |
        v
     API Layer
        |
        v
  Business Logic
    /    |     \
   v     v      v
Postgres Stripe  Queue
           |
           v
        Webhooks

The exact architecture will depend on the product.

The important part is whether the developer can explain why each component exists.

For example:

• Why is PostgreSQL being used?
• Where does authorization happen?
• How are background jobs handled?
• Where is payment state stored?
• How are webhook events processed?
• What happens when an external service is unavailable?

A developer who can explain trade-offs is more useful than someone who can simply list technologies.

2. Look at the Database Design

A SaaS database usually contains relationships that become more important as the product grows.

For example:

CREATE TABLE organizations (
  id UUID PRIMARY KEY,
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE TABLE users (
  id UUID PRIMARY KEY,
  email TEXT NOT NULL UNIQUE,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE TABLE memberships (
  organization_id UUID NOT NULL
    REFERENCES organizations(id),

  user_id UUID NOT NULL
    REFERENCES users(id),

  role TEXT NOT NULL,

  PRIMARY KEY (organization_id, user_id)
);

This is more useful than simply creating a users table with an organization_id column and assuming the requirements will never change.

Ask the developer:

• What are the core entities?
• How are relationships represented?
• Where are foreign keys used?
• Which fields need indexes?
• How will schema changes be migrated?
• What happens if an organization is deleted?

You don't need to know SQL deeply.

You want to see whether the developer is thinking about data integrity and future changes.

3. Check How Authorization Works

Authentication answers:

"Who is this user?"

Authorization answers:

"What is this user allowed to do?"

Those are different problems.

For example, this is not enough:

app.get("/api/projects/:id", requireAuth, getProject);

The user may be authenticated, but do they actually belong to the organization that owns the project?

A simplified authorization check might look like:

async function canAccessProject(userId, projectId) {
  const result = await db.query(
    `
    SELECT 1
    FROM projects p
    JOIN memberships m
      ON m.organization_id = p.organization_id
    WHERE p.id = $1
      AND m.user_id = $2
    `,
    [projectId, userId]
  );

  return result.rowCount > 0;
}

The important question for a SaaS developer is not whether they know this exact implementation.

Ask:

"How do you prevent one organization's users from accessing another organization's data?"

If they haven't thought about tenant isolation, that's worth investigating before development starts.

4. Ask How They Handle Database Migrations

A production database should not depend on manually editing tables.

Suppose version one has:

users
projects

Six months later you need:

organizations
memberships
projects
subscriptions

How does the developer introduce those changes?

A migration system lets schema changes become repeatable:

001_create_users
002_create_projects
003_create_organizations
004_create_memberships
005_add_subscription_status

This matters when another developer joins the project or when you deploy to staging and production.

Ask:

"If I clone the repository and connect a fresh database, can I reproduce the current schema?"

A good development workflow should make the answer close to "yes."

5. Payments Are More Than a Checkout Button

Payment integrations are a good way to distinguish a demo from a production system.

For example, don't make the browser the source of truth for subscription status.

A typical flow is:

Customer
   |
   v
Payment Provider
   |
   v
Webhook
   |
   v
Your API
   |
   v
Database
   |
   v
Account Access

One common mistake is processing the same webhook event twice.

External services can retry webhook deliveries, so your handler should be designed to be idempotent.

For example:

app.post("/webhooks/stripe", async (req, res) => {
  const event = constructStripeEvent(req);

  const existing = await db.query(
    "SELECT 1 FROM webhook_events WHERE event_id = $1",
    [event.id]
  );

  if (existing.rowCount > 0) {
    return res.sendStatus(200);
  }

  await db.query(
    `
    INSERT INTO webhook_events (event_id, event_type)
    VALUES ($1, $2)
    `,
    [event.id, event.type]
  );

  if (event.type === "invoice.paid") {
    await handleSuccessfulPayment(event);
  }

  res.sendStatus(200);
});

In a real implementation, the event insertion and business update should also be designed carefully around database transactions and failure scenarios.

Ask the developer:

"What happens if Stripe sends the same webhook twice?"

It's a simple question that can reveal a lot about their production experience.

6. Ask What Happens When Requirements Change

This is one of the most useful technical discussions before starting a SaaS project.

Suppose the original requirement is:

One user → one project

Then the business changes:

Organization
  ├── many users
  └── many projects

Can the existing architecture accommodate this?

You don't want a developer to predict every future requirement.

That's impossible.

Instead, look for code and architecture that keep important responsibilities reasonably separated.

For example:

Controller
   ↓
Service
   ↓
Repository / Database

doesn't automatically make an application good, but it can make certain changes easier than putting database queries, business rules, authentication, and HTTP handling into one enormous function.

The question isn't:

"Will you build a perfect architecture?"

It's:

"Can the architecture evolve without rewriting unrelated parts of the system?"

7. Ask How They Test the Important Parts

You don't necessarily need 100% test coverage.

You do need confidence around the parts where bugs can cause serious problems.

For a SaaS application, that could include:

Authentication
Authorization
Billing
Subscription state
Critical business rules
Data access
Webhook processing

For example:

test("user cannot access another organization's project", async () => {
  const response = await request(app)
    .get(`/api/projects/${otherOrganizationsProjectId}`)
    .set("Authorization", userToken);

  expect(response.status).toBe(403);
});

This kind of test is more valuable than simply testing whether a button renders.

Ask:

"Which parts of the application would you test first?"

The answer should reveal whether the developer understands where the application's actual risk lives.

8. Ask What Happens After Deployment

Deployment isn't the end of the engineering work.

Ask what happens when:

• a database migration fails
• an API starts returning errors
• a background job gets stuck
• a deployment introduces a bug
• an external API goes down
• a production database needs to be restored

At minimum, you should discuss:

Git repository
Environment variables
Database backups
Migrations
Logging
Error monitoring
Deployment process
Rollback strategy
Access management

Also make sure the project isn't dependent on one person's laptop or personal accounts.

The repository, cloud infrastructure, database, domain, payment account, and important service accounts should have a clear ownership model.

A Simple Technical Interview for a SaaS Developer

You don't need a three-hour interview.

Give the developer a short description of your product and ask these questions:

Architecture

How would you structure this application?

Database

What would the main entities and relationships look like?

Authorization

How would you prevent users from accessing another customer's data?

Payments

What happens if a payment succeeds but your webhook isn't processed?

Scaling

Which part of this system do you expect to become a bottleneck first?

Changes

What part of this design would be hardest to change later?

Deployment

How would you safely deploy database changes?

Handoff

If another developer takes over six months from now, what would they need?

You don't have to know the perfect answers.

Pay attention to whether the developer identifies assumptions, asks clarifying questions, discusses trade-offs, and explains failure cases.

The Biggest Red Flag Isn't a Specific Technology

A developer using MongoDB isn't automatically bad.

A developer using PostgreSQL isn't automatically good.

The same applies to React, Next.js, Node.js, AWS, Docker, serverless functions, or any other technology.

The more useful signal is whether the developer can connect technical decisions to actual requirements.

For example:

Requirement
    ↓
Business Rule
    ↓
Data Model
    ↓
API / Service
    ↓
Authorization
    ↓
Testing
    ↓
Deployment

That chain is what turns a product requirement into an actual system.

Final Checklist

Before hiring a developer for a SaaS project, make sure you can get clear answers to these:

• [ ] Can they explain the proposed architecture?
• [ ] Can they explain the database relationships?
• [ ] Do they understand authentication vs authorization?
• [ ] Do they have a migration strategy?
• [ ] Do they understand payment/webhook failure cases?
• [ ] Can the system accommodate changing requirements?
• [ ] Are important business rules tested?
• [ ] Is deployment reproducible?
• [ ] Are backups and monitoring considered?
• [ ] Can another developer take over?
• [ ] Does the company own the critical accounts and infrastructure?

The goal isn't to find a developer who predicts every future problem.

That's impossible.

The goal is to find someone who recognizes the important engineering decisions early, understands the trade-offs, and doesn't treat production software as nothing more than a collection of screens and API endpoints.

I'm Haseeb, building SaaS products at Seebify.

Full write-up with the business-side reasoning → https://www.seebify.com/blog/how-to-choose-a-saas-developer