Select Page

We’re two weeks into this experiment and I wanted to take a moment and distill the key learnings so far from this. As a recap if you’re new here I posted this challenge to myself to create a profitable micro-SaaS in 30 days during the month of July as someone who doesn’t know how to write code. I made the app I was envisioning in three days using Claude Code. I’m documenting my takeaways and epiphanies from this process in hopes this helps others who are attempting to build stuff and just need help to get over that initial chasm of technical daunting-ness.

Recap

Week one I finally figured out what I believe is the secret sauce to working effectively with Claude. I see a lot of comments in forums and Reddit threads from folks frustrated with how tools like Cursor, Windsurf and Claude seem to be amnesic and end up degrading as you work with them eventually producing spaghetti code, chasing red herrings and in general getting derailed. I experienced that phenomenon first hand on my attempt building LunchMixer.com with Cursor. But what I’ve figured out is that a) you treat Claude like a teammate in how you deal with it and b) you follow best practices as a team would to capture tribal knowledge and store it in a central place accessible to the team. You need to be constantly distilling the learnings of the development process and then referencing those from the .clauderules file. I’ll explain.

Treat Claude like a Teammate

Back in the day at iTOOL we’d do a pow-wow every morning where the 6-7 devs would all circle their chairs and we’d go around the circle and each state the three key bits:

  1. What did you accomplish yesterday
  2. What are you focused on today
  3. What blockers are you wrestling with currently

We use this same process today only via Discord with the team working on Message Everywhere. It’s the most effective way to ensure everyone is focused on the right things and never let someone go more than a day when they’re completely stuck on something.

I’ve been using this process with Claude and I’ve set it up such that it recognizes a few key phrases and triggers pre-built scripts that execute the key activities, so that when I say:

Let’s do the standup 

  1. Claude analyzes any .md files in /guidance/retrospectives/features from yesterday to see what we accomplished yesterday.
  2. Then it checks Linear via MCP to see what issues are currently in the “Todo” column (these are the things I want to focus on next)
  3. Lastly it checks for any session retrospective files with yesterday’s date in /guidance/retrospectives/sessions
  4. It then synthesizes all of that into our desired format above.

Let’s do a feature retrospective

Claude reads back through our prompting exchange for whichever feature we built last and condenses it into a write up like the one below that captures all the key learnings from implementing that feature and navigating any errors or roadblocks.

Let’s do a session retrospective

Similar to the feature retrospective above, Claude analyzes our dialogue for the entire session and condenses it into learnings. There is some overlap with the Feature Retrospective but we do this since you can have multiple features built in one session and/or have multiple sessions required to build one feature. This preserves all key lessons irrespectively of how development went.

Let’s write the blog post

Claude checks for any new Feature or Session Retrospectives since the datetime of the last blog post and rolls it all up in a summary format like the one below.

Through this process of building, encountering errors, fixing them and then distilling that wisdom into documentation that lives in the /guidance folder, Claude actually gets better over time and makes fewer errors.

But the epiphany here and the massive win is that /guidance folder that lives in source control is actually portable and can be injected into any new project effectively transporting the “tribal knowledge” of how we do work so it’s instantly available on new projects. This is the real takeaway from these past two weeks.

Below I’ll share some screenshots of how I structure my issue cards in Linear and then examples of Feature & Session Retrospectives as well as the summary blog post template.

Where I’m headed next

AgentForm is working deployed live via the free plan on Vercel. You can test it out now on any Google Form and it should give you the capability in two clicks to transform your Google Form into a conversational experience. So… mission accomplished. In terms of adding support for all other form providers and trying to make a biz out of this I’ve come to the realization that I’d rather just help a few friends implement the apps they need/want for their businesses. This has been a fun experiment but I’m taking a week off and when I come back on the 23rd I’ll be going heads-down on putting what I’ve learned here to work for a handful of friends in their respective ventures.

I will continue blogging lessons and takeaways and I am also in process of pulling together a little resource (may be a Udemy course or could be just an e-Book- haven’t decided yet the form factor) that will distill all of this into a recipe one can follow to come up to speed on all of this. I still need to figure out whether the target audience is non-technical solo founders or could be instead technical folks who are getting displaced from their jobs. That is 100% happening as we speak and I think the lifeboat there could be helping them transition to more product managers wielding tools like these to build their own SaaS or productized service.

At any rate below are the promised screenshots and resources:

What my Linear kanban board looks like

How I communicate what I want in each issue card in Linear

Claude comments when it finishes working and moves the Linear card to “For Review” status column


Session Retrospective: July 3, 2025 – Session 2

Session Overview

Focus: GRID7-56 – WordPress MCP connection and blog post generation process Duration: ~1.5 hours (11:00 AM – 12:30 PM EST) Outcome: ✅ Completed – Simplified to markdown file generation

Key Accomplishments

✅ WordPress MCP Investigation

  • Researched multiple WordPress MCP server options
  • Identified connection issues with untrusted/non-existent packages
  • Made executive decision to simplify approach

✅ Blog Generation System Implementation

  • Created lib/blog-generator.js – Core blog post generation logic
  • Modified scripts/daily-blog-post.js – CLI interface for blog generation
  • Established /guidance/blogposts/ directory structure
  • Generated first test blog post successfully

