Design Phase

In this phase, the focus is on designing of application.

We will need to figure out the following: stack, user flows, creation of high-level architecture, figma designs, backend endpoints, database architecture and devops architecture . This foundation is essential for creating a smooth development workflow and achieving our project goals efficiently.

1. Tools

Tool	Purpose
Draw.io	For system architecture diagrams, flowcharts, and illustrating component interactions.
Figma	For wireframe creation, UI mockups, and prototype screens.
Jira	To track design tasks and ensure issues are documented and followed up.
Slack	For team communication and coordination.
Miro	For brainstorming sessions on user flows, wireframes, and collaborative design decisions.

2. Overview

Objective: Translate business requirements into technical solutions.

How to achieve this:

• Plan the overall system architecture (Graphs, Diagrams, how high level components will interact with each other).
• Update database schemas, relationships, and optimizations.
• Start with a designing/FE phase, draw a mock up application and think what should be on the FE side, and how BE will interact with an application.
• Create user flow (how the user is going to interact with an application)
• Define the endpoints, payloads, and data flow for internal and external services.
• Split one complex task into small issues described by template

3. High-Level System Architecture

Main Question: What are the main components of the system, and how will they interact?

• Define essential components and dependencies, including services, databases, and external systems.
• Plan for scalability, anticipating potential challenges and future extensions.

Component	Purpose	Tech Stack	Details
Frontend	Enables users to browse products, register, log in, and make purchases	React / React Native or no-code	- User flow mapping for interactions with complex components
			- Consider outsourcing design & development if specialized expertise is required
Backend API	Provides endpoints for business logic, data processing, and delivering data to frontend	Django	- REST/WebSocket/GraphQL endpoints
			- Auto-documentation with Swagger for API clarity
Database	Manages data storage and entity relationships	PostgreSQL, managed by Python ORM	- Define tables, relationships, and optimization strategies (indexes, constraints, unique keys)
Caching Layer	Reduces database load by storing frequently accessed data	Redis	- Caches user sessions, product data, and other high-demand queries
			- TTL settings for cache expiration
Containerization	Packages and deploys application consistently across environments	Docker	- Dockerfiles created for frontend, backend, and caching services
			- Ensures consistency in dev, staging, and production environments
Orchestration	Manages, scales, and deploys application containers across multiple servers	Kubernetes (K8s)	- Automated container scaling based on traffic; useful for handling spikes in product views and purchases
			- Manages Redis, PostgreSQL, and Django API services in isolated pods
Monitoring & Logs	Tracks system health, application performance, and logs for debugging	Prometheus, Grafana, ELK (Elasticsearch, Logstash, Kibana)	- Prometheus for monitoring, Grafana for dashboards
			- ELK stack for centralized logging and quick troubleshooting
CDN & Delivery	Distributes static assets and media files globally for faster loading times	Cloudflare / AWS CloudFront	- Serves images, CSS, and JavaScript assets closer to users
CI/CD Pipeline	Automates build, testing, and deployment workflows	GitHub Actions or GitLab CI/CD	- Stages for unit, integration, and E2E testing

So, in the end we will be having the diagram for all tech stacks. I suggest having the same stack for all projects, to simplify the development. After that we can leverage this on a project levels, once we come up with a project structure and setup.

I would expect to achieve the following in the end:

graph TD
    A[Frontend - React/React Native] -->|User Interaction| B[API Gateway]

    %% Backend API Layer
    B --> C[Backend API - Django]
    C --> D1[User Auth Service]
    C --> D2[Product Catalog Service]
    C --> D3[Payment Service]

    %% Redis and Database Layer
    D2 --> E[Redis Cache]
    D1 --> F[PostgreSQL Database]
    D2 --> F
    D3 --> F

    %% External Integrations
    D1 --> G1[Auth0 or Firebase]
    D3 --> G2[Stripe for Payments]

    %% CI/CD Pipeline and Kubernetes
    C --> H1[CI/CD with GitHub Actions]
    H1 --> H3[Deployment on Kubernetes]

    %% Monitoring and Logging
    C --> I[Prometheus Monitoring]
    I --> J[Grafana Dashboard]

    %% Kubernetes (K8s) Pods
    H3 --> K1[Backend Pods]
    H3 --> K2[Frontend Pods]
    H3 --> K3[Redis Pod]
    H3 --> K4[PostgreSQL Pod]

    %% User Access
    M[User Devices] --> L[Load Balancer]
    L --> A

