DEV Community: Nicolas A. R.

TaskCanvas: Visualizing task.md with Sanity

Nicolas A. R. — Mon, 05 Oct 2026 06:38:55 +0000

AnTaskCanvas

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange.

AnTaskCanvas started with a fairly ordinary problem.

I tried a lot of task management tools: Linear, Trello, GitHub Projects, Notion, Microsoft To Do, Google Tasks, and quite a few others. They all solve parts of the problem well, but in my case I always ended up with the same friction: planning and the actual repository lived in different places.

I would create tasks for one project, move on to another, then another one, and after a while that planning would be disconnected from its original context. I had to remember which workspace belonged to which repository, which notes belonged to which idea, and where I had written down that task I quickly captured so I would not forget it.

The end result was much less sophisticated than all those tools promised: a folder full of paper notes, random reminders, Google Keep, and scattered ideas.

The idea for AnTaskCanvas had actually been in my head for quite a while.

Originally, I imagined it as a VS Code extension: something that would let me open a project and see its tasks directly from the same place where I was writing code.

The problem was that I never really had the time to build all the infrastructure around it.

And with the rise of vibe coding, the problem became even more obvious to me.

You can build an application very quickly now, but you can also end up with bugs, half-finished screens, and decisions you made in a hurry and barely remember a week later. The faster you move, the easier it becomes to lose track of what you were doing and what was still pending.

The idea still made sense, but building it meant solving persistence, data modeling, users, state, and a whole infrastructure layer before getting to the part I actually cared about:

turning tasks into something visual without falling back to keeping everything locally — and quietly hoping my computer never decides to explode.

Then Sanity entered the picture.

Suddenly, a large part of that infrastructure no longer had to be the project itself. Sanity gave me a foundation for modeling and persisting the information without first having to build an API, a database, and all the infrastructure around it.

For me, that was hard to ignore.

The boring part already had a solid foundation.

What was left was the visual part.

And an idea I had been postponing for a long time could finally become something real.

The idea behind AnTaskCanvas is deliberately simple: each project can carry its own planning in a TASKS.md file, keep that file versionable and portable, and still turn it into something visual.

That file can be imported into the application, viewed and organized through a Canvas or Kanban view, and exported back to Markdown.

The application also tries to sanitize the file, because real TASKS.md files are rarely pristine. Tasks get written quickly, structures become inconsistent, and small formatting mistakes appear when the only thing that matters at that moment is not forgetting an idea.

What matters to me is not turning Markdown into another closed database.

It is keeping the planning directly connected to the project it belongs to.

Sanity sits just before that planning becomes part of the repository's official history.

An idea can appear at any time: during a commute, during a sleepless night, or while working on a completely different project. You do not necessarily want to turn it into a commit immediately. Sometimes you just want to keep it, see it in context, and decide later whether it deserves to make it into production.

That is where Sanity gets a second role.

GitHub preserves what we finally decided to build.

Sanity also preserves what we are still thinking about.

AnTaskCanvas uses that persistence to keep working state and project context even before everything has to become part of the Git history.

That creates a fairly natural separation:

Sanity is the living state of the project.

TASKS.md is its portable representation.

GitHub is its versioned history.

AnTaskCanvas sits between those three layers.

It is not trying to replace Linear, Trello, Notion, or GitHub Projects. It also does not require AI to manage tasks.

Its goal is much more specific: take something as flat and simple as a TASKS.md file and turn it into a visual, persistent, understandable workspace without breaking its relationship with the repository.

Because the problem I am trying to solve is not that we lack task managers.

It is that too often our ideas about a project live in one place, while the actual project lives somewhere else.

What I Built

I built AnTaskCanvas, an application that turns a TASKS.md file into a more visual way of working with the tasks inside a project.

The idea is simple: TASKS.md remains the portable source of truth, but instead of working only with a text file, AnTaskCanvas can import it, interpret it, and organize its tasks through Canvas and Kanban views.

The application also tries to sanitize the file during import.

In real projects, these documents are often written in a hurry, with inconsistent structures or small formatting errors. Before representing them visually, AnTaskCanvas analyzes and normalizes that information so it can work with it more predictably.

Once inside the application, tasks can be organized visually and persisted using Sanity.

Sanity stores the structured representation of the tasks as well as information that does not belong inside the Markdown itself, such as positions, dimensions, and the visual state of groups inside the Canvas.

When we want to return to the portable format, the planning can be exported back to TASKS.md.

The current main flow is:

TASKS.md
   ↓
import
   ↓
analyze / sanitize
   ↓
task model
   ↓
Canvas / Kanban
   ↓
persist with Sanity
   ↓
export TASKS.md

