Building a SaaS application often seems like a technical issue: choose a stack, create a dashboard, set up a server, and then find users. In practice, the hardest part actually occurs before the first line of code is written—determining whether the problem you want to solve is truly felt, recurring, and costly enough to make people willing to pay.
SaaS, or Software as a Service, is software used over the internet with a subscription or periodic payment model. This model is appealing because revenue can be recurring, but customers can also easily cancel if the benefits are not clear. Therefore, product ideas should start from business problems, not from a list of features.
Attractive features are not necessarily important
Imagine someone creating an application to manage social media content schedules. The features are comprehensive: calendar, analytics, collaboration, notifications, and integration with many platforms. However, potential users may already be using spreadsheets, group chats, or other applications that they find sufficient.
The product could be very well made, but it would still be hard to sell because it does not solve an urgent problem. New features only add value if customers already recognize the costs of the old way—such as wasted time, repeated mistakes, lost opportunities, or work that relies too heavily on one person.
This is an important distinction between “a product that can be made” and “a product worth building”. The former is determined by technical capability. The latter is determined by market needs.
Start by mapping the most troublesome jobs
Before creating a prototype, make a list of tasks that potential customers perform regularly. Don’t just ask, “What application do you need?” Questions like this often yield overly general answers or are influenced by fleeting desires.
Use questions that are closer to real experiences:
- What tasks are most often delayed or need to be repeated?
- Which parts rely most on spreadsheets or manual messaging?
- What mistakes frequently incur costs?
- When was the last time this problem occurred?
- What have you tried to address it?
- Who is most affected if this problem remains unsolved?
Concrete answers are usually more useful than general opinions. Someone who says “this feature would be very helpful” may not necessarily use or pay for it. Conversely, someone who can show work files, manual workflows, and the costs of mistakes signals a stronger need.
Measure value, not just user numbers
The number of interested people is not the only measure of opportunity. What’s more important is the economic value of the problem. A product with one hundred customers who gain significant benefits can be healthier than a product with thousands of users who only try it once.
Use simple calculations to estimate value:
- How many work hours can be saved each month?
- How much can error costs be reduced?
- How much revenue or transactions are at risk of being lost?
- What are the current costs of applications or labor being used?
- How often does this problem occur?
For example, an administrative team spends 20 hours a month manually transferring order data. If the effective labor cost is Rp50,000 per hour, that task costs about Rp1 million per month. A product that can cut down most of that work has a clearer value basis than an application that only offers a more modern interface.
This calculation is not a final price. It is a tool to test whether the problem is significant enough to become a business.
Validate before building too far
Validation does not have to start with a perfect application. In fact, making a product too complete at the beginning can hide the weaknesses of the idea because time and costs have already become significant.
Some forms of validation that can be done include:
- Problem interviews. Talk to potential users about the processes they are running, rather than immediately selling a solution.
- Simple prototypes. Create screen flows using images or design tools, then ask potential users to explain how they would use it.
- Concierge service. Perform the process manually for a few customers. This method helps understand specific cases before everything is automated.
- Landing page. Offer specific benefits and measure whether people are willing to leave contact information or sign up for a trial.
- Paid pilot. If possible, ask for a small payment for the trial period. Financial commitment usually provides a stronger signal than just free registration.
The goal of this stage is not to seek praise. The aim is to find out why people may not want to use the product, and then refine assumptions before development costs escalate.
Build the first version for one important flow
The initial product does not have to solve the entire business process of the customer. Choose one flow that occurs most frequently and is easiest to measure the results.
For example, don’t immediately create a complete operational platform for an online store. Start with one clear problem, such as matching payments with orders or providing alerts when stock approaches minimum levels. If that flow successfully saves time and reduces errors, then other features can be added based on real needs.
Prioritize features with three questions:
- Does this feature solve the main problem?
- Can the results be measured?
- Will customers be disappointed if this feature is not available?
If the answers are not clear, that feature may not need to be included in the first version.
Design monetization from the start
Monetization is not a stage to be considered only after the product is finished. Pricing structure affects who the target customers are, what features must be available, and what operational costs can be borne.
For SaaS, some common approaches include per-user fees, fees based on the number of transactions, packages based on features, or usage-based pricing. The best choice depends on how customers derive value.
If the product's benefits increase with the number of users, a per-user price may make sense. If the main value comes from the number of transactions processed, a volume-based model may be more appropriate. Avoid mimicking competitors' pricing without understanding the relationship between price, value, and your own service costs.
Also, make sure to account for often-overlooked costs, such as data storage, third-party services, customer support, security, and time to handle specific cases.
What does this mean for us?
Technology business opportunities do not always come from the most complex ideas. Often, the biggest opportunities lie in repetitive, boring tasks that are still done manually—especially if those tasks directly impact money, time, or compliance.
If you are considering creating a SaaS or digital product, don’t start with the question “What features can I build?” Start with “Whose problem is significant enough for them to solve right now?”
After that, validate through conversations, prototypes, manual processes, and if possible, early payments. Technology remains important, but good technology will only yield a business if placed on the right problems.
– Rio Yotto @rioyotto