On the other hand, it is not really helpful, so this can be skipped for our startups.

4. User Flow

Objective: Each user flow should outline specific steps a user will take to achieve a goal, such as browsing products, registering, logging in, or completing a purchase.

This will be extremely helpful during our further development. For all key features we need to think how the user will interact with an application to simplify the process, to validate the idea and having a clear picture of what our application can deliver to the market. Even across competitors.

Examples

1. Product Browsing Flow Purpose: Enable users to explore and filter products.

1. User navigates to the "Products" page.
2. Frontend sends a request to Backend API (via GET /products endpoint).
3. Backend API retrieves product data from PostgreSQL and caches frequently accessed data in Redis.
4. Frontend displays the product list, with options to filter and sort.
5. User selects filters (e.g., price range, category), and Frontend sends updated requests.
6. Backend API returns filtered products, displayed on Frontend.

graph LR
    A[User navigates to Products Page] --> B[Frontend sends GET /products request to Backend API]
    B --> C[Backend API retrieves data from PostgreSQL]
    C --> D[Backend API caches frequent data in Redis]
    D --> E[Backend API sends product list to Frontend]
    E --> F[Frontend displays products with filter/sort options]

2. Product Purchase Flow Purpose: Enable users to select and purchase products.

1. User adds items to their cart and clicks "Checkout."
2. Frontend sends a POST /checkout request with cart details to Backend API.
3. Backend API calculates the total cost, applies discounts, and prepares payment information.
4. Payment Service integrates with Stripe to handle payment processing.
5. User completes payment on the Frontend and receives a confirmation email.
6. Backend API logs the order in PostgreSQL and stores a transaction record.

graph LR
    A[User adds items to cart and clicks Checkout] --> B[Frontend sends POST /checkout request with cart details to Backend API]
    B --> C[Backend API calculates total, applies discounts, prepares payment details]
    C --> D[Backend API integrates with Stripe for payment processing]
    D --> E[User completes payment on Frontend]
    E --> F[Backend API logs order in PostgreSQL and stores transaction]
    F --> G[User receives payment confirmation email]

4.1 Delivery

Flow Name	Steps
User Registration	User registers → Form data sent → Validations → DB storage → Confirmation email
User Login	User enters credentials → Authenticated via token → Session stored in Redis
Product Browsing	User navigates products → Frontend sends GET /products → Backend returns products → User filters/sorts
Product Purchase	User checks out → Cart data sent to backend → Total calculated → Stripe payment → Confirmation email
Order History/Tracking	User views order history → Data retrieved based on user ID → User can view tracking info

IMPORTANT: From developer's perspective, I wouldn't too focus on the backend side of user flow, I would focus more on how users are going to interact with our application overall.

In my opinion, real software engineers translate business requirements, into technical solutions. Not only the code quality matters, but the functionality, interactivity and usability of the project itself. That's why we get a big bucks.

5. Figma Design

Objective: Create a visually appealing and user-friendly design for the application.

To achieve this objective, we will use Figma, and this part will be outsoursed to the specialists, so we will need to define the documentation for a freelancer to discuss what we would like to see within our application.

5.1 Wireframing

We will need to create wireframes for each screen of the application. Wireframes provide a basic layout and structure for the design. Consider the user flow and interactions discussed in the previous section.

Example

