Documenting the Build
This is the second article in a series call Breaking the Monolith.
Because I want to document this process, I plan to use Gemini to do some writing about this project, so I started a second chat to focus on the writing piece. I asked the LLM to write an Anchor Prompt for me that would allow me to keep the main planning conversation open, while maintain a separate discussion that will be about the big picture. Using an Anchor Prompt allows me to transfer information from one chat to another.
| Prompt I am starting a series of Confluence pages to document my journey building a custom Formula 1 statistics application. The Context: I am a veteran developer with a deep background in the Microsoft stack (MS SQL, C#, ASPX, IIS). I am deliberately moving away from that ‘monolith’ mindset to build this project using a ‘Modern Nerd’ stack. The Stack: PostgreSQL, FastAPI (Python) using SQLModel (ORM), Next.js (React) with Tailwind CSS, running on Docker & Railway. Your Role: You are my drafting partner and editor. Your goal is to help me turn my technical progress and ‘aha!’ moments into engaging, concise, and helpful blog posts. We want to highlight the ‘Why’ behind my choices and the specific hurdles of moving from .NET to this modern ecosystem. Our First Task: I have just finalized my architecture planning. Let’s draft a short ‘Intro’ post (Post #0) that explains why I’m taking this leap and introduces the stack. Ask me 3-4 targeted questions to get the raw material you need to write the first draft.” |
| Response I’ve noted the shift from the Microsoft monolith to the “Modern Nerd” stack for your F1DB project. To draft the Intro post (Post #0), I need a bit more raw material: The “Breaking Point”: Was there a specific limitation in the MS stack or a particular “aha!” moment that convinced you this project specifically required PostgreSQL and FastAPI? The Learning Curve: Coming from C# and ASPX, what is the single biggest “mental model” shift you’ve encountered so far while setting up SQLModel or Next.js? The F1 Factor: Why build a Formula 1 app specifically to test this stack? Does the nature of F1 data (high-volume, relational, real-time) play into the choice of PostgreSQL and Python? The Goal: Aside from the tech shift, what is the ultimate “vision” for the app—is it purely for personal analysis, or are you aiming for a specific feature the current F1 sites lack? How would you like to proceed with these points? |
| Take Away A new technique that I am learning, is to explain to the model what I want to achieve, and then asking the LLM to provide me with the questions that I should ask. This is new to me, and is an experiment. We will see. |
Setting a New Anchor Point
I discussed some of the language and topics with the LLM, and made some general tweaks. I find that these LLM’s write in a very dramatic style sometimes. I don’t want drama, I just want some helping getting my thoughts on paper quickly, and in a readable fashion.
| Prompt After discussing some changes, I finalized the content, deployed it to a page on my site (at this point it was published on Confluence), and then export the entire content to PDF. I then shared the PDF w/ the LLM and let it know that this is what I came up with after our discussions, and after some editing by a human. |
| Response This is a great look at the final version of Post #0. Seeing it in its Confluence format provides helpful context on how you’re structuring the “why” and the technical breakdown for your audience. A few key takeaways from your finalized post that I’ll keep in mind for our next drafting session: Refined Motivation Skill Refresher: You’ve clearly framed this as a deliberate move to refresh your skillset and rebuild your mental models by stepping away from the familiar Microsoft stack. The “Expert-to-Junior” Transition: You’ve highlighted the value of becoming a “junior” again in a new ecosystem to effectively learn. The Technical Decision-Making Relational Logic Over Hype: Your section on why you chose PostgreSQL over MongoDB is a strong “aha!” moment. It demonstrates that your veteran understanding of relational data is driving the stack choice, rather than just picking what is trendy. AI as a Consultant: You’ve established a clear boundary for our partnership—using AI to accelerate decisions and distill information rather than generating “slop”. Current Progress Stack Finalized: We are locked in with Python 3.14, Next.js 16, and FastAPI 0.133. Next Step: The post concludes with the plan for environment provisioning, including scaffolding the frontend/backend and spinning up Postgres via Docker. |
| Take Away At the end of major check point, I am asking for a new anchor point/prompt. I have found in other projects that LLM’s work much better when you start small and build on previous ideas. |