Every so often, I go looking for a plugin to solve a relatively simple problem and make the mistake of assuming that somebody must already have built exactly what I need. In this case, I wanted a task list.
The problem was that I didn’t want a project management platform, a collaboration suite or a Kanban board with automations, workflows, milestones, dependencies, Gantt charts and seventeen different notification settings. I just wanted somewhere to keep track of the work I needed to do.
At the other end of the scale, the really simple task list plugins were too simple. A task, a checkbox and perhaps a due date wasn’t quite enough either. What I actually needed sat somewhere awkwardly in the middle, and after looking at the options available I came to a fairly obvious conclusion.
I should just build it.
The problem with buying software by feature count
Commercial software has a natural tendency to grow. A developer builds a task manager, customers ask for subtasks, then recurring tasks, then teams, notifications, calendars and integrations with Slack, Teams, Google Calendar and whatever else happens to be fashionable that month.
None of those features are necessarily bad, but eventually you can find yourself using software where 90% of the interface exists to support things you’ll never use. Worse still, you often end up changing the way you work to fit the software, rather than having software that fits the way you work.
For my own task management, I already knew exactly what information I needed. I wanted a task linked to a client and project, with a status, priority, relevant dates, estimated and actual duration, and the person responsible for it. I also wanted to attach the occasional file or link.
That was pretty much the specification.
WordPress already gave me most of the underlying system. A custom post type could store the tasks, Advanced Custom Fields could handle the data, and a few custom shortcodes could provide the front-end interface. There was no real need to introduce another large plugin when the building blocks were already there.
Simple quickly became slightly less simple
Of course, this is where these projects become interesting. The first version was straightforward, but then I started actually using it and immediately noticed small things I wanted to change.
For example, if a task is in progress and I haven’t recorded the actual time yet, I still want to see how long I thought it would take. The task list now shows the estimated time instead, but prefixes it with a tilde so ~4 hours is clearly an approximation rather than recorded time.
Then I noticed that decimal hours looked ugly. 0.25 hours isn’t particularly pleasant to scan in a list, so that became ¼ hour. Half an hour became ½ hour and three quarters became ¾ hour.
It’s a tiny detail, but that’s exactly the sort of detail you can fix when you’re building something for yourself. I doubt many commercial task management systems have a feature request near the top of their list saying “please make quarter hours look nicer”, but I wanted it, so I added it.
Dates evolved in much the same way. A task that hasn’t started has a planned date, a task in progress has a started date and a completed task has a completed date. I also know myself well enough to know that I’ll occasionally mark something as complete and forget to enter the completion date, so the system now adds today’s date automatically if I leave it blank.
Not revolutionary, but useful.
The best features came from actually using it
This was probably the most enjoyable part of the project. I didn’t try to design a complete task management application in advance. I built the basic version, started using it and allowed each irritation to suggest the next improvement.
The sorting dropdown felt clumsy, so the table headers became clickable. Once the table headers handled sorting, the dropdown was redundant and disappeared, leaving space for a Reset Sort button.
Completed tasks started cluttering the day-to-day list, so they’re now hidden by default with a Show Completed option. The task title needed more visual prominence, so its column became wider, bold and slightly shaded. Only the people who actually work on tasks should appear in the assignment field, so the user selector now only includes Editors rather than the site’s administrative account.
The latest addition came from looking at the duration column. I already had the number of hours and the hourly rate stored against each task, so I realised the system could calculate the likely value of the work. I didn’t want another column making the table wider, so hovering over the duration now shows the calculated value in a simple tooltip.
Again, none of these are headline features. You wouldn’t build a marketing campaign around a duration tooltip or automatically filling in a forgotten completion date, but together they make the system noticeably better to use.
That’s the advantage of building the boring stuff
There’s sometimes a temptation to think custom development should be reserved for complicated or unusual projects. I’m increasingly convinced that some of the best things to build are the boring internal tools you use every day.
A commercially available plugin might have 150 features and I might only need twelve. On paper, the commercial product is clearly more capable, but if my twelve features work exactly the way I think, use the terminology I use and remove the little annoyances that slow me down, my much simpler system can be considerably more useful to me.
My task system doesn’t have a roadmap, a feature comparison table or a Pro version. It doesn’t integrate with dozens of third-party services and nobody is going to produce a two-hour YouTube course explaining how to configure it.
It does, however, display ~½ hour instead of 0.5 hours, and strangely that makes me very happy.
Build the thing you actually need
This project started because I couldn’t find a task management plugin I liked. A few hours later, I had something considerably closer to the way I actually work, built on a platform I already use and using tools I already know.
Will I add more features? Almost certainly. In fact, based on the number of times I said “one last thing” while building it, I think that’s guaranteed.
But that’s rather the point. I don’t need to wait for a plugin developer to add a feature, submit a feature request or work around somebody else’s idea of how task management should operate. If something annoys me, or I spot a small improvement that would make the system more useful, I can change it.
Sometimes you don’t need more software. You just need the right software. And occasionally, the answer is to build it yourself.