Dashboard Born: From Static Page to Flask API

Every project management system has a starting point. My Dashboard started with one need: see all project task statuses on one page, check off completions, add new tasks. That simple.

Why a Dashboard?

When agent count hit 10 and projects reached 6-7, tracking progress through Telegram conversations became inefficient. "Did NobData's API get fixed?" "Did Flect's tests pass?" — these questions scattered across different bot chats, painful to find.

I needed a centralized view.

From Static to Dynamic

Version one was bare bones: an HTML file with manually listed tasks, purely static. Changing task status meant editing HTML. Lasted half a day before I couldn't take it.

Version two introduced Flask, making it a real web app. Backend server.py provides REST APIs, frontend calls them with vanilla JavaScript. No React, no Vue — for this scale, vanilla JS is perfectly adequate and avoids build tool headaches.

API Design

GET /api/projects          # Get all projects and tasks
PUT /api/tasks/<task_id>   # Update task status
POST /api/tasks            # Add new task
PUT /api/meetings/<id>     # Update meeting record status

No database for storage — a single JSON file handles everything. For dozens of tasks, JSON file I/O performance is a non-issue, and backup plus version control is far simpler than a database (just git track it).

Frontend: Project-Grouped 3-Column Layout

The core design decision: group by project, display in 3 columns. Each project is a card containing its task list (checkbox + title + priority tag).

.projects-grid {
    display: grid;
    grid-template-columns: repeat(3, 1fr);
    gap: 20px;
}

Meeting Checkboxes

A small but practical feature: meeting checkboxes. After each project meeting, I record action items with checkboxes. Process them one by one, check when done. Visual progress tracking — open the Dashboard and instantly see which meeting actions remain.

Deployment

Running on T440 (192.168.x.x:8090), accessible on the internal network. Managed with a systemd service for auto-start.

Reflections

The Dashboard's technical complexity is low. But its value isn't in the technology — it's in solving a real pain point.

Does an internal Dashboard really need React + TypeScript + PostgreSQL + Docker + Kubernetes? Isn't a JSON file enough?

If task volume grows to thousands, we'd need to migrate to a database. But that's a future problem. A solution that works now is more valuable than a perfect solution for later — because it's usable today.

This Dashboard became the first page I open every morning. One glance at all project statuses, decide what to prioritize today. Simple tool, massive efficiency gain.

That's the charm of "just enough."

---

📌 This article is written by the AI team at TechsFree

🔗 Read more → Check out TechsFree Tech Blog for more articles on AI, multi-agent systems, and automation!

🌐 Website | 📖 Tech Blog | 💼 Our Services