How I Built A Task Management Tool For Almost Nothing

from the all-the-information-is-in-the-task dept

This is part two of my series on using AI tools to fight back against tech company control. Part one explained why we can get beyond just begging billionaires to fix our tools. This part shows exactly how I built my own tool — with zero coding skills and almost no money.

A few weeks back, I got tired of productivity apps that don’t work the way I think and decided to build my own. Not for millions of users or venture capital — just for me. Using nothing but plain English prompts to AI tools (what’s referred to as “vibe coding”), I now have a task management system that works almost exactly how my brain works, costs almost nothing to run, and can’t be enshittified by some growth-hacking product manager.

As a joke/homage to the absolutely brilliant UK TV show Taskmaster, I call my app, “L’il Alex,” in honor of the show’s creator “Little” Alex Horne who is, after all, the “Taskmaster’s Assistant.” Which is exactly what I need. An assistant to help me with tasks.

Like plenty of people, I’m obsessed with productivity but terrible at productivity tools. I’ve tried dozens of different systems, but none stuck. I’m one of those awful people who keeps a mental list of tasks, supplemented by email, calendar chaos, and browser tabs I swear I’ll get to eventually.

This means things fall through the cracks — but more importantly, it means I’m constantly fighting tools designed for someone else’s workflow, not mine.

I’ve tried dozens of task management tools, and they all suffer from the same problem: they’re built for the mythical “average user” rather than how any specific person actually thinks. The closest I’ve found is Intend.do, which calls itself an “intentionality” tool rather than a productivity tool.

The key difference with Intend is that rather than loading up a million tasks that you never get to (the downfall I — and many others — have with most task manager tools), Intend is focused just on today. You create a few larger goals, and then each day, you jot down which tasks you want to do towards those goals. It makes it very simple to do that, and then as you go, you can check off what you accomplished. It also asks you some questions, and checks in with you over time.

Intend gets daily planning mostly right, but it can’t handle future task planning the way my brain works. There’s a hacky Workflowy integration, but it’s awkward. More fundamentally, Intend has strong opinions about how I should work, and like every other tool, forces me to adapt to its worldview. It got me maybe 65% of the way there — which is why I kept abandoning it.

This is the core problem with all productivity software: you’re renting someone else’s vision of how work should happen. When that vision doesn’t match yours, tough shit. You adapt or you leave. But you never get to actually control the tool.

So I decided to build exactly what I needed: daily planning like Intend, but with integrated future task management, and none of the philosophical baggage (some of which may be great for others, but didn’t mesh with me!). A tool that adapts to me, not the other way around.

Here’s where the “vibe coding” magic happens — and it’s way simpler than you think. I started with two popular AI coding tools (Bolt and Lovable) and just… asked them to build what I wanted. In plain English. No technical specs, no wireframes, no user stories. Just this:

I would like to create a kind of task manager, with the focus being on what you need to work on today, but which will also store “future” tasks. The main goal would be to let me choose which tasks I will work on that day, put them in a list and check them off, while also listing out future tasks that can be stored in a separate screen, but which can then easily be added to today’s tasks as necessary. It would also be useful to have the system nudge me if I put a task in “today’s tasks” multiple days without accomplishing it, perhaps asking me if I want to break it up into multiple tasks. The tasks can also be separated into different categories of tasks so I can organize what types of tasks they are. The categories should be changeable/editable. Tasks should be movable from category to category, and I should be able to prioritize tasks. Also, it should be possible to set tasks to be recurring. Tasks should also be able to store clickable links and notes. Future tasks can have dates attached to them. There should be a daily “check in” at the end of the day to see how I’ve done.

I wanted to try multiple platforms partly out of curiosity, but mostly because this is the beauty of vibe coding: if one AI interprets your request in a way that doesn’t click, you just try another. You’re not locked into anyone’s interpretation of what you need.

