top of page
Search

Case Study: Recipe Database

Writer: Dave Snyderman
Dave Snyderman
Dec 22, 2025
2 min read

Updated: Jan 1

For my first experiment using an AI agent to code a complete application, I wanted to build something practical—a web-based database app where users could log in, enter information, store it, search through it, view and edit records, and import/export data in various formats.


I've used multiple, commercially available databases over the years. They all have strengths and weaknesses. In software engineering, there's a general principle: the best application to write is one that scratches an itch you have. So building a cookbook application was an obvious choice. It allows me to pull together all of the recipes that I've accumulated and have one place where they're searchable and reviewable.


I didn't start with a CLAUDE.md file (the configuration file that tells Claude how to approach development). Instead, I wrote up a general overview document, and Claude took that and created its own CLAUDE.md file, which you can see in the GitHub repository.


My specification document was fairly detailed, but it was a monolith. I wanted a Java application using the Spring framework for the backend, connected to a PostgreSQL database, with a React frontend. That's a pretty standard enterprise stack, and I figured Claude would have seen plenty of similar architectures in its training data.


Here's where I learned my first major lesson: don't ask Claude to build everything at once. I gave it the whole spec and let it run, which led to more errors and integration issues than I would have encountered if I'd broken the work into smaller, atomic units. I also made the mistake of not having Claude write or run any tests until all the development was complete—a recipe for compounding problems.


Some parts of the development went surprisingly smoothly. Authentication via Google OAuth came together quickly, and Claude built out Docker containers without any hand-holding. In fact, it architected the entire application as a dockerized product from the start, which made deployment straightforward.


Here's something that surprised me: I haven't touched the code myself. Not a single line. Once I realized that Claude could work more efficiently without my interference—and that my edits often introduced inconsistencies—I stepped back entirely. The most efficient workflow was to let Claude own the development and focus my energy on specification and testing.


That said, I haven't fully tested the application yet. It works for basic use cases, but there are no guarantees beyond that. My punch list includes:


- Building out nutrition tracking support (the hooks are there, but it's not complete)

- Running a thorough test cycle beyond my initial smoke testing

- Load testing and scalability analysis

- Security review and penetration testing


But for a first attempt at AI-driven development, the results are impressive. The interface is visually clean, performance is snappy (at least with a single local user—not exactly a stress test), and the core functionality works as specified.





 
 
 

Recent Posts

See All
How does software development change with AI tools?

AI software development tools are fundamentally changing the roles played by software developers in several ways. Software developers are going to be writing less-- or, often, no-- code moving forward

 
 
 

Comments


Targeted Quality Laboratory Informatics Consulting

‪1+(585) 237-8259‬

Rochester, NY 14620

 

© 2025 by TQLI Consulting. Powered and secured by Wix 

 

bottom of page