You can.

Every single piece of code that you have must then honour and check that (and there's no way SQL can enforce that, you will have to in your code). You need to take great care that two connections can't both think they locked the record (very easy to do if you haven't got the isolation levels, locks and transactions exactly right in your locking code). You need some process/method to unlock rows that have somehow remained locked even though the user is done (many, many possible causes) while not unlocking rows that the users are just taking their time over.

You're looking at massive amounts of development here, huge testing requirements and very likely a lot of related bugs.

Is it really, absolutely necessary to reimplement the database locking methodology yourself? Is it worth the time and effort?

Grab that book I mentioned and have a read through the chapter on this. It's an entire chapter devoted to the myriad ways of getting this kind of process wrong.