Absolutely, the contract must be honoured. 100%. No two ways about it.
It's really simple, isn't it? You told him not to do it and he keeps doing it - I sense a deal breaker.
That being said, working for a start-up is no joke and the 'me time' goes out of the window, at times. When someone works for a company, it's a two way street - the developer is going to do his part for the company and make it great, but not at the cost of himself. He's also going to take care of himself.
I do not know why there's this new extremely infuriating trend of long hours in the valley and the software industry in general. A story is breaking out of the big 4 every other day in the valley. It's not OK to work for long hours. I don't know when it became the new normal.
Work is not the only thing in life, it's merely a part of it.
This would depend, really.
Is your team member slacking off when it comes to company work? If yes, then firing him could make sense. You say right now it doesn't have an impact, so why not wait until you know that it is having an impact?
Maybe your employee would realize when the work from your product piles up on him and slow down with his personal projects. I really think you should give things like these time.
Employee or Developer burnout is real, and if these side projects help your employee focus better on his work, I think there shouldn't be any problem.
This answer has received 4 appreciations.
I have a different perspective. Being a CTO of a startup if you are asking the developer to work for loooong hours say more than 11 hours a day then the developer cannot find non-office hours to work on side project. If the developer is good and values the work then most likely it is problem with the work culture. And as a CTO it becomes your responsibility to correct the work culture.
Most companies have a policy that any work done on premises and on company time are the property of the company. The exceptions to this are typically handled on a case-by-case basis in a contractual agreement.
If this person is valuable, it might be advisable to put out a company policy brief and discuss it with him as one final warning, advising him that from this point on, any work he does within the confines of your company's walls and on company time would be the intellectual property of your company. That might be enough for him to wise up and not work on his own stuff on company time.
If you don't feel it's worth it to keep this person around, then you've already warned him. It may be time for action.
I maybe a CTO in a very close futur (crossing fingers) and it was one of the questions an investor ask me: how I plan to manage this situation. Maybe to test my leadership and management skills.
My vision on this situation is if the developer is doing his job on time. No delay on the Gantt Chart/Scrum Rush, let him having some fun. Maybe he is testing a new framework that will have a good impact on your project. Also why don't you ask him about his side project, maybe this is something interesting and he maybe need help in advice or some co-workers with differents skills like marketing/sales to help him promote this application ? It maybe a second project for your company or just a good opportunity ? Who knows ?
But as every startup which consuming money (technology debt) and plan to reimburse it later, he have to focus on what he is paying for. So if the dev team is in a rush he have to focus on nothing else.
If you are a CTO you maybe have be a developer before or something relate. Just remember how hard it can be to focus 8hrs a day on the same algorithm. And how it's make you breath to work on something else, something new, just for an hour or two ? If you never be a developer I can tell you that's relaxing !