Have a SaaS Idea? What to Validate Before You Pay for Development

A founder has an idea, opens a document and starts writing features.

Dashboard.

Subscriptions.

Teams.

Notifications.

AI assistant.

Mobile app.

Admin panel.

Then the question becomes:

How much will it cost to build this?

There is an earlier question that can save much more money:

What must be true for this product to deserve being built?

Before paying for months of development, validate the assumptions that can kill the business even if the software works perfectly.

Because technical execution is only one category of risk.

A working product is not proof of a business

Software can be fast, secure and beautifully designed while solving a problem nobody cares enough to pay for.

A SaaS business needs more than functioning code.

At minimum, there must be a credible relationship between:

Problem → Buyer → Value → Acquisition → Usage → Revenue → Retention

Development proves that software can exist.

It does not automatically prove the rest.

Start by writing the problem without mentioning your product

Try completing this sentence:

[Specific person/company] repeatedly struggles with [specific problem], which currently causes [measurable consequence].

For example:

Operations managers at service companies manually reconcile job status across WhatsApp and spreadsheets, making it difficult to know what is delayed and who owns the next action.

That is testable.

Compare it with:

Companies need an AI-powered operations platform.

The second sentence already assumes the solution.

You cannot validate a problem if you define it using your product.

Validate who actually has the problem

“Businesses” is not a customer segment.

Neither is “startups.”

Narrow the first buyer enough that you can find real people who share similar conditions.

You may define them by:

• Industry.
• Company size.
• Role.
• Workflow.
• Existing software.
• Geography when it materially affects the problem.
• Trigger event.

A useful early segment is not necessarily your final market.

It is the group where learning is easiest and the problem is clearest.

Separate user, buyer and decision maker

The person using the software may not be the person paying for it.

An employee may use the product every day.

A department manager may own the budget.

IT or security may approve the integration.

Finance may approve the contract.

For B2B SaaS, map at least:

User → Champion → Buyer → Approver

Sometimes one person occupies all four roles.

Sometimes they are completely different.

This affects the product, sales process and pricing.

Ask what they do today

One of the strongest signals is not what somebody says they want.

It is what they already do.

Ask:

• How do you handle this today?
• Which tools are involved?
• Who does the work?
• How often does it happen?
• What breaks?
• What happens when it breaks?
• Have you tried to fix it before?

A spreadsheet that has survived for five years may be ugly, but it is a competitor.

Doing nothing is also a competitor.

Your product must beat the current behavior, not merely another SaaS logo.

Look for evidence of pain, not compliments

People are polite about ideas.

“This sounds useful” is weak evidence.

More meaningful signals include:

• They already spend money on the problem.
• Employees spend significant recurring time on it.
• They built an internal workaround.
• They combine several tools to solve it.
• The problem creates delays, lost opportunities or operational risk.
• Somebody is responsible for improving the metric affected by it.
• They actively search for alternatives.

You want evidence that the problem changes behavior.

Do not ask: “Would you use this?”

Hypothetical questions create hypothetical enthusiasm.

Ask about past and current behavior instead.

Weak:

Would you pay for a tool that automates this?

Stronger:

When did this problem happen last?

What did you do?

How long did it take?

Who was involved?

What are you currently paying for the tools used in that process?

What prevented you from solving it already?

Past behavior gives you something concrete to investigate.

Validate urgency

A painful problem can still be a bad first SaaS opportunity if nobody needs to solve it now.

Ask what creates urgency.

Possible triggers include:

• Growth makes the manual process fail.
• A new team or location is opening.
• Existing software is being replaced.
• Customer volume has increased.
• Compliance or contractual requirements changed.
• A key employee can no longer carry the process manually.
• Management has set a specific operational target.

A useful question is:

Why would this company change now instead of six months from now?

Without an answer, sales may become much harder than product development.

Validate willingness to change, not just willingness to pay

Money is not the only switching cost.

A new SaaS product may require customers to:

• Import data.
• Train employees.
• Change workflows.
• Connect systems.
• Ask IT for approval.
• Change customer behavior.
• Stop using a familiar tool.

A product can have positive ROI and still fail because the migration cost feels too high.

Your validation should ask what must change for adoption to happen.

Understand the existing alternatives

Search for the products your customer could use instead.

But also include non-software alternatives:

• Excel.
• WhatsApp.
• Email.
• An assistant.
• An agency.
• An internal developer.
• A manual process.
• A feature inside a larger platform.

Then ask:

Why is the current alternative not good enough for this specific segment?

If you cannot answer that clearly, building another tool may not create enough reason to switch.

Your competitor may be a feature, not a company

Suppose you want to build a standalone reporting SaaS.

The customer may already receive “good enough” reporting inside their CRM.

Your product is therefore competing with an existing feature bundled into software they already pay for.

That changes acquisition and pricing dramatically.

Competitive research should follow the workflow, not just category names.

Validate the acquisition path before the product is ready

Many technically strong products fail because founders discover distribution after development.

Ask:

How will the first 20 relevant customers hear about this?

Not the first million.

The first 20.

Possible paths include:

• Existing network.
• Direct outbound.
• Search demand.
• Communities.
• Partnerships.
• Existing audience.
• Marketplace distribution.
• Open-source adoption.
• Content.
• Paid acquisition.

You do not need a perfectly scalable channel yet.

But you need a believable way to reach the people you want to learn from.

Test distribution manually

If your planned acquisition channel is outbound, try contacting prospects before building the product.

If it is search, investigate whether people actually search for the problem and what they expect to find.

If it is a marketplace, understand listing requirements and existing alternatives.

If it is an audience, publish around the problem and see who responds.

Distribution is also an assumption that can be tested.

Validate the promise before the interface

A landing page can be useful before a complete product exists.

But the important part is not the design.

It is the promise.

A strong early landing page should communicate:

1. Who it is for.
2. What painful outcome it addresses.
3. How the approach is different enough to matter.
4. What the visitor should do next.

The call to action may be:

• Join a waitlist.
• Request early access.
• Book a discovery call.
• Start a pilot.
• Submit a workflow for evaluation.

The right CTA depends on how much commitment you need to test.

A waitlist is not product-market fit

Email addresses can be useful evidence of interest.

They are not proof that people will adopt, pay or stay.

The closer your test gets to real behavior, the stronger the evidence.

A rough evidence ladder might look like:

Page view → Email signup → Conversation → Workflow/data shared → Pilot commitment → Payment → Repeated use → Renewal

Each step asks the customer to give something more valuable: attention, time, access, money or behavior change.

Validate willingness to pay carefully

Pricing research is difficult because asking directly can produce unreliable answers.

Instead, understand the economics of the problem.

What does the customer spend today?

What employee time is involved?

What revenue, delay, error or risk is affected?

What alternative products cost money?

Who owns the budget?

Then test an actual offer when appropriate.

A real pilot proposal teaches you more than asking someone to choose a hypothetical price from a survey.

Do not start with a giant pricing page

Early pricing is an experiment.

You need enough structure to test whether the business model makes sense, not ten plans with complex feature gates.

For B2B SaaS, you may initially need to understand whether value scales with:

• Users.
• Locations.
• Transactions.
• Usage.
• Data volume.
• Revenue managed.
• Workflow volume.

Choose a pricing unit customers can understand and that has some relationship to the value created.

Then learn.

Identify the riskiest assumption

This is one of the most important exercises.

List assumptions such as:

• Customers have this problem frequently.
• The buyer can approve budget.
• They will connect their CRM.
• AI can classify the data accurately enough.
• They will trust automation for this action.
• We can acquire customers through search.
• They will pay enough to support the operating cost.

Then ask:

Which assumption, if false, kills the business fastest?

Test that one early.

Do not spend three months proving a feature is technically possible while the biggest risk is whether anyone will switch.

Your MVP should test an assumption

MVP does not mean:

Build every feature badly.

It means building the smallest credible product or process that tests the important uncertainty.

If the risk is demand, the MVP may be a landing page and manual service.

If the risk is workflow adoption, the MVP may be one end-to-end workflow.

If the risk is AI quality, the MVP may be an evaluation pipeline before a customer-facing UI.

If the risk is integration, the MVP may be one production connector.

Scope follows the uncertainty.

The MVP can contain manual work behind the scenes

Suppose your future product will automatically analyze a company's data and recommend actions.

For the first customers, part of that process can be manual if the customer experience still tests the core value.

This is sometimes called a concierge approach.

The goal is to learn whether the outcome matters before automating every internal step.

Do not fake capabilities or mislead customers about what is automated.

But do not build infrastructure merely to automate a process you have not validated either.

What should version one actually include?

A useful question is:

What is the smallest complete journey that produces the promised outcome?

Not the smallest number of screens.

A customer should be able to go from problem to outcome.

For example:

Connect source → Import leads → Qualify → Review → Send to CRM

That may require authentication, one integration, a review screen and a background job.

It may not require:

• Ten integrations.
• Native mobile apps.
• Advanced analytics.
• Team permissions for every enterprise scenario.
• White labeling.
• A public API.

Those can wait until evidence requires them.

Separate table stakes from differentiation

Some capabilities are necessary for the product to function but do not prove the idea.

Authentication is important.

Password reset is important.

Billing is important when charging customers.

But spending most of the first build polishing commodity infrastructure can delay learning about the unique value.

Use mature frameworks and services for commodity components where appropriate.

Put custom engineering into the risky or differentiating workflow.

Don't overbuild architecture — but don't build a dead end either

“It's only an MVP” is not permission to ignore basic engineering.

You still need reasonable decisions around:

• Data ownership.
• Security.
• Backups.
• Deployment.
• Observability.
• Migrations.
• Core domain model.

But you usually do not need architecture for millions of users before you have ten.

Build for the next credible stage and keep boundaries clean enough to evolve.

Multi-tenancy deserves an early decision

For SaaS, tenant separation affects the data model, authorization and testing.

You do not necessarily need the most sophisticated multi-tenant architecture on day one.

But you should know what constitutes a tenant and how data is isolated before customer data starts accumulating.