Direct GitHub integration — authentication, importing directly from a repository, and automatic synchronization — belongs to the next phase and is not part of the current demo.

AnTaskCanvas is mainly aimed at individual developers, indie hackers, and small teams working across multiple projects who want to keep planning close to the repository without turning it into yet another workspace that has to be remembered and maintained separately.

Demo

Live demo:

ancanvastask-pro.onrender.com

Screenshots:

Experience the primary interactive modes of AnTaskCanvas:

1. Infinite Spatial Canvas (`tldraw` v5)

Visual freeform canvas with custom TaskCard nodes, section groups, and live Directed Acyclic Graph (DAG) dependency connections (blockedBy).

2. Interactive Kanban Board

High-density column workflow (Todo, In Progress, Done, Blocked) with instant drag-and-drop state updates and inline editing.

3. Live Split Markdown Editor

Side-by-side CodeMirror Markdown editor with bi-directional AST synchronization—type in Markdown or edit visually with zero data loss.

4. Monorepo Document Explorer & Context-Aware Filters

Manage multi-scope task files (frontend/TASKS.md, backend/TASKS.md) with filter dropdowns that reactively reconcile with active document tags.

The main demo flow shows:

real TASKS.md
   ↓
import
   ↓
normalization
   ↓
Canvas
   ↓
Kanban
   ↓
editing
   ↓
persistence
   ↓
reload project
   ↓
restore visual context
   ↓
export TASKS.md

The goal of the demo is to show the real workflow, not just a collection of polished screens with controlled sample data.

Code

The source code for AnTaskCanvas is available on GitHub:

Repository:

https://github.com/anappwilos/AnCanvasTask_END

Branch:

main

The application is built with React, Vite, and TypeScript, using Tailwind CSS v4 for the interface and tldraw as the Canvas engine.

To work with TASKS.md, AnTaskCanvas uses a normalizer built on unified, remark-parse, and remark-stringify.

Its job is not simply to read Markdown.

It first interprets and normalizes the document into a structure that can be used by Canvas or Kanban, while still allowing the original Markdown workflow to remain intact.

At a high level, the flow looks like this:

TASKS.md
    ↓
markdownNormalizer.ts
    ↓
task model
    ↓
Canvas / Kanban
    ↓
sanityService.ts
    ↓
Sanity

The Sanity integration is kept separate from the logic responsible for interpreting Markdown.

That way, the file, its visual representation, and its persistent state do not depend directly on one another.

Main stack

React
Vite
TypeScript
Tailwind CSS v4
tldraw
unified / remark
Sanity
@sanity/client

Main pieces

src/utils/markdownNormalizer.ts
→ TASKS.md parsing and normalization

src/services/sanityService.ts
→ Sanity integration

src/services/workspaceService.ts
→ workspace and persistence operations

src/sanity/schemas/
→ Sanity content model

The main architectural decision was to keep three responsibilities separate:

TASKS.md
→ portable content

AnTaskCanvas
→ editing and visual representation

Sanity
→ persistent structure and visual memory

This allows AnTaskCanvas to store information that only makes sense to the application — such as the position and dimensions of a card inside the Canvas — without polluting TASKS.md with metadata that would be meaningless when opening the file directly in an editor.

My Build Process

AnTaskCanvas did not start with all of this architecture already figured out.

The first idea was much smaller: open a TASKS.md file and stop looking at it as a flat list of text.

A large part of the project started through vibe coding.

At first I mainly worked with Google AI Studio / Gemini and Antigravity to get the early versions up quickly. As the application grew, I also started using agents such as Codex for more focused reviews, debugging, audits, and changes where I wanted to avoid overly aggressive edits.

That shift ended up teaching me a lot about how I wanted to use AI during the project.

01 — Make it visual first

I started with React, TypeScript, and tldraw.

The first version had little more than a top bar, an infinite canvas, and a few fake task cards.

Before thinking about persistence, synchronization, or GitHub, I wanted to answer one question:

Does it actually make sense to look at a TASKS.md this way?

Then I added a second view in Kanban format.

That is where the core of AnTaskCanvas started to appear:

the same set of tasks could be seen as Markdown, as a Canvas, or as a board.

02 — Turning `TASKS.md` into more than plain text

The next step was reading a real file.

I started with the most basic Markdown tasks:

- [ ] Pending task
- [x] Completed task

Then came headings:

## Backend
## Frontend
## Bugs

which became visual groups.

From there I started adding metadata:

ID
Priority
Blocked by

Priorities from P0 to P3 could be represented visually, and Blocked by made it possible to draw dependencies between tasks as connections inside the Canvas.

At that point it stopped being just a Markdown viewer.

The document was starting to behave like a structure.

03 — Editing without breaking the source of truth

