Can You Build Your Own Project Management Tool? Four Ways to Build One, and the Limits of Each

With AI, building your own project management tool has become a far more realistic option.

This article compares four ways to build one and lays out the effort and limits of each. The short answer first: yes, you can build a project management tool. The real question is how many people will use it, for how long, and who will fix it.

Note: this article is written by the developer of GeckoFlag. GeckoFlag is an issue tracker that its developer built for their own use and then turned into a product. In this series, we write from the perspective of someone who has built one, covering both the good parts and the hard parts.

Why people want to build their own

People start thinking about building their own tool for different reasons. First, let’s look at each reason and ask whether building your own actually solves it.

If the reason is “too expensive” or “too much,” looking for a different ready-made tool may solve the problem. On the other hand, if your workflow is unusual and nothing fits, or building it is the goal in itself, building your own makes sense.

A clear reason also makes it easier to choose among the methods below.

There are four ways to build one

Broadly, there are four ways to build a project management tool.

Scroll the table sideways →

With any of these methods, you can build the basic shape: add tasks, give them an owner and a deadline, and change their status. The differences show up when more people start using it, and when you need to fix it later. Let’s look at each in turn.

Building it in a spreadsheet

The easiest option is Excel or Google Sheets. A minimal setup needs just four columns:

• Task: one to-do per row
• Owner: who does it
• Due date: by when
• Status: chosen from a drop-down, such as not started, in progress or done

Add conditional formatting so overdue rows change color, and delays become visible at a glance. For one to a few people working on a project that wraps up in a few months, this is often enough.

As the number of people and tasks grows, though, the sheet slowly starts to break down. There is nowhere to record the history of a task, and writing someone’s name as the owner does not notify them.

RelatedThe limits of managing work in a spreadsheet are covered in detail in Part 2 of our beginner series “Your First Project Management Tool,” “Where Does an Excel Tracking Sheet Hit Its Limit?”

Building it with a no-code tool

No-code tools such as Notion or Airtable let you create a database and display it as a list, a kanban board, a calendar and so on. You can put together an issue tracking system without programming.

Their strengths are that you can add fields freely and make things look good easily. You can try out a setup that fits your work and adjust it as you go.

On the other hand, watch out for the following:

• Costs tend to rise with headcount: many of these services charge by the number of users, so you may end up paying about as much as for a ready-made tool.
• Only the builder understands the structure: it is easy to end up in a state where only the person who built it knows which field connects to what.
• You depend on the service: any change to the service’s features or pricing affects you directly.

Building it by writing code

If you can program, you can build it from scratch. This gives you the most freedom, and you can fit it exactly to your work. It also makes an excellent learning project.

What takes time, though, is not the visible parts such as the task list or the entry form. It is the parts you cannot see on screen:

• Sign-in and password management
• Permissions: who can see and do what
• Storing the data, and protecting against losing it

On top of that, you handle everything after launch yourself: fixing bugs, and keeping up with updates to your server and programming language. It is not unusual for the time spent maintaining it to exceed the time spent building it.

Having AI build it

The method getting the most attention right now is having AI write the code. Ask it to “build an app where I can add tasks and give each one an owner, a due date and a status,” and you may have something working on screen in a matter of hours.

Getting something working without knowing how to code is a big change. There is one thing to be careful about, though.

If you cannot read the code it produces, you will not be able to fix it when a bug appears. Asking the AI again may fix it, but something else may break. To tell what broke and where, you still need to be able to read code.

How the safety and rights of AI-written code are handled also depends on the terms of the service you use and on how you use what you build. If you use it for work, check the terms of the AI service you use.

SeriesHow far you can actually get with AI is the experiment in Part 2, “We Had AI Build an Issue Tracker” (coming soon)

Choosing comes down to how many people, for how long, and who will fix it

Which of the four methods to choose depends less on features and more on how you will use it. Using three questions, how many people, for how long, and who will fix it, here is a rough guide:

Also, if your workflow is so unusual that no ready-made tool fits, building your own (writing code, or having AI build it) is worth considering, regardless of team size or time frame.

This table is only a rough guide. Even for one person or a small team, there are times when a tool makes things easier.

Pay special attention to the last row. Outside people will use it, it will be used for years, the person who built it may move on or leave. If even one of these applies, read Part 3 onward before you start building.

What lies between “it works” and “it’s usable”

Once people start building their own tool, many of them notice something partway through: there is a big gap between “it works” and “many people can use it for a long time.”

For example, the following are hard to think of while you are building the first screens:

• What each member can see: you want outside people to see only this one project
• Resetting a forgotten password: you want people to reset it themselves by email
• Email notifications: you want to notify people when they are assigned a task or when a comment is added
• Data backups: you don’t want to lose your task history even if the server fails

All of these become necessary as soon as more people start using the tool. And each one you build adds more to check and more to fix.

SeriesThe items people only notice after building their own are turned into a checklist in Part 3, “The Distance from ‘It Works’ to ‘It’s Usable’” (coming soon)

Summary

• You can build a project management tool with any of four methods: a spreadsheet, a no-code tool, writing code, or having AI build it
• Building your own helps most when your workflow is unusual and nothing ready-made fits, or when building it is the goal in itself
• Which method to choose comes down to how many people, for how long, and who will fix it
• There is a big gap between “it works” and “many people can use it for a long time”

Building your own is by no means a reckless choice. But thinking about what happens after you build it, before you start, will save you detours.

Next time, we will have AI build an issue tracking app and see how far it gets. At the end of the series, as a developer who built our own tool, we will share our conclusion on whether to build or buy.

How task management itself changes once you use AI at work is covered in Part 1 of our series “Task Management for Teams Working with AI,” “Now That You Use AI, Do You Still Need a Task Management Tool?”