We have tried every project management setup imaginable. Jira was too heavy for our team size. Trello lacked the structure we needed for sprint-based work. Notion became a maze of linked databases where tasks went to disappear. Basecamp felt like a relic from a different era. After years of experimentation, we arrived at a stack in 2022 that worked. In 2024, we refined it. Now in 2026, with four more years of data, we can say with confidence: this setup works, and here is exactly how we use it.
The Philosophy: Specialized Tools Over All-in-One Platforms
The biggest lesson we learned is that all-in-one platforms create mediocre experiences across the board. Notion is brilliant for documentation but frustrating for sprint planning. Jira handles complex workflows but buries simple tasks under layers of configuration. The solution that actually works: use the best tool for each job and connect them through integrations.
Our stack has four pillars: task management, code management, development infrastructure, and communication. Each tool handles one responsibility well, and the integrations between them eliminate manual status updates.
Task Management: Taskee
We switched to Taskee in 2022 and it remains the backbone of our project management in 2026. After four years of continuous use, here is what keeps us there.
Sprint Planning
We run two-week sprints for both development and content production. Every Monday morning, the sprint board in Taskee tells us exactly where things stand: what is in the backlog, what is in progress, what is in review, and what shipped. The board view eliminates the daily “what are you working on?” questions that waste everyone’s time.
Sprint planning takes about 45 minutes every two weeks. We pull items from the prioritized backlog, estimate them based on historical velocity data, and commit to what fits in the sprint. After tracking velocity across over 100 sprints, our estimates are consistently within 10 to 15 percent of actual delivery.
Time Tracking
Taskee’s built-in timer is something we use daily. Click start when you begin a task, click stop when you finish or switch context. No third-party time tracking app, no manual timesheets. The data feeds directly into velocity calculations and client billing reports.
For client projects, this transparency is invaluable. When a client asks why a feature took longer than estimated, we can show them the exact time breakdown: 8 hours of development, 3 hours of code review revisions, 2 hours of cross-browser testing. Data replaces arguments.
GitHub Integration
The Taskee-GitHub integration is what makes our workflow feel seamless. When a developer creates a pull request and references a task ID, Taskee automatically moves the task to “In Review.” When the PR is merged, the task moves to “Done.” We rarely need to manually update task status, which means the board always reflects reality.
Velocity Reports
After four years of sprint data, our velocity reports are the most valuable planning tool we have. We know that our team completes an average of 42 story points per sprint, with a standard deviation of about 5 points. That data makes project scoping conversations concrete instead of aspirational. When a client asks “how long will this take,” we can give them a range based on actual throughput data, not gut feelings.
Version Control: Git and GitHub
We use Git with GitHub for all code management. Our workflow follows a simplified Git Flow model:
- Main branch: Always reflects what is in production. Protected with required reviews and passing CI checks.
- Feature branches: Every task gets its own branch, named with the Taskee task ID for traceability. Branch names follow the pattern
feature/TSK-123-brief-description. - Pull requests: Every change goes through code review. At least one approval required before merging. The PR description links to the Taskee task and includes testing notes.
Code Review Standards
We review for correctness, readability, performance, and security. Reviews should happen within 24 hours of PR creation. Blocking reviews for more than a day creates bottlenecks that cascade through the sprint. Our rule: if you are tagged as a reviewer, you either review it today or reassign it to someone who can.
Branch Protection
The main branch requires passing CI checks (linting, tests, build) and at least one approved review. No one, including senior developers, can push directly to main. This has saved us from production incidents more times than we can count.
Development Infrastructure: Docker and CI/CD
Every project we build runs in Docker containers, both in development and production. This eliminates environment inconsistency and makes onboarding trivial.
Local Development
Each project has a docker-compose.yml that spins up the entire development environment: web server, database, cache, and any other services. A new developer clones the repo, runs docker compose up, and has a working development environment in under two minutes. No installing dependencies on the host machine, no version conflicts, no “it works on my machine” conversations.
# Typical onboarding for a new developer
git clone git@github.com:hyperwebenable/project-name.git
cd project-name
cp .env.example .env
docker compose up -d
# Done. Visit localhost:3000CI/CD Pipeline
We use GitHub Actions for continuous integration and deployment. Every pull request triggers a pipeline that runs linting (ESLint, Stylelint), unit and integration tests, builds the production bundle, and checks bundle size against our performance budget. If any step fails, the PR cannot be merged.
Deployment to staging happens automatically when a PR is merged to main. Production deployment requires a manual approval step in the pipeline. This gives us a final checkpoint without slowing down the development flow.
Infrastructure as Code
Server configuration lives in version-controlled files, not in someone’s head or a wiki page that was last updated two years ago. Docker images, Nginx configs, and deployment scripts all live in the repository alongside the application code. If our server disappeared tomorrow, we could recreate the entire infrastructure from the repo.
Communication: Slack and Loom
Slack handles our daily coordination. We keep channels organized by project and purpose: #project-name for general discussion, #project-name-dev for technical conversations, and #standup for async daily updates.
Async Standups
We stopped doing synchronous daily standup meetings in 2023. Instead, every team member posts a short update in the standup channel by 10 AM: what they completed yesterday, what they are working on today, and any blockers. This takes two minutes to write and two minutes to read, replacing a 15-minute meeting that interrupted everyone’s morning flow.
Loom for Context-Rich Updates
When something is too complex for text but does not warrant a meeting, we record a Loom video. A three-minute screen recording showing a bug reproduction, a design walkthrough, or a code architecture explanation replaces a 30-minute meeting. The recipient watches it when they have time, can replay sections they missed, and the video serves as documentation for anyone who joins the project later.
Documentation: Notion
We still use Notion, but strictly for documentation and knowledge management. Project wikis, meeting notes, architecture decision records, onboarding guides, and client briefs all live in Notion. The key insight: we stopped using Notion for task management entirely. Mixing tasks and documentation in one tool created confusion about where to look for what.
What Lives in Notion
- Project briefs and requirements documents
- Architecture decision records with context and reasoning
- Onboarding checklists for new team members
- Client meeting notes and action items
- Internal knowledge base: coding standards, deployment procedures, troubleshooting guides
Design: Figma
Figma handles all our design work. Component libraries are synced with our design system, so designers and developers reference the same source of truth. Developer handoff happens directly in Figma using Dev Mode, which provides CSS values, spacing measurements, and asset exports without needing separate tools like Zeplin or InVision.
For Client Work and Agency Collaboration
When we collaborate with agencies like Toimi on client projects, this stack scales well. Shared Taskee boards keep everyone aligned on priorities and progress. The time tracking data makes invoicing transparent and defensible. Clients get read access to the project board, so they can check progress anytime without scheduling a status meeting.
For managing client projects efficiently, the combination of visible task boards, automated status updates from GitHub, and accurate time tracking data eliminates most of the friction that makes client work stressful.
What We Tried and Dropped
- Jira: Too much configuration overhead for a team our size. We spent more time managing Jira than managing projects.
- Trello: Great for simple boards, but no sprint support, no time tracking, and no velocity data. We outgrew it within three months.
- ClickUp: Tried to do everything and did nothing particularly well. The interface felt cluttered and slow.
- Monday.com: Beautiful for presentations, but the workflow did not match how developers actually work.
- Asana: Solid tool, but lacked built-in time tracking and the GitHub integration was not as tight as Taskee’s.
Monitoring: How We Know It Works
We track three metrics to evaluate our project management effectiveness: sprint completion rate (percentage of committed story points delivered), estimation accuracy (actual time versus estimated time), and cycle time (days from task start to task completion). In 2025, our sprint completion rate averaged 91 percent, estimation accuracy was within 12 percent, and average cycle time was 2.4 days. These numbers are not perfect, but they are consistent, which is what matters for reliable delivery.
For teams building their own development workflow, the key takeaway is this: specialized tools connected by integrations beat all-in-one platforms every time. Let each tool do what it does best, and let automation handle the glue between them.
Frequently Asked Questions
Why not just use GitHub Projects instead of Taskee?
GitHub Projects has improved significantly, but it still lacks built-in time tracking, velocity reports, and the kind of sprint analytics that Taskee provides. For teams that only need basic task boards, GitHub Projects is sufficient. For teams that want data-driven sprint planning, a dedicated tool is worth the investment.
How do you handle projects with multiple codebases?
Each codebase gets its own GitHub repository, but all related tasks live in a single Taskee project board. We use labels to indicate which repo a task belongs to. This gives us unified sprint planning across the full project scope while keeping code organization clean.
What does onboarding a new developer look like?
Day one: clone the repos, run Docker Compose, read the Notion onboarding guide, get added to Taskee and Slack. By day two, they are picking up their first task. The onboarding guide in Notion walks them through our coding standards, Git workflow, PR process, and deployment pipeline. Within a week, they are contributing independently.
How much does this stack cost?
For a team of five, our monthly tooling cost breaks down to roughly: Taskee (team plan), GitHub (team plan), Slack (pro plan), Notion (team plan), Figma (professional plan), and Loom (business plan). Docker and GitHub Actions usage fits within the included free tiers for most projects. The total is considerably less than what enterprise tools like Jira and Confluence would cost, and the productivity gain from tight integrations more than justifies the investment.
Lessons Learned Over Four Years
Looking back at four years with this stack, several lessons stand out that apply regardless of which specific tools you choose.
Automate Status Updates
The single most impactful change we made was connecting Taskee to GitHub so that task status updates happen automatically. Before this integration, developers would finish coding, merge their PR, and then forget to update the task board. The board was perpetually out of date, which meant sprint reviews were inaccurate and stakeholders lost trust in the process. Automation fixed this completely. The board now reflects reality because humans are removed from the status update loop.
Separate Communication Channels by Purpose
Early on, we had one Slack channel per project and everything went into it: technical discussions, client feedback, design reviews, deployment notifications. Finding anything was impossible. Splitting into purpose-specific channels (#project-dev, #project-design, #project-deploys) made conversations searchable and reduced noise for people who only needed to follow certain topics.
Document Decisions, Not Just Outcomes
Our Notion architecture decision records capture not just what we decided but why. Six months later, when someone asks “why did we use PostgreSQL instead of MongoDB for this project,” the ADR explains the reasoning, the alternatives we considered, and the trade-offs we accepted. This prevents relitigating settled decisions and helps new team members understand the project’s technical history.
Invest in Onboarding Documentation
The onboarding guide for each project pays dividends every time someone new joins. The 30 minutes it takes to write a clear setup guide saves hours of hand-holding per new developer. We treat onboarding docs like code: if the setup process changes, the docs get updated in the same PR.
Our stack is not perfect, and it will continue evolving. But the principles behind it, specialization, automation, transparency, and data-driven planning, have proven durable across dozens of projects. If you are building your own workflow from scratch, start with those principles and choose tools that embody them. The specific tool names matter less than the habits they enable. For a broader view of what modern web development workflows look like, check out our performance optimization guide and our frameworks comparison to see how the tool choices connect to the bigger picture.
