Forem: Travis Wilson

I Deleted 100,000 Lines of Code to Pivot My App to Workflows (And Made It 37x Faster)

Travis Wilson — Thu, 05 Feb 2026 20:28:26 +0000

Two weeks ago, I had a data pipeline platform with separate Import and Export systems.

Today, I have a workflow engine. And it's 37x faster.

Net result: ~106,000 lines deleted. 2.5 minute operations now take 4 seconds.

Here's what happened.

The Market Told Me Something

I kept seeing the same thing on X: people sharing screenshots of their n8n workflows. Visual canvases with nodes and connections. "Here's how I automated my entire marketing pipeline." "Here's my AI agent workflow."

And I realized: that's what people want. Not "data pipelines"—workflows. Visual, connectable, shareable.

My platform could import data from S3, transform it, export to BigQuery. Powerful stuff. But nobody's posting screenshots of an import configuration form.

I wanted Flywheel to be the thing people screenshot and share. That meant pivoting from "data pipeline tool" to "workflow automation platform."

The problem? My entire architecture was built around "Import" and "Export" as separate concepts. Not nodes on a canvas. Not a visual workflow you'd want to show off.

The Architecture I Had

Two complete systems, doing almost the same thing:

Import System	Export System
`imports/handler.go`	`exports/handler.go`
`imports/service.go`	`exports/service.go`
`imports/dao.go`	`exports/dao.go`
`imports/model.go`	`exports/model.go`
`imports/subscriptions.go`	`exports/subscriptions.go`

Plus, for each of 8 data providers (S3, BigQuery, Postgres, DynamoDB, Firestore, GCS, Pub/Sub, Domo):

Import Code	Export Code
`{provider}/chunk_fetcher.go`	`{provider}/export_writer.go`
`{provider}/subscriptions.go`	`{provider}/export_subscriptions.go`

That's 16 files per provider just for the import/export split.

And the kicker? They couldn't talk to each other. Want to move data from S3 directly to BigQuery? Can't. You had to import to my system first, then export out. Two operations. Two sets of overhead. Two points of failure.

The Pivot

What if Import and Export were just... different nodes in the same workflow?

Old mental model:
  Import (External → Flywheel)
  Export (Flywheel → External)

New mental model:
  Source (read from anywhere) → Sink (write to anywhere)

A "Source" doesn't care if it's S3 or my internal storage. A "Sink" doesn't care if it's BigQuery or a file download.

Import = Source(S3) → Sink(Flywheel)
Export = Source(Flywheel) → Sink(BigQuery)
Direct ETL = Source(S3) → Sink(BigQuery) ← couldn't do this before

One unified workflow system. Not two separate systems pretending to be related.

Two Weeks, 1,310 Files

I had no users yet. No backward compatibility. No "gradual migration."

So I did the only sane thing: burn it down and rebuild.

Week 1: The Deletion

Deleted entire imports/ package (~5,500 lines)
Deleted entire exports/ package (~5,900 lines)
Deleted entire egress/ package (~1,000 lines)
Deleted per-provider import/export code across 8 providers
Deleted corresponding frontend: ImportWizard, ExportWizard, ImportList, ExportList

By end of week 1, the app didn't compile. That's fine. Dead code can't hurt you.

Week 2: The Rebuild

Created unified pipelines/ package with orchestrator
Created conditions/ package for filtering
Implemented Source/Sink capabilities for all 8 providers
Built React Flow canvas editor for visual workflow building
Wrote 700+ lines of architecture documentation

The new system has more functionality:

Direct ETL (Source → Sink, no intermediate storage)
Multi-source joins
Conditional routing
Enrichment nodes (database lookups mid-workflow)

Things that were architecturally impossible before fell out naturally from the unified model.

The 37x Speedup (This One Was Intentional)

The old architecture wasn't just duplicated—it was chaos.

Every provider had its own Pub/Sub consumer. Every provider had its own publisher. Messages were flying everywhere. Import triggers Export triggers chunk processing triggers completion handlers triggers cleanup.

I couldn't test it. I couldn't reason about it. I'd add a new provider and spend half my time debugging message flows that worked fine until they didn't.

The stress test told the story:

Old system: 2.5 minutes for 10K records
New system: 4 seconds for 10K records

The fix was simple: one orchestrator.

Instead of providers talking to each other through a spaghetti of Pub/Sub messages, the orchestrator controls everything:

Old: Provider A publishes → Queue → Provider B subscribes → publishes → Queue → ...
New: Orchestrator calls Provider A, gets data, calls Provider B, done.

The orchestrator knows the full workflow graph. It executes nodes in topological order. It handles errors in one place. It tracks progress in one place.

No more "which subscriber handles this message?" No more "why did this workflow stall?" No more "I changed one handler and broke three unrelated providers."

The 37x speedup came from:

No message queue overhead - Direct function calls instead of Pub/Sub round-trips
No intermediate storage - Stream directly from source to sink
No duplicate work - One chunking strategy, not two

I didn't optimize. I centralized control. Performance followed.

How AI Made This Possible

1,310 files in 2 weeks is not human-speed refactoring.

