DEV Community: Haseeb Sheikh

How to Evaluate a SaaS Developer: 8 Technical Checks

Haseeb Sheikh — Sun, 20 Sep 2026 13:43:47 +0000

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

How Much Does It Actually Cost to Build a SaaS in 2026? A Technical Breakdown

Haseeb Sheikh — Sun, 13 Sep 2026 10:35:45 +0000

A SaaS application can look simple from the outside and still require significant backend engineering.

A dashboard with ten screens might be cheap to build. A dashboard with multi-tenant data, role-based permissions, Stripe subscriptions, webhooks, integrations, background jobs, and production monitoring is a completely different engineering problem.

So instead of estimating SaaS development cost by the number of pages or screens, let's look at what actually creates the engineering work.

A Practical SaaS Cost Breakdown

For a typical web SaaS product, these are useful planning ranges:

Product stage	Typical budget	Typical timeline
Prototype / validation	$500–$2,500	1–3 weeks
Lean SaaS MVP	$3,000–$8,000	4–8 weeks
Production-ready SaaS	$7,000–$20,000	6–12 weeks
Complex SaaS	$20,000–$50,000+	3–6+ months

These aren't fixed market prices. The actual number depends heavily on the architecture and workflows your product requires.

The important question isn't:

"How much does SaaS development cost?"

It's:

"What engineering does this particular SaaS need to work reliably for real users?"

Let's break that down.

1. Your Database Architecture Matters More Than Your Number of Screens

A common mistake is estimating a SaaS based on UI screens:

Login
Dashboard
Settings
Billing
Admin
Reports

But the real complexity is usually underneath those screens.

For example, a B2B SaaS might have a structure like:

Organization
    ↓
Members
    ↓
Users
    ↓
Projects
    ↓
Transactions

Now every important query needs to understand which organization owns the data.

A simplified PostgreSQL query might look like this:

SELECT *
FROM projects
WHERE organization_id = $1
ORDER BY created_at DESC;

That organization_id isn't just another column.

It is part of your tenant-isolation strategy.

If tenant isolation is implemented incorrectly, one customer could potentially access another customer's data.

That's why database architecture becomes a major part of SaaS development cost as the product becomes more complex.

2. Authentication Gets Expensive When Permissions Get Real

A basic application might only need:

User → Dashboard

A production B2B SaaS can look more like:

User
  ↓
Organization
  ↓
Team
  ↓
Role
  ↓
Permission
  ↓
Resource

Suddenly authentication isn't just:

if (user) {
  return dashboard;
}

You may need to handle:

Sessions
Password resets
Email verification
Organization membership
Roles
Permissions
Resource-level authorization
Tenant isolation
Admin access

For example:

function canEditProject(user, project) {
  if (user.organizationId !== project.organizationId) {
    return false;
  }

  return user.permissions.includes("project:edit");
}

The code itself is small.

The expensive part is making sure these rules are applied consistently across every API endpoint and every important operation.

3. Stripe Is More Than a Checkout Button

One of the easiest SaaS features to underestimate is billing.

A simple requirement might be:

"We just need Stripe subscriptions."

But production billing usually involves:

Checkout
   ↓
Stripe
   ↓
Webhook
   ↓
Subscription state
   ↓
Database
   ↓
User access

A simplified subscription creation might look like:

const subscription = await stripe.subscriptions.create({
  customer: customerId,
  items: [
    {
      price: priceId,
    },
  ],
});

That is only the beginning.

You also need to think about:

Successful payments
Failed payments
Cancelled subscriptions
Upgrades
Downgrades
Refunds
Proration
Duplicate webhook events
Expired cards
Subscription status
Access after cancellation

One particularly important rule is:

Don't treat the browser's checkout response as the source of truth for subscription state.

Stripe webhooks should update your backend when important billing events occur.

For example:

