DEV Community

Cover image for I Built a Full Project Management App in 2 days Using Claude 4.6
Ola Prøis
Ola Prøis

Posted on

I Built a Full Project Management App in 2 days Using Claude 4.6

#opensource #productivity #rust #showdev

TL;DR: I built Ironpad, a local-first, file-based project & knowledge management system using Rust, Vue 3, and AI-assisted development in about 2 days. The code is open source, Here's how it went.

What is Ironpad?

Ironpad is a personal project management and note-taking system where files are the database. Every note, task, and project is a plain Markdown file with YAML frontmatter. No cloud, no vendor lock-in, no proprietary formats.

You can edit your data in Ironpad's browser UI, or open the same files in VS Code, Obsidian, Vim, whatever you prefer. Changes sync in real-time via WebSocket. Everything is versioned automatically with Git.

Ironpad Screenshot

Key features:

  • WYSIWYG Markdown editor (Milkdown, ProseMirror-based) with formatting toolbar
  • Project management with tasks, subtasks, tags, due dates, and recurrence
  • Calendar view with color-coded task urgency
  • Dashboard showing all projects with active task summaries
  • Git integration — auto-commit, diff viewer, push/fetch, conflict detection
  • Real-time sync — edit in VS Code, see changes instantly in the browser
  • Full-text search powered by ripgrep (Ctrl+K)
  • Dark theme by default, 5 MB binary, ~20 MB RAM, sub-second startup

GitHub: github.com/OlaProeis/ironPad

The Tech Stack

Tech stack diagram

Layer Technology Why
Backend Rust + Axum 0.8 + Tokio Performance, safety, tiny binary
Frontend Vue 3 + Vite + TypeScript Composition API, fast dev experience
Editor Milkdown (ProseMirror) WYSIWYG markdown rendering
State Pinia Clean, minimal state management
Data Markdown + YAML frontmatter Human-readable, editor-agnostic
Version Control Git (via git2 crate) Automatic history for everything
Search ripgrep Battle-tested, sub-100ms results
Real-time WebSocket Instant sync with external editors

Why Rust instead of Electron?

This was a deliberate choice. Here's the comparison:

Electron vs Ironpad comparison

Electron App Ironpad (Rust)
Bundle size 150–300 MB ~5 MB
RAM usage 200–500 MB ~20 MB
Startup 2–5 seconds < 500ms
Browser Bundled Chromium Your system browser
Distribution Complex installer Single executable

Every user already has a browser. Why bundle another one?

The Rust backend serves an API, the Vue frontend runs in whatever browser you already use. Double-click the executable, it opens your browser, you're working. That's it.

The Development Process: Built With AI

Here's where it gets interesting. Ironpad was built entirely using AI-assisted development. Not just autocomplete, the architecture, the PRD, the implementation, the debugging. All of it.

I call the approach Open Method: not just open source code, but the open development process. It is documented in the repo under docs/ai-workflow/.

AI development workflow

The 6-Phase Workflow

Phase 1: Multi-AI Consultation
Before writing a single line of code, I discussed the idea with multiple AI models, Claude for architecture, Perplexity for library research, Gemini for second opinions. Five minutes getting different perspectives saves hours of rework.

Example: When designing the task system, one model suggested storing tasks as checkboxes in a single tasks.md file. Another pointed out that individual task files with frontmatter would be more flexible and avoid concurrent edit conflicts. Individual files was the right call.

Phase 2: PRD Creation
We wrote a detailed Product Requirements Document covering everything: features, API design, data models, edge cases, and explicitly what's not in scope. The PRD went through 3 versions, incorporating feedback about concurrency control, file watching, git conflict handling, and frontmatter automation.

Phase 3: Task Decomposition
This was a lighter project, with a new model, so i decided to skip task-master and just make a checklist document, testing how much the AI could handle in one go, i was impressed!

Phase 4: Context Loading
AI models have training cutoffs, so I used:

  • Context7 (MCP tool) to pull current documentation for Axum, Vue 3, and Milkdown
  • ai-context.md — a lean ~100-line cheat sheet telling the AI how code should fit the codebase

Phase 5: Implementation
Build features in focused sessions. Test. Update checklist. Repeat.

Phase 6: Verification
The AI writes the code. I verify the product. Run it, click the buttons, try the edge cases. Never trust "this should work."

Tools Used

Tool Role
Cursor IDE Primary development environment (VS Code fork with AI integration)
Claude Opus 4.5/4.6 Architecture, implementation, debugging
Perplexity AI Library research, version checking
Google Gemini Second opinions, catching blind spots
Context7 (MCP) Up-to-date library documentation

The 200K → 1M Context Window Shift

Midway through development, Claude's context window jumped from 200K to 1M tokens. This was the single biggest change in the project's workflow.

Context window comparison

Before: 200K tokens (Claude Opus 4.5)

  • Could hold ~3-5 files at once
  • Had to split features into micro-tasks
  • Required handover documents between every task
  • Cross-file bugs were hard to find
  • ~15-20 min overhead per task (context setup)

After: 1M tokens (Claude Opus 4.6)

  • Entire codebase (80+ files) fits in one context
  • Full features implemented in single sessions
  • Handovers only needed between days
  • Cross-file bugs found automatically
  • ~0 min overhead per task

The Codebase Audit

The clearest demonstration: I loaded the entire Ironpad codebase into a single context and asked "what's wrong?"

