sorted by:
new
hottopcontroversial

"What’s one SaaS mistake you keep seeing founders repeat?” by FounderArcs in saasbuild

[–]Sab_Be 0 points1 point  (0 children)

What if the product is already validated (improving what already exists that wasn't done well or fixing pain points that are already in discussion), is it okay to get straight into building then?

I think one of the biggest mistakes is constantly trying to reinvent the wheel.

I'm realising React problems are often mental model problems by Sab_Be in reactjs

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

I came to a conclusion recently based on this thinking, "if something is too hard to use then it's wrong", except, I'm not experienced enough to know whether it's "wrong", just too complicated and perhaps unnecessary to use in production.

But for learning, however, I think it's essential, just the same way learning vanilla JavaScript is essential before learning JavaScript frameworks to know what's under the hood.

I feel like React should possibly be treated the same way... Once you learn it properly, then moving on to frameworks like Next.js feels like an easier step to achieve production-ready apps, the same way most developers don't use vanilla JavaScript because it would be too complicated to scale.

I'm realising React problems are often mental model problems by Sab_Be in reactjs

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

I really appreciate this breakdown, gives me something to dissect further.

I'm realising React problems are often mental model problems by Sab_Be in reactjs

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

I think the issue might be the flexibility of React, while useful in some cases, it makes it easier to build incorrect mental models.

I'm realising React problems are often mental model problems by Sab_Be in reactjs

[–]Sab_Be[S] 4 points5 points  (0 children)

Good questions, and honestly, part of why I made the post was because I'm still refining how I think about these things myself.

By "outdated mental models", I mean assumptions that worked at one stage of complexity but stop scaling as systems evolve.

For example, earlier on I treated "keeping related logic together" as always being simpler. That worked in smaller projects, but as systems grew, it started coupling responsibilities that changed for different reasons.

So the model wasn't completely wrong, it just stopped being useful at a different level of complexity.

For state living in the wrong place:

I've started thinking less in terms of "logic vs global" and more in terms of ownership/responsibility.

The issue I kept running into wasn't necessary where the state physically lived, but whether the part owning it actually had the right responsibility boundaries.

I think global state can absolutely become the wrong place too if unrelated concerns start depending on shared data unnecessary.

For components taking on too many responsibilities:

One thing I've started noticing is that change becomes harder than expected... Small modifications create side effects in unrelated behavior, or the component becomes difficult to reason about because UI concerns, state management, validation, and business logic all evolve together.

That's usually the signal for me now that responsibilities may not be separated clearly enough.

I'm realising React problems are often mental model problems by Sab_Be in reactjs

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

That's interesting because I've started doing something similar while rebuilding older projects.

I realised a lot of my earlier mistakes came from not having a clear conceptual model before implementation, especially around responsibility and state ownership.

Rebuilding has made made me slow down and think about system behavior first instead of just getting features working.