app.post("/webhooks/stripe", express.raw({ type: "application/json" }), async (req, res) => {
  const event = stripe.webhooks.constructEvent(
    req.body,
    req.headers["stripe-signature"],
    process.env.STRIPE_WEBHOOK_SECRET
  );

  if (event.type === "customer.subscription.updated") {
    const subscription = event.data.object;

    await updateSubscription(subscription);
  }

  res.json({ received: true });
});

The mechanism is a webhook-driven state update.

The engineering cost comes from making that state reliable when events arrive late, twice, or in an unexpected order.

4. Integrations Multiply the Number of Failure Points

Adding an integration can sound trivial:

"We just need Google Calendar."

But an integration normally introduces another external system that your application doesn't control.

You may need:

Your API
   ↓
OAuth
   ↓
External API
   ↓
Rate limits
   ↓
Retries
   ↓
External errors
   ↓
Data synchronization

For example, if your application creates calendar events, you need to decide what happens when the external API fails.

A basic retry strategy might look like:

async function createCalendarEvent(data, retries = 3) {
  try {
    return await calendar.events.insert({
      calendarId: "primary",
      requestBody: data,
    });
  } catch (error) {
    if (retries === 0) {
      throw error;
    }

    await new Promise((resolve) => setTimeout(resolve, 1000));

    return createCalendarEvent(data, retries - 1);
  }
}

In a real system, you'd usually want better retry policies, logging, idempotency, and background jobs.

This is why "three integrations" can represent significantly more work than "three API calls."

5. AI Features Are Usually Workflows, Not API Calls

AI can reduce development time for some parts of a product, but an AI feature is rarely just:

const response = await openai.responses.create(...);

A production AI workflow might look like:

User Request
     ↓
API
     ↓
Background Job
     ↓
AI Model
     ↓
Validation
     ↓
Database
     ↓
Notification

You may need to handle:

Model failures
Timeouts
Token usage
Long-running requests
Background processing
Invalid model output
Validation
Rate limits
Cost controls
Human approval

The expensive part is often everything surrounding the model.

6. Production Readiness Is Where "Cheap" MVPs Become Expensive

A demo can work without many production systems.

A real SaaS shouldn't depend on luck.

Production readiness can include:

Automated testing
        +
Secure secrets
        +
Database backups
        +
Error tracking
        +
Monitoring
        +
Rate limiting
        +
CI/CD
        +
Staging
        +
Database migrations
        +
Rollback strategy

For example, an application might work perfectly during development.

Then a production database migration fails.

Or a webhook starts sending duplicate events.

Or one API endpoint receives unexpected traffic.

Or a deployment introduces a regression.

Production engineering exists to make those situations manageable.

That's why a production-ready SaaS can cost substantially more than a prototype with the same UI.

7. A Lean MVP Should Reduce Scope, Not Engineering Quality

This is one of the most important distinctions when budgeting a SaaS.

Suppose your complete product vision contains 30 features.

You might only need five to validate whether customers will actually pay.

Build those five.

But don't intentionally build them badly.

A focused MVP could still have:

A proper PostgreSQL schema
Secure authentication
Clean API boundaries
Tenant isolation
Tested critical workflows
Stripe integration
Error monitoring
Production deployment

You're reducing what you build, not deliberately reducing how reliably you build it.

This is often the best way to reduce the initial SaaS budget.

So Where Does the Money Actually Go?

Instead of estimating a SaaS using one number, break the project into engineering categories:

Product discovery
        ↓
Architecture & database
        ↓
Frontend + backend
        ↓
Authentication & permissions
        ↓
Billing & integrations
        ↓
Testing & production readiness
        ↓
Infrastructure & deployment
        ↓
Post-launch engineering

For example, a focused SaaS with authentication, a dashboard, one core workflow, PostgreSQL, an admin panel, Stripe, and production deployment might fit into a relatively small MVP budget.

Add:

Mobile applications
Real-time chat
Advanced analytics
Multiple integrations
Complex permissions
AI workflows
International billing
Advanced reporting

…and the engineering scope can increase dramatically.

What About Infrastructure Costs?

Development cost and infrastructure cost are two different budgets.

An early SaaS might use:

Next.js
Vercel
PostgreSQL
Stripe
GitHub
An email provider
Sentry or another monitoring platform

You don't necessarily need an expensive cloud architecture on day one.

A small SaaS might spend tens or a few hundred dollars per month on infrastructure while spending thousands of dollars on the initial development.

As usage increases, infrastructure costs can grow with traffic, database usage, storage, email, AI usage, and other services.

What Happens After Launch?

The development budget shouldn't end when version one goes live.

Once real users arrive, you'll eventually deal with:

Bugs
Performance issues
Database optimisation
New features
Dependency updates
Security improvements
Infrastructure changes
New integrations
Refactoring

This is why SaaS development should be treated as a lifecycle rather than a one-time project.

A useful mental model is:

Initial Build
     ↓
Real Users
     ↓
Feedback
     ↓
Iteration
     ↓
Scaling
     ↓
Architecture Improvements

The goal isn't to predict every future requirement.

It's to build the first version in a way that doesn't make every future change painful.

A Practical SaaS Budget

For planning purposes, these ranges are a reasonable starting point:

$500–$2,500

Prototype or early validation build.

$3,000–$8,000

Focused SaaS MVP with a narrow feature set.

$7,000–$20,000

Production-ready SaaS with stronger architecture, authentication, billing, testing, integrations, deployment, and monitoring.

$20,000–$50,000+

Complex SaaS involving multiple roles, advanced workflows, significant integrations, AI systems, marketplaces, or mobile and web platforms.

These numbers are planning ranges, not guarantees.

The final cost should come from the workflows your product needs, not the number of screens in the design.

The Biggest SaaS Cost Mistake

The most expensive mistake isn't always choosing the wrong technology.

It's building too much before learning enough.

You can spend months building advanced analytics, multiple dashboards, AI automation, mobile apps, and dozens of integrations — and then discover that customers only wanted one simple workflow.

A better approach is:

Reduce unnecessary scope
        ↓
Launch earlier
        ↓
Get real feedback
        ↓
Measure usage
        ↓
Invest in what customers actually need

AI-assisted development can make certain parts of this process faster, but it doesn't eliminate the need for architecture, security, database design, testing, code review, or production monitoring.

Final Takeaway

There isn't one universal price for building a SaaS in 2026.

A prototype might cost a few thousand dollars or less. A production-ready SaaS can require tens of thousands. A complex platform can go far beyond that.

The better way to estimate the project is to ask:

What is the smallest useful version?
What architecture does it need?
Which workflows require serious backend engineering?
What integrations and billing systems are involved?
What does "production-ready" mean for this product?
What can wait until real customers prove it is necessary?

Build less.

But build the important parts properly.

I'm Haseeb, building SaaS products at Seebify. I write about the engineering decisions behind building and scaling production-ready SaaS products.

Full write-up with the business-side reasoning: Seebify — How Much Does It Cost to Build a SaaS in 2026?

No Budget to Build Your SaaS? Here's How to Get Started Anyway

Haseeb Sheikh — Sun, 30 Aug 2026 14:37:41 +0000

No Budget to Build Your SaaS? Here's How to Get Started Anyway

You have a SaaS idea.

You believe it can solve a real problem.

But there is one major problem:

You don't have the budget to hire a development team.

That doesn't necessarily mean you have to stop.

You can start by building what you can, validating the idea, and preparing a clear opportunity for someone who may want to join you as a technical partner.

The goal isn't to build an entire SaaS for free.

The goal is to get far enough that the right person can look at what you've done and say:

"I understand what you're building. I understand the opportunity. I understand what you need from me."

That clarity can be extremely valuable when your cash budget is limited.

Your First Job Isn't Hiring a Developer

One of the first mistakes I see founders make is immediately searching for a developer.

They have an idea and send a message like:

"I have a SaaS idea. I don't have a budget. Can you build it for equity?"

Put yourself in the developer's position.

You know almost nothing about the opportunity.

You don't know:

What the product does
Who needs it
Whether anyone wants it
What has already been built
How much work is required
What the founder is contributing
What the equity actually means
Where the company is going

