# Planmize

## Constraints and Requirements:
- The customer is searching for a low cost possibility to evaluate usefulness of his idea
- (Fast) Scalability is not a hard requirement, he might scale by small to medium sized businesses where capacities could be increased by hand for a long time
- Security: During the MVP Build phase no user accounts are required, as the customer is only using it for himself and 2-3 colleagues. A Basic Auth would be sufficient. But the solution must be able to include user auth later on, with organisation accounts that can create users, which have their own projects. So user accounts will be a complex topic in the future, that can mostly be disregarded for now
- The data we are dealing with is not critical, so basic security mechanisms like encryption and backups are sufficient
- Design and Speed is key to a successful solution

## Data Storage:
- The customer is storing complex data structures that match topics, subtopics, keywords and content in each other
- During the MVP we can work with tree like structures and low amounts of levels
- This would allow for using an open source SQL database like PostgreSQL
- In the future features might get more complex and would benefit from a graph database like neo4j
- We should evaluate costs of a graph database like neo4j in comparison to standards like PostgreSQL or MongoDB and go for the graph database if it’s possible with the budget and timeframe
- The content itself will probably not be stored on our application, but it could be. We will need an S3-like storage to store regularly created reports, create exports for download and maybe store content snapshots in the future

## Backend:
- The software is not planned to be growing too much in the future, we can probably go for two services:
- Interactive: One main service is responsible to handle user requests, provide data and perform data manipulation. This can be done in a language of your choice, probably a JS-based solution along with a react frontend reduces maintenance costs in the future
- Batch-Processing: There are jobs like creating content plans, exports and maybe analysis in the future, that are costly and benefit from regularly static creation rather than live calculation. Amount of data will not be as big to require a solution like spark, so we can trigger normal jobs in a docker container via a service like AWS Batch or create our own job queue with Redis or something similar
- Infrastructure: Scalability is not a key driver, but rather cost reduction. So we can ignore large-scale solutions like Kubernetes and go for something cheaper like EC2 Instances or easier like a serverless container environments (e.g. AWS Fargate). As development costs will be higher than hardware costs for quite some time, I’d recommend a serverless solution like Fargate
- Cloud Account will be provided by customer, we will get admin access
- Specific cloud provider needs to be discussed with customer, we can mage suggestions that will probably be agreed on

## Frontend:
- Customisation is a key factor in the solution, so we need a modern frontend framework like React or Vue. It should be discussed with the customer, if it’s possible to stick to a specific framework for the beginning to reduce development costs
- Preferred option for a frontend UI Kit would be Chakra UI for React as it allows for fast, flexible customization of components.

## Security:
- As said in the Introduction, security is not of specific concern but rather needs to be addressed in a pretty standard way. Encryption should be enforced for transport and data at rest, key management to secure data in database from provider is not required
- User Authentication does not need to be implemented for MVP
- We need to build the backend in a way that allows for future integration of user and organisation accounts. Account System can be seen as quite similar to something like GitHub
- Users can have their own account
- Users can belong to an organisation
- Projects can belong to users or organisations
- Project owners can invite users to the project with different roles
- All these will be defined in the future

## Payment:
- Not part of MVP