Building an iNaturalist Observation Tool with Claude Code on a Phone: Git Scraping in Practice

Project Background: Why Code on a Phone

Simon Willison (renowned developer and creator of Datasette) recently shared an inspiring project: while camping outdoors, he built a web tool from scratch to display iNaturalist nature observations—entirely on his phone using Claude Code for web.

Simon Willison is one of the co-creators of the Django framework. He later created Datasette—an open-source tool that instantly transforms SQLite databases into interactive APIs and web interfaces. He has long championed a "small tools" philosophy, advocating for solving real problems with the simplest possible tech stack. He's also an early practitioner and evangelist of AI-assisted programming, continuously documenting and sharing his experiences using LLMs for software development.

iNaturalist is a widely popular nature observation community platform, jointly operated by the California Academy of Sciences and the National Geographic Society, with over 150 million observations and millions of active users. Users can upload photos of plants and animals and receive AI-powered species identification—its core computer vision system suggests species, which are then confirmed by community experts. The platform provides a comprehensive RESTful API that allows developers to query observation data by user, location, time, and other dimensions, returning JSON-formatted data including species information, geographic coordinates, photo URLs, and more. Simon has two separate iNaturalist accounts, and he wanted to aggregate and display observations from both accounts together by time and location.

The requirement itself isn't complex, but it involves three stages: data retrieval, aggregation processing, and frontend display. What makes it truly interesting is that he chose to complete the entire development workflow during a camping weekend using only a phone.

Claude Code for Web is Anthropic's browser-based AI programming assistant. Unlike traditional desktop IDE integrations, it runs entirely in the browser, meaning users can access it on any device with an internet connection—including phones and tablets. It supports code generation, file editing, project structure planning, and more. While it can't execute code locally, it can generate complete deployable code and manage versions through platforms like GitHub. This illustrates a key value proposition of current AI programming tools: drastically reducing dependency on development environments.

Three-Layer Technical Architecture Explained

The entire project consists of three independent components, each with a distinct role while working together seamlessly.

Layer 1: Python CLI Data Processing Tool

Simon first built a Python command-line tool called inaturalist-clumper, responsible for pulling observation data from the iNaturalist API and performing "clumping" aggregation.

The default clumping rule is: observations within 2 hours of each other and within 5 kilometers geographically are grouped together. This design closely matches real-world usage—multiple photos taken during a single field observation outing naturally get grouped into one "trip." This type of spatiotemporal proximity-based clustering algorithm is common in Geographic Information Systems (GIS), essentially a simplified version of DBSCAN (Density-Based Spatial Clustering of Applications with Noise), except here it considers both time and space dimensions simultaneously.

Layer 2: Git Scraping for Automated Data Updates

The second component is the simonw/inaturalist-clumps repository, which employs the "Git Scraping" pattern that Simon himself popularized—using GitHub Actions to periodically run scripts and automatically commit processed results to a clumps.json file in the repository.

Git Scraping is a data collection pattern proposed and popularized by Simon Willison in 2020. Its core idea is to leverage GitHub Actions' scheduled trigger functionality (cron schedule) to periodically run data scraping scripts, then automatically commit results via git commit. Since Git is inherently a version control system, every data change is fully recorded, forming a natural time-series database. This pattern has been widely adopted for tracking government data changes, monitoring website content updates, recording API response changes, and more.

GitHub Actions is GitHub's built-in CI/CD and automation platform, defining workflows through YAML configuration files. Workflows can be triggered by code pushes, Pull Requests, scheduled plans (cron expressions), or external events. Each workflow runs in a GitHub-provided virtual machine supporting Ubuntu, macOS, and Windows environments, with the ability to install any dependencies and execute scripts. For public repositories, Actions usage is completely free with no minute limits, making the Git Scraping pattern virtually zero-cost.

Layer 3: Pure Frontend Static Display Page

The final layer is a static HTML page that fetches JSON data from GitHub via fetch() and renders it as a thumbnail grid of observation records. This leverages a key feature: GitHub's raw.githubusercontent.com domain sets appropriate CORS (Cross-Origin Resource Sharing) headers, allowing frontend code from any origin to directly fetch file contents. CORS is a browser security mechanism that by default blocks webpage JavaScript from making requests to different domains, but GitHub's open policy means developers don't need to set up proxy servers or backend APIs—pure static pages can read data files stored in repositories.

Specific implementation details include:

