I’ve seen several times the same questions about deadlines and development stages and wanted to share my take on it as a community member.
Is it allowed for teams to keep building after the submission period?
In my opinion it shouldn’t just be allowed to keep building after the deadline but it should be compulsory 
See it that way: this hackathon isn’t really a speed contest to show how fast your team can build a decent product. If that was the case the hackathon would be a “face-to-face” one week event where teams would show to the judges what they can accomplish in a short period of time. The goal of the hackathon is for projects to be able to showcase an idea and its implementation as something innovative, useful, contributing to the ecosystem’s growth.
If you see things that way, you will understand that the first deadline (earlier today) was set up because:
- Events need a submission deadline in order to start judging
- A MVP on the tesnet is asked to make sure teams are not only showcasing beautiful ideas but really intend to develop it and deploy it. Without that requirement, projects could simply present very ambitious ideas without the intention of deploying it (prize hunters).
If you take this in consideration, you understand that you should keep building after this deadline cause the goal wasn’t for projects to show what they can do in 2 months but prove that they are seriously building and willing to contribute to Tron’s growth.
Some might want to ask me why JustMoney’s team have deployed on mainnet before the first deadline if this deadline wasn’t a kind of end point. We could have taken more time to build the product. Well first of all the product isn’t totally finished and I don’t think any product will ever be finished since you can ALWAYS improve it. We still have some milestones to reach and plenty of ideas for the future. Secondly, we don’t wanted to announce something that wouldn’t be directly usable by the community. We wanted them to discover the swap based spot trading platform and being able to directly start placing orders if they wish to.
Is it fair for new projects to compete with older projects?
This question has already been solved. If an older project builds a product/feature on top of something that has been presented in a previous season of the HackaTron, they will have to go to the builder section and show that the new product/feature presented constitutes a significative improvement, defined as following: something that could be presented as a brand new product by itself.
If an older project is building a brand new product that has nothing to do with the previously presented products, they will then compete against new teams.
What is important here is to realise that what is judged is not the team but the idea, the concept that is being developed and its implementation . Is it innovative, is it filling a gap, is it useful,…? What older team have built before isn’t taken in consideration.
“2 months and a half is very short to go through all the product building stages from the idea to a MVP”
Well in the rules it’s stated that the product should have been built in 2023… which doesn’t mean that you couldn’t have had the idea a while back and taken the time to mature it in your head or on paper. If we think again about what I wrote here above: the HackaTron is an event that has for purpose to showcase products that will contribute to the ecosystem’s growth and provide funds (prizes) to the teams that have proven they have great ideas and are willing to contribute with quality products.
If a team’s goal is to jump from a hackathon to an other one again and again for the solely purpose of getting money, I don’t see how they could have time to mature worthy ideas and might find it difficult to respect the deadlines. Well that’s their own problem 
Once again this is a personal opinion which might not be shared by the HackaTron organisation. For official statements trust only @admin.hackathon, @EMerchant, @StevenTRON, @WindsOfChange92 and @HunterTRON
Those who can’t stick to the deadlines won’t go the next stages.