This introduced one of the more important problems.

I did not want the Canvas to become another database completely disconnected from the original file.

If I changed a task visually, that change had to be able to return to Markdown.

So I added editing operations such as:

changing a title;
completing a task;
changing priority;
creating tasks;
deleting tasks;
moving tasks between groups.

Those changes needed to make their way back into the document.

The rule was simple:

TASKS.md had to remain portable and understandable outside AnTaskCanvas.

04 — Sanity started much smaller

The first Sanity integration was fairly limited.

The initial idea was to use it only for information that did not really belong inside TASKS.md:

card positions;
dimensions;
visual groups;
Canvas state;
representation-specific configuration.

The content itself would still belong to Markdown.

But once persistence was working, Sanity started to occupy a fairly natural place inside the project.

There was information I did not yet want to turn into repository history, but I also did not want to lose:

working state;
visual context;
positions;
grouping;
structured information around tasks.

The architecture started to split in a way I had not originally planned:

Sanity as living state.

TASKS.md as the portable representation.

Git as versioned history.

Sanity eventually grew into a deeper integration, with structured persistence, visual state, and an embedded Studio inside the application.

05 — Auto organize

Once groups, priorities, and dependencies existed, manually placing every task stopped being fun.

With five cards, it is manageable.

With fifty, not so much.

That is how Auto organize appeared.

The idea was to use a layout engine to automatically distribute Canvas elements and create a reasonable starting arrangement.

After that, the user could still move things manually.

This also revealed something that happened repeatedly throughout the project: a feature can be technically correct and still be annoying in real use.

We later had to adjust behaviors such as automatic centering and Canvas movement to avoid camera jumps and interactions that interrupted the workflow.

06 — Real Markdown is much messier than demo Markdown

Up to this point, the examples worked beautifully.

Then real files arrived.

Duplicate IDs.

Broken dependencies.

Invalid priorities.

Inconsistent indentation.

Unknown metadata.

Checkboxes written in slightly different ways.

And tasks written quickly because the only important thing at that moment was not forgetting them.

That ended up creating a part of the project that was not in the original plan at all: the safe Markdown normalizer.

Instead of silently modifying the document, AnTaskCanvas can analyze the file and generate a normalization proposal.

Before accepting the changes, the user can review a diff and decide what to apply.

The original stays untouched until the operation is confirmed.

It is probably one of the features that best represents how AnTaskCanvas evolved:

it exists because real usage broke assumptions that worked perfectly in the prototype.

07 — Real files

Then came the less exciting but necessary part:

opening .md files;
drag and drop;
importing;
exporting;
saving;
detecting changes;
handling different documents.

The application started to move away from being a demo built around controlled data and toward something capable of working with real documents.

Over time this also evolved into the idea of workspaces and multiple-document handling.

08 — AI-generated design became a problem

This is where the process changed quite a bit.

For a large part of the development I worked with Google AI Studio and Antigravity.

The models were very good at adding things.

That was exactly the problem.

Every request like:

improve the interface

could turn into another card, another button, another gradient, another shadow, another badge, or another section.

In some iterations I ended up with more decoration than actual improvement.

The application started to develop that very recognizable AI-generated interface look:

too many cards;
too much empty space;
gradients;
glassmorphism;
shadows;
huge buttons;
excessive rounding;
repeated information;
landing-page aesthetics applied to a work tool.

The more I asked:

“Make it more modern.”

the worse it got.

The model interpreted “improve” as “add.”

So I started doing the opposite:

remove.

Gradients, glassmorphism, shadows, and unnecessary decoration were stripped away.

Border radii were reduced, information density increased, and functional hierarchy became more important than ornament.

That process also changed my prompts.

I went from asking:

make it more modern

to defining concrete rules around density, typography, spacing, hierarchy, responsive behavior, accessibility, and especially when not to create anything new.

I also started adding documentation and rules for agents.

It was no longer enough to say what I wanted.

I had to explain what I did not want.

09 — Internationalization: when the prompt had to mature too

One of the later major phases was i18n.

I wanted developers to keep writing readable source text while message extraction happened automatically, without manually maintaining keys like:

t("tasks.actions.delete")

The goal was a compiler-first architecture.

By this point the prompt itself looked very different from the prompts I used at the beginning.

Instead of simply saying “add translations,” I started by defining the architecture I wanted and the things the agent should not do.

One of the real prompts was:

Implement a modern, automatic, compiler-first internationalization architecture across the entire project.

Developers should work with readable source text.

I do not want manual semantic keys such as t("tasks.delete") or manually maintained translation dictionaries.

Before modifying code, detect the framework, bundler, TypeScript setup, existing i18n system, and component structure.

