SAINT VINCENT DE PAUL
THANK YOU LETTER BUILDER
“Can you help me format a letterhead?” That is how this project began. A family member who serves as the Corresponding Secretary for a local Society of Saint Vincent de Paul conference needed help preparing monthly donor letters. What sounded like a familiar graphic-design favor exposed a much larger service problem: donor information was being retyped by hand, letters were produced one at a time, and no system preserved the history behind those relationships. I started with the letter itself, built a simple offline generator, and then expanded it into a secure application with persistent data, guided review, and human-controlled AI. In that sense, the project became a map of my own career—from graphic design and art direction to product design, engineering, and agent-system design.
[YEAR]
2025-2026
[CLIENT]
Owned Product
[TOOLS]
Figma, Claude Design
Codex, Pencil, Paper,
Claude Code
1.0
SAINT VINCENT DE PAUL
THANK YOU LETTER BUILDER
“Can you help me format a letterhead?” That is how this project began. A family member who serves as the Corresponding Secretary for a local Society of Saint Vincent de Paul conference needed help preparing monthly donor letters. What sounded like a familiar graphic-design favor exposed a much larger service problem: donor information was being retyped by hand, letters were produced one at a time, and no system preserved the history behind those relationships. I started with the letter itself, built a simple offline generator, and then expanded it into a secure application with persistent data, guided review, and human-controlled AI. In that sense, the project became a map of my own career—from graphic design and art direction to product design, engineering, and agent-system design.
[YEAR]
2025-2026
[CLIENT]
Own Product
[TOOLS]
Figma, Claude Design
Codex, Pencil &
Claude Code
BUILDING AI THAT TAKES THE REPETITIVE WORK OUT OF CHARITY—WHILE KEEPING GRATITUDE, JUDGMENT, AND HUMAN CONNECTION IN HUMAN HANDS.
[THE CHALLENGE]
The challenge was not simply to automate a document. It was to reduce a repetitive monthly burden without automating the care out of gratitude. The primary user is an older, non-technical volunteer handling sensitive donor information on behalf of a charitable organization. Every design decision therefore had to balance speed with readability, data integrity, privacy, and clear human control.
[NAVIGATE CHAPTERS]
[THE CHALLENGE]
Each month, the conference receives a spreadsheet of parishioner donations. The Corresponding Secretary was opening an existing Word or PDF template, retyping each donor's name, mailing address, and gift amount, then printing every letter individually. The work was repetitive, but it was not meaningless. These letters acknowledge the people whose generosity helps fund a food pantry and utility assistance for neighbors in need. That distinction shaped the entire project. The goal was never to remove the person from the process. It was to remove the clerical friction surrounding the part that still needed a person: checking the donor information, reading the message, and signing off on a sincere expression of thanks. Because the primary user is not especially comfortable with technology, the interface also had to make every step obvious. Large type, plain language, visible status, forgiving edits, and clear confirmation became product requirements—not polish added at the end.
[BASIC LETTER DESIGN]
The first request really was about the letterhead. I began with the existing Saint Vincent de Paul identity, preserving the seal, parish information, and restrained formality of the original correspondence. The objective was not to “rebrand” a charitable conference. It was to give an established ritual the care and visual dignity it deserved, while producing a template that would remain reliable when printed on an ordinary office printer. That work surfaced the operational problem hiding beneath the graphic-design brief. A polished template still required someone to copy information into it dozens of times. So I treated the letter as both an artifact and a system output. The layout became a precise 8.5-by-11-inch canvas with fixed zones for the address, message, gift amount, and signature. Designing those rules first let the next version generate letters programmatically without losing the familiarity of the document volunteers and donors already knew. The letter itself isn't overly designed - this is what the task called for, and simple formatting made it much easier to replicate the letter at scale explained throughout the remainder of this case study.
LETTER BUILDER APPLICATION
[APPLICATION PRELUDE]
I built the first Letter Builder as a single, self-contained HTML file. There was nothing to install, no account to create, and no server to maintain. The volunteer could open it in a browser, upload the month's CSV, review the parsed donor records, and generate both individual letters and one combined PDF for batch printing. The tool also packaged the files into a month-and-year ZIP for record keeping. That deliberately small implementation was the right first product decision. It matched the user's technical comfort, worked offline, and tested the most important assumption before I invested in infrastructure: could a spreadsheet become a trustworthy batch of print-ready letters? The prototype handled the full CSV-to-PDF flow and was well received. Just as importantly, its limitations became an honest roadmap. It could not remember donors between sessions, detect duplicates, preserve donation history, manage access, or support nuanced review. The proof of concept had proven the value—and clarified what a durable product would need next.
[APP AUTH]
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec suscipit odio ipsum, non egestas neque tincidunt molestie. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos.
[BRAND MESSAGING]
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec suscipit odio ipsum, non egestas neque tincidunt molestie. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos.
DESIGN SYSTEM
[FOUNDATIONS]
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec suscipit odio ipsum, non egestas neque tincidunt molestie. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos.
[DESIGN SYSTEM]
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec suscipit odio ipsum, non egestas neque tincidunt molestie. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos.
[IMPLEMENTATION]
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec suscipit odio ipsum, non egestas neque tincidunt molestie. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos.
[DESIGN SYSTEM COMPONENTS]
LETTER REVIEW PROCESS
[MANAGING DONORS, DONATIONS AND LETTERS]
I designed the product around the real monthly rhythm of the work. A volunteer imports a spreadsheet or adds a donation manually. The application parses and normalizes each row, compares it with the donor registry, and asks for help only where the data is ambiguous. Once the month is clean, the system prepares draft letters and moves the volunteer into a focused review queue. The important design work lives in the states between those actions. A letter can be a draft, need re-approval after an edit, be approved for printing, or be confirmed as printed. Downloading a PDF does not pretend the physical letter was mailed. Editing an approved letter visibly returns it to review. Missing addresses, unresolved matches, and other blockers appear before they can create a bad batch. This makes the workflow faster without making it opaque. At any point, the volunteer can understand what happened, what still needs attention, and what will happen next. Automation advances the routine parts; the human remains responsible for the consequential ones.
[MONTHLY LETTERS]
Letters are organized by month and by status, making the queue readable at a glance. A volunteer can move between drafts, revised letters, approved letters, and printed records without losing the context of the current batch.
[ADD DONATION]
Not every gift arrives through a clean spreadsheet. Manual entry uses the same validation and donor-matching rules as an import, so one-off donations can join the monthly workflow without creating a parallel system.
PLATFORM ARCHITECTURE
[BUILDING FOR EASE OF USE]
The second version transformed a disposable monthly tool into a persistent operating system for donor gratitude. I built it with Next.js, TypeScript, Supabase, and server-generated PDFs, but the architecture followed a product principle rather than a technology preference: complexity should live beneath the interface, not inside the volunteer's workflow. The system keeps a master donor registry, donation history, monthly batches, imported rows, letter versions, and an audit trail. Incoming spreadsheet data is normalized and matched against existing records using deterministic rules. Potential duplicates are surfaced for review rather than merged automatically. Every sensitive record is scoped to the organization, and validation happens again at the server boundary even when the interface has already checked the input. On the surface, that infrastructure becomes a small set of understandable places: Dashboard, Donors, Monthly Donations, Letters, and Settings. The dashboard answers “Where does this month stand?” The deeper system handles identity, history, permissions, and recovery so the volunteer can focus on the next clear action.
[MONTHLY DONATIONS]
The monthly view turns a spreadsheet drop into a reviewable record. Volunteers can see the total received, donor count, unresolved rows, and readiness for letters without translating backend states or hunting across files.
[DONOR REGISTRY]
The donor registry preserves the relationship beyond a single gift. Contact information, giving history, and related letters stay connected, while possible duplicates remain visible decisions instead of becoming silent data problems.
EDITING LETTERS WITH AN AGENT
[APPROVING AND EDITING LETTERS]
The original prototype used one reliable paragraph for every donor. The larger application introduced a more ambitious question: could AI help each letter feel attentive to the relationship without inventing facts or taking authorship away from the volunteer? The drafting system is designed so code supplies the facts and the model supplies the phrasing. Donation amounts, dates, giving frequency, relationship milestones, and seasonal context are calculated deterministically. AI can then shape a warmer or more varied expression of gratitude around that verified information. If the model is unavailable, the system falls back to a dependable template rather than blocking the month's work. Every result enters the application as a draft. Volunteers can read it, edit it directly, request another version, keep the original, or approve it. Applying a revision to an approved letter clears that approval and sends the letter back through review. The agent can help with language; the human still decides what the organization signs and sends.
[LETTER REVISIONS]
Manual editing remains a first-class path. The volunteer can change the letter directly, save the revision, and see that it now needs another approval—preserving flexibility without hiding the consequence of an edit.
[AGENT REWRITE]
Rewrite controls translate common intentions into simple choices: make it warmer, shorter, or more formal. The suggestion appears as a proposed version, and it replaces the current text only after the volunteer explicitly accepts it.
[DOWNLOAD LETTERS]
Approved letters can be produced individually or as a combined monthly PDF. The application keeps generation, download, approval, and printed confirmation separate so its record reflects what actually happened—not what the software assumes happened.
IN-APP AGENT CHAT INTERFACE
[AN AGENT THAT CAN TAKE ACTION ACROSS THE APP]
The in-app assistant—Vincent—grew from the same principle as the letter workflow: AI should reduce friction without becoming an invisible operator. Instead of adding a general chatbot, I designed a domain-specific helper that can explain a likely donor match, summarize the current month, interpret a natural-language request, and prepare a donor, donation, or revision for review. Its core interaction model is propose → confirm → act. A request such as “Add a $50 donation for this month” becomes a structured confirmation card with editable fields. The assistant cannot quietly decide which donor the user meant, calculate money in prose, bypass permissions, approve a letter, or print a batch. Identity, dates, amounts, validation, and access remain deterministic application responsibilities. That boundary is also the focus of the current production-hardening work. The goal is not to make the agent appear autonomous. It is to prove, action by action, that natural language reaches the same safe and auditable paths as the forms a volunteer could use manually.
[AGENT CHAT]
The drawer keeps help available without forcing the volunteer into a separate AI product. Conversation stays attached to the work, uses plain language, and remains intentionally limited to the application's charitable and administrative domain.
[DYNAMIC RESPONSES]
Responses are grounded in the current screen and live batch state. Vincent can explain what is blocking the month or what needs attention next, while database queries—not model guesses—supply the underlying facts.
[REAL ACTION]
Chat can prepare real work, but preparation is not permission. The governing rule is that confirmed agent actions must use the same validated, organization-scoped server paths as manual forms; production hardening is verifying that promise end to end.
5. OUTRO
What began as a letterhead became an offline utility, then a secure product, and finally a test bed for human-controlled agent design. That progression feels almost comically disproportionate to the original request, but it is also why the project matters to me. It brought the different chapters of my career into one continuous piece of work: graphic design shaped the artifact, art direction gave the experience dignity, product design simplified the monthly ritual, engineering made the system durable, and agent design explored where AI could help without taking control. The current application is in production hardening and usability validation rather than public launch. Its July 2026 engineering baseline passed lint, TypeScript, a production build, 1,843 automated tests, and 681 focused agent tests. I am deliberately not calling that user impact. It is evidence that the system is being treated with the rigor donor data and charitable work deserve. The next proof must come from the volunteers who will use it.
A LETTERHEAD BECAME A PRODUCT, A PRODUCT BECAME AN AGENT, AND THE MISSION KEPT THE HUMAN IN THE LOOP.
The irony is that this began with the kind of request family members make when “designer” is the visible part of a profession they do not fully understand. Yet it became a remarkably complete brief for everything my work has grown to include. More importantly, it gave that growth a useful direction. The point was never to add AI because the technology was available. It was to apply increasingly sophisticated tools to a modest, human problem—and to help volunteers spend less energy operating software while they sustain the relationships that make charitable work possible. For me, that is what AI for good looks like: not replacing the people doing the work, but building better instruments for them.
NEXT PROJECT
BUMBA MODULAR FRAMEWORK
A RESEARCH PROJECT
BUILDING AI THAT TAKES THE REPETITIVE WORK OUT OF CHARITY WHILE KEEPING GRATITUDE, JUDGMENT, AND HUMAN CONNECTION IN HUMAN HANDS.
[THE CHALLENGE]
The challenge was not simply to automate a document. It was to reduce a repetitive monthly burden without automating the care out of gratitude. The primary user is an older, non-technical volunteer handling sensitive donor information on behalf of a charitable organization. Every design decision therefore had to balance speed with readability, data integrity, privacy, and clear human control.
[NAVIGATE CHAPTERS]
[THE CHALLENGE]
Each month, the conference receives a spreadsheet of parishioner donations. The Corresponding Secretary was opening an existing Word or PDF template, retyping each donor's name, mailing address, and gift amount, then printing every letter individually. The work was repetitive, but it was not meaningless. These letters acknowledge the people whose generosity helps fund a food pantry and utility assistance for neighbors in need. That distinction shaped the entire project. The goal was never to remove the person from the process. It was to remove the clerical friction surrounding the part that still needed a person: checking the donor information, reading the message, and signing off on a sincere expression of thanks. Because the primary user is not especially comfortable with technology, the interface also had to make every step obvious. Large type, plain language, visible status, forgiving edits, and clear confirmation became product requirements—not polish added at the end.
[BASIC LETTER DESIGN]
The first request really was about the letterhead. I began with the existing Saint Vincent de Paul identity, preserving the seal, parish information, and restrained formality of the original correspondence. The objective was not to “rebrand” a charitable conference. It was to give an established ritual the care and visual dignity it deserved, while producing a template that would remain reliable when printed on an ordinary office printer. That work surfaced the operational problem hiding beneath the graphic-design brief. A polished template still required someone to copy information into it dozens of times. So I treated the letter as both an artifact and a system output. The layout became a precise 8.5-by-11-inch canvas with fixed zones for the address, message, gift amount, and signature. Designing those rules first let the next version generate letters programmatically without losing the familiarity of the document volunteers and donors already knew. The letter itself isn't overly designed - this is what the task called for, and simple formatting made it much easier to replicate the letter at scale explained throughout the remainder of this case study.
LETTER BUILDER APPLICATION
[APPLICATION PRELUDE]
I built the first Letter Builder as a single, self-contained HTML file. There was nothing to install, no account to create, and no server to maintain. The volunteer could open it in a browser, upload the month's CSV, review the parsed donor records, and generate both individual letters and one combined PDF for batch printing. The tool also packaged the files into a month-and-year ZIP for record keeping. That deliberately small implementation was the right first product decision. It matched the user's technical comfort, worked offline, and tested the most important assumption before I invested in infrastructure: could a spreadsheet become a trustworthy batch of print-ready letters? The prototype handled the full CSV-to-PDF flow and was well received. Just as importantly, its limitations became an honest roadmap. It could not remember donors between sessions, detect duplicates, preserve donation history, manage access, or support nuanced review. The proof of concept had proven the value—and clarified what a durable product would need next.
DESIGN SYSTEM
[DESIGN SYSTEM COMPONENTS]
LETTER REVIEW PROCESS
[MANAGING DONORS, DONATIONS AND LETTERS]
I designed the product around the real monthly rhythm of the work. A volunteer imports a spreadsheet or adds a donation manually. The application parses and normalizes each row, compares it with the donor registry, and asks for help only where the data is ambiguous. Once the month is clean, the system prepares draft letters and moves the volunteer into a focused review queue. The important design work lives in the states between those actions. A letter can be a draft, need re-approval after an edit, be approved for printing, or be confirmed as printed. Downloading a PDF does not pretend the physical letter was mailed. Editing an approved letter visibly returns it to review. Missing addresses, unresolved matches, and other blockers appear before they can create a bad batch. This makes the workflow faster without making it opaque. At any point, the volunteer can understand what happened, what still needs attention, and what will happen next. Automation advances the routine parts; the human remains responsible for the consequential ones.
PLATFORM ARCHITECTURE
[BUILDING FOR EASE OF USE]
The second version transformed a disposable monthly tool into a persistent operating system for donor gratitude. I built it with Next.js, TypeScript, Supabase, and server-generated PDFs, but the architecture followed a product principle rather than a technology preference: complexity should live beneath the interface, not inside the volunteer's workflow. The system keeps a master donor registry, donation history, monthly batches, imported rows, letter versions, and an audit trail. Incoming spreadsheet data is normalized and matched against existing records using deterministic rules. Potential duplicates are surfaced for review rather than merged automatically. Every sensitive record is scoped to the organization, and validation happens again at the server boundary even when the interface has already checked the input. On the surface, that infrastructure becomes a small set of understandable places: Dashboard, Donors, Monthly Donations, Letters, and Settings. The dashboard answers “Where does this month stand?” The deeper system handles identity, history, permissions, and recovery so the volunteer can focus on the next clear action.
EDITING LETTERS WITH AN AGENT
[APPROVING AND EDITING LETTERS]
The original prototype used one reliable paragraph for every donor. The larger application introduced a more ambitious question: could AI help each letter feel attentive to the relationship without inventing facts or taking authorship away from the volunteer? The drafting system is designed so code supplies the facts and the model supplies the phrasing. Donation amounts, dates, giving frequency, relationship milestones, and seasonal context are calculated deterministically. AI can then shape a warmer or more varied expression of gratitude around that verified information. If the model is unavailable, the system falls back to a dependable template rather than blocking the month's work. Every result enters the application as a draft. Volunteers can read it, edit it directly, request another version, keep the original, or approve it. Applying a revision to an approved letter clears that approval and sends the letter back through review. The agent can help with language; the human still decides what the organization signs and sends.
IN-APP AGENT CHAT INTERFACE
[AN AGENT THAT CAN TAKE ACTION ACROSS THE APP]
The in-app assistant—Vincent—grew from the same principle as the letter workflow: AI should reduce friction without becoming an invisible operator. Instead of adding a general chatbot, I designed a domain-specific helper that can explain a likely donor match, summarize the current month, interpret a natural-language request, and prepare a donor, donation, or revision for review. Its core interaction model is propose → confirm → act. A request such as “Add a $50 donation for this month” becomes a structured confirmation card with editable fields. The assistant cannot quietly decide which donor the user meant, calculate money in prose, bypass permissions, approve a letter, or print a batch. Identity, dates, amounts, validation, and access remain deterministic application responsibilities. That boundary is also the focus of the current production-hardening work. The goal is not to make the agent appear autonomous. It is to prove, action by action, that natural language reaches the same safe and auditable paths as the forms a volunteer could use manually.
5. OUTRO
What began as a letterhead became an offline utility, then a secure product, and finally a test bed for human-controlled agent design. That progression feels almost comically disproportionate to the original request, but it is also why the project matters to me. It brought the different chapters of my career into one continuous piece of work: graphic design shaped the artifact, art direction gave the experience dignity, product design simplified the monthly ritual, engineering made the system durable, and agent design explored where AI could help without taking control. The current application is in production hardening and usability validation rather than public launch. Its July 2026 engineering baseline passed lint, TypeScript, a production build, 1,843 automated tests, and 681 focused agent tests. I am deliberately not calling that user impact. It is evidence that the system is being treated with the rigor donor data and charitable work deserve. The next proof must come from the volunteers who will use it.
A LETTERHEAD BECAME A PRODUCT, A PRODUCT BECAME AN AGENT, AND THE MISSION KEPT IT HUMAN.
The irony is that this began with the kind of request family members make when “designer” is the visible part of a profession they do not fully understand. Yet it became a remarkably complete brief for everything my work has grown to include. More importantly, it gave that growth a useful direction. The point was never to add AI because the technology was available. It was to apply increasingly sophisticated tools to a modest, human problem—and to help volunteers spend less energy operating software while they sustain the relationships that make charitable work possible. For me, that is what AI for good looks like: not replacing the people doing the work, but building better instruments for them.
CONTD'