That is much cheaper than discovering the boundary later.

Billing should follow the business model

Do not integrate every billing scenario before knowing what customers buy.

But if payment is one of the assumptions you need to validate, do not hide it until the end either.

The product architecture should support the pricing experiment you are actually running.

AI SaaS has additional validation questions

If the product depends on AI, add another layer of risk.

Ask:

• Can the model perform the task on representative real data?
• What is the failure rate?
• What happens when it is uncertain?
• Does a human need to review the result?
• What is the inference cost per successful task?
• Does the data require a private architecture?
• Will users trust the AI with this decision or action?

Build an evaluation set early.

Do not validate an AI product with five impressive demos.

Measure the outcome, not demo quality

A demo can make people say “wow.”

A product needs to make them come back.

Define what success means for the first pilot.

Examples:

• Time to complete a workflow.
• Number of manual handoffs removed.
• Percentage of cases completed without intervention.
• Qualified leads produced.
• Errors caught.
• Tasks completed per employee.

Choose metrics connected to the problem you claimed to solve.

Retention is where the truth becomes clearer

Acquisition tells you somebody was interested enough to try.

Retention tells you whether the product continues to matter.

The appropriate retention period depends on the workflow.

A daily operations tool and quarterly compliance tool should not have the same usage expectations.

Ask:

When should a successful customer naturally return?

Then measure behavior around that cycle.

Talk to people who stopped using it

Early founders naturally spend time with happy users.

Churned or inactive users often contain more useful information.

Ask:

• What were you trying to accomplish?
• Where did the workflow break?
• What did you use instead?
• Was the problem less important than expected?
• Was switching too difficult?
• Did another stakeholder block adoption?

Do not turn the conversation into a sales call.

You are investigating the failure mode.

Beware of custom-development disguised as SaaS

An early B2B product may need configuration for customers.

That is normal.

But if every new customer requires weeks of unique code, you may be operating a software consultancy with a shared codebase rather than scalable SaaS.

That can still be a good business.

Just understand the economics.

Track which requirements are:

• Configuration.
• Integration.
• Product feature.
• Customer-specific development.

The distinction becomes important as you scale.

Validate support and onboarding cost

A customer paying a subscription can still be unprofitable if onboarding and support consume excessive human time.

Measure:

• Time to onboard.
• Number of implementation calls.
• Data cleanup required.
• Support requests.
• Manual operations your team performs.

These are part of product economics.

A practical pre-development checklist

Before committing to a substantial build, I would want reasonable evidence for these questions:

Problem

• Who has it?
• How frequently?
• What does it cost them?
• What do they do today?

Buyer

• Who uses the product?
• Who pays?
• Who can block adoption?

Urgency

• Why change now?

Competition

• What are the software and non-software alternatives?

Distribution

• How will we reach the first relevant customers?

Economics

• What value can the product create?
• What might customers pay?
• What does delivery cost us?

Product

• What is the smallest end-to-end outcome?

Technology

• What technical assumption is genuinely risky?

Evidence

• What have real potential customers actually done that supports our assumptions?

You do not need certainty.

You need enough evidence to justify the next investment.

A sensible sequence for many SaaS ideas

A practical progression can look like:

Problem interviews → Manual research → Offer → Landing page → Conversations → Prototype → Pilot → MVP → Paid usage → Retention → Expansion

Not every product follows this exact order.

The principle is to increase investment as evidence increases.

When should you start coding?

Coding should start when software is the cheapest credible way to answer the next important question.

Sometimes that is very early because the technical feasibility itself is the biggest risk.

Sometimes you can learn for weeks without writing production code because demand is the bigger uncertainty.

The right milestone is not:

“We finished validation, now we build.”

Validation continues after launch.

The better question is:

What do we need to learn next, and what is the cheapest reliable experiment that can teach us?

What I would avoid before the first real evidence

Unless the use case requires it, I would be cautious about investing heavily in:

• Multiple native applications.
• Complex enterprise permissions.
• Large integration catalogs.
• Advanced analytics.
• Multi-region infrastructure.
• Sophisticated AI orchestration.
• Large admin systems.
• Extensive customization engines.

Every feature should earn its way into the roadmap through a real requirement or tested hypothesis.

The founder's job before development

Before asking an engineer to turn the idea into code, turn the idea into a set of testable statements.

For example:

We believe operations managers at X type of company lose Y kind of value because of Z workflow.

We believe they currently solve it using A and B.

We believe they can be reached through C.

We believe a product that delivers D outcome will justify changing their current process.

Now each statement can be challenged.

That is far more useful than a 70-feature specification.

Have a SaaS idea and deciding what to build first?

Bring the idea, target customer and current assumptions.

We can map the riskiest assumptions, define the smallest useful experiment and decide whether the next step should be research, prototype, MVP or production development.

Discuss your SaaS or MVP with Fady Mondy.

I help founders move from idea to evidence to production — without spending the first budget on features that have not earned the right to exist.

---

Related: MVP Development, SaaS Development, SaaS vs Custom Software, Product Engineering, Custom Software Development and AI ROI.