DearPage

DearPage is a digital scrapbook that takes you from idea to memory. You turn loose ideas into events, pictures, and memories. Link with a partner for a place to manage and track your activities.

Comment

Inspiration

Last year was one of the hardest years of my life. I was between jobs, going through a separation after a failed marriage, and beginning to confront how little I felt I had truly experienced during the previous twenty years. I had spent so much time surviving, working, and following routines that I had forgotten how to explore. When I looked backward, there were years I could account for, but too few moments I could genuinely return to.

Then I met Page.

Page turned my life upside down in the best possible way. She taught me how to be adventurous again: to travel, try unfamiliar food, discover new places, say yes to spontaneous ideas, and treat life as something to actively experience rather than merely pass through. Suddenly, I had a growing list of places I wanted to take her, things I wanted us to try, letters I wanted to write, pictures I wanted to preserve, and moments I knew I would eventually want to revisit.

The problem was that our story was already becoming scattered. Ideas disappeared into text messages and browser tabs. Plans lived in calendars. Photographs accumulated in camera rolls. Feelings were expressed in messages that became nearly impossible to find again. Even when all the pieces still existed, nothing preserved the relationship between them: why we wanted to do something, how we planned it, what happened, and what the experience eventually meant to us.

I explored the tools already available and found some things in the space, such as Day One (https://dayoneapp.com/shared-journals/) supports private shared journals. Google Photos Live Albums (https://blog.google/products-and-platforms/products/photos/keep-your-favorite-photos-date-live-albums/) can automatically collect photographs of selected people and pets. But I could not find a tool that I liked designed around the complete progression from discovering something we might enjoy, to planning it, experiencing it together, and preserving it as part of our shared history.

That progression became the heart of DearPage: An idea or inspiration becomes an event. At the event stories are made and pictures are taken. Afterward, it gets written into a memory that allows you to look back fondly on the moments you've had.

I imagined DearPage as a form of digital scrapbooking, but also as an extension of myself. It would help me remember where we had been, what we had done, how those experiences made us feel, and what we still hoped to explore. Instead of only storing the past, it would connect the past to the future.

I wanted the experience to follow what I think of as my “Apple principle”: elegant, intentional, approachable, and natural enough that the technology fades into the background. DearPage should never feel like a database that someone has to maintain or a work ticket they have to complete. It should feel like a quiet place where life can be imagined, planned, experienced, and remembered.

DearPage is ultimately my way of preserving a life that I had only recently learned how to start living—and of imagining a future with the girl who has grown in my heart.

What it does

DearPage is a private shared-life archive and planner for individuals, couples, close friends, and eventually families. It works across desktop and mobile, including as an installable progressive web application. Its defining feature is not any individual screen, but the way every part connects to the next and gradually turns intention into history.

Ideas

Ideas are where the story begins. An Idea might be a restaurant someone mentions, a concert, a weekend destination, a recipe, a museum, or a place that looks beautiful in a photograph. DearPage gives those sparks somewhere to live without requiring an immediate date or complete plan.

Capturing an Idea is intentionally lightweight. A user should be able to preserve the original excitement without filling out a large form. An Idea does not need a schedule because it represents possibility: something we may want to experience in the future.

Event

When we decide to act on it, that Idea can be promoted into an Event. The original record remains intact, preserving why the experience interested us in the first place.

The Calendar is where possibility becomes intention. An Idea can become a distinct Calendar Event with a date, time, location, reminders, notes, recurrence, and other practical information.

The Idea and Event remain connected without becoming the same object. Changing an Event’s date or location does not rewrite the original Idea. If an outing is postponed or cancelled, the Idea can return to the backlog without erasing the history of the planning attempt. If the Event happens, DearPage can carry its context forward into a Memory.

This creates a history that contains more than the final result. It preserves what we hoped to do, how we tried to make it happen, and what eventually came from it.

Letters

Letters preserve the emotional story surrounding those experiences. They are designed as slower, more intentional communication than ordinary chat. A Letter can begin as a private draft, be sent to someone in a shared Link, record when it has been read, receive a heart, and continue through ordered replies.

A Letter might be written before a trip while anticipating it, during a difficult moment, on an anniversary, or after an ordinary afternoon that unexpectedly became meaningful. It can later be connected to the relevant Memory so the archive preserves not only what happened, but also what we thought and felt.

Letters remain meaningful objects in their own right. Connecting one to a Memory does not copy or flatten it into a generic note. The Letter retains its author, recipient, correspondence history, and presentation while becoming part of the larger story.

Dynamic Albums

Albums organize the photographs created along the way, but they work differently from traditional photo folders. Most album tools ask someone to create a static container and manually choose which photographs belong inside it. Once those choices are made, the album presents only that single organization of the library.

DearPage treats every photograph as an independent object and treats an Album as a saved way of looking at the photo library. An Album can dynamically group photographs by Memory, date, person, place, trip, or tag. Traditional filters are still available, but they are only one part of the experience.

A photograph from Savannah might appear in “Savannah,” “Trips with Page,” “Spring 2026,” and a specific Memory without being copied, moved, or trapped inside any one folder. Adding it to a Memory can make that relationship available as another way to organize the library without removing the photograph from anywhere else.

The underlying photographs remain stable while the scrapbook changes shape around them. Instead of asking, “Which album did I put that photograph in?” DearPage asks, “How do I want to remember this part of my life today?”

Memories

Memories are where the rest of DearPage comes together. After an Event happens, it can become the foundation of a Memory page. The original Idea explains why we wanted the experience. The Calendar Event provides when and where it happened. Photographs and Albums show what it looked like. Letters and private notes preserve what we thought and felt.

A Memory is therefore more than a journal entry or photo folder. It is an evolving scrapbook page assembled from connected material. Each Idea, Event, Photo, Letter, and note keeps its own identity and history, but DearPage presents them together as chapters of one experience.

Over time, the same archive can be explored in different ways. Someone can move through it chronologically, geographically, through a particular person, through a trip, or through the experiences that mattered most.

Links

Links define who shares that story. In DearPage, a Link is the private connection between people rather than a public group or generic shared folder.

Every user begins with a personal space, making DearPage useful before anyone else joins. Linking with another person creates a mutual shared space where they can collect Ideas, plan Events, exchange Letters, upload Photos, and build Memories together.

This relationship-first model gives every item a clear home and audience. It also allows someone to maintain different histories with a partner, family member, close friend, or simply themselves without mixing those contexts together.

The people define the Link. The content then grows naturally from the relationship rather than forcing users to create and administer artificial group containers.

Public Page

The Public Page provides a carefully controlled window into that private archive. The authenticated application is the scrapbook’s back room: where Ideas, unfinished plans, notes, Letters, and photographs are created and managed. The Public Page is the showroom.

A user can deliberately publish a finished Memory, dynamic Album, or sent Letter through a revocable, read-only page. Visitors see only the content selected for that page. They cannot enter the underlying Link, browse unrelated photographs, read private notes, or discover the planning material behind the shared experience.

Visitors can leave a heart, allowing a small amount of interaction without turning DearPage into another public social network. Removing a public page removes outside access without deleting or changing the private source material.

The result is one continuous narrative. A passing thought becomes an Idea. The Idea becomes an Event. The Event gathers photographs, Letters, and notes. Those pieces become a Memory. Dynamic Albums provide different paths back through the same history. Links determine who shares it, while the Public Page allows selected moments to be shown to the outside world.

DearPage is not just a collection of planning, journaling, and photo tools. It is the connective tissue between them.

How we built it

DearPage was built nearly completely with codex and GPT 5.6. I typically find that GPT is better at understanding whole systems and complex relationships, which is the majority of what DearPage is. I do, however, use Claude (and in this case Claude 5, as it's been available) to help design better frontend ui/ux, which I think it's superior at, and to "fact check" GPT 5.6.

My workflow is typically to brainstorm, design, and develop in GPT, throw it over to Claude to verify there aren't missing gaps of consideration, which I then throw the response back to GPT who then either confirms Claude's concerns, or will give reasons why it's not actually an issue, which I then confirm. This use of different systems and algorithms, I've personally found, greatly reduces tunnel thought, which AI systems are prone to. It helps them break out of that circuit so that the approach is more holistic.

I am a full-stack developer, but in this case, my role was not to manually implement each feature. My role was to define the product, design the system, establish architectural boundaries, communicate intent, evaluate the results, and guide the AI through repeated rounds of planning, implementation, testing, and refinement.

Instead of asking it to build its own version of the project, I give it my overall vision then we go through each item in the outline together to flesh out the concept and design. We discuss the relations between each system and what the most effective design concepts would be to get the overall effect. In some cases I talk from an architecture perspective of interfaces and what I want exposed, in some cases relationally what I want to be relevant or where I want the connections to be, and in some cases I simply tell it what I want the overall experience from the user's perspective to be.

I typically spend about 90% of my time planning with codex before code is written. We write everything down in a docs/ directory so that I can pull it over between sessions.

I like clear delineation between front and backend, so they were made into separate TypeScript applications. The frontend uses Vue 3, Vite, Vuetify, Pinia, TipTap, and SCSS. The backend uses Node.js, Express, PostgreSQL, Knex, Zod, and a driver-based architecture that separates the product’s domain logic from its database implementation.

Both sides are organized into domain-owned modules. Letters, Calendar, Ideas, Memories, Albums, Links, notifications, search, and public sharing each have defined ownership boundaries. Instead of using shared modules, which can get sticky and cause confusion for both myself and GPT, I always maintain separate interfaces (even for electron apps). This makes it extremely easy to reason about features and makes it ultimately more flexible and portable if I want to replace a portion of the system. I've found that streamlining the project's layout and design and favoring clear over clever improves the output of GPT's code and helps create a system that's easier to maintain.

The backend separates domain contracts, routes, services, validation, and PostgreSQL repositories. Database changes are represented by ordered SQL migrations, creating an explicit history of the data model. The frontend uses shared API contracts and drivers while keeping feature-specific views and components inside their corresponding modules.

These rules gave the AI a stable map. It knew where new behavior belonged, which layers it was allowed to cross, and which patterns it needed to preserve.

My work with Codex followed a design-first rhythm. I would break the application into specific domains and then break each domain into small, concrete tasks. Typically, I build in a test-driven environment where I define the tests, how I expect the interfaces to look and be used by the developer, and then have GPT fill in the code to meet that interface and usage expectations. In this project, however, there was less of a test-first approach because I had it take on a far more substantial role in the design and development. I did not touch any of the code, myself, at all. I do still have GPT design tests that are comprehensive to ensure the usage expectations are matched. When there is a bug, I typically ask GPT to design a test to check that edge case in order to prevent future regressions.

I kept tasks deliberately small. Codex might implement one database transition, one dialog, one API contract, or one responsive behavior at a time. I would review the result, test it, clarify the next objective, and continue from there.

After every few development rounds, I asked Codex to perform a wider sweep of the project. Those sweeps looked for repeated components, oversized views, duplicated logic, inconsistent forms, incorrect module ownership, and styling that had drifted away from the shared Vuetify theme.

Codex would then extract reusable form controls, consolidate repeated behavior, move common logic into shared components, strengthen tests, and bring screens back into visual alignment. These recurring reviews kept individual features from developing their own unrelated architecture or design language.

DearPage began on June 10, roughly a month before OpenAI Build Week. During the Build Week submission period, I used Codex and GPT-5.6 to meaningfully extend that new foundation.

The Build Week work included refining every aspect of the application from an idea to its current form, open local registration, recurring Calendar Events, simpler creation flows, default shared-person context, curated Public Pages, richer Memory journeys, public photo viewing, improved shared-Memory creation, bulk photo editing, persistent Album grouping preferences, responsive mobile refinements, expanded accessibility and end-to-end coverage, and more flexible Event reminder controls.

The application now includes secure session authentication, Google and Facebook identity foundations, private media handling, realtime refresh events, email and push-notification support, an installable PWA, Capacitor foundations for Android and iOS, automated backend tests, Playwright end-to-end tests, accessibility checks, container deployment definitions, and Kubernetes deployment and backup infrastructure.

Challenges we ran into

The most difficult part of AI-assisted development was learning how to create prompts that communicate intent rather than merely listing requirements.

A successful prompt often needed several layers at once. It needed the personal narrative behind the feature, the objective it served in the overall product, the emotion the experience should create, and my principle that DearPage should feel elegant and like an extension of the user.

It also needed precise technical requirements: data relationships, permissions, responsive breakpoints, expected desktop and mobile behavior, API boundaries, error states, and verification steps.

If I supplied only the technical details, the result might function correctly but feel sterile. If I supplied only the story, the result might look appealing but fail to fit the architecture. The challenge was learning to communicate meaning and implementation boundaries together.

Visual feedback presented a similar problem. Saying that a page “looks wrong” gives the AI very little useful information. I had to learn how to identify the exact route, component, dialog, field, visual state, screen size, and neighboring element involved.

I also needed to explain why something felt wrong. Was the hierarchy unclear? Was a button receiving too much attention? Was a form displaying advanced information too early? Was a mobile dialog using a desktop interaction pattern? The more precisely I could describe the problem, the more effectively the AI could correct it without unintentionally changing unrelated parts of the application.

The relationships between DearPage’s concepts were another major challenge. An Idea, Event, Photo, Letter, Album, and Memory might all describe the same experience, but they are not interchangeable records. Each has its own purpose, history, and lifecycle.

Connecting them without duplicating information or exposing the user to the underlying complexity required repeated data-model and interaction-design passes. The database needs stable identities and explicit relationships, but the user should experience a simple path from “We should do this” to “Remember when we did this?”

Forms were particularly difficult. The system may benefit from dates, people, places, tags, categories, relationships, and visibility information, but presenting all of that at once makes creating something feel like work. I repeatedly had to decide what was essential now, what could be inferred, and what should remain hidden until someone asked for more control.

Privacy also had to work across every layer. The rules for a private Letter draft, a sent Letter, a contextual note, a shared Link, an archived space, and a published Memory are all different. Those rules had to remain consistent across the database, APIs, search results, notifications, media access, and user interface.

Finally, it was challenging to keep a rapidly growing AI-generated codebase coherent. AI can create a feature quickly, but without recurring architectural reviews, each feature can introduce its own component patterns, terminology, and visual language.

The consolidation sweeps, shared design documents, database migrations, change logs, automated tests, and project conventions became essential. They gave Codex a durable understanding of the system and helped prevent short-term changes from weakening the larger product.

Accomplishments that we're proud of

I am particularly proud of the dynamic Album system.

It supports ordinary filters, but it is not limited to filtering or static folders. Albums are saved perspectives over the photo library, allowing the same collection to reorganize itself by person, place, date, tag, trip, or Memory.

This makes DearPage feel more like a living scrapbook than a file manager. The photographs stay stable while the paths through them change according to what the user wants to remember. It addresses the familiar problem of having thousands of photographs but no meaningful way to experience them as part of a story.

I am also proud of the balance DearPage strikes between intimacy and openness. It can contain private Letters, unfinished Ideas, personal notes, plans, and photographs while still giving people a deliberate way to share selected moments.

Publishing a Memory does not open the private archive behind it. It creates a separate, curated presentation of that moment. This allows people to indulge the natural desire to share something meaningful without making their entire relationship public.

Most of all, I am proud that the individual systems coordinate as one comprehensive experience.

Ideas lead naturally into Calendar Events. Events become anchors for Memories. Letters and notes provide emotional context. Photographs and Albums provide visual context. Links define the relationships in which those moments exist. Public Pages provide a controlled way to share the result.

Despite being composed of many domains, DearPage feels like one product rather than a collection of unrelated tools. Each segment contributes to the same purpose: helping people live more intentionally and preserve what that life becomes.

I am also proud that DearPage became a real, persisted, responsive application rather than a collection of mock screens. Its workflows have database behavior, permissions, validation, migrations, notifications, responsive layouts, and automated tests behind them.

Finally, I am proud of what the AI-native development process demonstrated. With strong design direction, carefully defined architecture, small implementation steps, and regular refactoring, Codex and GPT-5.6 were able to build and rapidly extend a substantial full-stack application without me manually writing its code.

This workflow is already being repeated for a separate project where I am creating a custom game engine from scratch using SDL3, WebGPU, and C++ to devastating effect. Within 1-2 short weeks I've been able to not only build a fully functioning and demonstrably working game engine, but I also have a fully customized GUI on top of it that's being refined continuously, showing that the pattern works.

What we learned

The first major lesson was that relationships between concepts are often more difficult to design than the concepts themselves.

Creating an Idea form is straightforward. Creating a Calendar form is straightforward. The difficult part is deciding what should happen when an Idea becomes an Event, what information should carry forward, what should remain independent, and how both should later connect to a Memory without duplicating or rewriting their history.

The same difficulty appears everywhere. A photograph may belong to a Memory while remaining independently visible in the photo library. A Letter may add emotional context to a Memory while remaining private correspondence. An Event can anchor a Memory without becoming the Memory itself.

I learned that preserving these relationships requires stable identities, deliberate transitions, and clear ownership. The interface then has to hide most of that complexity from the person using it.

I also learned that every field has a cost. A technically complete form can be emotionally exhausting to use. If preserving an experience begins to feel like entering a work ticket, people will stop doing it.

DearPage therefore has to ask only for what is useful at that moment, provide thoughtful defaults, hide secondary details until they are needed, and reuse information that has already been provided. The amount of data a system can collect is not the same as the amount it should demand from the user.

That lesson extended to visual design. Reducing clutter does not always mean removing features. Often it means establishing better hierarchy, progressive disclosure, consistent dialogs, clearer actions, and reusable form patterns.

A screen can remain powerful as long as it does not present every possibility at once. Some controls should appear only when they become relevant. Some information belongs on the detail page rather than the creation form. Some actions need labels, while others become clearer when represented consistently through familiar visual patterns.

The biggest lessons, however, came from working with AI. AI does not remove the need for structure and design; it increases their importance. A model can build very quickly, which means an unclear decision can also spread very quickly. Instead of simply telling Codex to build something, I had to provide a coherent design vision, establish boundaries, break the work into understandable steps, and explain how each new piece related to what already existed.

My role changed from manually writing code to acting as product designer, system architect, editor, tester, and reviewer. I needed to define the destination, create a route toward it, inspect what was produced, and ensure that each local improvement remained compatible with the larger product.

I learned that it is often better to complete five rounds of design, one round of implementation, and five more rounds of planning than to ask AI to redesign the product directly with every prompt.

Planning creates a stable mental model of the product. Without that stability, each isolated request risks solving a local problem while confusing or damaging the whole. Asking for repeated direct changes can cause the model to continually reinterpret the design. A planned sequence allows it to build toward one consistent objective.

Design documents, project conventions, change logs, migrations, and tests became a form of shared memory between me and the AI. They allowed Codex to understand not only what the project currently contained, but why it had been designed that way.

I also learned that verification must remain part of the creative process. AI-generated code still needs type checking, linting, automated tests, browser testing, responsive inspection, accessibility checks, and human review. The speed of generation makes these safeguards more important, not less.

The final lesson was that AI works best as a collaborator with constraints. The clearer I became about meaning, scope, architecture, and the experience I wanted to create, the more capable Codex became at turning that vision into a working product.

What's next for DearPage

The immediate next step is continuing to refine the user experience across desktop and mobile. DearPage already uses one responsive application across both, but navigation, forms, photo editing, Calendar interactions, Memory creation, native pickers, notification settings, and offline-to-online transitions can continue to feel more natural on each device. The goal is for both versions to provide the same connected experience while respecting how people use each device.

I also want to keep reducing the effort required to preserve a memory. DearPage should become better at carrying information forward, suggesting useful connections, and helping someone complete a Memory without forcing them to manually reconstruct everything that happened.

For example, when an Event becomes a Memory, DearPage could bring forward the date, place, people, original Idea, and relevant photographs. It could help identify Letters or notes that may belong to the same experience while leaving the final decision with the user.

The next major product direction is AI-assisted suggestions.

DearPage could help someone discover gifts based on wishlists, interests, birthdays, anniversaries, and meaningful details that have been deliberately saved. It could suggest restaurants, day trips, travel destinations, activities, or new experiences based on places someone has enjoyed, Ideas waiting in the backlog, upcoming plans, available time, travel distance, season, and the kinds of experiences they want to have more often.

An upcoming trip could surface museums, restaurants, scenic places, or activities near the destination. A birthday could bring forward relevant wishlist items or remind someone of an Idea they saved months earlier. An anniversary could resurface a meaningful Memory and suggest a new experience connected to it.

A quiet weekend could become an opportunity to finally act on an Idea that has been waiting for the right moment. A group of photographs from an Event could become the beginning of a Memory rather than remaining forgotten in the camera roll.

These suggestions should feel like assistance from a system that helps someone pay attention to their life. Users should remain in control of which information DearPage can use, and the application should make it understandable why a particular suggestion appeared.

Beyond individual relationships, I see DearPage becoming a nucleus for family memories.

A couple’s archive could eventually grow into a private family history shared with children, parents, grandparents, and close friends. Different people could contribute photographs, Letters, stories, and perspectives while controlling which parts belong to personal, relationship, or family spaces.

A single family event could contain photographs from several people, stories told from different perspectives, Letters written years apart, and Memories that continue growing across generations. DearPage could become the place where those pieces remain connected instead of becoming scattered across accounts, devices, and services.

That archive could also extend into the physical home.

DearPage could connect to framed calendars that combine upcoming plans with photographs from the past. Digital picture frames could display dynamic Album views rather than requiring someone to maintain another static photo folder. A family might see an upcoming birthday, a planned outing, and a Memory from the same date several years earlier in one living display.

The longer-term infrastructure vision is a DearPage home hub: hardware owned and controlled by the user that runs a local instance of the platform. Photographs, Letters, and Memories could live on hardware inside the home, while a central DearPage service provides registration, secure connectivity, software updates, and optional synchronization. The user would own and control the hardware containing their most personal content.

This edge-storage model could reduce the amount of private media DearPage needs to store centrally while giving people greater confidence that their family history remains local, private, and physically in their possession. A hosted service could provide convenience, while a home hub could provide local ownership and long-term control.

Ultimately, DearPage could become more than a scrapbook, journal, calendar, or photo library. It could become the private center of a person’s or family’s shared history: a place to imagine what they want to experience, plan it together, live it, preserve what it meant, return to it over time, and eventually pass those stories forward.

Build Week eligibility and prior-work disclosure

DearPage existed before the OpenAI Build Week submission period. The event's official submission window began July 13, 2026 at 9:00 a.m. PDT and ends July 21, 2026 at 5:00 p.m. PDT. In accordance with the official rules, this submission does not claim that the entire product was created during that window.

Before Build Week, DearPage already had its personal motivation, relationship-space model, visual direction, authentication/settings foundation, and early versions of its ideas, calendar, memories, albums, links, letters, permissions, and deployment architecture.

During Build Week, Codex with GPT-5.6 meaningfully extended and stabilized the project through 30 dated commits retained in this repository, including:

  • Open self-registration and a redesigned sign-in-first entry experience.
  • Stronger admin behavior, account flows, security checks, release gates, and mobile layouts.
  • Simplified creation flows, linked-person defaults, and recurring events.
  • A curated public-page system with memory chapters, explicit publication state, revocable sharing, and links to memories and calendar context.
  • Refined shared-memory creation, connection management, photo uploads, photo editing, albums, and gallery organization.
  • Deeper calendar, correspondence, memory, map, and navigation journeys.
  • Push-registration hardening, clearer outbox state, optional-OAuth test coverage, and synchronized dependency locks.
  • Repeated lint, build, integration, browser, live-health, and deployment validation.

The primary Codex thread began shortly before the submission period and continued through Build Week using GPT-5.6. At the time this submission repository was prepared, its persisted transcript recorded at least 46 user-message events and 515 completed patch-application events after the official start time. The same period is independently reflected by the 30 Git commits dated July 14–18 and the redacted session inventory in codex_history.

Built With

Share this project:

Updates