Do not replace a valid existing solution unless necessary.

Prioritize a small, typed solution with no external translation APIs at runtime.

The full prompt eventually covered automatic extraction, ID generation, pluralization, accessibility, regional formatting, CI, and even which strings should not be translated.

The implementation ended up using Lingui.

And, as often happens, the plan was simpler than the implementation.

At one point:

lingui extract

returned:

0 messages

even though the application was full of text.

I had to review configuration, macros, and versions.

After fixing the issue, extraction found:

193 messages

and the project compiled correctly again.

That episode captures fairly well how my use of AI changed:

less

“build this for me”

and more

“work inside these constraints and inspect what already exists first.”

10 — Bugs that do not appear in the nice screenshot

There were also plenty of less photogenic moments.

One deployed version ended up as a completely blank white screen.

I had to review dependencies, package management, Vite configuration, and runtime errors.

I eventually added a RootErrorBoundary so that a startup failure would no longer leave the user with nothing but a blank page.

There were also problems inside tldraw.

For example, an early attempt to prevent certain shapes from being created intercepted the process too early and broke the internal store.

The solution was not to add another abstraction.

It was to let tldraw complete its operation correctly and intervene afterward.

These are not the most attractive parts of the project.

But they probably explain the build process better than the polished screenshots do.

11 — What changed in the way I use AI

I started by using AI mostly to generate.

I ended up using it much more to:

inspect;
compare;
look for regressions;
apply small changes;
validate;
work within constraints.

One pattern I ended up reusing was:

Before modifying anything, inspect the project and understand how it currently works.

Do not rebuild the architecture.

Do not add unnecessary dependencies.

Do not modify components unrelated to the problem.

Identify the root cause first.

Then apply the smallest necessary change.

Verify the result with build, TypeScript, lint, and tests if available.

If something cannot be verified, say so explicitly.

inspect → understand → fix → verify

Do not add code “just in case.”

It may sound obvious.

In practice, it produced better results than many huge prompts.

The prompts changed too.

At the beginning they mostly described what I wanted to appear.

By the end they mostly described the boundaries within which the agent was allowed to work.

I think that was one of the most interesting lessons from the project.

With vibe coding, generating code is often not the hardest part.

The hard part is making sure every new generation does not destroy the intention of the previous one.

Sanity Project Details

Project ID: or19faat

Dataset: production

API Version: 2024-03-01

Public Dataset URL:

https://or19faat.api.sanity.io/v2024-03-01/data/query/production?query=%2A%5B0...20%5D%7B_id%2C_type%7D

Sanity is the layer that allows AnTaskCanvas to go beyond simply turning a Markdown file into a visual interface.

The starting point is still TASKS.md: a flat, portable format that is easy to keep next to the project.

But Markdown has a fairly obvious limitation once you try to turn it into something visual.

It can describe a task, its status, or its subtasks, but it does not know that a card was placed at a particular position on the Canvas, inside a certain group, or with specific dimensions.

That is where Sanity comes in.

The model

AnTaskCanvas currently uses three main document types.

`workspace`

Represents the general context of a project.

It stores workspace information and relates the tasks that belong to it.

`task`

Represents the structured version of a task found in TASKS.md.

It can store information such as:

title;
description;
status;
priority;
tags;
subtasks;
group or section;
dependencies.

This means that a line of Markdown stops being only text and becomes structured content that the application can query and represent in different ways.

`canvasVisualState`

This is probably the most important piece for the AnTaskCanvas idea.

The content of a task and the way we choose to organize it visually are two different things.

That is why Canvas state is stored separately.

For each task, it can keep information such as:

taskId
x
y
width
height

and for each group:

groupTitle
x
y
width
height
isCollapsed

This makes it possible to move a card, resize it, or reorganize a group without artificially modifying the content of TASKS.md.

In other words:

Markdown stores what a task is.

Sanity can store how we had organized it visually.

Why separate `task` and `canvasVisualState`

I could have stored everything inside the task document itself.

I did not, because that would have mixed two different concepts.

A task can move many times without its content changing.

Likewise, I can edit the title, priority, or a subtask without wanting to modify its position inside the Canvas.

Keeping them separate allows each part to evolve for a different reason:

task
→ changes when the content changes

canvasVisualState
→ changes when the representation changes

It also keeps view-specific information out of the task model.

Kanban, for example, needs to know the state of a task.

It does not need to know its X/Y coordinates inside the Canvas.

From flat file to Canvas

The current flow can be summarized like this:

TASKS.md
   ↓
parser + normalizer
   ↓
structured task model
   ↓
Canvas / Kanban
   ↓
Sanity

