While I've never been "let go", I've made a strong effort to keep the door open at every place I was a full-time employee. In every case, this has led to more and better work down the road.
Of course it's bad ethics to write stuff that only you can maintain. But if you built it, regardless of how well you documented it and how easy someone else could maintain it you're the current expert and by the sound of the OP the rest of the team is not in his league. So the employer thinks to cut costs now that the major work has been done and they're in 'maintenance mode'. That might work, for a while. And then in a few weeks when they want something a bit more elaborate it may very well turn out that letting the OP go was a mistake.
Being good at something (or at least, much better than your co-workers) is the other method you're looking for, no need to resort to evil stuff.
Likely this was reflected in the OPs salary, note that he's let go but his co-workers are not, so probably he was making more per hour than they. And now he'll make more per hour still and his former boss will be more than happy to pay once he realizes that OP could turn him down just as easy as he was let go.
And the OP's former boss gets to pay for the actual hours needed to implement the desired feature rather than a monthly cheque.
Could be a win both ways in that sense. OA gets a customer with a regular need and existing investment. Former boss gains flexibility and can show headcount reduction.
> It's bad ethics to write stuff that only you can maintain
However, even in the best codebase, it takes time for somebody new to come up to speed. If they need help now, it will make sense for them to call in the original developer.
So, if you were a good developer and something happens, you can get called in to consult. Make sure you hit them for 50+% more than whatever your salary was; that's the penalty for the company gaining the flexibility to not use you when they don't have work.
And, even if something doesn't happen, they might want you to train the next person, again, make sure you charge appropriately for it.
Don't be a dick--especially if the company is going down, there are going to be other people springing loose shortly and you might want to work for/with them.
It's bad ethics to write something only you can maintain for self-interest.
If your boss tells you to throw hacks in or pile up a bunch of tech debt, it's your job to say, "this is ill advised, and here's why", and then do it anyway if that's his or her informed decision. There are often pressing business needs that mean having feature X now, and possibly paying more in the future to clean it up or for other features, is a fine tradeoff.
Lots of code is in the place, where test coverage is poor or there are grungy hacks to make things work, and hence is much more easily maintained by the original author.
