For one of my webserver platforms, SHPS, I designed authorization to be key-bound. You can define keys, check if a user has a key, and based on that let them perform actions. Users can be part of groups, and keys can be assigned to groups, too. Basically a lot like how AD etc. works. I don't know if there's a name for it, but I call it key-based authorization, and it's very fine-grained, so you can have "normal" users, "admins", and everything in between.

I would not go with a single property on the front end like 'type' i would keep the role based permissions in the backend. Like admins will have different permissions and normal users different. You also may create a relation table like groups to combine permissions and assign users to groups. Then for each action check if asking user have permission to do so and either reject or approve request. Otherwise anything on front-end can be compromised easily.

Having first or last user being admin user wouldn't make a big difference if you cover your bases good. It is mostly considered as bad practice if your sql queries are prone to injection. For instance you get username and password from a form and have them in your query like this without cleaning and validating.

select * from users where username='.$_GET("username").' And password='.$_GET("password")

Now if i send ' or 1=1 ' in your form, it will be

select * from users where username='' or 1=1 '' And password='' or 1=1 which will return the first user.

The problem is not about having the first user as admin user but having enough controls to not this happen at all.