Pattern Enforcement

Every provider needed the same structure:

// provider.go - capability registration
func (p *S3Provider) Capabilities() []string {
    return []string{"source", "sink"}
}

// source.go - Reader implementation
func (p *S3Provider) CreateReader(ctx, config) (Reader, error)

// sink.go - Writer implementation
func (p *S3Provider) CreateWriter(ctx, config) (Writer, error)

Claude ensured all 8 providers followed this exactly. No "slightly different" implementations that would bite me later.

Blast Radius Mapping

Before deleting anything, Claude identified every file that referenced imports or exports:

47 files in the core packages
64 provider-specific files
89 test files
200+ frontend components

Nothing got orphaned. Nothing got forgotten.

Test Migration

Every deleted test had a corresponding new test. The test suite never went red during the refactor. When imports/service_test.go got deleted, equivalent coverage existed in pipelines/service_test.go.

What I Shipped

Node Type	What It Does
Source	Read from S3, Postgres, BigQuery, Firestore, GCS, DynamoDB, Pub/Sub
Transform	Modify records with JSONata expressions
Enrichment	Look up additional data from databases
Join	Combine records from multiple sources
Sink	Write to any of the above + file downloads

Users drag nodes onto a canvas, connect them, run the workflow. No "configure import then configure export" friction.

The Lesson

Deletion enables features.

The old architecture couldn't do direct ETL. It couldn't do joins. It couldn't do conditional routing. Not because I didn't want those features—because two separate systems couldn't coordinate them.

Unifying Import and Export into Source and Sink made all of that trivial.

Distributed systems are a last resort.

Every provider having its own consumer/publisher felt "scalable." In practice, it was untestable spaghetti. One orchestrator with direct control is simpler, faster, and actually works.

Don't distribute until you have to.

Early stage is the cheapest time to pivot.

This refactor would be impossible with real users. It was a complete model change. Database schema changes. API changes. Frontend changes.

If you're pre-launch and your architecture doesn't match your market positioning, now is when you fix it. The cost only goes up.

Try It Yourself Flywheel

If you're sitting on an architecture that doesn't match what users actually want:

Ask if your abstractions match user mental models. "Import/Export" was my mental model. "Workflow" was theirs.
Look for duplicate systems. If you built the same thing twice with different names, you can probably unify them.
Question your distributed architecture. If you can't easily test or reason about message flows, you probably over-distributed.
Early stage = cheap pivots. No users means no migration. Just delete and rebuild.

Sometimes the answer is mass deletion.

Have you ever pivoted your app's architecture to match market language? What triggered the change?

AI Finally Lets Startups Sweat the Small Stuff

Travis Wilson — Mon, 19 Jan 2026 14:11:25 +0000

Every startup has a graveyard of "we'll fix it later" decisions.

The animation that's slightly janky. The form that takes 4 clicks when it should take 2. The 500 utility functions that all do basically the same thing. The config system that requires updating 8 files to add one option.

We tell ourselves it's fine. Ship now, polish later. Move fast, break things.

Later never comes.

Instead, you end up with:

A codebase where fixing one bug creates two more
A "standards" doc that's really just a list of exceptions
3am alerts because the nightly job is running again and the DB is at 100% CPU
Engineers who spend more time understanding old code than writing new code

I've watched this happen at every company I've worked at. The technical debt compounds until "later" would take months.

AI Changed What "Later" Means

I'm building Flywheel solo using an AI-native codebase approach. Here's what's different:

I actually do the small things.

Not because I'm more disciplined. Because I finally have time.

Yesterday I spent 20 minutes tweaking a login page layout. Adjusting the transparency on a divider. Making the container width responsive to the form state. Small stuff.

A week ago I deleted 5,600 lines of over-engineered code and replaced it with 20 lines of config. Not because I had spare time - because Claude helped me systematically update 194 files without missing anything.

Last month I shipped a complete visual redesign in two weeks. New landing page, refined color palette, updated workflows across the entire application. That's a quarter's worth of work at most companies.

These aren't "nice to haves" I'm deferring. They're getting done now, while the context is fresh and the cost is low.

The Compound Effect of Doing Things Right

When you fix the small stuff immediately:

1. You don't accumulate exceptions.

Instead of "this works everywhere except X, Y, and Z" - it just works everywhere. No special cases to remember.

2. Your codebase stays navigable.

6 months from now, I won't be reverse-engineering my own decisions. The code says what it does because I had time to make it clear.

3. Bugs stay bugs - not symptoms.

When something breaks, it's actually broken. Not a cascade from some workaround three layers deep.

4. Onboarding stays fast.

New contributors (or future me) don't need a tour guide through the historical accidents.

Why Day 0 Matters

The best time to do things right is when you're writing the code. The context is loaded. The tradeoffs are clear. The cost is minimal.

Every day you wait, the cost goes up:

More code depends on the bad pattern
More people learn the workaround
More exceptions get documented
More tests encode the wrong behavior

AI doesn't just help you ship faster. It gives you back the time to ship correctly.

If you're starting something new in 2025, use AI from day one. Not to cut corners - to finally have time to care about the corners.

