From my experience I'd say yes— devoting time now while the rest of the app isn't as built out is a good time to make sure you get your bases covered on authentication and account for everything you want. Once you really get rolling it will be harder to devote the brain power to get auth right.

You now have the freedom to really take the right approach with this, make sure there's a ton of testing around this important part, and things will feel easier if you make it a strength from day 1.

My cynical answer is: unless you have a minimum feature set users want you don't have a product. Whether it has authentication or not is kind of secondary to this.

This unfortunately leads to a horrible quality cycle, one I cover in are we forever cursed with buggy software

More constructively perhaps, if detailed authentication is a critical feature then adding it now might make sense. But if simpler authentication is acceptable, you may be fine adding it on later.

My advice: integrate authentication early, but don't reinvent the wheel. Find an OSS solution (Hydra looks interesting) or SaaS provider (like Auth0) that can handle the hard parts for you. It's really easy to mess up something as complex and important as authentication.

One approach that's worked well for me is to find some sort of simple, extensible middleware (like Passport in Node or PAC4J in Java) that can abstract away authentication (and possibly authorization too). Then, I add it to my project, with the most basic setup possible (like using HTTP Basic Auth against a hard-coded list of usernames and password hashes). Then, I work on implementing some of my core services. When I get to the point that someone else might want to call the service (like an alpha or beta user), I deal with the more complicated configuration necessary to add in a full-featured authentication engine.

I will say, though, that if you go with something like Auth0, you can skip the "basic setup" part, since integrating with those types of services is usually quite simple.