I'm sorry for your position, you definitely shouldn't had just thrown in the jungle like this.

Normally I would suggest you read about the subject. Robert Martin, Martin Fowler, "Design Patterns" by the gang of four. But since you are in a tight schedule, the basic principles are:

Code "style" (this is really important and your future self will thank you) 1. Your future self and your (future) coworkers should be able to easily understand you code, ideally without the need of comments unless strictly necessary (good identifier names may not be enough for complex logic and regex) 2. Avoid comments, since once you've written them, you'll gonna need to remember of updating it whenever necessary. Maybe add your name, the date you've written and maybe some expiration date to ensure if someone crosses it he will know if it is updated or not. And yes, LLMs also forget to update them. 3. Code can change. Always write code in a way the parts that will probably change will be easy to change. 4. Avoid code duplication. It will attract bugs. Eventually you'll update one block and forget to update the other and this will break the application.

Backend best practices 1. Use ORMs to both enjoy you editor/IDE's language feature (it will probably not understand there's a block of SQL in the middle of your code), mitigate SQL injection and automatize changes in the database structure 2. Be aware of the N+1 problem 3. Create database indices for common used filters associated with heavy queries (they are basically a mapping between column values and table rows, so the database can access rows as if it were using primary keys. There's more to it, but that's enough for you to know) 4. JOIN with subqueries are usually more efficient than plain JOIN 5. Validate data in front end, back end and in database (using constraints). The first will ensure UX; the second will improve security, data integrity and facilitate front end integration; the third is less capable but more reliable in securing data integrity. 6. The further from the CPU the operation is happening, the slowest. If you can centralize the logic in the CPU, do it. You can't centralize in the CPU but can in the memory? do it. Network communication is slow, access to secondary memory is slow. Of course speed is not your only concern. If you need a data to persist you'll probably need to store it in a database. But, for example, storing the start date and frequency of an event and generating the actual dates on the fly is usually more efficient than storing each date. Also, if the data takes some time to change, you can cache it to reduce latency. 7. Continuous Deployment. This will make your life as a developer much easier. 8. Write tests for every critical flow in your system. You don't want to be afraid of changing the code and even less unknowingly pushing bugs 9. Don't waste your time with performance unless needed. Code maintainability is the priority.

SRE best practices (your future self will thank you once the system is down for god know why) 1. You don't need a full monitoring suite for a small application, but at the very list store your logs in a way you can query using some tool like Kibana ou CloudWatch Logs 2. Maintain at least CPU and Memory usage metrics for every machine you use. The moment the application was killed by OOM, there won't be logs to help you (maybe syslog, but who said you'll be able to access the machine?). Also maintain saturation metrics for your databases like number of connections and cache hitrate.

I guess that's it.