Forem: Florian

Week 8 of 40 – Giving CatAtlas a Real Identity (and Tests)

Florian — Sun, 04 Jan 2026 00:29:02 +0000

Objective of the week

Strengthen the CatAtlas foundation by introducing a real identity layer and a new dimension of data, while adding automated tests for the first time.

The goal was to move beyond individual sightings and start modeling cats as entities, supported by AI-assisted summaries and backed by tests so the system can evolve safely.

What I built

This week I extended CatAtlas in several important ways:

Introduced an explicit Cat identity (cats table) separate from sightings
Turned entries into true sightings, optionally linked to a cat
Added photo support (via photo URLs for now)
Built a GenAI-style cat profile that aggregates multiple sightings into a single, readable description
Added automated tests using pytest and FastAPI’s TestClient

CatAtlas now has:

facts (sightings),
identities (cats),
derived knowledge (AI enrichment and profiles),
and guardrails (tests).

What I learned

Why separating observations from identity is critical in AI-assisted systems
How to evolve a database schema incrementally without breaking existing data
How to introduce a new data dimension (photos) without overengineering uploads
How GenAI-style features often start as aggregation + templating, not models
How to write integration-style tests against real FastAPI endpoints
How to make a codebase safer to change by testing behavior, not implementation

What was hard / surprising

Managing TypeScript and backend contracts as the data model grew
Understanding where identity decisions should live in the system
Debugging test import paths and environment-specific database behavior
Realizing how quickly complexity increases once entities relate to each other

The biggest challenge wasn’t writing code — it was keeping the mental model clean.

What I’ll do next week

Next week, I want to build on this foundation by making CatAtlas more visual and interactive.

Possible directions:

real photo uploads instead of URLs,
basic UI flows for assigning sightings to cats,
or preparing the system for actual vision-based matching.

The focus will stay on structure first, intelligence second.

Week 7 from 40 – Making AI Features Feel Real

Florian — Fri, 02 Jan 2026 20:50:15 +0000

Objective of the week

Moving from simple coding practices to making first ideas real by creating a page to publish feral cat sightings. I moved from isolated sightings to identity and relationships by introducing a first version of same-cat matching.

The goal was not accurate identification, but to learn how to suggest possible matches using simple, explainable logic based on text descriptions and locations.

What I built

I extended CatAtlas with a “same-cat matching v0” feature.

Each cat sighting can now:

trigger a matching process,
receive a ranked list of possible matches,
and display simple explanations for why two sightings might refer to the same cat.

This turns the app from a list of entries into an emerging network of related sightings.

GitHub repo:

👉 https://github.com/codespaces?repository_id=1122410808

Live site:

👉 https://orange-disco-pj4g9w4w46prh96pw-5173.app.github.dev/

What I learned

Designing similarity-based matching instead of binary identification
Working with arrays of objects to compute scores and rankings
Introducing explainable “reasons” for AI-like decisions
Managing additional per-item UI state in React
Thinking in terms of relationships between records, not just records themselves

What was hard / surprising

Deciding where matching logic belongs (backend vs frontend)
Tuning similarity thresholds so results feel useful, not noisy
Placing derived UI blocks correctly inside React list rendering
Realizing how quickly complexity grows once entities relate to each other

What I’ll do next week

Next week, I want to strengthen the CatAtlas foundation further by introducing a new dimension of data, such as photos or a more explicit “cat identity” concept.

The focus will be on adding structure carefully, without jumping too early into heavy AI or computer vision.

Week 6 from 40 – Making AI Features Feel Real

Florian — Tue, 30 Dec 2025 17:45:45 +0000

Reflection

This week was about turning an “AI demo” into something that behaves like a real product.

I extended the analysis feature so results are persisted and cached instead of being recomputed every time. This meant adding a new database table, thinking about derived data, and introducing concepts like hashing, upserts, and cache validation.

What stood out most was that the hard part wasn’t the analysis logic itself — it was designing the data flow and contracts so frontend, backend, and storage stay in sync.

The app now survives restarts with both entries and their analyses intact, which makes the system feel stable and intentional. It’s a small step, but an important shift from “toy AI feature” to “engineering an AI capability.”

What I learned

How to persist and cache AI-derived data instead of recomputing it
Why hashing is useful to detect meaningful changes in input text
How to design “analyze once, reuse many times” workflows
How frontend types and backend contracts must evolve together
That AI engineering is as much about data and state as it is about models

What was hard / surprising / confusing

Keeping frontend and backend response models in sync
Understanding when to recompute analysis vs return cached results
Dealing with TypeScript errors caused by small schema mismatches
Debugging issues that were about process and state, not code syntax