Semantic changes made from Canvas or Kanban can be reflected back into the Markdown content, while Sanity stores the structured representation and the spatial state of the project.

That keeps the separation fairly clear:

TASKS.md
→ portable and interoperable content

AnTaskCanvas
→ editing and visual representation

Sanity
→ structured persistence and visual state

Persistence between sessions

AnTaskCanvas combines Sanity with a small local cache layer.

When restoring the visual state of a project, the application tries to retrieve it from Sanity using its projectId.

It can also keep a local copy of the visual state as a fallback if Sanity is unavailable or the connection takes too long.

That means that when reopening a project, we can recover more than just its tasks.

We can also recover how the workspace had been organized.

That was an important part of the original problem: coming back to a project months later and finding more than a list of pending tasks.

I wanted to recover some of the visual context I had been working with as well.

What is persisted and what is not

Not everything needs to live in Sanity.

Sanity stores:

workspaces;
structured tasks;
relationships between workspace and tasks;
visual state of cards;
group position and dimensions;
expanded or collapsed state of groups.

On the other hand, temporary interface state such as the current selection, zoom level, camera position, active filters, temporary searches, or open modals does not need to become persistent data.

Those are momentary working states, not part of the project itself.

Recovering context, not just data

This distinction became more important than I expected.

When I return to an old project, I do not only want to know that ten tasks are still pending.

It also helps to remember how I had grouped them.

Which tasks were close together.

Which group I had left open.

Which part of the project I had mentally separated from the rest.

That kind of information is difficult to express inside Markdown without polluting the file with purely visual metadata.

Sanity lets AnTaskCanvas preserve that context without turning TASKS.md into a proprietary format.

Sanity Studio inside AnTaskCanvas

The project also integrates Sanity Studio inside the application itself.

This makes it possible to inspect and manage structured documents without completely leaving the AnTaskCanvas interface.

During development, this was particularly useful because I could inspect what the application was actually generating instead of relying only on what I could see on the Canvas.

No realtime yet

One of the things I simplified during the latest refactor was real-time synchronization.

The current version does not maintain a permanent subscription through client.listen().

Persistence happens explicitly when the user modifies or saves state.

That was a deliberate decision for this version.

AnTaskCanvas is currently aimed mainly at individual developers, so there was no need yet to introduce the complexity of multi-user collaboration, conflicts, or simultaneous change resolution.

That can come later if the product actually needs collaborative editing.

The relationship with `TASKS.md`

An important decision was not to use Sanity as a replacement for Markdown.

If AnTaskCanvas disappeared tomorrow, the file should still be useful.

TASKS.md does not need AnTaskCanvas in order to exist.

The user can export it and continue working with it from an editor, a repository, or any other Markdown-compatible tool.

Sanity adds persistence and structure.

But it does not try to trap the project's content inside the application.

A deliberate decision

I also deliberately avoided storing the entire TASKS.md file as one big text block inside Sanity.

That would have been easier.

But it would also have removed much of the benefit of structured content.

AnTaskCanvas separates:

content,

structure,

visual representation.

Markdown remains portable and readable outside the application.

Sanity stores the parts that actually benefit from being structured and persistent.

And the Canvas uses both to turn something fundamentally flat into a visual workspace.

The same content, multiple representations

The same task can appear in different views without being duplicated:

task
   ├── Canvas
   ├── Kanban
   └── TASKS.md

All three representations refer to the same task.

But each one needs different information.

Markdown needs content.

Kanban mainly needs status and grouping.

Canvas also needs position and dimensions.

The Sanity schema keeps those differences separate instead of forcing one structure to solve every use case at once.

In one sentence

If I had to summarize Sanity's role in AnTaskCanvas:

TASKS.md remembers the tasks. Sanity remembers the structured and visual context around them.

That is what allows AnTaskCanvas to be more than a Markdown viewer.

It becomes a workspace you can return to and continue from where you left off.

Agent Session

I do not have a public Agent Session associated with the project.

A large part of AnTaskCanvas was developed using Google AI Studio / Gemini and Antigravity, and later I used other agents for more focused review, debugging, and auditing tasks.

Instead of linking to a session that does not exist, I want to include one of the real prompts that best represents how my way of working with agents changed during the project.

At the beginning, my instructions were much more open-ended.

As AnTaskCanvas grew, I found that I got better results by defining the constraints first, the expected architecture, and especially what the agent should not do.

This was one of the prompts used while implementing the internationalization system:

Implement a modern, automatic, compiler-first internationalization architecture across the entire project.

Developers should work with readable source text.

I do not want manual semantic keys such as:

t("tasks.actions.delete")

or manually maintained translation dictionaries.

Before modifying code:

detect the framework;

detect the bundler;

detect TypeScript;