You're being asked to take a significant risk based almost entirely on trust.

Instead, do some of the work first.

Step 1: Turn Your Idea Into a Clear Product

Before you approach anyone, answer a few basic questions.

What problem are you solving?

Don't describe the technology.

Describe the pain.

For example:

"Small businesses spend several hours every week manually preparing reports from multiple systems."

That's easier to understand than:

"I'm building an AI-powered business intelligence platform."

Who has this problem?

Be specific.

Instead of:

"Businesses"

Try:

"Small agencies with 5–20 employees."

The more specific you are, the easier it becomes to validate your idea.

What does your product do?

Explain the solution in simple language.

Someone who knows nothing about your industry should understand it.

Why would someone pay for it?

You don't need a perfect pricing strategy at this stage.

But you should have a hypothesis.

For example:

"$49/month for small teams."

Now you have something you can test.

Step 2: Build a Landing Page

You don't need the complete application to start presenting your idea.

Build a simple, professional landing page.

It should explain:

The problem
Your solution
Who it's for
Main benefits
How it works
Early screenshots or mockups
Call to action
Contact or waitlist

This can often be done using website builders or AI-powered tools without hiring a developer.

Depending on the tools you choose, you may be able to get the first version online for free or for a few dollars.

The objective isn't to impress investors.

It's to make your idea real enough to evaluate.

Step 3: Build a Basic Prototype With AI

This is where things have changed dramatically for founders.

You no longer necessarily need to hire a development team just to create the first visual version of a product.

AI-powered development tools can help you create basic screens and workflows.

For example:

Signup
Login
Forgot password
Dashboard
Forms
Settings
Basic user workflow
Simple admin screens

You might be able to create an early prototype for free or with a small monthly AI-tool budget.

But remember:

A prototype is not a production-ready SaaS.

That's okay.

You're not trying to build the final company yourself.

You're creating enough of the product to demonstrate:

"This is what I mean."

A clickable prototype can communicate more than ten pages of explanation.

Step 4: Talk to Potential Customers

Don't spend months building before speaking to customers.

Find people who match your target audience.

Ask them about the problem.

For example:

How do you solve this today?

What is frustrating about your current process?

How often does this problem happen?

How much time does it take?

Have you paid for a solution before?

What would make you switch?

Don't focus only on whether they like your idea.

People are very good at saying:

"That's a great idea."

That doesn't mean they'll use it.

Look for stronger signals.

Someone asking:

"When can I try it?"

is more interesting.

Someone asking:

"How much will it cost?"

is even more interesting.

Someone willing to become a paying customer is stronger still.

Step 5: Package Everything Into a Simple Presentation

This is probably the most important step if you have little or no budget.

Before approaching a technical partner, create a simple presentation.

It can be:

A PDF
A Notion document
Google Slides
A short pitch deck
A product brief

It doesn't need to look like a Silicon Valley investor deck.

It needs to be clear.

I would structure it like this:

1. Product

What are you building?

2. Problem

What problem does it solve?

3. Target customer

Who will use it?

4. Current solution

How do people solve the problem today?

5. Your solution

How will your product improve the situation?

6. Current progress

What have you already done?

For example:

Landing page completed
Prototype completed
25 customer interviews
50 people interested
5 beta users

Whatever your numbers are, show them honestly.

7. Roadmap

What do you want to build next?

Keep the first version small.

8. What you need

Be extremely specific.

For example:

"I'm looking for a technical co-founder to help turn the current prototype into a production-ready SaaS."

That's much better than:

"I need a developer."

9. What you can offer

This is where you need to be completely transparent.

Step 6: Consider Equity + a Small Stipend

If you genuinely don't have enough money to pay market-rate compensation, you have to acknowledge that.

But that doesn't mean the only option is:

"Work for free."

You can explore a structure that works for both sides.

For example:

Equity + small stipend

The stipend provides some immediate compensation.

The equity represents long-term upside and ownership.

The exact arrangement depends entirely on the situation.

There is no magic percentage that applies to every startup.

