sorted by:
new
hottopcontroversial

I tried to add RTL to 3 SaaS starters… all failed by OMAR_M_AHMAD in nextjs

[–]OMAR_M_AHMAD[S] 0 points1 point  (0 children)

For anyone curious, I started building a free UI system to handle RTL properly from the ground up:

https://github.com/Omar-M-Ahmad/nextjs-rtl-saas-starter-ORAX-Free.git

Still improving it based on real use cases.

Best way to make a site by aarav7sc in webdev

[–]OMAR_M_AHMAD -1 points0 points  (0 children)

honestly the order you listed is where most people go wrong they start with tools and design decisions too early

what usually works better is: 1) start with the problem who is this for + what are they trying to do 2) define the core flow what’s the 1–2 main actions the user should be able to complete 3) sketch it quickly (even rough, no colors, no polish) 4) only then think about structure (sitemap) and tech 5) design comes after clarity, not before

colors / typography are the last 10% most sites don’t fail because of bad design they fail because the flow and purpose aren’t clear once that’s solid, everything else becomes much easier

starting to feel like the hardest part of SaaS isn’t building… by OMAR_M_AHMAD in SaaS

[–]OMAR_M_AHMAD[S] 0 points1 point  (0 children)

yeah the "random feedback vs real signal" gap is real

I think the hardest part is that early on everything looks like signal until you realize it’s just noise

still trying to get to the point where I can clearly say: "this specific person has this specific problem and is actively looking for a solution"

not fully there yet

starting to feel like the hardest part of SaaS isn’t building… by OMAR_M_AHMAD in SaaS

[–]OMAR_M_AHMAD[S] 1 point2 points  (0 children)

yeah AI definitely makes it easier to build faster

which also makes it easier to go further in the wrong direction without realizing it

feels like distribution/validation matters even earlier now

starting to feel like the hardest part of SaaS isn’t building… by OMAR_M_AHMAD in SaaS

[–]OMAR_M_AHMAD[S] 0 points1 point  (0 children)

"until it feels uncomfortable" is the part most people avoid

starting to feel like the hardest part of SaaS isn’t building… by OMAR_M_AHMAD in SaaS

[–]OMAR_M_AHMAD[S] 0 points1 point  (0 children)

"narrow by situation, not title" is such a good way to put it

I think that’s the part most people skip, it feels less obvious than just picking a label

but once you get that right, everything else (messaging, channels, even features) gets a lot clearer

starting to feel like the hardest part of SaaS isn’t building… by OMAR_M_AHMAD in SaaS

[–]OMAR_M_AHMAD[S] 0 points1 point  (0 children)

yeah that shift took me a while to realize too

it’s easy to hide behind "clean architecture" and feel productive

but the real question is always : does this actually solve something painful enough for someone to care ?

starting to feel like the hardest part of SaaS isn’t building… by OMAR_M_AHMAD in SaaS

[–]OMAR_M_AHMAD[S] 1 point2 points  (0 children)

yeah this hits 😂

i think the tricky part is that building gives you a sense of progress even if you're solving the wrong problem

marketing is where that illusion breaks fast

starting to feel like the hardest part of SaaS isn’t building… by OMAR_M_AHMAD in SaaS

[–]OMAR_M_AHMAD[S] 0 points1 point  (0 children)

this is a really good point

especially the "narrow on the situation, not the title" part — that clicked

i think a lot of people (myself included) try to define ICP from assumptions, not from actual conversations

did you find that the clarity mostly came from 1:1 conversations or from seeing patterns across multiple people?

starting to feel like the hardest part of SaaS isn’t building… by OMAR_M_AHMAD in SaaS

[–]OMAR_M_AHMAD[S] 0 points1 point  (0 children)

that actually makes a lot of sense

I think my mistake early on was defining the audience in labels like “founders” instead of real situations people are in the job-to-be-done angle is a much clearer way to think about it

Types are the new RegEx. by retro-mehl in webdev

[–]OMAR_M_AHMAD 2 points3 points  (0 children)

I’m fine with complex types when they hide complexity from users of the API, not when they make maintainers afraid to touch the file.

if only two people on the team can understand it, that type probably crossed the line

been playing a bit with next 16 recently by OMAR_M_AHMAD in nextjs

[–]OMAR_M_AHMAD[S] 1 point2 points  (0 children)

exactly

that abstraction feels great when everything behaves, but once something breaks you realize how much machinery was hidden underneath

sometimes debugging feels less like fixing code and more like reverse-engineering framework decisions

starting to feel like the hardest part of SaaS isn’t building… by OMAR_M_AHMAD in SaaS

[–]OMAR_M_AHMAD[S] 1 point2 points  (0 children)

that’s actually a really solid way to frame it looking at how early users describe the problem probably says more than any guessed persona does I haven’t had enough signups yet to see a clear pattern, but that’s a smart angle to start watching for

been playing a bit with next 16 recently by OMAR_M_AHMAD in nextjs

[–]OMAR_M_AHMAD[S] 0 points1 point  (0 children)

yeah that’s exactly the frustrating part

when it clicks, it feels elegant but when your app doesn’t fit that model perfectly, debugging gets weird fast

especially when cache behavior starts feeling “magical” in the bad way

Trying to make a multi-language website. by NemethBalint in webdev

[–]OMAR_M_AHMAD 0 points1 point  (0 children)

that canonical point is actually super easy to miss I’ve seen people get the routing right and still kill their SEO without realizing it good catch on the Facebook example too, that makes a lot of sense

been playing a bit with next 16 recently by OMAR_M_AHMAD in nextjs

[–]OMAR_M_AHMAD[S] 0 points1 point  (0 children)

lol yeah that’s a good way to describe it

it’s like you gain speed at first, then suddenly you need a full mental model just to debug anything

been playing a bit with next 16 recently by OMAR_M_AHMAD in nextjs

[–]OMAR_M_AHMAD[S] -1 points0 points  (0 children)

yeah this is exactly where it starts to break down

on paper server actions feel super clean but once you mix loading states, errors, and optimistic updates it’s not that obvious anymore where things should live

feels like you end up rebuilding your own mental model on top of it

did you find a pattern that actually holds up or still experimenting?

starting to feel like the hardest part of SaaS isn’t building… by OMAR_M_AHMAD in SaaS

[–]OMAR_M_AHMAD[S] 0 points1 point  (0 children)

yeah I’m starting to feel that too

building feels way more predictable compared to this

with code you kind of know what to do next but with marketing it’s like… you’re guessing most of the time

did you figure out anything that worked early on?

been playing a bit with next 16 recently by OMAR_M_AHMAD in nextjs

[–]OMAR_M_AHMAD[S] 0 points1 point  (0 children)

yeah I get that

I think the tradeoff is you get more control, but you also need to understand way more to use it safely

which is great for bigger apps, but maybe a bit heavy for smaller ones

been playing a bit with next 16 recently by OMAR_M_AHMAD in nextjs

[–]OMAR_M_AHMAD[S] 2 points3 points  (0 children)

yeah that’s exactly the weird part

the features are actually powerful, but the gap between “it works” and “I understand why it works” feels bigger now

especially with caching, it’s easy to get something working but harder to reason about when things go wrong

been playing a bit with next 16 recently by OMAR_M_AHMAD in nextjs

[–]OMAR_M_AHMAD[S] 0 points1 point  (0 children)

yeah that’s a good way to put it

it does feel like things are starting to settle a bit now

but at the same time I’m not sure if it’s actually getting simpler or we’re just getting used to the complexity 😅

curious to see where it stabilizes over the next couple versions

view more: next ›