With that, both created initial versions of this tool. Bolt called its version “TaskIntent” while Lovable called its version “Future Focus Daily.” I started playing around with each one, making some suggested changes or explaining how I wanted things to work slightly differently. Each service gives you a certain amount you can prompt the system for free each day (with Lovable it’s 5 free prompts, with Bolt it’s based on the number of tokens you use, but is roughly 5 free prompts).

After three days, I realized that the version Lovable had created was closer to what I wanted and decided to just focus on that one (this is also where I renamed it to “L’il Alex”; RIP “Future Focus Daily”). This highlights something important about vibe coding: different tools interpret the same request differently, and finding the right fit is part of the process. It’s not about the “best” tool — it’s about what works for your specific brain.

At that point, I also thought I’d see if I could build and deploy the tool for myself for no money, based on just giving it five prompts per day. By that third day, I started using the tool to manage my tasks. The only major problem I ran into early on was a realization that, despite my connecting this new app (at Lovable’s suggestion!) to a database at Supabase, it initially was storing all my tasks locally. So when I logged in on my phone to see how it worked as a mobile app, it was empty. But all it took was a single prompt to rectify that, and now my tasks are stored in a database.

My plan to do the whole thing for free hit a stumbling block a few days later, when I realized that while Lovable’s free account gives you five free prompts per day, there is still a limit of 30 total per month. So, after about six days of using it, you’re likely on hold until the next month starts.

At that point, I tried a few other approaches. I had connected my Lovable project to GitHub, so I had a repository with all the code, and I saw that Bolt had recently integrated with GitHub as well. I tried to open the repository with Bolt to see if I could continue working on it there, but it… didn’t work. It literally would ask me which project I wanted to use in GitHub, I would click on the repository, and Bolt would just reload as if nothing happened.

Then, at the suggestion of a friend, I tried to import the project into Firebase Studio, owned by Google, and built on top of Firebase. As with Bolt, I first tried to pull in my GitHub repo, which worked… except, for reasons I don’t understand, the AI features then all seemed disabled. After messing around with it for a bit and getting nowhere, the same friend who recommended I try Firebase Studio said “it might just be faster to ask Firebase Studio to recreate the project from scratch.” I gave it the same prompt and… it created “Momentum Flow,” with its own interpretation of the prompt.

I played around with it a bit more, but quickly realized that Firebase Studio definitely expects a bit more knowledge/experience to use and is not nearly as seamless as Lovable. For example, knowing I needed a database backend, I asked it to set that up and (not surprisingly) it suggested I use Firebase. But… rather than set it up, like Lovable did with Supabase, it just told me I needed to set it up manually. And I kept running into similar issues, where it would suggest what I should do, rather than just doing it. I’m sure that’s great for actual programmers, but my goal here was different.

For what it’s worth, I also tried another tool called Adaptive.ai (it named my app FocusDay), which seems pretty cool, but after running into a few more issues with it, I gave in and decided that my goal of a totally free app was too ambitious and agreed to pay $25/month for 100 prompts at Lovable. It turns out that you actually get more than that, as Lovable gives you five free prompts a day (use ‘em or lose ‘em that day), and after you use those up, you get those 100 additional prompts. So, in reality, you can do somewhere between 100 and 250 prompts, if you time it right.

Since then, I’ve been iterating the app to work exactly how my brain works. It’s probably terrible for anyone else — but that’s the point. For the first time in years, I have a productivity tool that doesn’t fight me.

This is what total control over your tools actually looks like. Here’s the “plan your day” page, which I either use late at night for the next day, or early in the morning for the upcoming day:

Tasks age visibly so I can see what I’ve been avoiding. Everything flows the way my brain actually works.

I prioritize tasks however makes sense to me that day. I can mark what I’m working on now versus next, and it automatically organizes itself around my actual workflow.

At day’s end, it checks in with me the way I want to be checked in with — not with guilt-inducing streaks or gamification bullshit, just some simple stats and details about the day (and it lets me create follow-ups on tasks I completed recently).

