DEV Community: Haseeb Sheikh

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.