What to decide before you build a SaaS app

If you are searching for how to build a SaaS app, it is tempting to start with screens, features, architecture, pricing, or the name. Those subjects will matter later. They do not yet prove that someone will use and pay for the product.

Before the first version, decide who pays, what job the software actually does, and what is left out.

Those three decisions are more useful than a long feature list. They force you to describe demand in a way that can be checked with real people.

Who pays

Name the person who would pay.

Not companies. Not teams. Not “users”. One person with a responsibility, a frequent enough problem, and a reason to change how they work.

A useful sentence sounds like this: “The operations manager at a multi-site service business pays because incoming requests take too long to consolidate.” Or: “The founder of a small agency pays because client approvals keep falling back on them every week.”

This is not positioning work yet. It is a reality check. If you cannot name the person, explain why the problem belongs to them, and say why they would try something now, your first version is probably answering a vague demand.

A common trap is building for several profiles while none of them clearly owns the purchase. The product may be useful to daily users, but if nobody carries the problem at the level of budget, adoption, or decision, the SaaS will be hard to launch.

So before any screen, ask who could decide to try this in a real setting. If the answer requires a whole committee from day one, the scope is probably still too broad.

The job the software does

Now write the job in one sentence.

One person arrives with a situation and leaves with a result. The sentence should be concrete, short, and verifiable.

“Improve collaboration” is not enough. “Help teams manage projects” is not enough either. Those phrases describe a category, not a first product.

A useful sentence is closer to: “A team lead receives a request, gets it approved, and can find its status without chasing everyone.” Or: “An operations coordinator collects incoming documents and knows which files are complete without checking each one by hand.”

One job. If the sentence needs “and also”, you probably have two products, or at least two different versions.

This is usually the uncomfortable part. Many ideas feel close. Many use cases sound legitimate. It is easy to add a second profile, a reporting view, a configuration module, or an integration that feels obvious. At this stage, SaaS product development is cutting until the first job is true.

If you are unsure whether the job is narrow enough, test it with a simple question. Could a person use the first version this month for that one job, even if many surrounding tasks still happen elsewhere? If yes, you may have a strong starting point. If no, the job is probably still too broad.

What the first version leaves out

A SaaS MVP is not a small copy of the full product. It is the smallest version that lets the right people try the main job.

That distinction matters. A small copy tries to represent every future area of the product, just with less depth. A real MVP makes one path possible from end to end: problem, action, result.

That means you must write what is out.

The advanced reports are out.
The second type of user is out.
The settings nobody asked for are out.
Rare cases are out.
Automations that would make the product more comfortable later are out, if the core job can already be tried without them.

In practice, the first version is defined as much by this list as by the features it includes.

For every idea, ask a blunt question: can a real person still try the main job without this? If yes, leave it out for now. If no, it may need to stay.

This protects your learning. If the first version covers too much, feedback becomes noisy. People comment on preferences, settings, and edge cases before you know whether the core job is worth solving in this form.

A strong first version rarely looks like the product you imagine long term. It looks more like a narrow path that can be walked from start to finish.

What not to decide yet

Some decisions feel productive because they are visible. They are often too early.

The exact name, a full pricing grid, a marketplace, a mobile app “because everyone has one”, a partner program, a complex role system: all of that can wait until someone who is not you has used the first version.

This does not mean improvising. It means protecting the project’s attention. Before real use, many decisions are theoretical. They will be better once you have actual objections, real wording from buyers, and feedback on the main job.

The risk is not only building the wrong thing. It is also deciding too early on subjects that depend on real use. Pricing, messaging, and segmentation may change when you discover who truly feels the problem and in what context.

At this stage, the useful sequence is not a full roadmap. It is a decision sequence: payer, job, exclusions.

A week of decisions

You can do the most important pre-build work in a week if you keep it concrete.

1. Write who pays, in one line.
2. Write the job, in one line.
3. Write three things the first version will not do.
4. Find five people who match the payer.
5. Ask whether they would use the first version for that job this month.
6. Note the exact words they use to describe the problem.
7. If they describe a different job, change the sentence before you build.

This is not market theater. The goal is not compliments. The goal is to see whether these people recognize the problem as theirs, describe the same result you described, and have a reason to try soon.

If they use different words, pay attention. If they point to a neighboring but different need, tighten the job. If they do not feel urgency, the first version may still be too broad or too comfortable.

This week gives you a better starting point than a long feature list. It helps you decide what goes in, what stays out, and what waits.

What comes next

Starting, here, means those three decisions are written down and checked with real people. The build comes after.

Once you have that, you can shape a first version around a buyer, a job, and a clear set of exclusions. If you want help turning those decisions into a focused first product, Perfusion can help.