107 lines
5.0 KiB
Markdown
107 lines
5.0 KiB
Markdown
Prompt: Project Brief for a Custom SaaS Project Management Application
|
|
1. Executive Summary
|
|
|
|
I need a custom SaaS (Software as a Service) application designed to manage a large and diverse portfolio of personal and professional projects. The core problem is a lack of a centralized system, leading to disorganization, forgotten projects, and inefficient prioritization. The application must feature a deep hierarchical structure, robust project management tools, and be deployable within my existing cloud infrastructure.
|
|
2. The Problem Statement & My Needs
|
|
|
|
I am currently managing numerous projects across many different categories:
|
|
|
|
Language learning
|
|
|
|
Software development
|
|
|
|
Community initiatives
|
|
|
|
Personal goals
|
|
|
|
Commercial ventures
|
|
|
|
Non-profit activities
|
|
|
|
These projects vary in age, with some started a decade ago and others just a month ago. My primary challenges are:
|
|
|
|
Forgetting about projects: I lose track of ongoing or paused initiatives.
|
|
|
|
Mis-prioritization: I often assign high priority to low-impact projects.
|
|
|
|
Inefficient effort allocation: I spend too much time on projects that require less attention and vice-versa.
|
|
|
|
Lack of a single source of truth: My project information is scattered and disorganized.
|
|
|
|
The goal of this application is to provide a single, clear dashboard where I can see, manage, prioritize, and track all my projects effectively.
|
|
3. Core Functional Requirements
|
|
|
|
The application should provide the following core features:
|
|
|
|
Centralized Project Dashboard: A main view that lists all projects, allowing for sorting, filtering, and searching.
|
|
|
|
Deep Hierarchical Structure (Parent/Child Projects): This is a critical requirement. I organize my thoughts and work hierarchically. The system must support deeply nested projects.
|
|
|
|
Example:
|
|
|
|
Level 1: Language Learning (Parent Project)
|
|
|
|
Level 2: English Learning (Child Project)
|
|
|
|
Level 3: Prepare for the YDS Exam (Grandchild Project)
|
|
|
|
The system should comfortably handle at least 7 levels of nesting.
|
|
|
|
Project Management Tools: For each project (at any level), I need to be able to:
|
|
|
|
Add detailed notes and descriptions.
|
|
|
|
Create a simple, integrated Wiki for documentation and knowledge management.
|
|
|
|
Set priorities (e.g., High, Medium, Low).
|
|
|
|
Assign categories or tags.
|
|
|
|
If it's a software project, provide a way to link to or manage a Git repository.
|
|
|
|
Methodology Inspiration: The system's design can draw inspiration from established international project management strategies and methodologies (e.g., GTD, Agile concepts, etc.). The concept could even be broader than "projects" and encompass "goals" or "initiatives."
|
|
|
|
4. Non-Functional Requirements
|
|
|
|
Architecture: The application must be built as a multi-tenant SaaS platform. While I will be the first user, the architecture should allow other users to sign up, create their own accounts, and manage their own isolated set of projects.
|
|
|
|
Localization: The UI must be multi-lingual.
|
|
|
|
Initial Languages: Turkish, English, and Arabic.
|
|
|
|
Future Languages: The ability to add Chinese or other languages should be considered.
|
|
|
|
The localization system should be implemented using a standard, easily expandable format like JSON files.
|
|
|
|
5. Technical & Deployment Environment
|
|
|
|
The application must be designed to be deployed and operated within my existing infrastructure. This is a hard requirement.
|
|
|
|
Host Machine: An Oracle Free Tier VM (24GB RAM, 4 vCPUs).
|
|
|
|
Operating System: Rocky OS.
|
|
|
|
Orchestration: A K3s Kubernetes cluster is running on the machine.
|
|
|
|
Management: I use the Rancher UI (installed as a Docker container) to manage the K3s cluster.
|
|
|
|
Source Control: I use a self-hosted Gitea instance, installed via Helm on Rancher, for all my code.
|
|
|
|
Development Environment: I use Coder, running in the K3s cluster, which provides a browser-based VSCode environment for development. All git push/pull operations are done from Coder to Gitea.
|
|
|
|
CI/CD Pipeline: The entire CI/CD process is managed by Gitea Actions, using a Gitea runner deployed within my K3s cluster. The expected workflow is as follows:
|
|
|
|
A git push to the Gitea repository triggers a Gitea Actions workflow.
|
|
|
|
The workflow builds the application code into a Docker image.
|
|
|
|
The newly created image is pushed to the container registry integrated within my Gitea instance.
|
|
|
|
The final step in the workflow updates the relevant Kubernetes deployment/container in my cluster to use the new image, effectively deploying the change to production.
|
|
|
|
The new application must be architected to fit seamlessly into this push-to-deploy workflow.
|
|
6. Development Philosophy
|
|
|
|
Leverage Open-Source: I am not attached to the idea of building everything from scratch. The project should make extensive use of reliable open-source libraries, frameworks, and components for both the frontend and backend to accelerate development.
|
|
|
|
Urgency: I consider this project to be an urgent need to solve my current organizational challenges. |