For the layperson definition of project, of course you're right.
The problem is the professional definition of project, which comes with project management practices and preconceptions.
Those are generally harmful, because they try to manage or control both time and resources needed to deliver unknowns in advance of an inherently discovery-based process that results in (re-)scoping as you learn:
https://en.wikipedia.org/wiki/Project_management_triangle
> It sounds like you prefer to work in an env where there are only fixed-time, variable scope projects. I like that better too.
I posit it's not just "prefer", it's reality. That all "projects" are in fact "fixed time, variable scope" in hindsight. In other words, "it takes as long as it takes" to uncover and ship a minimum viable scope for the "job to be done".
As an entrepreneur, it's preferable to create a workplace that acknowledges that reality up front, and designs the "way of working" for it.
As an engineer, it's preferable, as you note, to join one.
---
Some more musings:
The OP's post says work stops being fun. A key reason why is all the unfortunate beliefs, management overhead, and recrimination for practices trying to override reality and failing.
Small startups don't care. The cost of 5 people being wrong seems irrelevant compared to charging at the problem and getting it done, or finding out it doesn't work so you can pivot. How many "Show HN" are after a pivot? How many "Launch HN" for that matter?
Enterprises care. The cost of 500, or 5000, building the "wrong thing" seems unacceptable (even if less cost per person!), so big companies keep piling on layers of risk management that delay getting in touch with reality.
One reason they do this is the value of the outcome isn't clear. Perhaps it's political, perhaps it's make-work to keep someone's department full sized, perhaps it's a failure of imagination. So they develop scar tissue about shipping multi-year boondoggles that deliver no value. The problem was, it wasn't valuable in the first place, and if they'd just tried it out in the small and iterated, they'd have learned with fewer man-hours than all the planning.
For a great take on this, see Tom DeMarco (author of Peopleware) rethinking his entire stance on projects after 50 years(!) trying to tell people how to project-manage better:
https://www.computer.org/csdl/magazine/so/2011/06/mso2011060...
He even throws in the towel on estimation with the now famous phrase, "All projects that finish late have this one thing in common: they started late."
He effectively accepts reality: the needful is the needful, the value is the value, so if it's valuable you'll do what you have to do, just start already and get it done.
What I've found is, a big enterprise can understand this. The CEO can hold his business leaders accountable to telling the value that an effort should generate, the CFO can "venture capital" an appropriately sized investment in a fixed capacity team, and the team can focus to deliver value -- or offer a pivot -- before they run out of funding and can't raise another round.
If they're shipping well, and getting market traction, the business leader looks good, the CEO is happy, and the CFO can continue to invest. One neat thing with this is the remarkable "budget" predictability that comes with investing in teams instead of in projects. Control your capacity and focus, you'll always hit your expense numbers, with net higher RoE as a nice side effect. So not only are customers getting value early, boards and shareholders are impressed with "hitting the numbers".
So this solves that iron triangle.
By continually focusing in on shipping what brings high RoE, you can let "the business" pick any arbitrary amount of time (quarterly? annually?) to announce sets of new features as releases. You can keep teams steady and employed delivering instead of wastefully scaling up then laying off as if tacit knowledge loss didn't have a cost.
And people can feel good about building value they can see as they work.