detect the existing i18n system;

detect the component structure;

detect the build system.

Do not replace a valid existing solution unnecessarily.

The final solution must be:

compiler-first;

typed;

automatically extracted;

without external translation APIs at runtime;

without manually created semantic keys;

with as little architectural noise as possible.

The full prompt was considerably longer.

It eventually covered pluralization, interpolation, regional formats, accessibility, message extraction, CI, automatic ID generation, and which types of strings should not be translated.

The result did not work correctly on the first attempt either.

During implementation:

lingui extract

at one point found:

0 messages

The configuration and macro imports had to be reviewed before the issue was found.

After fixing it:

193 messages

were detected and the project compiled correctly again.

This part of the development summarizes my experience with vibe coding in AnTaskCanvas fairly well:

the prompt stopped being just a description of what I wanted to build and started becoming a set of boundaries within which the agent was allowed to work.

AnMemoryNest: A Place to Preserve the Stories Behind Our Photographs

Nicolas A. R. — Mon, 13 Jul 2026 06:15:15 +0000

This is a submission for Weekend Challenge: Passion Edition.

What I Built

This time, I decided to create an application that, although it is not directly connected to my main professional field, is deeply related to something I truly care about: memories.

A photograph has the ability to freeze time. It can preserve a journey, a friendship, a family celebration, or an ordinary moment that becomes incredibly valuable years later.

However, today we take hundreds or even thousands of photographs that are often forgotten. They get lost among countless files, remain hidden inside a backup, or gather digital dust on an old hard drive.

Many images also stay on our phones and are never shared with the friends or family members who experienced those moments with us.

That is why I decided to create MemoryNest.

MemoryNest is an application designed to bring together, organize, and preserve photographs, memories, and stories among families and groups of friends.

I did not want to create just another photo gallery or another cloud storage service.

I wanted to create a space where photographs could recover their context, their stories, and their connection to the people who appear in them.

A place where memories are not only stored, but also shared, completed, and preserved over time.

What MemoryNest Offers

MemoryNest allows users to create collaborative albums where family members and friends can contribute their own photographs, add stories, and rebuild memories together.

The application can be used to:

Collect photographs from a trip with friends.
Create collaborative family albums.
Preserve stories from parents and grandparents.
Organize weddings, celebrations, and family gatherings.
Build travel journals and document important life stages.
Add context, dates, locations, and people.
Keep memories inside a private space.
Preserve a digital legacy for the future.

For example, after an Interrail trip, each person may have different photographs stored on their phone.

One person may have the landscapes, another the meals, another the train journeys, and someone else those spontaneous moments that nobody else managed to capture.

Normally, all those images remain scattered across several devices, messaging conversations, and cloud services.

With MemoryNest, all those different perspectives can be brought together in one place and transformed into a shared story.

The Role of Artificial Intelligence

Artificial intelligence is part of MemoryNest as a support tool for organizing and recovering memories.

When someone has hundreds or thousands of photographs, reviewing every image, sorting it, and adding information can become an endless task.

AI helps reduce that workload.

It can suggest:

Album titles.
Photograph descriptions.
Tags and categories.
Groups of related images.
Possible dates or locations.
Duplicate or highly similar photographs.
Memories that are still incomplete.
An initial structure for the story of a trip or event.

MemoryNest also includes a memory assistant that can help users explore their albums, find specific memories, and draft stories based on the information already preserved.

For example, a user could ask:

What memories do we have from our trip to Italy?

Or:

Help me write a short story about this family album.

Artificial intelligence is not intended to replace people or invent memories.

It can help recognize that several photographs belong to the same trip, but only the people who lived that moment can explain why it mattered.

That is why AI acts as an assistant inside MemoryNest.

Artificial intelligence helps organize the photographs.
People preserve the meaning of the memory.

Demo

You can try MemoryNest using the following links:

anmemorynest.ai.studio

The demo is prepared so that users can explore the application without creating an account.

It includes sample albums, family stories, trips, and memories to demonstrate how the collaborative experience works.

Code

MemoryNest was developed as a modern full-stack web application.

The main technologies used are:

React
TypeScript
Tailwind CSS
Node.js
Express
Firebase
Google Cloud Firestore
Google AI

The artificial intelligence integration runs on the server to protect credentials and keep sensitive information away from the browser.

GitHub Repository:

anappwilos / AnMemoryNest

An

Run and deploy your AI Studio app

This contains everything you need to run your app locally.

View your app in AI Studio: https://ai.studio/apps/ad2fb8cf-3728-4ab7-8970-91ec637ca344

Run Locally

Prerequisites: Node.js

Install dependencies: npm install
Set the GEMINI_API_KEY in .env.local to your Gemini API key
Run the app: npm run dev