A technical co-founder joining at the idea stage is very different from an experienced engineer joining an MVP that already has hundreds of customers.

The arrangement should consider:

How early the company is
How much work has already been done
Expected time commitment
Technical responsibility
Existing traction
Founder contributions
Expected future commitment
Whether the person is a co-founder or contractor

And whatever equity arrangement you make should be properly documented with appropriate legal advice.

The most important thing is:

Don't hide the risk. Explain it.

Step 7: Don't Sell Equity. Sell the Opportunity.

This is a subtle but important difference.

If your entire pitch is:

"I can't pay you, but I'll give you equity."

you're focusing on what you don't have.

Instead, explain what the person is joining.

For example:

"We're solving a problem for small property managers. We've interviewed 30 potential customers, built the first prototype, and have 12 businesses interested in testing it. I'm handling the business, customer development, and sales. I'm looking for a technical partner to own the product engineering side. I can offer a small monthly stipend plus equity."

Now the conversation is completely different.

The person can evaluate:

Founder + Problem + Market + Progress + Role + Compensation + Opportunity

That's a real decision.

Step 8: Show What You Are Bringing to the Table

If you aren't technical, you still have a lot to contribute.

Don't approach a technical partner as if their job is to build your idea while you simply wait.

Your contribution might be:

Customer research
Sales
Marketing
Industry knowledge
Product strategy
Partnerships
Fundraising
Customer support
Operations
Business development
Vision

A strong technical partner should feel that you're building the company together.

Not that they're being hired to turn your idea into reality while you sit on the sidelines.

Step 9: Understand the Difference Between an MVP and Production Software

This is where many non-technical founders get confused.

You may have an AI-generated prototype that looks fantastic.

That's great.

But production software has another layer of complexity.

Someone needs to make sure things such as:

User accounts
Data
Payments
Security
Permissions
Backups
Performance
Reliability
Error handling

are handled properly.

Your first prototype doesn't need to solve every problem.

But once real customers depend on your software, the standard changes.

That's when experienced technical help becomes especially valuable.

Step 10: Don't Build Everything

Your first SaaS version should be much smaller than your dream product.

Suppose your long-term vision includes:

Web application
Mobile apps
AI assistant
20 integrations
Advanced analytics
Automated workflows
Team collaboration
Enterprise permissions

Don't build all of that.

Ask:

What is the one workflow that proves this product is useful?

Build that first.

For example:

User signs up
      ↓
Creates a project
      ↓
Uses the core feature
      ↓
Gets the promised result

If that works, you have something worth improving.

Step 11: Use Your Limited Budget Carefully

Having a small budget doesn't mean you should refuse to spend anything.

It means you need to spend intentionally.

Your first $100 might be more valuable when spent on:

Customer research
A domain
Essential software
A small AI-tool subscription
Early marketing experiments
Professional design help
Technical review

rather than building ten features that nobody asked for.

Ask yourself:

What is the biggest uncertainty in my startup right now?

Then spend money to reduce that uncertainty.

If nobody wants the product, you need validation.

If people want it but the prototype doesn't work reliably, you need engineering.

If the product works but nobody knows about it, you need distribution.

Your spending priorities should change as you learn.

A Simple Path for a Founder With Almost No Budget

If I were starting from zero today, I'd think about it like this:

Stage 1 — Idea

Budget: $0

Define:

Problem
Customer
Solution
Business model

Stage 2 — Presentation

Budget: $0

Create:

Product brief
Pitch deck
Screenshots
Roadmap
Team requirements

Stage 3 — Landing Page

Budget: $0–$10+

Create a professional website and start collecting interested users.

Stage 4 — Prototype

Budget: $0–$10+

Use AI tools to build the first visual version.

Stage 5 — Validation

Talk to potential customers.

Get feedback.

Find beta users.

Stage 6 — Find the Technical Partner

Present:

The product
The problem
Your research
Your prototype
Your traction
Your roadmap
The role
The expected commitment
Equity
Stipend, if possible

Stage 7 — Build Production Software