-- Screen 1 -> Main screen
+--------------------------------------+
| Logo       Home    Shop    Login     | (Header)
+--------------------------------------+
|          Hero Image/Promo            |
|    [Start Shopping] Button           | (Hero Section)
+--------------------------------------+
|    Featured Products or Categories   | (Product Overview)
+--------------------------------------+
|        Footer with Links             |
+--------------------------------------+

5.2 Screen descriptions

We will need to define all screens in figma to present clear idea for the designer who will implement the magic and use them to draw

Each screen should include specific components which are well described for the person who is going to develop the design of an application.

Please, see the following example of the Screen #10 - Map Location:

• Map View: Interactive map to select a location.
• Pin for Location: Drop a pin to select an exact point.
• Confirm Button: Button to confirm selected location.
• Pop up Window: Description of the shop (location/working hours)

5.3 Outsource the task

When outsourcing the Figma design phase, create a clear and detailed design brief to guide the freelancer.

The following should be included to the technical task:

• Project Overview: A brief about the application, its goals, and target users.
• Screen Requirements: A list of all screens with clear descriptions of required elements and functionalities.
• Branding Guidelines: Color palette, typography, logo usage, and any branding materials.
• Design Inspiration: Reference similar designs or mood boards to convey the desired style (minimalist, vibrant, professional, etc.).

I suggest to schedule a couple of weekly sessions to check in on the feedback from designer, listen to their suggestions and find out if the design aligns with the vision of our team.

5.4 Iterate and Refine

Based on feedback and testing, iterate and refine the design as necessary. We will need to continuously improve the design based on user feedback and usability testing.

• User Experience Enhancements: Adjust layouts or interactions to enhance usability based on testing.
• Consistency: Ensure all screens align with the brand’s style guide and maintain uniformity.
• Accessibility: Verify that the design meets accessibility standards (e.g., sufficient color contrast, readable font sizes).

5.5 Delivery

In the end we would expect to have the following:

• Wireframes for initial structure approval.
• Ready mockups for each screen.
• Interactive prototype demonstrating basic user flows.
• Link to the figma for a complete design

6. Backend Endpoints

The next phase within the DESIGN section will be backend. During backend we will need to consider the following:

6.1 Stack

In order to make all projects the same for easier management, I would suggest to use the default stack for each of them

1. DRF (Django Rest Framework)
2. Postgresql
3. Flutter/React
4. Docker
5. K8S
6. AWS (EC2/Terraform/RDS/ElasticCache)
7. Celery/Cron
8. ElasticSearch/Fuzzy matching
9. Redis
10. Github/Gitlab
11. Jira

Depending on the project the stack can vary and it's important to figure it out in the beginning of development, not to have any surpirses and give everyone an option to prepare better for the development.

6.2 Endpoints Docs

Endpoints for the application will be built based on the requirements and ready FE screens/ mock ups.

Please, see the following structure of the endpoints which should be defined before the development of an application:

Screen 1/2 --> Login / Register

Notes: These endpoitns should be grouped and defined under specific categories, so it's just an example.

Endpoint	Method	Description
/api/v1/login	POST	Login the user
/api/v1/products	POST	Login the user

• [POST] /api/v1/login/

{
  "email": "western.ant2@gmail.com",
  "password": "q1w2e323"  
}

Response

{
  "token": "e34c9e57595b385a867b0eb8076a09bf0ee16037"
}

Notes: (They should directly state what logic should be required under this BE endpoint to simplify the further planning)

• Check if the user exists in the DB
• Authenticate the user

• Redirecting to the main page (screen 4)

• [GET] /api/v1/products

Retrieve a list of products filtered by various criteria.

---

• Query Parameters