View on GitHub

How I Built It

One of the main goals during development was to make sure that MemoryNest did not feel like a traditional file manager.

I did not want to create a cold or overly technical interface.

The application uses a warm and calm visual style inspired by family albums, journals, and memory books.

Photographs and stories are given more visual importance than technical metadata.

The experience is designed so that anyone can:

Explore memories.
Create albums.
Invite family members or friends.
Add photographs.
Complete stories.
Use AI to organize content.
Collaborate with other people.

Privacy was also treated as a priority.

Photographs, family stories, and personal memories should remain protected and accessible only to authorized people.

MemoryNest is designed as a private and collaborative space, not as a public social network.

Prize Categories

Best Use of Google AI 🏆

MemoryNest uses Google AI to help transform large collections of photographs into memories that are organized, accessible, and easier to share.

Artificial intelligence can assist with image classification, duplicate detection, title generation, and the creation of descriptions or stories.

The memory assistant can also answer questions related to albums and help users recover information stored inside their collection.

The main idea is not to use AI to create artificial memories.

Its purpose is to help people find, organize, and preserve their real memories.

Why MemoryNest Is Different

There are many applications for storing photographs.

However, storing an image does not mean preserving its story.

A photograph can remain inside a folder for years without anyone remembering who appears in it, where it was taken, or what happened that day.

MemoryNest tries to recover that context.

It does not focus only on saving files, but on preserving:

People.
Relationships.
Places.
Stories.
Emotions.
Different perspectives of the same memory.

A gallery stores photographs.

MemoryNest tries to preserve everything that exists behind them.

What’s Next

In the future, I would like to expand MemoryNest with features such as:

Audio memories.
Transcription of family stories.
Interactive travel maps.
Automatic timelines.
People grouping with explicit consent.
Importing collections from old hard drives.
Restoration of damaged photographs.
Digital time capsules.
Family trees connected to memories.
Printable album exports.
Mobile applications.
Advanced digital legacy options.

One of my future goals is for MemoryNest to help recover old collections stored on hard drives, inside disorganized folders, and in forgotten backups.

The idea is to transform all that content into albums that families and friends can rediscover together.

Final Thoughts

MemoryNest was born from a simple idea.

Today, we have an extraordinary ability to capture moments, but we do not always know how to preserve them.

Photographs remain on our phones, disappear inside backups, or are forgotten on old hard drives.

Over time, their context also disappears.

We stop remembering who appears in them, where they were taken, or why that moment was important.

MemoryNest tries to change that.

It aims to provide a space where family members and friends can bring their photographs together, complete their stories, and preserve a shared legacy.

Because saving a photograph is important.

But sharing its story is what truly preserves the memory.

AnGithubManager: an application for my day-to-day life as a developer

Nicolas A. R. — Wed, 04 Mar 2026 14:27:22 +0000

What I Built with Google Gemini

My last few months have been focused on creating various projects as part of my AI learning journey.

I'm a Git and GitHub enthusiast, but I didn't interact much with the interface. Lately, however, I've found myself needing to use it, but working on multiple projects simultaneously made navigating the GitHub interface quite cumbersome. To address this, I started the AnGithubManager project using Google AI Studio.

This is where Gemini solves my main problem: creating a simple pull request without having to think about it automatically, saving a significant amount of time, and above all, providing invaluable support when my head is spinning with problems.

Welcome

Lista

Navegación

Detalle

Demo

https://angithubmanagerbeta.onrender.com/

Images creating PR:

What I Learned

I learned about the real-world, production implementation of Gemeni services.
As a side effect, I also learned to use Google AI Studio.

Google Gemini Feedback

What worked best was that it could be implemented from day one.
The most complicated part at the time was keeping it running in different environments such as Google AI Studio, local, and production, due to technical limitations in Google AI Studio, which didn't support enviorments by default. Therefore, I had to hardcode a backend URL to call if it couldn't find a valid environments.

gemini #googleaistudio #github #anappwilos

🛒Shopping list to make shopping faster - AnQuickMerca

Nicolas A. R. — Mon, 02 Mar 2026 06:53:57 +0000

The Community

I don't know if my community exists, but if it doesn't, it wouldn't be bad to create one; it's simply about going shopping.

What I Built

What I created (or what I tried to create 😅) is a shopping list app, but with a key difference compared to other apps: it optimizes your route within the supermarket. The idea is to shop more quickly and efficiently, avoiding that feeling of wandering around thirty times to pick up three things… or worse, arriving at a new supermarket and getting lost in the aisles looking for a loaf of bread or even a stocker, who's always there… until you need them and they mysteriously disappear 🫥.