Once the idea has enough evidence behind it, bring in experienced engineering to turn the prototype into a reliable SaaS.

What Made Me Say Yes to a Zero-Budget Founder

This isn't theoretical for me.

Recently, a founder approached me about helping scale their SaaS.

They had essentially no budget.

They were still building their team and were offering equity across technical, sales, and marketing roles.

But I didn't say yes because of the equity.

I said yes because of the clarity.

The founder clearly explained:

What they were building
What problem they were solving
What they had already accomplished
What they needed
What they were offering
Where they wanted to go

I didn't have to guess.

I didn't have to spend hours figuring out what the opportunity was.

They had done the work to make the opportunity understandable.

That matters.

Your Lack of Budget Doesn't Have to Be Your Biggest Weakness

You probably can't compete with a funded startup on salary.

That's okay.

You can compete on other things.

You can show:

Preparation.

Ownership.

Clarity.

Traction.

Vision.

Commitment.

A developer might reject an opportunity with a large salary if the product, founder, or problem isn't compelling.

And someone might consider an equity-based opportunity if they genuinely believe:

"This is something worth building."

That doesn't mean you should expect people to work indefinitely without compensation.

It means you should create an opportunity where the risks, responsibilities, and potential rewards are clearly understood by everyone involved.

Don't Let "No Budget" Become "No Action"

The worst thing you can do with a small budget is nothing.

You don't need to have everything figured out.

Start with what you can control.

Build the landing page.

Create the prototype.

Talk to customers.

Write the product presentation.

Find out whether people care.

Document what you've learned.

Then approach the technical people you need.

Don't say:

"I have an idea. Can you build it?"

Show them:

"Here's what I'm building. Here's the problem. Here's what I've already done. Here's what I've learned. Here's what I need from you. Here's what I can offer. And here's where I want to take this."

That's a completely different conversation.

When you don't have a big budget, clarity becomes part of your compensation package.

Budget tells people what you can pay.

Clarity tells people whether they can trust the opportunity.

Sometimes the right technical partner isn't looking for the biggest paycheck.

They're looking for something worth building.

I'm Haseeb, building SaaS products at Seebify. The full founder-focused version of this topic is here: https://www.seebify.com/blog/how-to-build-saas-mvp-with-no-budget

Scaling a Node.js + PostgreSQL SaaS Backend: Pagination, Redis Caching, and Background Jobs

Haseeb Sheikh — Tue, 25 Aug 2026 11:46:07 +0000

One backend. One PostgreSQL database. An admin panel, a web app, and two mobile clients all hitting the same API.

It worked fine — until it didn't. p99 latency crept past 4 seconds, the job queue started backing up, and the instinct was to add more servers. That instinct is almost always wrong. Here's the actual sequence that fixed it, with the code — not just the theory.

Measure before you touch anything

Don't scale based on a feeling. Track these five things before changing infrastructure:

CPU/RAM on your app servers
API latency — p95 and p99, not the average (a 200ms average can hide a p99 of 4s)
Query latency, active connections, lock contention
Error rate per endpoint
Queue depth and job processing time

A basic dashboard covering these tells you whether the problem is application, database, or queue — before you spend money on the wrong layer.

Make the application do less work first

This is the cheapest scaling win, and the one most often skipped.

Cursor-based pagination instead of large offsets

app.get('/api/orders', async (req, res) => {
  const { cursor, limit = 25 } = req.query;
  const query = cursor
    ? `SELECT * FROM orders WHERE id > $1 ORDER BY id LIMIT $2`
    : `SELECT * FROM orders ORDER BY id LIMIT $1`;
  const params = cursor ? [cursor, limit] : [limit];
  const { rows } = await pool.query(query, params);
  res.json({ data: rows, nextCursor: rows.at(-1)?.id ?? null });
});

An indexed WHERE id > cursor avoids the cost of skipping hundreds of thousands of rows just to discard them — unlike OFFSET 50000, which still scans everything before it.

Kill N+1 queries

Fetching 100 orders, then querying the customer for each one separately, turns 1 query into 101:

-- Before: 1 query + 100 more in a loop
SELECT * FROM orders LIMIT 100;

-- After: 1 query
SELECT orders.id, orders.total, users.name
FROM orders
JOIN users ON users.id = orders.user_id
LIMIT 100;

The dangerous part: N+1 is invisible with 10 records and painful with 10,000.

PostgreSQL: indexes, EXPLAIN ANALYZE, connection pooling

CREATE INDEX idx_orders_user_id ON orders(user_id);

EXPLAIN ANALYZE
SELECT * FROM orders WHERE user_id = 123;

EXPLAIN ANALYZE shows you sequential scans, bad row estimates, and unnecessary sorts — don't guess why a query is slow, look.

Five app servers each opening 20 raw connections is 100 connections fast, and Postgres has a hard limit. Pool them:

const { Pool } = require('pg');

const pool = new Pool({
  host: process.env.DB_HOST,
  max: 20,                     // per instance, not global
  idleTimeoutMillis: 30000,
  connectionTimeoutMillis: 2000,
});

For anything beyond a handful of app instances, put PgBouncer in front of Postgres so pooling is handled centrally instead of per-process.

Redis: cache-aside, not a database

Cache-aside is the default pattern: check Redis → fall back to Postgres on a miss → write through → return.

const redis = require('ioredis')();

async function getDashboardSummary(userId) {
  const cacheKey = `dashboard:${userId}`;
  const cached = await redis.get(cacheKey);
  if (cached) return JSON.parse(cached);

  const summary = await computeDashboardSummary(userId); // hits PostgreSQL
  await redis.set(cacheKey, JSON.stringify(summary), 'EX', 60); // 60s TTL
  return summary;
}

The hard part isn't reading from cache, it's invalidation — when the underlying data changes, update or evict the key, or you'll serve a stale permission set long after it changed.

Redis also isn't your source of truth; use it for caching, rate limiting, and sessions, not durable business data.

Background jobs, with real retry logic

Your API shouldn't block on report generation, PDF exports, or bulk email. Using BullMQ:

const { Queue, Worker } = require('bullmq');

// Producer — API route
const reportQueue = new Queue('reports', { connection: redisConnection });

app.post('/api/reports', async (req, res) => {
  const job = await reportQueue.add('generate-report', { userId: req.user.id });
  res.status(202).json({ status: 'processing', jobId: job.id });
});

// Worker — separate process
new Worker('reports', async (job) => {
  const { userId } = job.data;
  await generateAndStoreReport(userId);
}, {
  connection: redisConnection,
  attempts: 3,
  backoff: { type: 'exponential', delay: 5000 },
});

Retries alone aren't enough — a worker can crash after sending an email but before marking the job done, and the retry will fire again:

new Worker('invoices', async (job) => {
  const { invoiceId } = job.data;

  const alreadySent = await redis.get(`invoice-sent:${invoiceId}`);
  if (alreadySent) return; // retried, but the email already went out

  await sendInvoiceEmail(invoiceId);
  await redis.set(`invoice-sent:${invoiceId}`, '1', 'EX', 86400);
});

Without that idempotency check, a retried job means a duplicate invoice email in someone's inbox.

Rate limiting, tiered by plan

An endpoint that normally sees 100 req/min can suddenly see 20,000 — spike, bad integration, or abuse. Enforce limits consistently across instances via Redis:

const rateLimit = require('express-rate-limit');
const RedisStore = require('rate-limit-redis');

const limiter = rateLimit({
  store: new RedisStore({ sendCommand: (...args) => redis.call(...args) }),
  windowMs: 60 * 1000,
  max: (req) =>
    req.user?.plan === 'enterprise' ? 5000 :
    req.user?.plan === 'paid' ? 1000 : 100,
});

app.use('/api/', limiter);

Gotchas that don't show up until production