The Small Stuff I've Actually Done

Things that would have been "later" at a normal startup:

Consistent loading states across every component
Proper error boundaries with helpful messages
Animations that feel intentional, not jarring
Forms that remember your progress
One way to do each thing (not three legacy approaches)
Comments that explain why, not just what
Tests that run in seconds, not minutes

None of these are impressive individually. Together, they're the difference between software that feels maintained and software that feels abandoned.

The Real AI Advantage

Everyone talks about AI making you 10x faster.

I think the real advantage is simpler: AI makes "do it right" and "do it now" the same thing.

You don't have to choose between shipping and quality. You don't have to accrue debt you'll never pay. You don't have to explain to your future self why the code is the way it is.

You just build it properly the first time, because you finally can.

What "later" tasks are piling up in your codebase? What would you fix if you had the time?

Marketing as Code: Why My Brand Docs Live in Git

Travis Wilson — Fri, 16 Jan 2026 01:38:28 +0000

Developers are told to "build in public" and "do marketing."

But we're also told to use:

Notion for brand docs
Google Docs for content drafts
Spreadsheets for tracking
Buffer for scheduling
5 dashboards for analytics

Sound familiar?

Here's a different approach: put it all in your codebase.

The Structure

/docs/marketing/
├── brand-voice.md           # Who we are, how we talk
├── daily-checklist.md       # Today's priorities
├── competitive-analysis.md  # Positioning
└── social/
    ├── CLAUDE.md            # Guide for AI agents
    ├── devto/
    │   ├── activity-log.md  # Posts, comments, engagement
    │   └── posts/           # Drafts and published content
    ├── ih/
    │   ├── activity-log.md
    │   └── posts/
    ├── x/
    │   └── activity-log.md
    └── hn/
        └── activity-log.md

The Skill

I built a Claude Code skill that loads all of this automatically:

# marketing-persona skill

## Session Startup
1. Read /docs/marketing/brand-voice.md
2. Check /docs/marketing/daily-checklist.md
3. Search for relevant articles to comment on
4. Present today's agenda

When I invoke /marketing-persona, Claude has:

Full brand context
What I did yesterday
What worked (engagement numbers)
What's on today's list

Why This Works

Single source of truth.

No "it was in the Google Doc" vs "I thought it was in Notion." Everything is in /docs/marketing/. Period.

AI has full context.

Claude reads the activity logs. Knows what I posted last week. Knows which comments got replies. Suggests what to do next based on what's actually working.

Git history = accountability.

I can see exactly when I changed positioning. What comments I left last week. When I last updated the brand voice. It's all versioned.

Searchable.

grep -r "user123" docs/marketing/

Every interaction with that person, instantly. Try that with Slack threads.

New session = instant onboarding.

A new Claude session reads the docs and has full context in seconds. No "let me catch you up on what we've been doing."

Something to do during long tasks.

Claude Code handles big refactors and complex features that can take 10-20 minutes to run. Instead of context-switching to Twitter or refreshing my inbox, I draft and edit marketing posts. The AI writes drafts, I refine them, and by the time we're done, the refactor is complete. Productive waiting.

The Result

50 minute session today:

3 comments on relevant posts (Claude found them via web search)
Activity logs updated
Tomorrow's checklist ready

I'm not a marketer. But with the right docs + AI context, I don't need to be.

The Bigger Picture

This is part of a pattern I'm seeing: docs as the API between humans and AI agents.

/docs/marketing → AI handles content, campaigns, tracking
/docs/architecture → AI understands system to ship features
/docs/support → AI answers questions with full product context

The better your docs, the more your AI can do autonomously.

Anyone else keeping business docs in their codebase? I'm curious what other "non-code" things people are version controlling.

The Status Field That Grew Three Heads (And How We Fixed It)

Travis Wilson — Thu, 15 Jan 2026 02:16:54 +0000

I shipped a "simple" status field six months ago.

Yesterday I deleted it and replaced it with... a status field.

Here's how three fields became one, and why it took 193 files to fix a problem I created.

The Original Sin

When I first built import/export configs, the status was obvious:

type ImportConfig struct {
    Status string `json:"status"` // "draft" | "active" | "paused"
}

Clean. Simple. Done.

Then users started running imports. I needed to know if the last run succeeded or failed:

type ImportConfig struct {
    Status        string `json:"status"`        // "draft" | "active" | "paused"
    LastRunStatus string `json:"lastRunStatus"` // "success" | "failed" | "running"
}

Still manageable. Two fields, two concerns.

Then I built the wizard. Users needed to save progress mid-flow without creating broken configs. Easy fix:

type ImportConfig struct {
    Status        string `json:"status"`
    LastRunStatus string `json:"lastRunStatus"`
    IsDraft       bool   `json:"isDraft"` // wizard in progress
}

Three heads. One monster.

The Combinatorial Nightmare

Here's the problem with three fields: they create a state matrix.

Status: draft | active | paused | disabled | completed
LastRunStatus: success | failed | running | (empty)
IsDraft: true | false

That's 5 × 4 × 2 = 40 possible states.