What I’ll do next week

Next week, I want to build on this foundation by introducing a more realistic AI component — either by integrating a real model/API or by adding evaluation and comparison between different analysis approaches.

The focus will stay on architecture and learning, not on building something “impressive.”

Week 5 of 40 adding my first “AI-like” endpoint

Florian — Mon, 29 Dec 2025 00:10:41 +0000

Week 5 – Learning by Getting Stuck (and Unstuck)

This week was less about adding new features and more about understanding the mechanics of modern development environments.

Objective

The objective this week was to add my first AI-style capability to the existing full-stack application and, more importantly, to understand how frontend, backend, and development environments interact in practice.

Rather than focusing on a complex model, the goal was to learn the integration pattern: defining an API contract, exposing a new endpoint, calling it from the UI, and rendering the result.

What I built

I extended my Learning Log application with a new analysis endpoint on the backend and an Analyze button in the frontend.

The backend now accepts text and returns a structured response (summary, tags, sentiment). The frontend triggers this analysis per entry and displays the result directly below the item. While the analysis itself is simple, the architecture mirrors how real AI-powered features are built and integrated.

What happened

While adding my first “AI-like” endpoint and integrating it into the frontend, I ran into a series of issues that all boiled down to one thing: environment and process management.

I had questions like:

Why does uvicorn say “address already in use”?
Why do I see two processes listening on the same port?
Why does npm complain about package.json when I just want to restart the backend?
Where is my frontend actually running, and how do I even find its URL?
What does “restart the frontend” really mean in Codespaces?

What I learned

uvicorn --reload starts two processes (watcher + worker), and sometimes both need to be stopped
Ports don’t magically free themselves; knowing how to inspect and kill processes matters
In Codespaces, nothing is “local” in the way my intuition expected — ports must be exposed and URLs discovered

Most importantly:

The hard part wasn’t writing code — it was building the right mental model of what runs where and why.

Reflection

This week felt slow and occasionally frustrating, but it was incredibly valuable. Each “why is this broken?” question turned into a small piece of foundational knowledge I’ll reuse constantly.

Progress didn’t look like more features — it looked like fewer mysteries.

On to the next week.

Week 4_b of 40 – Adding Persistence with SQLite

Florian — Sat, 27 Dec 2025 22:24:02 +0000

What I did

As a stretch goal for Week 4, I extended my FastAPI backend with SQLite persistence.

Instead of keeping entries only in memory, the backend now stores them in a local SQLite database. This means data survives backend restarts, which already makes the app feel much more “real”.

What I learned

How to use Python’s built-in sqlite3 module
How to create tables automatically on app startup
How to replace in-memory lists with SQL queries
How important restart testing is when working on backend persistence
How frontend and backend can remain unchanged while storage evolves

This was a great reminder that good interfaces (HTTP APIs) allow you to change internals without breaking clients.

What was interesting

The most satisfying moment was restarting the backend, refreshing the frontend, and seeing the data still there.

Small win, I know I know — but an important milestone.

What’s next

Next week or more likely tomorrow, I’ll build on this setup and start adding “smart” behavior on top of the API, moving closer to AI-driven functionality.

Week 4 of 40 – First Full-Stack App with React, TypeScript, and Python

Florian — Fri, 26 Dec 2025 20:55:07 +0000

Objective of the week

The goal of this week was to take the next real step toward full-stack development.

Until now, everything lived either in a static page or entirely in the frontend. This week I wanted to:

Build my first backend API using Python
Connect a React + TypeScript frontend to that API
Get frontend and backend to talk to each other
Learn the basics of working with GitHub Codespaces and the terminal

What I built

I built a small Learning Log application with a clear separation between frontend and backend.

Backend

Python + FastAPI
Endpoints to:
- create entries
- list entries
- toggle a “favorite” flag
Automatic API documentation via Swagger

Swagger UI:

https://orange-disco-pj4g9w4w46prh96pw-8000.app.github.dev/docs

Frontend

React + TypeScript
Fetches data from the backend API
Displays entries
Allows creating new entries and marking them as favorites

Frontend UI:

https://orange-disco-pj4g9w4w46prh96pw-5173.app.github.dev/

This is the first project in this challenge where:

the frontend depends on a backend,
data flows over HTTP,
and things break if URLs, ports, or environments are wrong.

What I learned

This week was packed with fundamentals that I had either forgotten or never really learned properly:

How to work with the terminal again:
- navigating folders
- activating virtual environments
- running servers
The basics of GitHub Codespaces:
- it’s a real Linux machine in the cloud
- processes stop when you close it
- ports must be explicitly exposed
How FastAPI works:
- defining request and response models
- automatic Swagger documentation
How a frontend talks to a backend using:
- fetch
- JSON
- environment variables
Why frontend apps need a configurable API base URL

This week made it very clear that modern development is less about syntax and more about understanding the system as a whole.

What was hard / surprising / confusing

Quite a few things 😅 — and that’s exactly why this week mattered.

I initially treated things in requirements.txt like terminal commands
I repeatedly forgot to activate the Python virtual environment
uvicorn: command not found taught me a lot about how environments really work
Understanding where my code was running vs where my browser was running took time
The concept of forwarded ports in Codespaces was new and unintuitive at first
Knowing which URL the frontend should call (and why localhost doesn’t work here) was confusing
Forgetting to restart the frontend after changing .env caused a lot of head-scratching

Overall, the hardest part wasn’t coding — it was mental models:

what runs where,
what talks to what,
and what needs to be restarted when something changes.

What I’ll do next week

For Week 5, I want to build on this exact architecture:

Keep React + TypeScript on the frontend
Keep Python on the backend
Add the first “smart” behavior
- something that processes text
- analyzes, summarizes, or enriches entries

This will be my first step toward AI-adjacent functionality, built on top of the foundations laid this week.

Week 4 was slower, more frustrating, and more educational than the previous ones — which is probably a good sign.

Week 2 of 40 – My Idea Log & Randomizer

Florian — Sat, 29 Nov 2025 23:03:23 +0000

Objective of the week

The goal this week was to take a small step forward in complexity while staying within a familiar environment. After getting comfortable with GitHub Pages in Week 1, I wanted to:
Build something slightly more interactive than a static page
Practice using browser storage so the app could remember things
Keep reinforcing the basic workflow: create → commit → deploy → reflect
Continue building confidence without disappearing down a perfection rabbit hole

What I built

This week I created a tiny Idea Log & Randomizer web app.
It lets me: Add ideas with a title and short description
Store ideas in localStorage so they persist across refreshes
Display all ideas in a simple list
Pick a random idea with one click
Everything is plain HTML + CSS + JavaScript, deployed again with GitHub Pages.
URL: https://florianhoeppner.github.io/w40-week02-idea-log/

What was hard / surprising / confusing
/

What I’ll do next week

For Week 3, I want to introduce the next layer of complexity
Start using TypeScript instead of plain JavaScript
Build a small UI using React
Keep the functionality simple

Week 1 of 40 – Static Idea of the Week

Florian — Sat, 29 Nov 2025 22:47:46 +0000

Objective of the week

Wanted to get familiar with the environment I’ll be working and releasing in
Just needed to get something started without any big purpose
Figure out where to store my code, how to deploy, and write a blog pos t

What I built

I built a static HTML page with a simple piece of JavaScript
When the page loads, it picks a random idea and displays it
URL: https://florianhoeppner.github.io/w40-week01/

What was hard / surprising / confusing

I tried creating three files (index, CSS, script) in Replit and deploying from there
The Replit AI agent wasn’t helpful, so after a few attempts I switched to GitHub instead

What I’ll do next week

Add a dialog box and some interaction, still using HTML and JavaScript

Getting Back

Florian — Sat, 29 Nov 2025 00:25:08 +0000

When I was 15, I wrote my first programs on a C64. Later came Pascal, PHP, Java, JSP, and even a phase working with COBOL and JCL on OS/390 in a bank. For many years, writing software was a big part of my life — until I slowly drifted away into building PowerPoints instead of building products.

Lately, with so much happening in tech, I realized how much I miss the fun of creating things, experimenting, and working on my own ideas. That’s when I came across the 40 ideas in 40 weeks challenge. It immediately clicked. Maybe this is exactly what I need: shipping small ideas quickly, avoiding the perfection trap, and learning by delivering every single week.

My goal is simple: small but finished.

My Starting Stack

Languages: TypeScript + Python
Frontend: React + component library
Backend: Serverless functions (Vercel / Netlify)
Database: Supabase (Postgres + Auth)
Hosting: Vercel / Netlify
Tools: VS Code, GitHub, CI from GitHub to Vercel/Netlify

Weekly Plan

Pick one idea
Build a minimal but real version
Publish: demo, GitHub link, or blog post
Reflect: What was the objective? What did I learn?

I’m excited — and a bit nervous if I can allocate enough time — but mostly ready to rediscover the joy of building. Let’s get started.