CASE STUDY · LPI · 2026
WeCreate DAM
I rebuilt a 42,700-piece liturgical content library around the calendar its customers work to, as one of LPi’s first products built entirely with AI.
Violet, green, red, gold: the colors of the liturgical year.
MY ROLE
Product owner, UX/UI designer, director of the AI build
TIMEFRAME
11 weeks, Aug 4 – Oct 19, 2026
TEAM
Me and AI agents (Claude Code), with engineering help on content sync and sign-in
PLATFORM
AWS serverless, React, Python, Figma
THE PROBLEM
A generic library for a calendar-driven job
WeCreate sells ready-to-use art and writing to parish bulletin editors and community newsletter teams: covers, prayers, readings, social posts, many in English and Spanish. That’s about 42,700 assets and 390 GB. It all lived on a generic third-party digital asset manager that knew nothing about the calendar our customers work to.
Editors work to a weekly deadline, usually a week or more ahead of Sunday. Finding “everything for the Third Sunday of Advent” meant a keyword hunt.
Dates were tagged by hand, again every year, because the date of Easter, and everything that hangs off it, moves.
Prayers and readings came as Word downloads that had to be opened before the text could be pasted into a bulletin.
Catholic parishes and community organizations shared one catalog and one vocabulary, though they plan around different calendars.
We had no control over the interface and almost no usage data, so we couldn’t tell which content customers downloaded, or when.
It was expensive, and about to cost more. The vendor charged about $65,000 a year and planned to raise the price at renewal. That decided it: we would build our own, and the renewal date set the deadline.
MY ROLE
Product owner, designer, and the human in the loop
Set the product vision and wrote the plan leadership approved.
Designed every screen in Figma, plus the design system the code takes its colors and type from.
Made more than a hundred recorded product decisions, from “does a saint’s day that falls on a Sunday keep its date?” to which words the community storefront may use for a holiday.
Ran feedback rounds with internal reviewers and walked every build on the test site before it went to production.
Approved every change to production.
I didn’t write code by hand. Engineering colleagues set up the first nightly copy of the old library and connected sign-in to the LPi Dashboard. AI agents built everything else.
STRATEGY
Own what makes WeCreate valuable. Rent the rest.
Own the domain, rent the commodity
Storage, delivery and sign-in are ordinary infrastructure, so they run on AWS managed services and the existing LPi Dashboard. The calendar logic, search, storefront and reporting are what customers pay for, so we built those ourselves. With no always-on servers, test and production together run within a $300 monthly AWS budget, and costs grow only with use.
One product, two storefronts
Catholic parishes and community organizations (senior centers, government offices, synagogues) use the same product, each with its own home page, vocabulary and calendar.
Copy the library first
Before any screen existed, a nightly import mirrored the whole legacy library into our own storage. We built against real content from day one, and the old platform kept running until we were ready.
Measure before designing
Every feature started by counting what was really in the data. That habit caught several assumptions that were off by a factor of ten before any of them became code.
Tag by occasion, not by date
Content is tied to “Second Sunday of Advent”, never to a date. Each year’s official liturgical calendar turns names into dates, so content shows up on time every year without retagging.
Figma is the source of truth
Layouts come from the WeCreate DAM Figma file and design tokens from the design-system page. The agents read both directly, so design and code don’t drift apart.
BUILT ENTIRELY WITH AI
One product owner, a team of AI agents
WeCreate DAM is one of the first products at LPi built entirely with AI. I worked with Claude Code, Anthropic’s coding agent, as the engineering team. AI agents wrote 1,381 of the repository’s 1,410 code commits (98%). My job was to make sure they built the right thing and built it correctly.
11
weeks from scoping to production
449
pull requests merged
98%
of code commits written by AI
3,100+
automated tests
86
design specs and build plans
How a feature got built. Every feature went round this loop, often several times a day. The top lane was mine.
Design. I framed the problem and designed the screen in Figma. The agents read the frames through the Figma connector, and the code’s design tokens are generated from the Figma design-system page.
Measure and spec. The agent checked the real data first, then wrote a short spec that put every open question to me as numbered options with a recommendation.
Rule. I picked, corrected or rejected each option. The ruling went into the spec with my reason, so it couldn’t be quietly reinterpreted later.
Build and review. The agent wrote a plan, then built it test-first, often splitting the work across several agents at once. No engineer reviewed the merges, so automated review was the gate: an AI code review, a security review for anything touching sign-in or customer data, and the full test suite before every push.
Deploy and walk. Changes went to the test site through a reviewed infrastructure change set and were checked against live data. Then I walked them in the browser, and my feedback started the next round. Nothing reached production without my go-ahead.
What made it trustworthy
A rulebook for agents. A guardrails document of about 470 lines records the traps we’d already hit, and the claims an agent may not make without evidence, such as “deployed” or “tests pass”.
Memory that outlasts a session. The agents keep more than 130 notes on rulings, data quirks and lessons, so Monday’s session knows what we decided on Friday.
A changelog that records corrections. Every change explains why it mattered. When a number turned out to be wrong, the correction was added instead of rewriting the past. It’s now 5,400 lines long and is the project’s institutional memory.
What stayed human
The AI is fast at code and patient with data. It doesn’t know which saint a parish editor expects to see on a Sunday, or which words a synagogue newsletter editor would find out of place.
Every call about what customers see, what it’s called and when it appears was a product decision, and it was mine.
CHANGES FROM THE OLD PLATFORM
From a file cabinet to a calendar
Finding content
Before: Keyword search across one flat catalog
Now: A home page built around the next seven Sundays and upcoming holidays, and search results grouped by section with liturgical filters
Dates
Before: Date tags applied by hand each year
Now: Content tagged to the occasion; the official calendar sets the dates each year
Audiences
Before: One catalog and one vocabulary for everyone
Now: Separate Catholic and community storefronts, each with its own words and calendar
Text content
Before: Word file download
Now: Text shown on the page and copied in one click, with the Word file still available
Languages
Before: Spanish versions found by searching again
Now: An English/Spanish switch on the asset page
Print files
Before: CMYK files previewed with distorted color
Now: Print-ready downloads by default and color-managed previews
Uploading
Before: Files with optional tags
Now: A five-step guided upload, with audience and tags required before anything goes live
Reporting
Before: Effectively none
Now: Every search, view and download recorded by audience
Design
Before: The vendor’s interface
Now: Our own design system, designed in Figma
Running cost
Before: About $65,000 a year in vendor fees, with an increase planned
Now: Pay-per-use AWS within a $300 monthly budget ($3,600 a year) for test and production together, about 94% less
Before and after
BEFORE
Legacy home page with no clear navigation structure and extremely limited customization options
AFTER
The Catholic home page opens on the Sundays editors are working toward.
BEFORE
Legacy search results. No opportunity for display titles, just filenames- the user had to scroll and scan to get to the next section and search for what they wanted.
AFTER
Results grouped by section, with counts and filters in the customer’s vocabulary.
BEFORE
Legacy asset page (placeholder: replace with your screenshot)
AFTER
An asset page with the language switch, print-ready download and Similar Content.
BEFORE
Legacy upload screen (placeholder: replace with your screenshot)
AFTER
The five-step admin upload. Nothing reaches a customer until it’s published.
IMPACT ON THE USER EXPERIENCE
For editors: less hunting, more finished bulletins
It starts with this week. This Week’s Content shows the next seven Sundays, because editors work ahead. Seasonal & Holidays and Optional Memorials are one click away.
Search speaks their language. Results are grouped by section and filtered by liturgical season, publication date or holiday.
Less work per piece. An English/Spanish switch, prayer text copied straight into the bulletin, print-ready downloads, and similar content beside every asset.
A storefront that fits. Community editors browse by month and civic holiday, with no church wording.
Live text. A prayer is read and copied on the page instead of downloaded as a Word file.
The community storefront is the same product, organized by month and civic holiday.
For admins: a library that stays organized
Every admin task is documented step by step, with screenshots of the real screens, in the WeCreate DAM Admin Guide.
Uploads keep the library clean. A guided five-step upload suggests holidays from file names and requires an audience and tags before anything is published.
The calendar runs itself. Once a year, admins upload the bishops’ published liturgical calendar, review what changes, and approve it.
Admins see what customers will see. Upcoming Content lists every pin and holiday the storefront will show and the art behind each. Admins can also create their own pins for campaigns.
Usage data, for the first time. Downloads, users and top assets, broken out by library.
Manage Calendars: one row per liturgical year, approved from the published calendar.
Upcoming Content shows exactly what the storefront pins, with the art behind each.
Analytics Overview. Usage reporting the old platform never gave us. The figures shown are from internal testing.
BUMPS ALONG THE WAY
What went wrong, and what we changed
The data wasn’t what we assumed
Early estimates were often wrong, sometimes by a factor of ten. One way of reading the old library would have taken about 150,000 requests where 265 did the job. A labeling problem thought to affect 3,011 items affected 298.
CHANGE Measurement became the first step of every feature, and every correction was logged.
Print color on screen
Print files are CMYK, and browsers showed them in neon colors.
CHANGE Color-managed previews, and 36,755 images re-rendered in 86 minutes.
AI-written titles needed supervision
Hundreds of assets had no usable title. The model drafted titles but kept using phrases we had banned, and our checks rejected 31% of its first drafts.
CHANGE Retries, and a preview I approved before anything was applied. 590 of 599 untitled assets now have a clear title.
No engineer reviewing merges
With agents merging their own work, a mistake could ship without anyone reading it.
CHANGE AI code review, security review and the full test suite became required gates. They caught real problems, including a database change in one plan that would have broken the next deploy.
Thousands of old Word files
5,247 legacy .doc files couldn’t be shown as text on the page.
CHANGE A small conversion service made them readable, so their prayers and readings appear as live text.
Many agents, one codebase
With several AI sessions running in parallel, they collided. One switched another’s branch, a pull request merged while fixes were still on their way to it, and two branches claimed the same decision number.
CHANGE Each session works in its own isolated copy of the code and checks a pull request’s state before pushing.
TIMEFRAME
Eleven weeks, scoping to production
It took 11 weeks from the first scoping document on August 4 to the last import from the old platform on October 19, 2026. Production stood up about six weeks after the platform plan, and the work ran across 48 working days.
Milestone dates as recorded in the project changelog.
CONCLUSION
AI wrote the code. The product decisions stayed with me.
WeCreate DAM is built and running in production. On October 19 the nightly copy from the old platform was switched off, so new content now goes into WeCreate DAM. It runs on a budget of $3,600 a year, against about $65,000 a year for the old platform before its planned price increase.
One product owner working with AI delivered work that would normally need a dedicated engineering team.
The speed comes from the process. Specs, recorded rulings, tests, review gates and a changelog are what make AI output safe enough to ship.
Measure first. The most expensive mistakes were assumptions, and the cheapest fix was counting before building.
Judgment stays human. What customers see, what it’s called and when it appears are product decisions, and they decide whether the product feels right.
It’s repeatable. The guardrails, the build loop and the onboarding guide give the next LPi team a starting playbook for building with AI.
WeCreate DAM · Megan Russell · Product owner & designer