• Using loading="lazy" for image lazy loading to optimize page performance. This is a native HTML deferred loading attribute that tells the browser to only initiate network requests when images are about to enter the viewport. For pages containing many images, loading all thumbnails at once could generate hundreds of concurrent HTTP requests, severely impacting page load speed. Browsers implement this functionality under the hood via the Intersection Observer API, requiring no JavaScript from the developer.
• Clicking thumbnails opens a modal via the native HTML <dialog> element to display full-size images. <dialog> is a native HTML5 modal component that achieved full support across all major browsers in 2022. Compared to traditional JavaScript modal libraries, the native dialog element offers built-in focus management, keyboard navigation support (Escape key to close), backdrop overlay (::backdrop pseudo-element), and other accessibility features—all without any third-party dependencies.
• Displaying common species names (when available)

The Elegance of the Git Scraping Pattern

The most noteworthy architectural decision in this project is the use of Git Scraping. It treats a GitHub repository as a free, version-controlled database:

• Zero-cost hosting: GitHub provides storage and CDN services for free
• Automatic updates: GitHub Actions scheduled tasks keep data continuously refreshed
• Complete version history: Git naturally records every data change, making it easy to trace back
• CORS-friendly: GitHub raw files support cross-origin access, allowing frontend JavaScript to fetch directly without building an API server

This pattern is particularly suited for personal projects with modest data volumes and infrequent updates. No database needed, no backend service needed—a single GitHub repository handles data storage, updates, and distribution. It's worth noting that GitHub has a 100MB limit per file and recommends keeping total repository size under 1GB, making this pattern best suited for small-to-medium datasets in text formats like JSON and CSV. For scenarios requiring frequent updates (e.g., every minute) or large data volumes, traditional databases remain the better choice.

Completing Frontend Development with a Single Prompt

The entire frontend page was developed by handing a carefully crafted prompt to Claude Code. Simon's prompt structure is worth studying:

1. Clear objective: Explicitly state what file to build and which repository it belongs to
2. Specify data source: Provide the complete URL of the JSON file
3. Describe functional requirements: Thumbnail grid display, lazy loading, modal for viewing full images
4. Add specific details: Image URL construction format, interaction behavior, information display rules

This structured prompt writing approach is far more efficient than vaguely saying "make me a webpage." Giving AI sufficient context and constraints is what enables getting usable results on the first try. This reflects the core principle of prompt engineering: specificity trumps vagueness—the more explicit the constraints, the more controllable the AI's output. When using AI programming on mobile, where multi-round debugging and iteration is inconvenient, providing complete and precise requirements in one go becomes especially critical.

Design Philosophy and Reusable Development Patterns

Though small in scope, the design principles behind this project are worth borrowing in many other contexts:

• Separation of concerns: Data retrieval, storage/updates, and frontend display are three independent stages—any layer can be replaced independently. This is the classic layered architecture principle from software engineering, where each layer only concerns itself with its own responsibility, interacting with other layers through clearly defined interfaces (in this case, the JSON file format).
• Maximizing free infrastructure: GitHub simultaneously serves four roles—code hosting, data storage, automation execution, and static page hosting. GitHub Pages provides free static website hosting with custom domain and HTTPS support, fully replacing traditional web servers for personal projects.
• Progressive construction: First build the CLI tool to ensure data processing logic is correct, then add automation, and finally build the frontend display. This inside-out build order ensures each step can be independently verified, reducing debugging complexity.
• Simplicity first: Pure static pages with no build steps, no framework dependencies, no backend server. Against the backdrop of increasingly complex frontend engineering (webpack, Vite, React, Next.js, etc.), this return to native HTML/CSS/JavaScript feels refreshing. For tool pages with clear functionality and simple interactions, the native tech stack is more than sufficient—while avoiding the maintenance burden of dependency updates and build configuration.

Conclusion

This project is a textbook example of "small tools, big wisdom." Simon Willison combined Claude Code, Git Scraping, and GitHub Pages—all free tools—to solve a real problem with minimal cost and time investment.

For developers looking to build personal data display tools, this pattern is directly reusable: process data with Python scripts, update on schedule with GitHub Actions, and display with static pages. No server needed, no database needed—just a clever combination of a few simple components. This "serverless" personal project architecture represents an increasingly popular development paradigm—leveraging free platform capabilities to minimize operational complexity, letting developers focus on solving the actual problem at hand.