N+1 queries are invisible at small scale. They only hurt once a customer has thousands of rows, by which point they're already in production.
Forgotten cache invalidation serves stale data silently — a user balance or permission set that's wrong for minutes or hours with no error thrown anywhere.
In-memory session state breaks the moment you add a second node. const sessions = {} living in process memory means a request routed to a different instance won't see it. Sessions, cache, and uploaded files need to live in Postgres, Redis, or object storage — not app memory — before you run more than one instance.
Jobs without idempotency duplicate side effects on retry, not just waste compute — a resent email or a double-charged webhook is a worse bug than a slow query.

Scale infrastructure last, not first

Once the application and database are genuinely optimized: vertical scaling (bigger machine) is simple but has a ceiling. Horizontal scaling (more machines behind a load balancer) needs a stateless app first — shared sessions, shared cache, shared storage — or you'll get inconsistent behavior depending on which node a request hits.

Skip Kubernetes and microservices until there's a concrete reason — a workload that needs to scale independently, or a team boundary large enough to justify separate deploy lifecycles.

Neither one makes a slow query fast or an unindexed table efficient.

Takeaway

Measure → Optimize → Test → Scale

Most of the wins above cost nothing but engineering time — pagination, an index, a cache with a sane TTL, moving slow work off the request path.

Infrastructure is the last lever to pull, not the first.

I'm Haseeb — I build production SaaS backends (Node.js, PostgreSQL, Redis, Stripe) at Seebify. Full write-up with the business-side reasoning and a complete stage-by-stage scaling roadmap here.

How I Built a $0/Month Ecommerce MVP Without Shopify

Haseeb Sheikh — Sun, 09 Aug 2026 11:15:10 +0000

A founder came to me with a simple requirement:

100+ products
Customers need to browse products
Customers need to place orders through WhatsApp
No online payments
No monthly Shopify subscription

The interesting part?

He didn't need a traditional ecommerce platform.

He needed a simple way to display products and receive orders.

The Problem

The original idea could easily turn into a large ecommerce application:

User accounts
Authentication
Shopping cart
Checkout
Payment gateway
Order management
Email notifications
Product management
Inventory
Hosting infrastructure

But most of these weren't actually required.

The business only needed:

Products → Cart → WhatsApp order

So we started there.

What We Built

The customer-facing side has three main steps:

Browse products
Add products to the cart
Send the order directly to WhatsApp

The admin panel handles:

Adding products
Editing products
Uploading product images
Setting prices
Managing inventory

There is no unnecessary checkout flow or payment system.

The Architecture

For this MVP, we intentionally kept the architecture simple.

Frontend

Next.js

The customer website and admin interface are built with Next.js.

Hosting

Vercel

The application can be deployed on Vercel's free tier, which removes the need for a traditional server for this MVP.

Database

Supabase

The product data is stored in Supabase using its free tier.

The goal was to avoid paying for infrastructure before the business had validated the idea.

Why We Didn't Build Payments

The founder didn't need online payments.

Customers were going to place their orders through WhatsApp.

Adding Stripe or another payment provider would have introduced additional complexity without solving an actual business problem.

So we didn't build it.

The same principle applied to authentication and email notifications.

If a feature isn't needed to validate the business, it can wait.

The $0/Month MVP

With this architecture, the initial infrastructure cost can be $0/month using the free tiers of Vercel and Supabase.

That doesn't mean every ecommerce business can run indefinitely for free.

As traffic, storage, database usage, or business requirements grow, paid infrastructure may become necessary.

The goal here was different:

Validate the business before paying for infrastructure.

What I'd Add Later

If the business starts getting real traction, we can introduce features based on actual needs:

Online payments
Customer accounts
Order tracking
Automated notifications
Advanced inventory management
Analytics
More powerful admin features
Better order management

The important part is that these features can be added later.

We don't need to build everything on day one.

The Bigger Lesson

Good engineering isn't about building the biggest system possible.

It's about understanding the actual problem and choosing the simplest architecture that solves it.

In this case, the business didn't need Shopify.

It needed a product catalog and a way to turn a customer's cart into a WhatsApp order.

So that's what we built.

Start with what the business actually needs.

Then add complexity when the business earns the right to need it.