New version of Will Be Done is released! Will Be Done is an offline-first, self-hosted task manager with a visual weekly timeline.

The main idea is simple: collect tasks, put them on a week timeline. I find that the week timeline helps me stay more organised and fits naturally into my workflow. It works offline-first with server sync, so tasks are stored locally in the browser/desktop app (like Linear), and it also gives an instant UI.

What changed since my last post (v0.10.0):

  • Added mindmap support
  • Added calendar support with readonly ical/caldav integration
  • Added markdown WYSIWYG editor, with collaborative edit support (yjs)
  • Added OpenAPI support
  • Added task recovery: deleted tasks go to Trash, and there’s an undo popup on accidental task/project/section delete
  • Added undo/redo
  • Added notes
  • Added multi-select

Links:

Demo: https://demo.will-be-done.app/

GitHub: https://github.com/will-be-done/will-be-done

Download desktop app: https://github.com/will-be-done/will-be-done/releases

More info: https://will-be-done.app/

Self-host with Docker:

docker run -d \
  -p 3000:3000 \
  -v will_be_done_storage:/var/lib/will-be-done \
  --restart unless-stopped \
  ghcr.io/will-be-done/will-be-done:latest

Then open http://localhost:3000/.

Would love to hear feedback!

AI disclosure

  • Design - architecture, system design: no AI involved. I’ve been working on local-first apps for ~5y and have been a software engineer for ~10y. I even built HyperDB, a database for local-first apps, because existing solutions such as Dexie and RxDB didn’t meet my needs.
  • Implementation - Pair. From the start of the project it was Hint, but now it’s Pair.
  • Testing - Generated.
  • Documentation - Pair.
  • Review - Pair. I have coderabbit AI + greptile, but also do manual review.
  • Deployment - Pair.
  • MonkderVierte@lemmy.zipEnglish
    52·
    4 hours ago

    Sounds like something i need. Will try, as soon as i get my server running. 😁

    To the downvoters butthurt about AI use: pair-programming is fine here, catches the worst issues with LLM, as long as the dev doesn’t get AI psychosis. And this is mostly a GUI type app anyway, “architecture, system design: no AI involved”, so the server part is likely fine.

    • quolpr@lemmy.worldOPEnglish
      3·
      3 hours ago

      Hey! Yep, thanks for the kind words. I’m fully responsible for the architecture and system design. I spent a lot of time thinking this through, and how to build good local-first apps was on my mind even before AI (I built a note-taking app called Harika before and worked at RemNote).

    • craigify@lemmy.sdf.orgBanned from communityEnglish
      32·
      4 hours ago

      Hello. I also continue to grapple with LLM use in software development myself, and I have so far found it most useful for me for research, documentation discovery, reading and summarizing RFCs and docs, as well as brainstorming and building smallish snippets of code.

      Can you describe what you mean by pair programming with LLMs?

      • MonkderVierte@lemmy.zipEnglish
        2·
        3 hours ago

        Can you describe what you mean by pair programming with LLMs?

        You mean the dev, right?

        Edit: in my case, i understand with it that the LLM can see the code but not touch it.

      • femtek@lemmy.blahaj.zoneEnglish
        11·
        2 hours ago

        Now this is what Google “search” output but it did neatly define the different types. I use pair and hint based at work as they self host some models and I still want to get better at what I do.

        1. Pair Programming (Driver / Navigator)

        • How it works: You and the LLM take turns writing and reviewing code, mirroring human pair programming. [1]
        • Roles:
        • You Drive, LLM Navigates: You write the core logic, and the LLM points out edge cases, syntax bugs, or refactoring ideas.
          • LLM Drives, You Navigate: You outline the architecture or pseudocode, and the LLM scaffolds and writes the boilerplate implementation. [1]
        • Best used for: Complex feature design, real-time debugging, and interactive problem-solving. [2, 3]

        2. Hint-Based / Socratic Programming

        • How it works: Instead of asking the LLM to write the solution, you ask it to act like a mentor or tutor that only gives small conceptual hints or diagnostic questions.
        • How to prompt it: “Don’t give me the code. Tell me which function is likely causing this memory leak and give me a hint on how to fix it.”
        • Best used for: Learning new languages, sharpening debugging skills, and preventing over-reliance on auto-generated code.

        3. Spec-Driven & “GSD” (Get Ship Done) Development

        • How it works: You write a formal specification (spec file, requirements, and design docs) first, and feed it into an agentic workflow or IDE assistant to build the application step-by-step. [4]
        • Best used for: Building greenfield applications, managing multi-file changes, and keeping AI output aligned with a clear product blueprint. [4]

        4. Multi-Model Parallel Programming

        • How it works: You feed the exact same prompt or task into multiple LLMs simultaneously (e.g., Claude, GPT, and Gemini) inside environments like Cursor IDE, which spins up isolated Git work trees for each model. [5]
        • Best used for: Comparing different architectural approaches, edge-case handling, or test-case generation before merging the best solution. [5]

        5. Meaning-Typed Programming (Type-Driven LLM Calls)

        • How it works: An emerging paradigm (such as research languages like Jack) where LLM invocations are abstracted directly into type signatures and function semantics rather than brittle, hand-crafted prompt strings. The compiler handles prompt construction, type parsing, and retries automatically.
        • Best used for: Deeply embedding AI calls (like content generation or game level design) straight into strongly typed application code. [6]

        6. Autonomous Agent Loops (“Vibe Coding” / Self-Correcting Agents)

        • How it works: You give an AI agent a high-level goal, unit tests, and shell/file access. The agent writes code, runs the test suite, reads the stack trace, self-corrects, and loops until the tests pass.
        • Best used for: Writing self-contained scripts, repetitive migrations, and well-bounded bug fixes (e.g., via SWE-Bench style workflows). [4, 7, 8]