The system handles my unfinished tasks exactly how I want: no shame, no penalty, just moving them back to the future pile for tomorrow’s planning session, with the kind of notifications I want. So each day starts fresh, and I get to plan out how I want my day to go.

The whole thing has worked brilliantly since about day three. After two weeks of daily use, I’m genuinely hooked — not because of gamification tricks or habit-forming design patterns, but because the tool actually serves me instead of fighting me. I’m still tweaking some things here and there, but the tool just works. For me.

Here’s the real magic: when I want a new feature, I just ask for it. Last week I decided I wanted habit tracking integrated into my task flow. A few prompts later, done. No waiting for the next product roadmap, no hoping some PM thinks my use case matters. No upsell on it as a “premium” feature. I just had the system build it.

I also added a bookmarklet for capturing articles to write about and turning them into tasks as well as an email integration for turning emails into tasks. These weren’t planned features — they were just friction points that annoyed me, so I eliminated them.

The email integration required setting up a webhook through IFTTT — the AI initially suggested Gmail could handle webhooks directly (wrong), but it quickly pivoted to working solutions. This is typical of vibe coding: the AI makes occasional mistakes, but iterating toward working solutions is still faster than begging some company to maybe add your feature request to their backlog.

Sure, there are still some small bugs to fix and features to add. But here’s the difference: when something doesn’t work the way I need it to, I can actually fix it. I’m not stuck filing support tickets into the void or hoping the next update doesn’t break something I rely on.

There have been minor annoyances — occasionally when I asked it to add a feature, it reverts older changes or gets weird design ideas — but I can just tell it to fix things and it does. Compare that to every other productivity tool I’ve used, where design decisions that annoy me are just permanent facts of life I have to accept.

Intend got me 65% of the way there. L’il Alex is already at 85% and climbing. More importantly: when my needs change, the tool adapts. I’m not locked into someone else’s vision.

This is exactly what vibe coding is for: solving personal friction points without waiting for permission from product managers whose incentives don’t align with yours.

So, for all the folks who are concerned about centralized control and losing agency over their digital lives: there are now more options beyond just yelling at tech companies or hoping for better government regulation. For personal productivity tools, workflow automation, and small community projects, you can actually build what you need, no coding skills needed. The tools exist, they’re accessible, and they work. Sometimes the best way to escape someone else’s control is to just stop asking, and just take charge.

Filed Under: , , , , , , ,
Companies: bolt, google, intend, lovable

Rate this comment as insightful
Rate this comment as funny
You have rated this comment as insightful
You have rated this comment as funny
Flag this comment as abusive/trolling/spam
You have flagged this comment
The first word has already been claimed
The last word has already been claimed
Insightful Lightbulb icon Funny Laughing icon Abusive/trolling/spam Flag icon Insightful badge Lightbulb icon Funny badge Laughing icon Comments icon

Comments on “How I Built A Task Management Tool For Almost Nothing”

Subscribe: RSS Leave a comment
31 Comments
Anonymous Coward says:

This is how I’ve begun using AI as well, although I tend to use MS Copilot or Duck.ai, and just have them build me python scripts that in turn will build stuff for me.

I’ve found “write me a python script that will build a…” works amazingly well, with no integrations needed. Then, I run the scripts, check the results, and give the AI feedback. I’ve also got it to build the scripts as independent functions, so once one action works the way I want, I can re-use it in any projects I want, and feed it back into the AI and ask for tweaks if I want a slightly different script to build something else.

This was mostly to get around context window hell, where one of the key bits you need falls off the end of the window without you noticing. Building stuff in small chunks and then running it all to build something more complex seems to work for me, anyways.

Mark Murphy (profile) says:

Writing Software Is Like Buying a Puppy

TL;DR: It’s all fun and games until somebody has to clean up the mess on the floor.

 

Presumably, this Web app uses Web frameworks. Do you know what they are? Do you know what versions you have? Do you know how you will update them and fix any compatibility issues that arise? Do you know how you will find out about security issues related to them?