The app is based on a very popular supermarket in Spain (Mercadona), mainly because of its physical layout, data availability, and because it's the one I frequent most (hehe). Even so, the approach can easily be applied to any other store.

And this is where the community comes in: it would be responsible for updating locations, notifying users of stock shortages, or other details that a company normally can't (or doesn't want to) share. It's true that I still need to polish this part a bit (hehe), but the idea is clear.

Remember that this is a demo; therefore, some data may not be 100% accurate, and it's not yet available to end users. But if it's successful, and the community supports it, we could develop it further and implement it for real-world use. 🙂

Demo

Idea

Code

nicolasalarconrapela / AnQuickMerca

Un gestor de compras en supermercado fisico

AnQuickMerca

Optimize your shopping in seconds

🌐 https://anquickmerca-frontend.onrender.com

What is AnQuickMerca?

AnQuickMerca is a Progressive Web App (PWA) built to optimize your Mercadona shopping in real time. Create smart shopping lists, get an efficient in-store route, and search products with AI assistance.

Key Features

🛒 Shopping lists — Create, edit, and organize multiple lists
🗺️ In-store navigation — Optimized aisle routes to reduce time and backtracking
🔍 AI-assisted search — Find products using Google Gemini assistance
🌍 Store picker — Interactive Spain map with Mercadona locations
📱 Installable PWA — Works offline and feels like a native app on mobile
🌐 Bilingual UI — Full interface in Spanish and English
🔁 Recurring lists — Schedule daily, weekly, monthly, or yearly shopping
💰 Estimated total — Real-time cost estimate as you build your list

Tech Stack

Technology	Purpose
React 19 + TypeScript	Frontend framework
Vite 6	Build tool & dev server

…

View on GitHub

How I Built It

It is a Vite and Typescript project with persistence in localstorage

devnewyear2026 Portfolio - Nicolás Alarcón Rapela

Nicolas A. R. — Mon, 02 Feb 2026 07:33:43 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

Portfolio

Don't forget to include the dev label!GC

How I Built It

I have used Google AI Studio and AnGravity

What I'm Most Proud Of

Well, what I'm most proud of is being able to put it together with such short notice, since I only found out last week, but honestly, it turned out much better than I could have ever imagined.

Repository: https://github.com/nicolasalarconrapela/AnPortafolioIA

DEV Community: Nicolas A. R.

TaskCanvas: Visualizing task.md with Sanity

AnTaskCanvas

What I Built

Demo

1. Infinite Spatial Canvas (tldraw v5)

2. Interactive Kanban Board

3. Live Split Markdown Editor

4. Monorepo Document Explorer & Context-Aware Filters

Code

Main stack

Main pieces

My Build Process

01 — Make it visual first

02 — Turning TASKS.md into more than plain text

03 — Editing without breaking the source of truth

04 — Sanity started much smaller

05 — Auto organize

06 — Real Markdown is much messier than demo Markdown

07 — Real files

08 — AI-generated design became a problem

09 — Internationalization: when the prompt had to mature too

10 — Bugs that do not appear in the nice screenshot

11 — What changed in the way I use AI

Sanity Project Details

The model

workspace

task

canvasVisualState

Why separate task and canvasVisualState

From flat file to Canvas

Persistence between sessions

What is persisted and what is not

Recovering context, not just data

Sanity Studio inside AnTaskCanvas

No realtime yet

The relationship with TASKS.md

A deliberate decision

The same content, multiple representations

In one sentence

Agent Session

AnMemoryNest: A Place to Preserve the Stories Behind Our Photographs

What I Built

What MemoryNest Offers

The Role of Artificial Intelligence

Demo

Code

anappwilos / AnMemoryNest

An

Run and deploy your AI Studio app

Run Locally

How I Built It

Prize Categories

Best Use of Google AI 🏆

Why MemoryNest Is Different

What’s Next

Final Thoughts

AnGithubManager: an application for my day-to-day life as a developer

What I Built with Google Gemini

Demo

What I Learned

Google Gemini Feedback

gemini #googleaistudio #github #anappwilos

🛒Shopping list to make shopping faster - AnQuickMerca

The Community

What I Built

Demo

Idea

Code

nicolasalarconrapela / AnQuickMerca

Un gestor de compras en supermercado fisico

AnQuickMerca

What is AnQuickMerca?

Key Features

Tech Stack

How I Built It

devnewyear2026 Portfolio - Nicolás Alarcón Rapela

About Me

Portfolio

How I Built It

1. Infinite Spatial Canvas (`tldraw` v5)

02 — Turning `TASKS.md` into more than plain text

`workspace`

`task`

`canvasVisualState`

Why separate `task` and `canvasVisualState`

The relationship with `TASKS.md`