OurObit.org memorial service launches

Background

Over the years I've supported several friends and family members to craft and host obituaries. I've sampled a variety of services and never found they provided the right tone, usability, or value. So, I decided to create my own — see an overview of the completed OurObit project.

I had other motivations too: I wanted to gain experience with a new toolset and platform for building a SaaS; and I wanted to explore the use of AI coding tools.

Implementation Highlights

Choosing Nuxt. For a development framework I considered Nuxt 4, Next.js, and Django. Django was tempting — I have the most experience with Python and its ORM is mature — but it felt overbuilt for a service that is fundamentally a content-and-auth problem, and server-side rendering a Vue or React front-end on top of it would have added complexity I didn't need. Next.js was the obvious React answer, but I've been building with Vue long enough that the mental overhead of React's paradigms felt like a tax on velocity. Nuxt won on familiarity, on the quality of its ecosystem (Nuxt UI, Nitro), and critically because Nitro's Cloudflare Workers preset meant I could target edge deployment from day one without a separate API layer.

Workers, cheap storage, and edge. The full stack runs as a Cloudflare Workers ESM bundle (~2.8 MB gzip), cold-starting in under 100 ms globally. Storage is Cloudflare D1 (SQLite via Drizzle ORM), R2 for photo storage, and KV for rate limiting and session state.

Payments via Polar.sh. A developer-friendly subscription platform chosen for its clean API, transparent pricing, and no lock-in. Supports monthly, yearly, and lifetime plans, with automatic BC GST + PST calculation.

Print keepsake — a four-attempt engineering story. Generating a 300 DPI file using Cloudflare Workers turned out to be surprisingly constrained:

• Attempt 1: @resvg/resvg-wasm fetching the WASM file at runtime — blocked by V8 isolate policy (dynamic WebAssembly.instantiate() is forbidden on CF Workers free tier).
• Attempt 2: wasm_modules wrangler binding — rejected at deploy time because the project uses ESM workers, and wasm_modules is a CJS-only feature.
• Attempt 3: Static import via a custom Rollup plugin — the WASM bundled correctly, but total gzip hit 3.9 MB, exceeding the 3 MB free-tier limit.
• Attempt 4 (success): Generate the TIFF entirely client-side using utif (a pure-JS TIFF encoder, ~55 KB), drawing the memorial's SVG onto a 2550 × 3300 px canvas via the browser's native Canvas API. Zero impact on Worker bundle size.

Security. Cloudflare Turnstile CAPTCHA on all public-facing forms; KV-backed IP rate limiting (10 attempts per 10 min on registration, 5/5 min on login); Drizzle ORM parameterized queries throughout to prevent SQL injection; HTTPS-only, no session tokens in localStorage.

Memorial connections. Families can propose consent-based links between related memorials — a obit_links_proposed table with a propose/approve/reject flow ensures both parties agree before any public connection appears.

IndexNow. On publish or republish of a search-opted-in memorial, a ping is sent to api.indexnow.org for immediate crawl scheduling.

AI Support

In this project I used Microsoft Visual Studio Code as my IDE, and leveraged several AI models — or as I call them 'agents' — via Copilot Chat. At the start I varied my choice as I tried to get a feel for what results I would get from, for example, Claude Haiku, versus Sonnet and Opus, or from the various 'medium'-level or 1X cost GPT and Gemini with Claude offerings. I generally found that most of the 'medium' level models gave me good planning and coding suggestions. In the middle of the project though, when I was adding and changing things that had implications for other parts of the code, I used Claude Opus 4.7 (3X cost) routinely. I switched to this more powerful model when I noticed a few times that the agent was getting into what appeared to be loops, where it returned to an initial idea or pathway towards a solution. I probably could have continued alternating between 0.33X, 1X and 3X level models, but I was finding that my AI development budget was lower than I expected, so why not just use the most expensive?

What went well?

• Plan Mode — Requesting feedback on ideas is a great use of agents. As always, the better you scope and describe what you think you want, the better the resulting plan ideas. I was often bemused at the agent's insightful reference to concepts outside of the coding realm, like SEO, usability and even comments on client demographics.
• Creating tests — In the past I've had trouble leaning into test-driven development, but AI agents build tests quickly and changing the test to adapt to changes in design is not so daunting. In the latter half of the project, I found I was building tests before writing code about half the time, including Playwright tests of the GUI.

Where did AI models fall short?

• Disconnect between sessions — AI agents have memory within a session and they keep hidden files with notes between sessions. But... Early in the project I noted how disconnected the agents were when starting a new session. To try to resolve this, I asked the agent to help me build admin.md, service_plan.md, and build_log.md files and added them to my repo. In short, admin.md had all the technical specs, service_plan.md had the list of features for MVP and Post-MVP, and the build-log.md had a rolling list of what got done, what worked well, and when lessons were learned. I then set up two routines: 'UPMEM' to get the agent to update these three files at the end of each session, and 'DOWNMEM' for reading the three files to start a session.
• Over-enthusiasm — I had multiple (dozens?) of experiences where the agent was ready to move on or declare a feature complete... before testing in test and production was complete. I think this is a little odd for a coding assistant tool; I always found something to change or fix during testing.

What would I do differently?

• Hey coach? — I loved having the agents as coaches, explaining to me how development in Nuxt used this or that pattern. Agents are great because they are endlessly patient with explanations and diversions. As a result, I will probably use another coding framework for my next project — just to keep learning.
• So many options — I may try using Claude Code Desktop instead of Visual Studio Code. Just to see how different it is. Part of that will be due to privacy considerations. With Code, Copilot sees the prompts and interfaces with the agent. With Claude, there would be one less party. I have disabled the settings in Copilot that would allow it to use my code and prompts for training. But, I'm not confident that it won't be. I also look forward to hearing how home-hosted agents improve.