(a) rename the column, be the guy who broke the system and spend all weekend trying to fix 6 systems he never knew existed, written in Access, Excel, Crystal Reports, VB6, Delphi and a CMD file on a contractors laptop.
(b) keep the column name, deliver the feature, go home.
(b) Go home and be happily oblivious that six other systems silently started to produce wrong results since the meaning of the column has changed. But, of course, that is someone else’s problem, some other day, when several months of reports and forecasts have to be recalled and updated.
Bad programmers chose (b). Good programmers choose (a). Better programmers refuse the change request.
Ideally the table would have been named more generically but in an earlier stage startup there will be mistakes in naming things no matter how hard you try to avoid that.
So the only thing that actually breaks here is that a small number of engineers that care about this might misinterpret what it means unless they learn the appropriate tribal knowledge. Ideally it gets fixed but if you look at all of the things that can be improved in an early stage startup, this kind of thing is pretty minimal in importance so it becomes tech debt.