Most of them were nonsense. What does status=active, lastRunStatus=running, isDraft=true mean?

I had no idea. Neither did my code.

The frontend had this gem:

function getDisplayStatus(config: ImportConfig): string {
  if (config.isDraft) return 'draft';
  if (config.lastRunStatus === 'running') return 'running';
  if (config.status === 'paused') return 'paused';
  if (config.lastRunStatus === 'failed') return 'failed';
  if (config.status === 'active') return 'ready';
  return 'draft'; // ¯\_(ツ)_/¯
}

That function was wrong. I just didn't know which cases were wrong.

The Recognition Moment

I was adding a new feature when I realized I couldn't answer a basic question:

"Is this import ready to run?"

The answer required checking three fields, understanding their precedence, and hoping I got the logic right.

That's when I knew: I hadn't modeled status. I'd accumulated symptoms.

The Fix: One Field to Rule Them All

The refactor was simple in concept:

Before: 3 fields tracking overlapping concerns
After: 1 field with 5 mutually exclusive states

const (
    StatusDraft   = "draft"   // Wizard incomplete, missing required fields
    StatusReady   = "ready"   // Complete config, can be run
    StatusRunning = "running" // Currently executing
    StatusPaused  = "paused"  // User paused execution
    StatusFailed  = "failed"  // Last run failed, needs attention
)

type ImportConfig struct {
    Status string `json:"status"` // One of the above. That's it.
}

No matrix. No precedence. No guessing.

"Is this import ready to run?" → config.Status == StatusReady

But Wait, What About the Wizard?

The isDraft field existed because wizards need to save partial progress.

Removing it meant solving a different problem: where does wizard state live?

Answer: in a DraftData field that only exists when Status == StatusDraft:

type ImportConfig struct {
    Status    string     `json:"status"`
    DraftData *DraftData `json:"draftData,omitempty"` // nil unless Status=draft
}

type DraftData struct {
    CurrentStep     string          `json:"currentStep"`
    PendingSchema   *PendingSchema  `json:"pendingSchema,omitempty"`
    PendingDataType *PendingDataType `json:"pendingDataType,omitempty"`
}

The key insight: pending resources live in draft data, not in real tables.

When you're mid-wizard creating a schema, that schema doesn't exist yet. It's a pending schema stored in DraftData. Only when you finalize does it become real.

No more orphaned schemas from abandoned wizards.

The Damage Report

Fixing this touched:

193 files
11,786 additions
4,179 deletions
Backend models, services, handlers
Frontend types, hooks, wizards
Tests across both

Was it worth it?

The getDisplayStatus function is now:

function getDisplayStatus(config: ImportConfig): string {
  return config.status;
}

Yes. It was worth it.

Lessons

1. State fields multiply.
One becomes two becomes three. Each addition feels small. The complexity is combinatorial.

2. "What state is this?" should be trivial to answer.
If you need a flowchart, you have a modeling problem.

3. Pending resources aren't real resources.
Wizard state is draft data, not partially-created entities.

4. Big refactors are just many small changes.
193 files sounds scary. It was really "update Status constant" × 193.

Building Flywheel - data pipelines for startups. If you've ever watched a "simple" field grow three heads, I'd love to hear your war stories.

We Deleted 5,600 Lines of Code with Claude (and Found 1 Bug)

Travis Wilson — Wed, 14 Jan 2026 01:14:02 +0000

I spent weeks building a provider registry system for my data pipeline platform. Sources, connection templates, database seeds, UUID mappings, capability checks, service arrays.

Then I deleted almost all of it.

194 files changed, 8,798 insertions(+), 14,411 deletions(-)

Net result: ~5,600 lines of code removed. One bug found after the full rewrite.

Here's what happened.

The Over-Engineered System I Built

I needed to manage providers (Google Cloud, AWS, Postgres) and their services (BigQuery, Firestore, DynamoDB). Seemed simple enough.

But I built this:

Location	What It Stored
`seeds/sources_seed.go`	Source entities with services arrays
`seeds/templates_seed.go`	ConnectionTemplate entities with schemas
`seeds/constants.go`	Hardcoded UUIDs
`frontend/components/connections/index.ts`	UUID → Component mapping
`frontend/components/connections/*.tsx`	Hardcoded `selectedServices` arrays
`frontend/lib/services/google-cloud-capabilities.ts`	OAuth scopes per service
Database (Firestore)	Sources and ConnectionTemplates collections

8+ files defining the same information in different ways.

Want to add a new provider? Touch 8 files. Want to add a service to an existing provider? 6 files. Want to understand how it all fits together? Good luck.

I told myself this was "flexible" and "extensible."

The Realization

Then I actually thought about it:

Nothing was dynamic. OAuth scopes are locked at the OAuth app level. You can't grant different scopes per connection - they're baked into the OAuth consent screen.

There was no use case for partial service access. "This Google Cloud connection has BigQuery but not Firestore" - when would that ever happen? A connection is just credentials. If those credentials can't access BigQuery, the API returns 401. Done.

I was maintaining complexity for flexibility I'd never use.

The "sophisticated" architecture was solving a problem that didn't exist.