You are storing the data in some database-as-a-service, apparently (you mention Supabase, but it’s unclear if that’s who you went with in the end). Will you be paying attention to its announcements and making changes to your app as needed? Will you be tracking its reported security flaws? What sort of backups will you have, and how will you restore them? What will you do if they have downtime for an hour? A day? A week? Forever?

How much testing was done? If there is a bug in the generated code that causes latent corruption in your data model, how will you find and fix it?

And so on.

 

You have focused on the cool fun part of programming. Lots of neophyte software developers do that! It’s practically a rite of passage. However, you need an actionable plan for dealing with the software that you wrote over time. Using self-written software without such a plan is like buying a puppy with no thoughts of how to raise one. Worse: puppies are simple by comparison, though usually they are cuter.

Note that none of my concerns are due to AI directly. “Vibe coding” exacerbates the problems, but it does not cause them. “Vibe coding” has the potential of introducing an “eternal September” event, though, where lots of people write lots of stuff that will become abandonware.

It is very possible that you do have plans regarding the sorts of things that I mentioned above. You have been running Techdirt for a long time, and I suspect that you have above-average tech skills as a result. But that also means that you are not necessarily representative of the audience that might gravitate towards “vibe coding”.

I am not saying that “vibe coding” is bad, or that your software sucks! However, as a long-time industry veteran who has gone through past “eternal Septembers” (e.g., all data can be managed by Excel spreadsheets), I have concerns.

Regardless, I hope that you enjoy your new puppy! Get a flea-and-tick collar, as you really don’t want it to have bugs.

Anonymous Coward says:

Re:

Eh. For personal use for non precise or possibly destructive use cases I don’t see the issue.

I wouldn’t trust a vibe coded app to handle my personal finances for example.

It doesn’t have other users, you aren’t going to get sued by a user for a bug, and so on.

The only issue I see is when the code gets too large to manage by AI successfully, where changes start to break things.

Anonymous Coward says:

Re:

This is why I get AIs to write modular Python scripts instead. It means I can also get the AI to write a script that monitors the service update channels and CVE lists and alert me if something’s gone out of spec or is in urgent need of a patch — and then secondary scripts to apply patches.

In my case, it also helps that I can read the Python and see what it’s doing, and fix it if it’s not doing the right thing.

But for puppy coding, using that modular approach also means that they get to play with their shiny new tool immediately, and when something eventually breaks, they’ve probably learned enough along the way to fix that one broken piece without having to start over.

For example, knowing I needed a database backend, I asked it to set that up and (not surprisingly) it suggested I use Firebase. But… rather than set it up, like Lovable did with Supabase, it just told me I needed to set it up manually. And I kept running into similar issues, where it would suggest what I should do, rather than just doing it. I’m sure that’s great for actual programmers, but my goal here was different.

Here’s the thing. The Google AI was taking the correct approach. It’d be nice to also be able to automate those steps, but at least the AI was informing the prompter as to what needed to be done, giving the prompter the option to learn, and to have some understanding of what will eventually go wrong and need to be fixed. While more painful, it does mean that when one of the links in that chain vanishes in 6 months, that won’t mean the entire project needs to be abandoned AND won’t mean that there’s a forced crash course in DB admin.

Anonymous Coward says:

Re:

Something else to add to your comment: I just had the realization that for most people, there’s very little difference between what Mike’s done here and using a SaaS product — sure, SaaS is more likely going to be patched and kept up to date, but over time, it will cease to do things the user wants it to do, forcing them to change habits or look for a different solution.

So from that perspective, this is an improvement, even if it results in exploitable services that never get updated and eventually fail due to a key component going offline — after all, it’s not like we don’t have millions of WordPress and Drupal services out there, out of date and insecure.

I guess what I’m saying is that it helps solve an immediate end user problem, frees users from SaaS monoculture (making it harder to exploit ALL the solutions), while still not fixing the problems that very much already exist everywhere where someone isn’t willing to pay for real developer services.

