Our four-person team at Pristren manages between 30 and 50 tasks per week inside Zlyqor, which adds up to roughly 160 tasks per month. That number might sound high for a small team, but it reflects something real about knowledge-work at this scale: the work is granular, it is parallel, and if you do not break it into specific tasks, it lives in someone's head or in a Slack message thread until it falls through.
This post explains exactly how we structure those tasks, what the taxonomy looks like, how we organized work before Zlyqor (and why it broke), and what the AI task suggestions actually contributed versus what we ignored.
Before: Slack Messages and Spreadsheets
Before Zlyqor, our task management was a combination of three things that worked poorly together.
The first was Slack. When someone needed something done, they sent a message. The receiver either did it or flagged it with a checkmark emoji. Whether it got done, when it got done, and how long it took were not tracked anywhere. Things were forgotten. Things were done twice. Things were done wrong because the requirements were buried in a thread of 40 messages.
The second was a shared Google Sheets spreadsheet with columns for task name, owner, due date, and status. We maintained this inconsistently. When the team was under pressure, updating the spreadsheet was the first thing to stop happening. By month two of any project, the spreadsheet was a historical artifact, not a working tool.
The third was individual todo lists. Each team member had their own system, which meant no one had visibility into what anyone else was working on at any given moment. Coordination happened through status meetings, which added more meeting time to solve a problem that better tooling would have prevented.
The failure mode of this system: at the start of a new week, I had no reliable way to answer the question "what is everyone working on, and is anything blocked?" I had to ask in Slack, wait for four replies, and piece together a picture that probably missed half of what was actually in progress.
How We Structure Tasks in Zlyqor
The structure we use is: Organization, then Projects, then Phases, then Modules, then Tasks. In practice, most of our work runs through two to three active projects at a time, each with two to four phases.
A Phase is a major stage of the project. For a software product, a phase might be "MVP Build," "Beta Testing," or "Post-Launch Optimization." For a client project, it might map to billing milestones.
A Module is a functional grouping within a phase. For the MVP Build phase, modules might be "Authentication," "Dashboard," "Billing Integration," and "Deployment." Each module contains between 5 and 15 tasks.
Tasks are atomic. The rule we try to follow: if a task cannot be completed in one sitting by one person, it is not a task, it is a module that needs to be broken down. This rule is violated regularly, but having the rule makes the violations visible and fixable.
The Task Taxonomy
Looking at six months of task data, our work falls into roughly six categories. Here is the approximate time split:
Product development tasks: 40 to 50 percent. These are the tasks that produce the actual deliverable, whether that is code, design, copy, or architecture decisions.
Client communication tasks: 10 to 15 percent. These include writing proposals, preparing demos, drafting update emails, and handling feedback. They take more time than teams usually budget for.
Quality and review tasks: 10 to 15 percent. Code reviews, design reviews, testing, and bug fixes. This is the work that most teams underestimate in project planning.
Administrative tasks: 8 to 12 percent. Invoicing, expense tracking, contract management, and the other operational work that keeps a business running.
Research and learning tasks: 8 to 12 percent. Evaluating new tools, reading documentation, testing integrations, and the work of staying current in a field that changes every few months.
Planning and coordination tasks: 5 to 8 percent. Writing project specs, updating roadmaps, running retrospectives, and the work of making sure the team is aligned.
The insight here is that only 40 to 50 percent of tasks are directly productive in the immediate, deliverable sense. The other 50 to 60 percent is the infrastructure of doing the work. Teams that do not account for this infrastructure tend to underestimate how long projects will take.
What AI Task Suggestions Actually Did
Zlyqor has an AI feature that suggests tasks based on the content of a project, the phase you are in, and the work already recorded. I want to be specific about what this did and did not contribute for us.
What it got right: when we started a new module, the AI suggestions often caught tasks we had forgotten to include. For a "Billing Integration" module, for example, it suggested tasks like "test webhook failure handling" and "add retry logic for failed payments" that I would have added eventually but that would have been added late. Having them surfaced at the start of the module, rather than as post-launch bug fixes, was genuinely useful.
What it got wrong: the AI suggestions are generic. They do not know the specific constraints of our project, our client's preferences, or the technical decisions we made three weeks ago. About 40 percent of the suggestions we received were either already covered by an existing task, irrelevant to our specific implementation, or too vague to be actionable as written. We used them as a checklist prompt, not as ready-to-go tasks.
What we ignored: suggestions in categories where our process was already solid. The AI consistently suggested documentation tasks, for example, and we consistently had documentation built into our development process already. Accepting those suggestions would have created duplicate tasks.
The net contribution: the AI suggestions probably added 8 to 12 genuinely useful tasks per month that we would have otherwise missed or added late. At our productivity rate, catching those tasks early rather than late saves meaningful time. But the suggestions required active evaluation, not passive acceptance.
What the Data Changed About Our Planning
The most valuable thing about having 160 tasks per month of real data is what it does for future project planning.
When I estimate a new project now, I am not guessing. I can look at comparable past projects and see how many tasks they generated, how long each category of task actually took, and where we typically underestimated. Our estimates are now accurate to within 15 to 20 percent on similar projects, compared to 40 to 50 percent error rates when we were estimating from intuition.
The second thing the data changed: how I communicate with clients. When a client asks "how long will this take?" I can show them historical task data from similar work, broken down by category, with actual hours logged. That conversation is easier and more credible than "we think about six weeks."
The third thing: how we handle scope changes. When a client requests a change, I can look at comparable tasks in our history and give a specific hour estimate instead of a vague range. The data has made us a better business, not just a more organized one.
Keep Reading
- We Replaced 6 SaaS Tools With One: What 6 Months of Real Data Shows — The broader story of consolidating our toolstack and what it saved
- 160-200 Team-Hours Tracked Per Week: What Our Data Shows About AI-Assisted Productivity — How the hour data maps onto task data and what the combined picture shows
- The Hidden Cost of Tool Switching: What We Measured With Our 4-Person Team — The productivity cost of the tool sprawl this task structure replaced
Pristren builds AI-powered software for teams. Zlyqor is our all-in-one workspace — chat, projects, time tracking, AI meeting summaries, and invoicing — in one tool. Try it free.