The Replacement: 20 Lines

I had no users yet. No backward compatibility concerns. No data to migrate.

So instead of refactoring, I asked: What if I just deleted everything and replaced it with a single config file?

// frontend/lib/providers.ts
export const PROVIDERS = {
  'google-cloud': {
    name: 'Google Cloud Platform',
    auth: 'oauth2',
    services: ['bigquery', 'firestore', 'gcs', 'pubsub'],
  },
  'aws': {
    name: 'Amazon Web Services',
    auth: 'iam',
    services: ['dynamodb'],
  },
  'postgres': {
    name: 'PostgreSQL',
    auth: 'database',
    services: ['postgres'],
  },
} as const

export type ProviderId = keyof typeof PROVIDERS

That's it. ~20 lines replacing database tables, seeds, UUIDs, capability files, and registries.

The connection model went from this:

// Before: 6 fields, UUID lookups, redundant data
Connection = {
  id: 'abc123',
  sourceId: 'c7b3d8e9-5f2a-4b1c-9d6e-8a3b5c7d9e1f',  // UUID lookup
  templateId: 'template-google-cloud-oauth2',         // Another UUID
  services: ['bigquery', 'firestore'],                // Redundant
  connectionConfig: {
    selectedServices: ['bigquery', 'firestore'],      // Duplicate
    projectId: 'my-project',
  },
  credentials: {...}
}

To this:

// After: 4 fields, string ID, no redundancy
Connection = {
  id: 'abc123',
  providerId: 'google-cloud',           // Just the key from PROVIDERS
  config: { projectId: 'my-project' },  // Provider-specific config
  credentials: {...}
}

How Claude Made This Possible

This wasn't "let Claude write some code." This was AI-assisted architecture surgery.

1. Mapping the Blast Radius

I gave Claude the codebase context and asked it to find every file that referenced the old system. It identified:

All imports of the old types
All usages of the UUID constants
Frontend components using sourceId or templateId
Test files that would need updates
The order of operations to avoid breaking intermediate states

2. Systematic Execution

194 files is a lot to change by hand. More importantly, it's a lot to change correctly. Claude worked through them methodically:

Backend (Go):
- connections/model.go    → Remove Services, TemplateId; add ProviderId
- connections/service.go  → Update creation/validation logic
- connections/handler.go  → Update API request/response
- connections/dao.go      → Update Firestore queries
- router.go               → Remove /v1/sources/* routes
- Delete entire sources/ package (9 files)
- Delete entire connectiontemplate/ package (10 files)
- Delete seeds/sources_seed.go, templates_seed.go

Frontend (TypeScript):
- lib/providers.ts        → New static config (the 20 lines)
- hooks/use-source.ts     → Deleted
- hooks/use-connection-template.ts → Deleted
- services/source-service.ts → Deleted
- services/google-cloud-capabilities.ts → Deleted
- Update 40+ component files using the old types

3. Updating Tests in Lockstep

This is the key: we didn't delete tests, we updated them.

Every service change came with corresponding test updates. When we deleted the sources/ package, we also deleted its tests. When we simplified the connection model, we updated the connection tests.

The test suite stayed green throughout the refactor.

Why Only 1 Bug?

After changing 194 files, we found exactly one bug in end-to-end testing.

That's not luck. That's what happens when:

1. You have comprehensive test coverage.

Tests catch regressions immediately. When I changed the connection model, tests told me exactly which handlers and services needed updates.

2. You refactor with tests, not after.

Every change included its test updates in the same commit. Tests weren't an afterthought.

3. AI helps you be systematic.

Claude doesn't forget to update a file in some distant corner of the codebase. It doesn't get tired after file 80 and start making mistakes.

4. You have a clear architectural vision.

I wrote a detailed plan document before touching code. The target state was unambiguous: one config file, string-based provider IDs, no services arrays on connections.

What I Learned

Complexity is a choice

I built the complex system. Nobody forced me to create UUID-based lookups and database seeds for static data. I did that because it felt "proper."

Sometimes the proper solution is a 20-line config file.

AI is best for architecture, not just autocomplete

The value wasn't "Claude wrote code faster." The value was:

Claude helped identify all the tentacles of the old system
Claude maintained context across 194 files
Claude was systematic where I would have gotten tired

Well-tested code enables fearless deletion

I could mass-delete code because I trusted my tests. Every deletion was validated. No "I think this is safe" - either tests passed or they didn't.

No users = no excuses

Having no users yet meant I had no excuse to keep complexity around. No backward compatibility. No migration scripts. Just delete and move on.

If you're early stage and carrying technical debt, now is the cheapest time to fix it.

The New Developer Experience

Adding a new provider:

Add entry to PROVIDERS config (1 line)
Create connection form component
Create service config components
Create backend handlers

Adding a service to existing provider:

Add to PROVIDERS[providerId].services array (1 line)
Create service config components
Create backend handlers

No seeds. No migrations. No UUIDs. No template entities.

Try It Yourself

If you're staring at a system that feels heavier than it needs to be:

Ask what problem it's solving. Is that problem real or hypothetical?
Check if anything is actually dynamic. If the "flexible" parts never flex, they're just complexity.
If you have good tests, trust them. They'll catch your mistakes.
Use AI to map the blast radius. It's better at finding all the references than you are.

Sometimes the answer is mass deletion.

Have you ever deleted a system you built because you realized it was over-engineered? What helped you make that call?

I Built a Full AWS S3 Integration in Under 2 Hours—From First Prompt to Production

Travis Wilson — Mon, 12 Jan 2026 20:39:57 +0000

Recently I added complete S3 support to Flywheel—import and export, multiple file formats, chunked processing for large datasets. From first prompt to deployed in production: 1 hour 51 minutes.

Not because I'm fast. Because my codebase is designed for AI to extend it.

Here's exactly what I typed and what happened.

The Setup

Flywheel already had AWS support for DynamoDB. I wanted to add S3. Same provider, new service. In a traditional codebase, this would mean:

Remembering how DynamoDB was implemented
Finding all the files that need to change
Copy-pasting and modifying boilerplate
Hoping I didn't miss a registration somewhere

Instead, I have a /provider-setup skill—a structured prompt that knows our patterns, templates, and conventions.

The Prompts

Prompt 1: Kick it off

using /provider-setup lets plan out the work for reading from/to S3

Claude read the skill file, checked our existing AWS patterns (DynamoDB), and asked two clarifying questions: file formats and export mode. I answered "JSON + CSV, batch files." It created a checklist and showed me the implementation plan.

Prompt 2: Ship it

lets go for it

Four words. Over the next ~25 minutes, Claude generated the full stack—Go backend (handlers, services, event handlers), TypeScript frontend (config forms, bucket selection), plus all the wiring.

10:31 PM — Preview endpoint working, listing S3 files in the UI
10:34 PM — Full import complete, 12 records pulled from S3

Prompt 3: Bug fix

Export failed. I pasted the error:

PermanentRedirect: The bucket you are attempting to access
must be addressed using the specified endpoint

Claude identified it immediately: S3's ListBuckets is global, but writes need regional endpoints. Fix: call GetBucketLocation per bucket, auto-select region. 10:40 PM — Export working.

Prompts 4-5: Refinements

If we already get the region from the bucket list why even show the region selector?

does buckets even need the region query param?

Claude agreed with both. Removed the redundant UI, made the API param optional. Simpler UX, cleaner API.

The Timeline

Time	Milestone
10:00 PM	Started
10:05 PM	Requirements gathered, plan approved
10:31 PM	Preview endpoint working
10:34 PM	Full import complete
10:40 PM	Export complete
10:45 PM	Refinements done
11:44 PM	Passed `/check`, CI pipeline running
11:51 PM	Deployed to production

Total prompts: 5
S3 implementation: 45 minutes
Time to production: 1 hour 51 minutes (included fixing an unrelated issue from a previous release)

The finished S3 integration: import → transform → export, all at 100% success rate

Why This Works

This isn't about AI being magic. It's about the codebase being ready for AI.

1. Ruthless consistency

Every provider follows the same structure. Same files, same patterns, same naming conventions. Claude learned DynamoDB once—S3 was just "do that again for a different service."

For example, every provider package in our Go backend has the same shape:

backend/main/{provider}/
├── model.go           # Config structs, validation
├── service.go         # Business logic, import/export handling
├── handler.go         # HTTP endpoints
├── chunk_fetcher.go   # Pagination for imports
├── export_writer.go   # Batch writing for exports
├── subscriptions.go   # Event handlers
└── helpers.go         # Client creation, utilities

When Claude sees "add S3 support," it knows exactly what files to create and where they go. No guessing.

2. CLAUDE.md as the single source of truth

At the root of the repo, there's a CLAUDE.md file (~300 lines) that explains:

Project architecture and conventions
Common patterns (React Query keys, toast notifications, state management)
Where to find detailed docs for specific domains
Critical rules

Here's a snippet:

## Core Principles

### Architecture Rules
- **Edge-to-Service Pattern**: Handlers and subscriptions MUST delegate to service layer
- **Dual Records**: External records from sources + canonical normalized records
- **EBAC Authorization**: Entity-based access control with role and entity-specific permissions
- **Event Constants**: Always use pubsub package constants, never strings

### React Query Keys
['organizations']                    // List
['organizations', orgId]             // Single
['organizations', orgId, 'members']  // Related

This isn't documentation for humans—it's context for AI. Claude reads it at the start of every session and immediately knows how we do things.

3. Skills for repeated workflows

Skills are markdown files in .claude/skills/ that encode multi-step workflows. The /provider-setup skill is about 500 lines and includes:

A decision tree for gathering requirements
Patterns for different provider types (databases vs. object storage vs. message queues)
Checklists of all files that need to be created
Templates showing our conventions
References to existing implementations for context

Here's what the workflow section looks like:

## Workflow

### Step 1: Gather Requirements
Ask the user to clarify:
- Provider name (e.g., "mongodb", "s3")
- Capabilities: Import only, Export only, or Both
- Connection credentials needed
- Data access pattern (table-based, file-based, query-based)

### Step 2: Check Existing Patterns
If adding to an existing provider (e.g., S3 to AWS):
- Check for shared patterns (auth, region selection)
- Reuse existing components, don't duplicate

### Step 3: Initialize Checklist
[... creates a todo list of all required files ...]

I'm constantly iterating on this skill—every integration teaches me something new to add. But now every new integration starts from the same playbook.

4. Small, focused prompts work

Notice I didn't write detailed specifications. I said "lets go for it" and let Claude execute the plan it had already created. When there was a bug, I described what I observed, not what I thought the fix should be.

The codebase has enough structure that Claude can fill in the gaps correctly.

5. A `/check` skill for validation

Before any commit, I run /check --run-all. This skill:

Runs linting and type checks
Runs tests
Checks if documentation needs updating
Flags when marketing content should be created (like "you just shipped a feature, maybe write about it")

One command catches issues before CI. It's not just about code quality—it's about making the whole workflow predictable.

What I'd Tell Other Devs

If you're using AI coding tools daily, your codebase is now a prompt. You can fight that or optimize for it.

Start with:

Consistent file structure - Same files in the same places
A CLAUDE.md - Or whatever your AI tool uses for context
Document conventions explicitly - Don't rely on tribal knowledge
Create skills for repeated work - This is the multiplier. A /provider-setup skill means every new integration starts from the same playbook. A /check skill means code quality is one command. The upfront investment pays back every time.

The 40-minute S3 integration wasn't a one-time trick. It's how we work now. GCS took about the same. Firestore was similar. The pattern compounds.

Try This Yourself

Next time you're about to build something repetitive:

Document the pattern you're following
Create a checklist of all the files/registrations needed
Put it in a skill file or prompt template
Let AI execute while you review

The first time takes longer. Every subsequent time is under 2 hours to production.

Building Flywheel in public. Follow along on X/Twitter or Indie Hackers.

How strong fundamentals + AI helped me build a data pipeline platform in 6 months (solo)

Travis Wilson — Sun, 11 Jan 2026 04:38:46 +0000

I'm Travis, a staff engineer with 12+ years building data pipelines at various companies. Six months ago, I started building Flywheel - a data pipeline platform for startups. I'm a solo founder, working evenings and weekends.

Progress has been faster than expected. Not because of some secret productivity hack, but because of a combination I didn't expect: boring software fundamentals paired with AI-assisted development (specifically Claude from Anthropic).

Why Fundamentals Matter More With AI

When I started, I made a deliberate choice to invest in foundations before features:

Infrastructure as Code (Terraform) - Every piece of GCP infrastructure is codified
Event-Driven Architecture - Pub/Sub for all async operations, clean separation of concerns
Service Layer Pattern - Handlers delegate to services, business logic is isolated and testable
Consistent Conventions - Every domain follows the same structure

This felt slow at first. But here's the thing: AI tools like Claude are force multipliers for clean codebases.

When your architecture is consistent, Claude can:

Generate new endpoints that follow your existing patterns
Write tests that match your testing conventions
Refactor safely because tests catch regressions
Understand context faster because the code is organized

In a messy codebase, AI suggestions are often wrong or inconsistent. In a clean codebase, they're usually right.

What I Built

Flywheel is a data pipeline platform designed for early-stage startups:

Connect sources (databases, APIs, files)
Transform and normalize data
Export to warehouses (BigQuery, PostgreSQL, Domo, etc.)
Real-time monitoring and scheduling

It's the kind of infrastructure that typically takes a team 12-18 months. I built the core in 6 months, solo, while working a full-time job.

Current stats:

4,366 tests (2,471 backend + 1,895 frontend)
Test suite runs in under a minute
Merge to deployed: ~7 minutes with full build

On top of the unit tests, I've built a solid end-to-end test suite for the backend that exercises the full system. Now I'm working with Claude Code's built-in Playwright agent to build out a frontend end-to-end suite. The goal: release quickly and confidently. Tests aren't just about catching bugs - they're what let me ship fast without second-guessing everything.

I also lean heavily on Claude Code's built-in agents like code-explorer (for understanding unfamiliar parts of the codebase), code-reviewer (catches issues before I commit), and code-architect (helps plan features that fit existing patterns). These aren't magic - they work because the codebase is consistent enough for them to understand.

The Claude Workflow (What It Actually Looks Like)

I'm not using AI to replace thinking - I'm using it to break down complexity and maintain velocity.

1. Decompose the idea

I start with a high-level feature idea - like a visual flow graph for pipelines - and work with Claude to break it into manageable chunks.

Real example: A friend's company needed to sync CSV files from S3 to Domo, with Flywheel handling the column name → ordinal mapping. Sounds simple, but it required building out: S3 source support, Domo destination support, CSV parsing, and ordinal column handling.

I worked with Claude to decompose this into a plan with clear chunks. Each chunk becomes its own focused task.

2. Right-size the work

Here's something I learned the hard way: context windows matter. Go outside them and things get messy.

I use my experience to prioritize what to build first, then have a fresh agent break each chunk into what fits well in one context window. This keeps Claude focused and prevents the drift you get in long sessions.

3. Manual test, then write tests

I test manually first because I want to iterate quickly. Once I'm happy with how something works, then I have Claude write the tests to lock it in.

I also built a /check command - scripts that verify everything: tests passing, docs up to date, linting clean. It's my safety net between chunks.

4. Simplify at the end

Once a feature is complete and tests are green, I run a code-simplifier pass. Because we've built up tests along the way, refactoring is safe. This is where the clean codebase pays off - Claude can refactor confidently.

5. Refactor continuously

Every new feature that touches existing code is an opportunity to clean up. Small refactors. Better names. Clearer abstractions. It feels slow, but it's what keeps the codebase "AI-friendly" over time. Lazy shortcuts compound into a mess that even AI can't help you with.

6. Bugs happen (here's how I handle critical ones)

Do I commit bugs? Absolutely. But when a critical bug escapes that never should have - I don't let Claude just fix it. I make it write a test that reproduces the bug first. Then I verify the suggested fix manually.

This turns every escaped bug into a permanent regression test.

What Didn't Work

Letting AI make architectural decisions - Every time I let Claude "figure out" the structure, I ended up refactoring later. I design, Claude implements.
Long sessions without fresh context - Agent drift is real. Fresh context windows keep things clean.
Over-engineering early - Even with AI help, simpler is still better.

Why This Might Matter to You

If you're building something solo (or with a tiny team), you've probably wondered whether AI tools are actually useful or just hype. My take: they're a multiplier, not a replacement. They multiply whatever you already have - good or bad.

If your codebase is inconsistent, AI gives you inconsistent suggestions. If you don't know what good looks like, you can't evaluate what it produces. But if you've got experience and a clean foundation, AI lets you move at a pace that wasn't possible before.

The 12+ years in software learning what works (and what doesn't) is what makes Claude useful. Not the other way around.

Key Takeaways

Invest in fundamentals before features - IaC, event-driven architecture, clean patterns pay dividends
AI multiplies your existing skills - Experience means I know what good looks like. Claude helps me get there faster.
Context windows are a feature, not a bug - Fresh agents for each chunk keeps work focused
Tests after manual verification - Confirm it works, then lock it in with tests
Refactor continuously - Every feature is an opportunity to clean up. This keeps AI effective long-term.
Bugs become regression tests - Every escaped bug makes the system stronger

What's Next

Flywheel is in alpha - free to use while I build it out. If you're an early-stage startup that needs data pipelines without building infrastructure from scratch: flywheeletl.io

Has anyone else found that AI tools work better (or worse) depending on code quality? I'm curious if others have experienced this "fundamentals + AI" multiplier effect.

Forem: Travis Wilson

I Deleted 100,000 Lines of Code to Pivot My App to Workflows (And Made It 37x Faster)

The Market Told Me Something

The Architecture I Had

The Pivot

Two Weeks, 1,310 Files

The 37x Speedup (This One Was Intentional)

How AI Made This Possible

Pattern Enforcement

Blast Radius Mapping

Test Migration

What I Shipped

The Lesson

Try It Yourself Flywheel

AI Finally Lets Startups Sweat the Small Stuff

AI Changed What "Later" Means

The Compound Effect of Doing Things Right

Why Day 0 Matters

The Small Stuff I've Actually Done

The Real AI Advantage

Marketing as Code: Why My Brand Docs Live in Git

The Structure

The Skill

Why This Works

The Result

The Bigger Picture

The Status Field That Grew Three Heads (And How We Fixed It)

The Original Sin

The Combinatorial Nightmare

The Recognition Moment

The Fix: One Field to Rule Them All

But Wait, What About the Wizard?

The Damage Report

Lessons

We Deleted 5,600 Lines of Code with Claude (and Found 1 Bug)

The Over-Engineered System I Built

The Realization

The Replacement: 20 Lines

How Claude Made This Possible

1. Mapping the Blast Radius

2. Systematic Execution

3. Updating Tests in Lockstep

Why Only 1 Bug?

What I Learned

Complexity is a choice

AI is best for architecture, not just autocomplete

Well-tested code enables fearless deletion

No users = no excuses

The New Developer Experience

Try It Yourself

I Built a Full AWS S3 Integration in Under 2 Hours—From First Prompt to Production

The Setup

The Prompts

Prompt 1: Kick it off

Prompt 2: Ship it

Prompt 3: Bug fix

Prompts 4-5: Refinements

The Timeline

Why This Works

1. Ruthless consistency

2. CLAUDE.md as the single source of truth

3. Skills for repeated workflows

4. Small, focused prompts work

5. A /check skill for validation

What I'd Tell Other Devs

Try This Yourself

How strong fundamentals + AI helped me build a data pipeline platform in 6 months (solo)

Why Fundamentals Matter More With AI

What I Built

The Claude Workflow (What It Actually Looks Like)

1. Decompose the idea

2. Right-size the work

3. Manual test, then write tests

4. Simplify at the end

5. Refactor continuously

6. Bugs happen (here's how I handle critical ones)

What Didn't Work

Why This Might Matter to You

Key Takeaways

What's Next

5. A `/check` skill for validation