Anonymous Coward says:

Re:

TL;DR: It’s all fun and games until somebody has to clean up the mess on the floor.

Some years ago, I had a home inspection that I could summarize as “basically everything had been worked on by some unskilled person”. Most mistakes were quite small, and would’ve been easy to fix; if I’d hired a carpenter, plumber, electrician, HVAC person, pest control expert, mould remediator, and attic insulator, most would’ve been in and out in a couple of hours. Or I could’ve done some of that myself. (I walked away, because I couldn’t help but wonder what the inspector might have missed, and the offer hadn’t been priced as for a “fixer-upper”.)

I’m thinking that, in the future, programmers might mostly be the people hired to “clean up the mess on the floor”. I already know a couple of programmers like that, and they do pretty well (although they do have to hustle for clients; it’s not a consistent nine-to-five job). Tradespeople tell similar stories.

Long ago, it was speculated that the field of programming might go in this direction if Free Software became ubiquitous. I don’t recall anyone predicting it’d be free because it’d be written by A.I., thus ineligible for copyright; so that’s a fun surprise.

David Williams says:

Very interesting. I’m curious to what degree you proof / review / correct the code it generates. Do you just let ‘er rip and it works? Or is it more that it generates a relatively complete application architecture and implementation, but you still go through and iron out kinks and details and such.

Also curious how much review is spent making sure it doesn’t do anything bad. Example: when you had it connect to Supabase, does it / did you let it do all the account creation, authentication, etc? Or did it just create the methods in L’il Alex to configure the connection and you went and set up the Supabase account and connection using the methods it created?

Anonymous Coward says:

I would be absolutely terrified to expose vibe code to the internet like that. I would worry it’s riddled with security problems. But yeah, the capability is there. I wrote a whole scraper on my phone with ChatGPT once just to see if I could, and it went surprisingly well. I do think the average normie would have trouble with it; non-programmers who are nevertheless nerdy power users seem like the people who can get the most out of this approach.

Anonymous Coward says:

I’m basically a dumb guy with a liberal arts degree that taught myself Python and C#. I use my IDE’s AI plugin a lot, but I also go to GPT when I need something generic explained.

I would never copy/paste code from the assistants into my projects. I only allow myself to manually retype code it suggests. I only type code which I feel confident I understand. This has served me well, and I’m on a good pace to deliver a fully featured +more clone of one of the major AAAA (they release a console) publishers.

This is actually how I learned how to think/write. If I was assigned a reading in school and a passage struck me as particularly excellent, I went into my notes for the reading and wrote it again in its entirety, by hand, on pen and paper, using multiple pages if need be.

Just occupy your brain with the subject matter. Fill it to the brim till it’s overflowing. Whoever is making the content you put in there is irrelevant, human or robot, if you have a critical eye for reading sources and actively cogitate the entire time. I am prone to headaches!

I have equal skepticism for AI content and software documentation, because both are stale!

Leave a Reply to David Williams Cancel reply

Your email address will not be published. Required fields are marked *

Have a Techdirt Account? Sign in now. Want one? Register here

Comment Options:

Make this the or (get credits or sign in to see balance) what's this?

What's this?

Techdirt community members with Techdirt Credits can spotlight a comment as either the "First Word" or "Last Word" on a particular comment thread. Credits can be purchased at the Techdirt Insider Shop »

Follow Techdirt

Techdirt Daily Newsletter

Subscribe to Our Newsletter

Get all our posts in your inbox with the Techdirt Daily Newsletter!

We don’t spam. Read our privacy policy for more info.

Ctrl-Alt-Speech

A weekly news podcast from
Mike Masnick & Ben Whitelaw

Subscribe now to Ctrl-Alt-Speech »
Techdirt Deals
Techdirt Insider Discord
The latest chatter on the Techdirt Insider Discord channel...
Loading...