Parameter	Type	Description	Required	Example
category	string	Filters products by category. Accepts values such as fruit, beverages, etc.	No	fruit
price_from	integer	Minimum price for filtering products.	No	1
price_to	integer	Maximum price for filtering products.	No	4
trademark	string	Filters products by the retailer or brand. Accepts values like Silpo, ATB, etc.	No	Silpo
availability	string	Filters based on availability status. Accepts values like AV (Available) or NOT_AV (Unavailable).	No	AV
keyword	string	Searches products by keyword in the title.	No	egg

---

• Response

Returns a JSON array of products matching the specified filters.

• Response Structure

[
    {
        "title": "Pepsi",
        "price_min": "2",
        "price_max": "4",
        "icon": "[BLOB]/url",
        "trademark": "TESCO/LIDL/MORRISONS/WAITROSE",
        "availability": "AV/NOT_AV",
        "categories": "Fruit/Beverages",
        "favourite": true
    }
]

---

• Notes

• The backend will query the database based on the provided query parameters, applying filters as needed.

• If no filters are specified, all products will be returned.
• Fields like availability are optional and can be included if needed for frontend functionality.

And same for all endpoints within of our application.

IMPORTANT: Planning documentation should be updated any time if during the developent/pitch writing we consider that the initial option doesn't work as expected/ can't match the standarts.

On practice, the planning is usually implemented with 70-85% precision from the initial backend enpdoints.

6.3 Project Structure

The following project structure seems to be very sensible for me in terms of having a single application with both FE and BE.

├── backend
│   ├── app
│   │   ├── core                    # Core settings, utilities, and configurations
│   │   │   ├── settings.py         # Django settings
│   │   │   ├── celery.py           # Celery configuration
│   │   │   ├── urls.py             # Root URL configurations
│   │   │   └── wsgi.py             # WSGI entry point
│   │   ├── authentication
│   │   │   ├── models.py           # Authentication models
│   │   │   ├── serializers.py      # Authentication serializers
│   │   │   ├── views.py            # Authentication views
│   │   │   ├── urls.py             # URLs for auth-related endpoints
│   │   │   └── tasks.py            # Celery tasks for authentication
│   │   ├── products
│   │   │   ├── models.py           # Product-related models
│   │   │   ├── serializers.py      # Product serializers
│   │   │   ├── views.py            # Product views
│   │   │   ├── urls.py             # URLs for product-related endpoints
│   │   │   └── tasks.py            # Celery tasks for product management
│   │   ├── orders
│   │   │   ├── models.py           # Order-related models
│   │   │   ├── serializers.py      # Order serializers
│   │   │   ├── views.py            # Order views
│   │   │   ├── urls.py             # URLs for order-related endpoints
│   │   │   └── tasks.py            # Celery tasks for order management
│   │   ├── search                  # ElasticSearch integration for product search
│   │   │   ├── indexing.py         # Indexing configuration for ElasticSearch
│   │   │   └── views.py            # Search API integration
│   │   └── utils                   # Utility functions (e.g., JWT handling, email notifications)
│   ├── tests                       # Tests folder
│   │   ├── test_authentication.py  # Unit tests for authentication
│   │   ├── test_products.py        # Unit tests for products
│   │   └── test_orders.py          # Unit tests for orders
│   ├── requirements
│   │   ├── base.txt                # Base Python requirements
│   │   ├── development.txt         # Dev-specific requirements
│   │   └── production.txt          # Production-specific requirements
│   └── manage.py                   # Django management script
│
├── frontend
│   ├── public                      # Static assets
│   ├── src
│   │   ├── assets                  # Images, icons, etc.
│   │   ├── components              # Shared React components
│   │   ├── pages
│   │   │   ├── Home.js             # Home page
│   │   │   ├── ProductPage.js      # Product page
│   │   │   ├── LoginPage.js        # Login page
│   │   │   └── RegisterPage.js     # Registration page
│   │   ├── routes.js               # Frontend routing
│   │   ├── App.js                  # Main App entry
│   │   └── index.js                # React entry point
│   └── package.json                # Frontend dependencies
│
├── infrastructure
│   ├── docker
│   │   ├── Dockerfile.backend      # Dockerfile for backend
│   │   ├── Dockerfile.frontend     # Dockerfile for frontend
│   │   └── docker-compose.yml      # Compose configuration
│   ├── k8s
│   │   ├── deployment.yaml         # Deployment configurations
│   │   ├── service.yaml            # Service configurations
│   │   ├── ingress.yaml            # Ingress configurations
│   │   └── secrets.yaml            # Secrets management
│   └── terraform                   # Terraform configuration for AWS
│       ├── main.tf                 # Main Terraform file
│       ├── variables.tf            # Variables for Terraform
│       └── outputs.tf              # Output configurations
│
├── scripts                         # Automation scripts
│   ├── deploy.sh                   # Deployment automation script
│   ├── start_local.sh              # Start application locally
│   └── backup_db.sh                # Database backup script
│
└── docs
    ├── api
    │   └── api_documentation.md    # API documentation
    ├── architecture.md             # High-level architecture documentation
    ├── deployment.md               # Deployment process documentation
    └── readme.md                   # Project README