The AI found 16 issues, including:

  • Auto-commit silently broken — a flag never set to true anywhere. Finding this required reading main.rs, git.rs, and every route handler simultaneously.
  • Operator precedence bug — 0 > 0 evaluated before ?? in JavaScript
  • Missing atomic writes — only 1 of 8 write paths used the safe atomic pattern

14 of 16 issues were fixed in a single session. Zero compilation errors introduced.

This kind of comprehensive audit simply wasn't possible at 200K tokens.

What Worked (and What Didn't)

What worked well

1. PRD-first development
The single highest-leverage activity. The AI produces dramatically better code when it knows exactly what success looks like. Time spent on the PRD pays off 10x during implementation.

2. Rust's strict compiler
Rust is excellent for AI-assisted development because the compiler catches entire categories of bugs before runtime. With dynamic languages, bugs hide until production. With Rust, cargo check is a mechanical verification pass that eliminates memory safety, type mismatches, and missing error handling in one step.

3. The ai-context.md pattern
A lean (~100 line) architectural cheat sheet that tells the AI how to write code for this specific codebase. Without it, the AI invents new patterns. With it, code consistently matches existing conventions.

4. Fresh chats over long conversations
Context accumulates noise. By the third task in a single chat, the AI references irrelevant earlier context. Starting fresh with a focused handover produced consistently better results.

What didn't work

1. Trusting "this should work"
The AI confidently says this every single time. Without exception. Early on I'd take its word and move on. Then things would break two features later.

Fix: Test everything yourself. Click the buttons. Try the edge cases.

2. Vague requirements
"Add search" produces mediocre results. "Add full-text search with ripgrep, triggered by Ctrl+K, showing filename and matching line with context, limited to 5 matches per file" produces excellent results.

3. Over-engineering
The AI tends to add abstractions and generalization you don't need yet. It builds for a future that may never come.

Fix: Explicitly state YAGNI. Call it out. "Simplify this" works surprisingly well.

The Architecture

Architecture diagram

The design is intentionally simple:

User launches executable
         ↓
   Rust Backend (Axum)
   ├── REST API (notes, projects, tasks, git, search)
   ├── WebSocket server (real-time sync)
   ├── File watcher (external edit detection)
   └── Git auto-commit (60s batching)
         ↓
   Vue 3 Frontend (in your browser)
   ├── Milkdown WYSIWYG editor
   ├── Dashboard, Calendar, Task views
   ├── Pinia state management
   └── WebSocket client
         ↓
   Plain Markdown files on disk
   (editable with any tool)
Enter fullscreen mode Exit fullscreen mode

Core design decisions:

  • Files are the database. No SQLite, no IndexedDB. The filesystem is the source of truth.
  • Backend owns metadata. IDs, timestamps, and frontmatter are auto-managed. Users never manually edit metadata.
  • External editing is a first-class citizen. The file watcher detects changes from VS Code/Obsidian/Vim and syncs them to the browser UI in real-time via WebSocket.
  • Git for everything. Auto-commit every 60 seconds, manual commit with custom messages, full diff viewer built into the UI.

API surface (29 endpoints): 

Notes:       GET/POST /api/notes, GET/PUT/DEL /api/notes/:id
Projects:    GET/POST /api/projects, GET/PUT /api/projects/:id
Tasks:       GET/POST /api/projects/:id/tasks, GET/PUT/DEL per task
             PUT toggle, PUT meta, GET /api/tasks (cross-project)
Daily notes: GET/POST /api/daily, /api/daily/today, /api/daily/:date
Assets:      POST upload, GET serve
Search:      GET /api/search?q=
Git:         status, commit, push, fetch, log, diff, remote, conflicts
WebSocket:   /ws (real-time file change notifications)
Enter fullscreen mode Exit fullscreen mode

The Future of Ironpad

Roadmap

Coming in v0.2.0

  • Task comments & activity log — date-stamped entries per task, with the latest comment shown as a summary in the task list
  • Recurring tasks on calendar — daily/weekly/monthly tasks expanded across the calendar grid

On the horizon (v0.3.x)

  • Calendar drag-and-drop rescheduling
  • Week and day calendar views
  • Sort task list by due date or priority
  • Improved overdue indicators

Longer term

  • Quick-add task from anywhere
  • Bulk task actions
  • Task templates
  • Cross-project tag filtering
  • Kanban board view
  • Backlinks between notes
  • Graph view of note connections
  • Export to PDF/HTML
  • Custom themes
  • Mobile-friendly responsive layout

What will NOT happen

Ironpad will stay local-first. No cloud sync service, no user accounts, no SaaS. If you want remote access, push your data folder to a Git remote. That's by design, not a missing feature.

Try It / Contribute

Ironpad is MIT licensed and open source.

Quick start:

  1. Download from Releases
  2. Run the executable
  3. Your browser opens — start working

Or build from source:

git clone https://github.com/OlaProeis/ironPad.git
cd ironPad/backend && cargo run    # API server
cd ironPad/frontend && npm run dev # Dev server
Enter fullscreen mode Exit fullscreen mode

The complete AI development workflow documentation is in docs/ai-workflow/ — including the PRD, method, tools, and lessons learned.

If you have ideas or find bugs, open an issue. PRs welcome.

Links

Built with Rust, Vue, and a lot of AI conversations. The tools keep getting better, but the process of using them well still matters.

Top comments (0)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.