Host the site behind a domain. Enable SSL for it.
We also need SSL for brain-basket server.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html

Currently in test mode. Make it live.

Need a few info about the company, website URL, pan and business details etc.

Up to you of course but my suggestion would be feature-first over function-first, the former seems to be popular, I find it better but if you have a preference don't let me sway you.

The new flutter skeleton app uses feature-first, which I think cam from some user research, eg:
https://issueexplorer.com/issue/brianegan/new_flutter_template/10

One of the answers in there is particularly good:

---

I've used the function first approach in the past and have switched to the feature first quite some time ago (feature first and inside each feature-folder, a function first style structure). From my experience the feature first approach is better due to a couple of reasons:

Discoverability

When looking for a class, is usually easier to build a mental model around features versus layer (naming, layer separation, and other architectural decisions are always very opinionated). It's usually easier to categorize it by a feature than the specific layer.

Folder size

Sorting by function usually results in big folders containing a lot of files, and therefore making it harder to navigate

What gets modified together is together

From experience, it is very unusual to only modify a specific layer. In most apps, most work is done on features. That includes the whole stack of that feature (sometimes even ranging into the backend if you are using firebase). Having all files that are being changed together just helps maintain the mental model of the change.

Recursive structure

I personally really like a recursive feature model - where each feature has a specific layout by functions, but can also contain sub-features with the same layout. In this model, the whole app itself is just a feature.

• app_feature (not really called like this in the app)
  • search_feature
    • very_specific_variation_of_search_feature
  • other_feature

This also illustrates a dependency hierarchy where each feature can only depend on its parent. Anything globally accessible (for example the user management) is inside the app_feature