Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
How to start building SaaS Application?
#1
The daily posts on this forum, where many of you are launching your SaaS concepts and seeing remarkable success, captivate me. I have a background in software engineering, so I can attest to the time and work needed for these kinds of projects. I'm interested in your methods for developing a SaaS because of this.

How do you verify your concepts before making a firm commitment? Are you developing your MVP with low-code or no-code tools? As lone proprietors, how do you manage both the front-end and back-end elements, including hosting, security, authentication, and frameworks like React, Vue.js, Django, and Node.js?

It all seems so overwhelming. What are your strategies and suggestions for how to build saas application?

You’ll have more luck picking a boring market that already has product–market fit.

Not AI prompt tools. Not a crypto-powered task manager. Just a market where people already pay for solutions, complain about those solutions, and are actively looking for better ones.

That’s where the gold is.

If I were starting over, I’d spend my first week doing deep research:

Make a list of the top 5–10 tools in a specific vertical (like support tools, internal dashboards, CRMs)
Study their landing pages and pricing
Dig through their review sites, Twitter mentions
Reach out to a few customers and just ask what they love, hate, and wish they could change
Look for patterns in the complaints — recurring pain points. Pick a few of the biggest ones and build something that’s intentionally simple and focused on just those.

You don’t need to create a new market or invent something never seen before.

You just need to slot into an existing one with a better experience, better customer service, and enough clarity to win over early users.

Every user is worth more than just their monthly payment.

They bring ideas, context, edge cases, and sometimes even your next best feature idea — just not in the form you expected.

One of the most powerful things you can do early on is create a tight feedback loop. Make it easy for users to leave feedback, and make them feel comfortable doing it. Whether it’s a short email reply, a message in your widget, or a public suggestion — the feedback is gold.

I built UserJot to solve exactly this. It gives you a clean public board with upvotes, categories, and a way for users to see what’s being worked on. You can use any tool really, but the key is: make your customers part of the process.

And don’t just listen to compliments.

“The UX is confusing.”

“I didn’t realize I could click that.”

“This integration broke.”

Those messages matter far more than “I love this!”

Sometimes your best product decisions come from the smallest friction points.
Reply
#2
Thumbs Up 
Alright here's roughly how I'd break it down:

  1. Pick the boring stack. Don't overthink this part. next.js/rails/laravel + postgres + stripe for billing + something like clerk/auth0 for auth. These are solved problems; don't reinvent them. I've seen people burn 3 weeks evaluating frameworks before writing a single line of actual product code; that time is rarely worth it at this stage.
  2. Scope down hard. Most first SaaS builds fail because people try to build "the platform" instead of one sharp feature. Figure out the ONE workflow someone would pay for, build only that. If you can't describe what your MVP does in one sentence without an "and" in it, it's still too big.
  3. Multi-tenancy from day one, even if it's basic (just a tenant_id column and row-level scoping). Retrofitting this later is genuinely painful. I've watched teams lose a month migrating a single-tenant schema into a multi-tenant one after they already had paying customers on it. Bake it in early, even if 99% of your queries don't need it yet.
  4. Billing before you think you need it. Stripe checkout + webhooks for subscription status is like a day of work now, way more if you bolt it on after you have real users, real edge cases (failed payments, upgrades, downgrades, refunds), and no room to break things.
  5. Deploy early, deploy ugly. Vercel/railway/render, whatever gets it live fastest. Don't spend weeks on infra before you know if anyone wants this. A slightly janky product that's live beats a polished one sitting on your laptop.
Once the technical skeleton's up, get 5-10 real users on it before building anything else, teams, permissions, integrations, all of that comes after, not before. Watch what they actually do, not what they say they'll do. Half the "must-have" features people ask for during interviews never get touched once they're actually using the product.

The thing that's easy to underrate in all this. How the product looks and explains itself on first load matters as much as the stack choice, because a confusing landing page kills signups before anyone judges the product itself. You can have the cleanest codebase in the world and still lose 80% of visitors in the first 10 seconds if they can't tell what the product does or who it's for. Ended up specializing in saas design work after seeing this sink otherwise solid builds, not because the tech was bad, but because nobody stuck around long enough to find out. Happy to look at anyone's landing page if it's useful, even just for a quick gut check.
Reply




Users browsing this thread: 1 Guest(s)

About Ziuma

ziuma is a discussion forum based on the mybb cms (content management system)

              Quick Links

              User Links

              Advertise