I'm dubious. The fact that there are valuable minerals in the Utah desert is not news. This feels less like a surprise discovery and more like someone trying to milk the current administration for support, as the bottom of the article points out that the USA is currently trying to get more mining going.

That point on the map is also a bit south of where suburban development ends, which would make it fairly valuable real estate as the metro area expands. So I got online to confirm whether it really was owned by the mining company. I know from my prior days doing my own prospecting in that area that most of the land there is public, owned either by the feds or the state. Funny thing - that specific parcel doesn't show the owner on the Utah county parcel map. It is just a blank spot in the data. But it does have historical photos and shows that the dig site at that point has been there since at least 2015, so this could be new finds, but the dig site is definitely not new.

It could be true - it could be a new find on land owned by a private company. I cannot prove otherwise, but something smells a little fishy here.

That touches on why I never pursued server-side React in any form. It seemed to twist what was a clean break between layers into spaghetti. I totally get that it solves other problems, but it always felt to me more like trying to force React to be something it was not. The better strategy seemed to me to use React on sites where users can handle the bulk of a front-end React app, and don't use it elsewhere.

Specific to security, keeping React 100% client-side keeps things simple: Don't trust the front-end.

Have you considered that perhaps such things simply are not within its capabilities?

I mean, one of its flagship features is to make precise edits to images. And it's really good at it... until it randomly isn't.

This is why I push for Kanban whenever I am a PO. If we can ballpark an estimate, I can prioritize it. If we cannot ballpark an estimate, I can prioritize the research to clear out some of the unknowns. But most importantly, we set an expectation of rolling feature rollouts, not inflexible release dates. We communicate both internally and externally the next few things we are working on, but no hard dates. The article correctly identifies that hard release dates communicated to customers are the root cause of problems, so I simply don't give such things out.

Sorry, but how does Kanban come into this?

From your description, SCRUM, could work just as equally.

Don't get me wrong, I'm a fan of Kanban, it's awesome for visually presenting where bottlenecks are for tasks, but estimations aren't a feature of that.

But SCRUM maybe, where people are having a sprint planning meeting maybe more what you're thinking?

Kanban in IT world in my experience implies approach where you focus on the work and tasks as they come based on priority. It doesn't imply what is on the board is finished strictly by some date, as the whole premise is that you can't really know.

SCRUM implies sprints where you agree in advance what will be actually pulled into sprints and delivered by the team so spillovers are not really expected / wanted.

I think that we are agreeing that Kanban and estimates aren't really analogous

When working with kanban I maintained a average number of card done per days. if someone asked when some card woud be done, I just multiplied the number of card ahead of that one by average and get an estimate. You can estimate the cards but usually it doesnt really improve accuracy as tasks are on average the same size.

No, most technical founders have visions that don't truly have a market. Instead, the best founders listen to what other people need, synthesize solutions that work for other people, and reflect other people's visions back to them as a viable product.

See the Show HN Guidelines: https://news.ycombinator.com/showhn.html

"Join the waitlist" is never a "Show HN"

> But the longer I use them, the more issues I notice with them

And that is why AI-generated SaaS apps are hype. Because a reliable SaaS is not easier to build. It is easier to launch a prototype. But building a robust, reliable app that solves a real problem in a way that is worth paying for is a completely different level of effort.

Yes absolutely. A lot of these apps are surface level great, but the you dig deeper and its really just as easy to build the same functionality yourself. Keeping in mind that these are all decently well funded projects.

Often the "issues" aren't even bugs, its more the realization that I want some sort of functionality that they do not have; and immediately realize that if I spend a weekend on my own "base system" for that use case of SaaS; I can just attach anything to it, rather than waiting for them to release something new in 1-2 months.

Currently, making a site accessible is more like a strong linter and a few standard UX elements (skip to content, etc.) Typically your tasks are things like: Increase the contrast on these 11 fonts, add missing labels, ensure keyboard navigation works. It is more of a checklist-type set of actions than a framework or library.

But it was supposed to be evolving, at least from a regulatory perspective. The Office of Civil Rights in the DOJ owns enforcement of this, and that team is pretty friendly and reasonable. Or was a few years ago... I haven't talked to them since the current administration came in, so don't what what their current state is. In any case, their plan a couple years ago was to stop making it about checklists and accessibility checkers and work towards a broader goal of "Make the UX as good for people with limits as it is for people without limits." They wanted to get away from, for example, solutions that would meet the letter of the law by making a non-mouse user hit tab 117 times when a mouse user only had to do one click.

So if you are really trying to do accessibility well, that is the perspective to embrace - not "give me a tool that fulfills a checklist", but "Make UX equitable for all."

In my experience, the communication problems stem from the Americans who expect perfect English from all others. English is spoken across the entire business world between people for whom it is not their first language. The accents and broken English is epic in many organizations. Yet they work through it and get things done together.

If you work harder at taking the burden upon yourself to understand others, you might be surprised how well people can learn to communicate despite differing backgrounds.

I have the same experience as you. I have been working with many non-native English speakers from different countries, and Americans (and to some degree Brits) are usually the ones who can't follow what is said. This improves over time as they get used to different accents, but it seems it is easier for non-native speakers to understand foreign accents than native speakers in general.

I'm not saying I always understand 100% of what is said. When someone with an accent from a specific part of a country speaks super fast and is on a poor line with lots of street traffic in the background, it can be hard to follow. But usually I catch enough of it to be able to communicate.

Normally I have had very good experiences as well. My colleagues almost always speak very good English and even those who don't are understandable. Everyone is happy to conduct meetings (with many nationalities, as I work in a scientific field) in English.

Only once have I encountered a problem. A colleague berated me in front of others for speaking "difficult English" and accused me of doing this on purpose to cause trouble for them, instead of speaking proper international English like everyone else did. But, I am a native English speaker with an RP accent and we were all in England at the time, working for a British organisation. I was simply speaking normally and otherwise had no issue with this colleague, whose English was very good. I don't recall their having been any misunderstandings between us before.

That’s just saying the same thing. American companies have engineering quality loss when they try to collaborate with people they can’t communicate well with. Whether it’s dumb Americans or poor ESL, it’s not really relevant to the outcome because it’s the same.

> given that people pay a monthly subscription, so c-sat is rather important.

You are missing a key aspect of what is going on. People buy streaming services based on the content, not the app. People will complain about the app, put bad reviews up, and still pay their monthly fee, which is better for the business than having zero tech complaints and cancelling because the content sucks.

in general yes, but there is still lost opportunity.

This is true for nearly any business until the scales tip in the other direction.

"People come to mcdonalds for the burgers not the bathrooms" until eventually enough pain points (bathrooms, service, punctuality, traffic etc) make them stop coming