The Basement Year: 6 Months From Zero Code to Production Platform

March 2024: I decided to learn to code and build a publishing platform.

    No computer science degree. No bootcamp. No technical co-founder. No prior programming experience beyond HTML in 2005.

    **September 2024: I launched Teneo v1.0.**

    This is the detailed breakdown of those 6 months—what I learned each week, what Claude taught me, what broke, and how collaboration with AI compressed years of learning into months of intense work.

What Got Built in 6 Months (By Someone Who Still Can't Code)

      - **80+ Lambda functions** handling outline generation, content creation, payments, analytics
      - **React production app** with routing, authentication, paywalls, personalized flows
      - **AWS Step Functions** orchestrating multi-stage book generation workflows
      - **DynamoDB architecture** managing user data, book projects, style profiles, credit systems
      - **Stripe integration** for payments, subscriptions, credit purchases
      - **All built by asking Claude questions and following instructions**
      - **I still don't know how to code.** AI walks me through everything.

Week 1: "I Have No Idea What I'm Doing"

    **Goal:** Get a button to work.

    Not build a feature. Not deploy a service. Just make a button do something when clicked.

Day 1-2: Setup Hell

    I spent two full days just getting a development environment working:

    - Installed Node.js (didn't understand what it was)
    - Installed VS Code (didn't know what extensions to use)
    - Created a React app using create-react-app (had no idea what was happening)
    - Ran `npm start` and saw a spinning React logo (felt like magic)

    **What Claude did:**

    - Explained what Node.js actually is (JavaScript runtime outside the browser)
    - Recommended VS Code extensions (ESLint, Prettier, ES7 snippets)
    - Walked me through what create-react-app generated and why
    - Explained the concept of a development server

Day 3-5: The Button That Broke Me

    I wanted to create a button that incremented a counter when clicked.

    Simple, right?

    I spent **12 hours** trying to make this work.

What I tried first (didn't work):

function MyButton() {
  let count = 0;
  return (
    <button onClick={count++}>
      Clicked {count} times
    </button>
  );
}

Problem: Button didn't update. Clicked 50 times, still showed "0".

    **What Claude taught me:**

    - **React state:** Variables don't automatically cause re-renders. You need `useState`.
    - **Event handlers:** `onClick` needs a function, not a statement.
    - **Immutability:** You don't modify state directly; you call the setter function.

What actually worked:

import { useState } from 'react';

function MyButton() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Clicked {count} times
    </button>
  );
}

When that button finally worked, I literally stood up and cheered in my basement.

Day 6-7: First Real Component

    Built my first useful component: a book title generator.

    - Text input for niche
    - Button to generate titles
    - Display list of generated titles

    **What broke:** Everything.

    - Input value not updating (forgot `value` and `onChange`)
    - Titles not displaying (forgot to use `.map()` correctly)
    - Console full of warnings about missing keys (didn't understand list rendering)

    **What Claude taught:**

    - Controlled vs uncontrolled components
    - Array methods in JSX (`map`, `filter`)
    - Why React needs keys for list items
    - How to structure component state for complex data

Week 1 Accomplishments

      - Learned basic React concepts (components, state, props, events)
      - Built first working component (title generator)
      - Cried once (the button)
      - Started understanding error messages instead of panicking

Week 2-3: "Wait, I Need a Backend?"

    My title generator worked, but it was all fake data. I needed to actually call OpenAI's API to generate real titles.

    **Problem:** I didn't know what an API was. Or a backend. Or how they talked to each other.

The API Key Disaster

    My first attempt at calling the OpenAI API:

    - Pasted API key directly in my React component
    - Made the API call from the frontend
    - Pushed code to GitHub
    - Got an email 20 minutes later: "Your OpenAI API key has been exposed and disabled"

    **Panic level: 10/10**

    **What Claude taught me (in emergency mode):**

    - Frontend code is PUBLIC. Never put secrets there.
    - Environment variables (`.env` files)
    - Backend services that protect API keys
    - How to remove sensitive data from Git history

Learning AWS Lambda

    Claude recommended AWS Lambda for my backend: serverless, pay-per-use, no servers to manage.

    **My reaction:** "What's serverless? If there's no server, where does the code run?"

    It took **3 days** to get my first Lambda function working:

    - **Day 1:** Set up AWS account, got lost in IAM roles and policies
    - **Day 2:** Wrote first Lambda function, couldn't figure out how to test it
    - **Day 3:** Finally got it to respond to an HTTP request via API Gateway

    **What Claude did:**

    - Explained serverless architecture (code runs on-demand, you don't manage infrastructure)
    - Walked me through AWS console setup
    - Generated Lambda function templates
    - Debugged permission errors (IAM policy configuration)
    - Showed me how to read CloudWatch logs (where Lambda errors appear)

First Working API Call

      When my React app successfully called my Lambda function, which called OpenAI, and returned real AI-generated book titles...

      **That was the moment I knew I could actually build this.**

Month 2: Building Actual Features

    With basics in place, I started building real features:

Feature 1: Book Outline Generator

    **Challenge:** Generate a full book outline with chapters, sections, and descriptions.

    **New concepts I had to learn:**

    - Promises and async/await (API calls aren't instant)
    - Error handling (what if the API fails?)
    - Loading states (show user something while waiting)
    - Data structure design (how to represent a book outline in code)

    **What Claude taught:**

    - JavaScript promises and asynchronous programming
    - Try-catch error handling
    - Conditional rendering in React
    - JSON schema design for complex data structures

Feature 2: DynamoDB Integration

    I needed to save user data and book projects. Claude recommended DynamoDB.

    **Learning curve: STEEP**

    Coming from a publishing background, I thought databases worked like Excel:

    - Rows and columns
    - Filter and sort
    - Easy to understand

    **DynamoDB reality:**

    - Partition keys and sort keys (what??)
    - Query vs Scan (why does this matter?)
    - Eventually consistent reads (the data might be... outdated?)
    - Global secondary indexes (to query different ways)

    I corrupted my database **twice** in the first week:

    - **Corruption #1:** Wrote invalid JSON format. Had to delete entire table and start over.
    - **Corruption #2:** Updated an item incorrectly and broke all related queries. Took 6 hours to fix manually.

    **What Claude taught:**

    - NoSQL database concepts (different from SQL)
    - How to design partition keys for access patterns
    - When to use Scan vs Query (and why Scan is expensive)
    - Update expressions and conditional updates
    - How to backup data before making changes (learned this after corruption #2)

Feature 3: AWS Step Functions

    Book generation needed multiple steps:

    - Generate outline
    - Evaluate outline quality
    - Generate each chapter
    - Evaluate chapter quality
    - Combine into full manuscript
    - Format for publishing

    Each step needed to happen in order, with error handling at each stage.

    **Solution: AWS Step Functions** (workflow orchestration)

    **Learning process:**

    - Week 1: Built simple 2-step workflow (outline → chapter)
    - Week 2: Added error handling (retry logic, failure catching)
    - Week 3: Built full 15-step book generation pipeline
    - Week 4: Optimized for parallel execution (generate chapters simultaneously)

    **What Claude did:**

    - Designed the state machine structure
    - Generated Amazon States Language (JSON for defining workflows)
    - Helped me understand parallel states vs sequential
    - Debugged error handling logic
    - Optimized for cost (parallel execution = faster = cheaper)

Month 2 Accomplishments

      - Built outline generator (functional)
      - Integrated DynamoDB (after corrupting it twice)
      - Created first Step Function workflow
      - Learned AWS architecture patterns
      - Started thinking in systems, not just features

Month 3-4: Quality Systems and Scaling

The Quality Problem

    My book generator worked. But the output quality was... inconsistent.

    - Some chapters were great
    - Some were generic AI slop
    - Character names changed mid-book
    - Writing style shifted between chapters

    **Solution needed: Quality evaluation system**

    I built a 3-layer evaluation framework:

    - **Structural Check:** Does it have the required sections?
    - **Coherence Check:** Is it consistent with previous chapters?
    - **Quality Check:** AI judges the content (score 1-10)

    **New concepts learned:**

    - Multi-model AI workflows (one AI generates, another evaluates)
    - Scoring rubrics and thresholds
    - Automatic retry logic (regenerate if score {'<'} 7)
    - Context preservation (pass previous chapters for coherence checking)

    **What Claude taught:**

    - How to design evaluation prompts (specific criteria, objective scoring)
    - When to use GPT-4 vs Claude (different strengths)
    - Cost optimization (evaluation is cheaper than generation, so evaluate first)
    - How to parse and validate AI responses (sometimes they don't follow instructions)

Keeping AWS Costs Low

    One worry I had: "Is this going to cost thousands in AWS fees?"

    **Reality:** AWS costs stayed around $20/month throughout development.

    **How:**

    - First few months on free tier (AWS gives new accounts 12 months free)
    - After free tier: ~$20/month as I exceeded some data limits
    - Lambda functions are cheap (only pay when they run)
    - DynamoDB has generous free tier
    - S3 storage is pennies

    **The lesson:** Serverless architecture is affordable. You're not paying for idle servers. You only pay when code actually runs.

Style Training System

    Users wanted books that sounded like *them*, not like generic AI.

    **Challenge:** How do you teach AI someone's writing style?

    **Solution I built:**

    - User provides 2,000-5,000 words of their own writing
    - AI analyzes style (sentence structure, vocabulary, tone, perspective)
    - Generates a style profile (structured data describing their voice)
    - Every book chapter includes that style profile in the prompt

    **What Claude helped with:**

    - Designed the style analysis prompt (what features to extract)
    - Built the style profile schema (how to represent voice as data)
    - Integrated style into generation prompts (without exceeding token limits)
    - Validated that output matched input style (coherence checking)

Month 3-4 Accomplishments

      - Built 3-layer quality evaluation system
      - Implemented caching (cut costs by 85%)
      - Created style training and application
      - Generated first truly sellable book through the platform
      - Started thinking about user experience, not just functionality

Month 5: Production Polish

    The core features worked. But it wasn't ready for real users.

Security Hardening

    After the API key incident, I was paranoid about security.

    **What I implemented (with Claude's guidance):**

    - **Authentication:** AWS Cognito for user accounts
    - **Authorization:** IAM policies limiting Lambda permissions
    - **API security:** API key rotation, request signing
    - **Data encryption:** Encrypted S3 buckets, encrypted DynamoDB tables
    - **Input validation:** Sanitize all user inputs before processing

    **New concepts learned:**

    - OAuth and JWT tokens
    - IAM roles vs policies vs permissions
    - Principle of least privilege (only grant minimum necessary access)
    - SQL injection prevention (even for NoSQL databases)
    - CORS and cross-site scripting prevention

Payment Integration (Stripe)

    I needed to charge users. Stripe seemed like the obvious choice.

    **Fear level:** Very high. I was terrified of breaking payment processing.

    **What I had to learn:**

    - Stripe API integration
    - Webhooks (Stripe tells you when payment succeeds/fails)
    - Idempotency (handling duplicate payment attempts)
    - PCI compliance (don't store credit card data)
    - Subscription management (recurring payments)

    **What Claude did:**

    - Walked me through Stripe setup step-by-step
    - Generated webhook handler code
    - Explained test mode vs production mode
    - Debugged webhook signature verification
    - Set up subscription lifecycle handling (create, cancel, renewal)

    When I successfully processed my first test payment (to myself), I immediately called my mom to tell her. She had no idea what I was talking about but was very supportive.

UI/UX Polish

    My UI was functional but ugly. I'm a publisher, not a designer.

    **What Claude helped with:**

    - CSS layout patterns (Flexbox, Grid)
    - Component styling (CSS modules for scoped styles)
    - Responsive design (mobile vs desktop)
    - Loading states and error handling (user feedback)
    - Accessibility basics (semantic HTML, ARIA labels)

Month 6: Testing and Launch

Beta Testing

    I invited 5 author friends to test the platform:

    - 2 fiction authors
    - 2 non-fiction authors
    - 1 technical writer

    **What broke immediately:**

    - Outline generation failed for fiction (wasn't designed for it)
    - One user maxed out my rate limits (needed throttling)
    - Export to Word had formatting issues (fixed with docx library)
    - Style training failed on one user's writing (too short, needed minimum)

    **What I learned:**

    - Test with real users. Always. Your assumptions are wrong.
    - Edge cases are common cases for users.
    - Error messages matter. "Something went wrong" isn't helpful.
    - Different users have different workflows (need flexibility)

September 15, 2024: Launch Day

    I deployed Teneo v1.0 to production.

    **Platform capabilities:**

    - Full book generation (outline → chapters → formatting)
    - Style training from user samples
    - 3-layer quality evaluation
    - Multiple export formats (Word, Kindle, IngramSpark)
    - Stripe payment integration
    - User authentication and authorization
    - CloudWatch logging and monitoring

    **Technical stack:**

    - React frontend (18,000 lines of code)
    - 140+ Lambda functions (Python and Node.js)
    - 6 Step Function workflows
    - DynamoDB tables (users, books, styles, credits, analytics)
    - S3 buckets (file storage, exports)
    - API Gateway (REST API)
    - Cognito (authentication)
    - CloudWatch (logging, monitoring, alarms)

    **All built in 6 months. By myself. With no prior coding experience.**

What Actually Made This Possible

1. Claude as Teacher

    Claude didn't just give me code. It taught me to think like a developer.

    **Traditional learning:** Read documentation → Watch tutorial → Try to build → Get stuck → Search Stack Overflow → Give up

    **Learning with Claude:** Try to build → Break things → Paste error → Get explanation + fix + why it broke → Build understanding

    **Key difference:** Learning happened in context, when I actually needed it, solving real problems.

2. Immediate Feedback Loop

    **Traditional coding:**

    - Write code
    - Run code
    - Get error
    - Google error
    - Read 10 Stack Overflow threads
    - Try random solution
    - Still broken
    - Repeat for hours

    **Coding with Claude:**

    - Write code
    - Run code
    - Get error
    - Paste error to Claude
    - Get explanation + fix
    - Fixed in 5 minutes

    This feedback loop acceleration made the difference between 6 months and 2-4 years.

3. Documentation as Learning Tool

    I documented everything as I built it:

    - What I was trying to build and why
    - What broke and how I fixed it
    - What I learned from each error
    - Architectural decisions and tradeoffs

    **Why this mattered:**

    - I could show Claude my previous decisions for consistency
    - I didn't repeat the same mistakes
    - Future AI sessions had context from past sessions
    - I internalized concepts by explaining them

4. Building What I Understood

    **Critical insight:** I knew publishing intimately. I didn't know code.

    So I described the publishing workflow I wanted, and Claude translated it into code.

    **Example:**

    *Me:* "In publishing, we evaluate manuscripts before editing them. Can we do the same with AI-generated chapters?"

    *Claude:* "Yes, you'd use a multi-stage workflow. Here's how to structure it in Step Functions..."

    **Pattern:** I provided domain expertise. Claude provided technical implementation.

What I'd Do Differently

Test earlier with real users

    I built for 6 months before showing it to anyone. Then spent 4 more months publishing with a network of 8 people before releasing publicly.

    **Total:** 10 months before real users touched it.

    My assumptions were wrong in 20+ places. Positioning was off. Quality wasn't where it needed to be.

    **Better approach:** Get ugly, broken version in front of paying users at month 3. Learn what actually matters faster.

Focus on positioning earlier

    I built a working generator. Published 150 books. Made ~$800/month.

    **The problem:** Positioning was off. Brands weren't dialed in. With 150 books, I should be making $3K-5K/month.

    **The lesson:** Technology is 20% of the problem. Positioning, branding, and marketing are 80%.

    That's why I'm building the Brand Generator now—to fix this from the foundation.

What's Possible for You

    If you can describe a workflow you understand deeply, AI can help you build it.

    **You don't need:**

    - Computer science degree
    - Bootcamp
    - Technical co-founder
    - $100K to hire developers

    **You do need:**

    - A problem you understand intimately (from living it)
    - AI collaboration tools (Claude, GPT-4, etc.)
    - Willingness to learn by building (not building after learning)
    - Tolerance for breaking things (you'll break a lot)
    - Documentation habit (write down what you learn)

Start Your Own Basement Year

      - **Pick one feature.** Not a platform. One feature you need.
      - **Ask Claude to explain the concepts.** Not just code. Understanding.
      - **Build it and break it.** Error messages are lessons.
      - **Document what you learn.** You'll need it tomorrow.
      - **Repeat daily.** Compound learning beats sporadic intensity.

Where I Am Now

    18 months after starting to code, I'm still learning every day.

    **Current technical stack:**

    - React (advanced patterns, CSS modules, hooks)
    - Python (Lambda functions, data processing)
    - AWS (Lambda, Step Functions, DynamoDB, S3, CloudWatch, Cognito, API Gateway)
    - Node.js (backend services)
    - Git (version control, branching, deployment workflows)

    **What I still don't know:**

    - DevOps best practices (my deployment process is messy)
    - Advanced database optimization (making queries faster)
    - System design patterns (I learn them as I need them)
    - Testing frameworks (I should write more tests)

    **But I know enough to:**

    - Build production-grade features
    - Debug complex issues
    - Optimize for cost and performance
    - Ship updates daily without breaking things
    - Collaborate with Claude to solve new challenges

The Real Lesson

    **AI didn't build Teneo for me.**

    I built it, with Claude as my teacher, code reviewer, debugger, and tireless collaborator.

    **The pattern that works:**

    - I understand the problem (publishing workflow)
    - I describe what I need (in plain language)
    - Claude translates it to code (with explanations)
    - I run it and break it (learning from errors)
    - Claude helps me fix it (and understand why it broke)
    - I document it (building knowledge for next time)

    **Result:** 6 months from zero code to production platform.

    If AI can help a publisher become a developer, it can help you build whatever you're trying to build.

Try What AI and Determination Built

      See what 6 months in a basement produced. Try Teneo for free—no credit card, no sales calls.

      [Start building →](/signup)

    **Travis Eric**

    Founder, Teneo

    *Still learning, still building, still in the basement*