6.4 Delivery

In the end we expect to have the following:

• Defined stack of the application
• Well described endpoints of the application.
• Completed (maybe a bit adjusted) structure of the project

7. Database

Objective: Define the data structure, relationships, and indexing strategy to ensure efficient data storage, retrieval, and scalability.

7.1 Entities and Tables

Each main entity in the database will have a dedicated table. These entities are mapped in the Django ORM/SQLAlchemyORM as classes, each representing a model in our application. Below is a list of core entities, their purpose, and attributes.

---

1. Users

2. Purpose: Stores user information for authentication and interactions with our application

3. Indexes:
   • Unique index on email for fast authentication lookups.
4. Constraints:
   • UNIQUE(email): Ensures email uniqueness for each user.
   • CHECK(length(password) >= 8): Ensures minimum password length.

And for all entities we will want to figure out within an application.

7.2 Diagram

The next step will be to use draw.io to make a diagram based on our tables and defined endpoints.

erDiagram
    USERS {
        UUID id PK
        String email
        String password
        TIMESTAMP created_at
        TIMESTAMP updated_at
    }

    PRODUCTS {
        UUID id PK
        String name
        TEXT description
        DECIMAL price
        TIMESTAMP created_at
    }

    ORDERS {
        UUID id PK
        UUID user_id FK
        DECIMAL total_amount
        ENUM status
        TIMESTAMP created_at
    }

    ORDERITEMS {
        UUID id PK
        UUID order_id FK
        UUID product_id FK
        INTEGER quantity
    }

    CATEGORIES {
        UUID id PK
        String name
    }

    USERS ||--o{ ORDERS : "has"
    ORDERS ||--o{ ORDERITEMS : "contains"
    PRODUCTS ||--o{ ORDERITEMS : "includes"
    PRODUCTS }o--o| CATEGORIES : "categorized"

7.3 Indexes / Constraints

All indexes/constratins should be well documented. I am a big fan to solve everything on the database level firstly, so we will need to think about this in advance.

1. User Email Index: UNIQUE index on the email column in the Users table sfor quick authentication lookups.
2. Order History Index: Composite index on (user_id, created_at) in the Orders table for efficient order history retrieval.
3. Product Index: Composite index on (name, price) in the Products table to speed up product searches and sorting.
4. Category Index: UNIQUE index on the name column in the Categories table to facilitate rapid category lookups.

---

1. Email Uniqueness: UNIQUE(email) constraint in the Users table to ensure unique user emails.
2. Price Validation: CHECK(price >= 0) in the Products table to prevent negative pricing.
3. Quantity Validation: CHECK(quantity > 0) in OrderItems to ensure valid quantities.
4. Category Uniqueness: UNIQUE(name) in Categories table to avoid duplicate categories.

---

7.5 Backup and Recovery Strategy

Regular backups and documented recovery procedures are critical for data integrity.

1. Automated Backups: Schedule daily backups using PostgreSQL’s native tools or managed services (e.g., AWS RDS automated backups).
2. Retention Policy: Retain backups for at least 30 days to cover unexpected needs.
3. Disaster Recovery Testing: Perform quarterly restore tests in a staging environment to ensure backups are reliable.

Don't worry about this for now in design phase, I will come up with automation scripts to handle backups and recoveries.

---

7.6 Delivery

In the end we expected to have the following:

• High-level documentation outlining tables and relationships.
• Each table will have a detailed schema definition including column types, constraints, and indexes.
• Entity-relationship diagram visualizing the table relationships and their dependencies.

8. DevOps

Objective: To ensure smooth deployment, scaling, and maintenance of the application, we need a reliable DevOps strategy that covers automation, monitoring, and security across all environments.

8.0 Introduction

Since our application will be having a high-scalable devops infrastructure we will need to come up with a diagram to understand precisely what is required from the architecture as well.

We would like to achieve something similar to the following:

Notes: Additionally we will need to conduct the calculations on how much the system will cost to run and potentially, change AWS cloud on something cheaper, but with a similar functionality.

8.1 Infrastructure as Code (IaC)

Using Terraform will allow us to provision infrastructure resources automatically, enabling reproducible and version-controlled configurations. We'll use Terraform to manage and define resources on AWS for consistent cloud deployments, covering:

• EC2 instances for computing resources.
• RDS for our PostgreSQL database.
• ElastiCache for Redis caching.
• S3 and CloudFront for media and static file storage.
• IAM roles and permissions for secure access control.

8.2 Containerization and Orchestration

Using Docker for containerization ensures that our application remains consistent across environments. Every component—frontend, backend, database—will have its own Dockerfile to standardize the environment.

For deployment, Kubernetes (K8s) will manage these containers, handling scaling and orchestration across clusters. Key components:

• Deployment YAMLs: Define configurations for backend, frontend, Redis, and PostgreSQL pods.
• K8s Ingress: Manage external access to services and ensure HTTPS configurations for security.
• Helm Charts (optional): Consider for managing reusable configurations, making it easier to replicate setups for future projects.

8.3 Continuous Integration / Continuous Deployment (CI/CD)

A GitHub Actions or GitLab CI/CD pipeline will automate build, testing, and deployment workflows. Key stages:

• Build: Automatically build Docker images for frontend and backend on each commit.
• Test: Run unit and integration tests, with failed tests preventing deployment.
• Deploy: Push successful builds to AWS ECR (Elastic Container Registry) and deploy to Kubernetes.
• Build Docs: Implement the pipeline stage which will be building documentation for our APIs.

8.4 Monitoring and Logging

To ensure system stability and performance, we’ll deploy Prometheus and Grafana for real-time monitoring, along with ELK stack for centralized logging.

• Prometheus: Monitors metrics such as server load, API response time, and container health.
• Grafana: Dashboards for visualizing metrics from Prometheus, useful for tracking uptime and performance.
• ELK Stack (Elasticsearch, Logstash, Kibana): Collects, processes, and visualizes logs. Helps in tracking issues and auditing.

8.6 Delivery

The final DevOps setup should include:

• High level architecture of the Devops Infrastructure
• A Terraform setup for infrastructure provisioning.
• Docker and Kubernetes configurations for application containerization.
• A CI/CD pipeline automating build, test, and deployment workflows.
• Prometheus, Grafana, and ELK stack for monitoring and logging.
• Backup and recovery procedures documented and tested.

In some cases we may not need to over-complicate the devops infrastructure. Sometimes we may have much simplier, but scalable solution. Everything depends on the project.

9. Jira Product Stories

Before starting to the actual developemnt, we will need to create one more stage to have a clear understanding of the product we are building

9.1 User Stories Overview

Objective: To document user stories that capture the core functionalities and requirements of the application. These stories help in translating high-level business goals into detailed tasks, which can then be managed, assigned, and tracked in Jira.

Each story is written from the perspective of the end user, focusing on the key actions they can perform within the application. Each story includes acceptance criteria that define when the story is considered complete.

---

9.1.1 User Authentication

Story: User Registration

• As a new user
• I want to register an account on the application
• So that I can have a personalized shopping experience

Acceptance Criteria: - Users can enter an email, password, and additional required information. - The system validates the email format and ensures password meets security criteria. - Upon successful registration, users receive a confirmation email.

---

Story: User Login

• As a registered user
• I want to log into my account
• So that I can access my saved information and make purchases

Acceptance Criteria: - Users can log in using their email and password. - The system validates credentials and provides access upon successful authentication. - If login fails, an error message is displayed, explaining the issue.

---

9.1.2 Product Catalog and Browsing

Story: View Product Catalog - As a user - I want to browse the product catalog - So that I can see all available products

Acceptance Criteria: - Users can view a list of products with images, names, and prices. - Products are loaded from the database and displayed on the frontend. - Users can filter and sort products by categories, price, and availability.

---

Story: Search for a Product - As a user - I want to search for a specific product - So that I can find it quickly

Acceptance Criteria: - Users can enter a search term and receive relevant product results. - Search results display key information, including price and availability. - The system caches search results for frequently queried items.

---

9.1.3 Cart and Checkout

Story: Add Items to Cart

• As a user
• I want to add items to my shopping cart
• So that I can purchase them later

Acceptance Criteria: - Users can add products to the cart from product pages or search results. - The cart updates in real-time, reflecting added items and quantities. - Users can remove items or adjust quantities directly in the cart.

---

Story: Complete Purchase (Checkout) - As a user - I want to proceed with checkout - So that I can complete my purchase

Acceptance Criteria: - Users can proceed to checkout after adding items to their cart. - The system calculates the total, including any applicable discounts. - Users can enter payment details, and the payment service (Stripe) processes the transaction. - Upon successful payment, users receive a confirmation email.

---

9.2 Epic Organization and Prioritization

To streamline project management, we organize the user stories into epics based on their functionalities. Sample epics include:

• User Authentication and Profile Management
• Product Catalog and Browsing
• Cart and Checkout

9.3 Jira Configuration

For tracking, each story should have: - A unique story ID (e.g., AUTH-101 for user login). - A priority level (High, Medium, Low) based on business value and technical complexity. - Linked epics for organizational purposes. - All fields in jira should be filled in once picked up by developer.

9.4 Delivery

End Goal: A fully populated Jira board with organized and prioritized user stories, allowing teams to track, assign, and manage work effectively.

IMPORTANT: That is not ready to use tasks, but the snippet and overview of our application. We will start splitting tasks and making estimates during the next (development) phase.

10. Conclusion

The design phase is the bridge between theoretical planning and practical implementation. By creating a thorough, high-level architecture, identifying user flows, and defining the database schema and endpoints, we lay the groundwork for a smoother development process.

Based on my experience this can save us up to 80% of time which could be used for hustling, doing nothing and staring at the screen.

Integrating theory with practical workflows, such as CI/CD setup, DevOps planning, and scalability considerations, transforms this blueprint into a reliable framework (the plan which we will follow during the development phase).

11. Checklist

By the end of the design phase, ensure the following is created:

1. High-Level System Architecture: Complete and documented.

1. Frontend Designs: Comprehensive Figma wireframes covering all application screens.

1. User Flows: Detailed flows for all critical application interactions.

1. Database Documentation: Tables, relationships, constraints, and diagrams.

1. API Documentation: Complete backend endpoint documentation.

1. DevOps Infrastructure Plan: Includes setup and cost projections.

1. Task Management Setup: Jira dashboard with stories and segmented tasks.

Happy Development!