✅ Process Simplification

  • Removed complex WordPress MCP integration
  • Implemented markdown file output for copy/paste workflow
  • Tested end-to-end blog generation process
  • Committed code and marked Linear issue complete

Technical Decisions Made

✅ Pragmatic Over Perfect

Decision: Use markdown file generation instead of WordPress MCP integration Rationale:

  • WordPress MCP packages were unreliable/non-existent
  • Copy/paste workflow is simpler and more reliable
  • Focus development time on core app features vs tooling complexity

✅ Structured Data Processing

Implementation: Blog generator parses standup notes and retrospectives Benefits:

  • Automated content synthesis from existing documentation
  • Consistent blog post format and structure
  • Includes development metrics and technical insights

Development Metrics

Code Changes

  • Files Created: 2 new files (lib/blog-generator.jsscripts/daily-blog-post.js)
  • Lines Added: ~300+ lines of blog generation logic
  • Directories Created/guidance/blogposts/

Time Investment

  • Research Phase: 30 minutes (WordPress MCP investigation)
  • Implementation: 45 minutes (core logic and file I/O)
  • Testing & Refinement: 30 minutes (end-to-end validation)
  • Git & Linear: 15 minutes (commit and issue management)

Quality Measures

  • Working Solution: ✅ Generated functional blog post from real data
  • Code Quality: Clean, documented functions with error handling
  • User Experience: Simple CLI command for daily use

Key Insights

🎯 Scope Management Success

  • Recognized when to abandon complex approach for simple solution
  • Avoided over-engineering tooling at expense of core product development
  • Delivered working solution quickly vs perfect integration

🔧 Data Integration Patterns

  • Standup notes + retrospectives provide rich content for blog generation
  • Structured markdown parsing enables automated content synthesis
  • Development metrics add credibility to progress updates

📋 Process Validation

  • End-to-end test confirmed the entire workflow functions correctly
  • Generated blog post quality exceeded expectations
  • Copy/paste approach actually superior UX vs automated publishing

Looking Forward

✅ Immediate Value

  • Daily blog post generation now available on-demand
  • Consistent format ensures professional content quality
  • Automated metric inclusion saves manual work

🚀 Future Enhancements

  • Could add image generation for blog post headers
  • Template customization for different content types
  • Integration with social media posting if needed

Session Rating: 9/10

Strengths: Clear problem identification, pragmatic decision-making, working solution delivered Areas for Growth: Could have identified simpler approach sooner vs spending time on MCP research


Feature Retrospective

GRID7-52: Improvement: Make the /preview page more obvious of what the next step is in previewing the /traditional and /conversation pages

Accomplishments

  • De-emphasized “View Results” button from primary CTA to secondary action
  • Made Traditional Form and Conversation preview options the primary CTAs with prominent gradient styling
  • Improved visual hierarchy by dimming form structure elements while keeping question titles readable
  • Enhanced UX with descriptive text below buttons for clarity
  • Applied consistent changes across both /preview/page.tsx and /forms/[formId]/preview/page.tsx

Technical Challenges Solved

  1. Button Layout Optimization: Initially cramped multi-line button content – resolved by moving descriptions below buttons for better readability
  2. Visual Hierarchy Balance: Needed to dim distracting elements without making content unreadable – applied selective opacity to type badges and required indicators while preserving question titles
  3. Consistency Across Pages: Ensured identical improvements on both static and dynamic preview page variants

Key Technical Insights

  • Progressive UI Iteration: Starting with a working solution and iterating based on visual feedback led to better final result than trying to get perfect design upfront
  • Selective Opacity Application: Using 30% opacity on specific UI elements (badges, icons) while preserving readability of core content creates effective visual hierarchy
  • Gradient Button Styling: Full-width gradient buttons with proper spacing create strong CTAs that guide user attention effectively

Collaboration Highlights

  • Effective use of screenshots for visual feedback and iteration
  • Quick adaptation to user feedback on cramped button descriptions
  • Systematic approach using TodoWrite to track multiple related tasks
  • Clear communication about visual hierarchy priorities

Development Metrics

  • Lines of Code: 256 added, 97 modified
  • Token Usage: ~10,025 tokens (1,969 input + 8,056 output for today’s session)
  • Development Time: ~0.5 hours active work
  • Files Modified: 2 files across multiple commits
  • Features Shipped: 1 complete UX improvement (preview page CTA optimization)

Looking Forward

  • Consider documenting UI component patterns for consistent CTA styling across the app
  • Could extend this visual hierarchy approach to other pages with competing CTAs
  • Monitor user behavior to validate that the new layout improves conversion to preview actions

Feature retrospective for process improvement and blog post generation.


asdf


Thanks for reading. Could you answer a few questions below? This is incredibly helpful for understanding my readers and helps me create better content. thanks so much. -Sean

Can we keep in touch?

Can we keep in touch?

I'm Sean, founder of the Stone Soup Protocol and author of this blog. I write about useful ideas & techniques at the intersection of nocode, automation, open source, community building and AI and I make these accessible & actionable for non-technical folks. If you'd like to get a periodic roll-up summary from me, add yourself below. 

Great. I'll keep you in the loop! -Sean

Share This