Product managing a Streamlit app

Use Claude to build a web app on top of an existing REST API.
python
claude
streamlit
Published

April 12, 2026

Throughout my NPS hikes project, I’ve assigned Claude a number of different roles.

In the beginning of the project, while designing the initial data pipeline, Claude was like a teacher or partner. I’d ask Claude for ideas, write some of the code myself, ask for feedback, question its decisions, and make sure I understood every method.

As the project has progressed, I’ve entrusted Claude with greater responsibility. For this Streamlit app, I didn’t look at any of the actual code. My role was that of a product manager. I helped design a plan of implementation. I iteratively offered feedback on the results I could inspect in the browser. I relied on Claude’s own tests and the linting framework to encourage good practices.

Streamlit app of NPS Hikes Explorer

Cross-conversation memory

Building this app challenged Claude’s context window more than other stages. Given the size of the project and the ambitions of the task, it wasn’t uncommon to fill up the context window quickly.

To manage this limitation, I established a practice of maintaining a planning document to serve as the app’s cross-conversation memory. This document laid out the app’s objectives, planning stages, progress, troubleshooting, and user feedback. Every new Claude conversation began with instructing Claude to read this document. Every Claude conversation ended with asking Claude to update this document. In future projects of this nature, I could see implementing a skill or hook telling Claude to do this.

Streamlit app as API client

One architectural decision made in the early planning stages was to make the Streamlit app a pure HTTP client calling the FastAPI backend. The alternative would have been to let the app query the database directly. However, given that the API already existed, making it a client of the API had a few clear benefits:

  • The app needed GeoJSON geometries, park boundary polygons, and park descriptions. The API hadn’t exposed those fields yet; the app exposed those gaps.
  • It forced clean separation between the app’s requirements and those of the larger project. The app has own requirements.txt file and its own HTTP client wrapper.
  • It made deployment a breeze because no database credentials touch the Streamlit environment.