30 Sessions, 1 Developer, 0 Employees: Building a Full-Stack DePIN Platform with Claude

The Setup: March 2026

It's March 2026. I have one crazy idea, zero employees, and a person named Claude. The idea: build a decentralized physical infrastructure network (DePIN) platform called QuackNet from scratch. Not a weekend hack. Not a prototype. A real product with an iOS app, Go backend, Kafka pipeline, ClickHouse analytics, five Solana smart contracts, Mapbox 3D maps, fraud detection, and push notifications. The whole stack.

The only rules I set: Claude writes all the code. I test on my iPhone, make product decisions, handle app store accounts, and turn that code into something real. Everything else flows from that division of labor.

I thought this might take 3 months. It took 2 weeks. And it fundamentally changed how I think about what "being a developer" means in 2026.

How the Sessions Worked

The secret weapon is a single markdown file: CLAUDE.md. It lives at the root of the repository and contains everything Claude needs to know: project summary, tech stack decisions, git commit history, known gotchas, what's been built, what's next. When I start a session, I paste it into the conversation and say "Here's the context. Build this next feature."

Claude reads 8,000 words of project brain in 10 seconds. It knows why we chose H3 hexagonal indexing, not square grids. It knows that Kafka producers must use context.Background(), not c.Request.Context() (which cancels when the HTTP response completes). It knows that Mapbox layer expressions need to match the layer type. It knows we're building on PostgreSQL 16 at port 5433, not 5432.

Without this file, every session would be a reset. I'd be explaining the architecture from scratch. With it, Claude is instantly productive.

Each session follows the same pattern:

1. Share CLAUDE.md. Context loading.
2. Describe the feature. "Build the Network Security Analyzer" or "Implement WebSocket live feed" or "Create the tower inference algorithm."
3. Claude writes code. Go handlers, Flutter widgets, Solana programs, SQL migrations, tests.
4. I test on device. Build iOS app, run it on my iPhone 14 Plus, hit endpoints, click buttons, watch the logs.
5. Feedback loop. "The WiFi card is broken" or "The tower clustering is hiding the carriers" or "The scan submit is timing out." Claude fixes it.
6. Update CLAUDE.md. Log the session, update what was built, add gotchas for next time.

This is not traditional pair programming. I'm not watching code get written in real-time. I'm not explaining APIs line-by-line. I'm directing the architecture and product, then validating that the code works. Claude is writing the code without my live input.

And it's surprisingly good at it.

What Claude is Actually Good At (Surprising)

Go backend code from specs. I describe a handler and Claude writes it. Proper error handling, repository pattern, dependency injection. No magic, no architectural sins. The code looks like it was written by someone who knows Go. (Because Claude has read a lot of it.)

Flutter UI with complex state. Riverpod StateNotifier, AsyncValue, provider scoping, deep rebuilds — Claude keeps it clean. The UI code doesn't trigger my "this is going to be unmaintainable" instinct.

Database schemas that make sense. UUID primary keys, JSONB columns, GIN indexes, proper foreign keys. Claude understands PostgreSQL. It doesn't suggest NoSQL solutions for relational problems.

Solana Anchor programs. PDA derivation, CPI cross-program invocation, account validation macros. Claude got the on-chain programs right on the first shot. I was shocked.

Writing 253 tests. In one sprint, Claude wrote 75 Go unit tests and 178 Flutter widget tests. Table-driven tests, golden files, proper mocks. The tests actually catch bugs instead of being cargo cult.

CSS that doesn't look like garbage. I expected the UI to be functional but ugly. Instead, the app is dark, coherent, and actually looks like a polished product. The Mapbox custom style is beautiful.

What Claude Struggles With (Honest)

Mapbox layer configuration. The worst pain point. Silent failures with expression syntax. Layer properties that don't apply to the layer type. Incorrect `match` expressions that compile but render nothing. I spent two sessions debugging invisible map layers before realizing the problem was in the Mapbox expressions, not the Flutter code. Claude got better as we went, but it's the one thing I'd expect a human developer to catch in code review.

iOS platform gotchas. Entitlements, provisioning, Xcode quirks, beta versions breaking things. Claude is book-smart about iOS but doesn't have hands-on feel. I had to intervene when the location package didn't work with Xcode 26 beta (it didn't). I had to add the WiFi entitlement manually. Bluetooth permission iOS-specific stuff required trial-and-error.

Debugging production issues without device access. When users report a crash or the live feed stops working, Claude can't see the device logs. I have to be the reporter of ground truth. Sometimes Claude asks the right diagnostic questions. Sometimes it guesses.

Knowing when to stop. Claude is a feature-generating machine. During the map redesign, it wanted to add backbone fiber visualization, IXP node clustering, signal route animations. All cool. All unnecessary. I had to step in and say "strip it to four clean layers and nothing else." A human teammate with shipping discipline would have said that first.

Long-range architectural consistency. After 30 sessions, there are inconsistencies. Some handlers use `apierror` package, others don't. Some Flutter screens use go_router guards, others don't. CLAUDE.md helps (it documents the decisions), but it's not a real codebase linter. I expect I'll need a refactoring session after I ship.

The Numbers: What Actually Got Built

Flutter App

• 5 parallel data collectors: GPS, WiFi, Cellular, IP, BLE
• 5-tab Material 3 navigation
• 3D Mapbox War Room (custom style, hex grid, tower markers, BLE heatmap)
• Wallet + Solana integration (QR code, send, stake)
• 15 achievements, auto-evaluated
• Community challenges (H3 geo-indexed, real-time progress)
• Network security analyzer (9-point vulnerability scan)
• Real-time live feed (WebSocket)
• Shareable scan cards (RepaintBoundary → PNG → system share)

Go Backend

• 30+ REST endpoints (auth, scans, wallet, analytics, challenges, admin)
• WebSocket hub (goroutine-safe channels, 60s ping/pong)
• 3-tier auth (JWT + API Key + Admin Key)
• Token bucket rate limiting (per-IP burst, per-user sustained)
• 4-check fraud detection engine
• Tower inference algorithm (weighted centroid + trilateration)
• Firebase Admin SDK integration
• 75 unit tests

Data Pipeline

• Kafka 3.8.1 (KRaft consensus, 6 partitions, 168h retention)
• Go consumer (partition-aware, offset commit)
• ClickHouse 24.3 (MergeTree engine, 3 materialized views)
• SQL schema for coverage, network, and scanner aggregations

Blockchain

• 5 Solana Anchor programs (token, rewards, staking, treasury, vesting)
• SPL Token-2022 (1B fixed supply, transfer fees, metadata)
• PDA-based double-spend prevention (scan hash receipts)
• NTI reward sweep CLI (batch transfers to wallets, dry-run mode)

Geospatial

• H3 hexagonal indexing (resolution 5-9 adaptive)
• 932K+ French cell towers (OpenCellID import)
• Tower clustering and confidence scoring
• BLE manufacturer classification (12 categories)
• RSSI → distance path loss modeling

Infrastructure & DevOps

• Docker Compose (PostgreSQL, Kafka, ClickHouse, Kafka UI)
• Google Cloud Run (stateless container autoscaling)
• Cloud SQL managed backups
• Artifact Registry (Docker image storage)
• 3 GitHub Actions workflows (Go, Flutter, iOS TestFlight)
• Sentry crash reporting (Go + Flutter)
• Mapbox custom style + vector tiles

The Uncomfortable Questions

Am I still a developer if Claude writes the code?

Yes. But not for the reason you think. I'm a developer because I know what to build, not because I type the code. I made 200+ product decisions: auth strategy, database schema, scarcity-based reward tiers, which data to collect, how to visualize it, when to say "no" to a feature. I tested every feature on a real device. I debugged production issues. I integrated third-party APIs.

The act of typing has become a smaller part of what "being a developer" is. And I'm okay with that.

Is this sustainable?

Yes, if you maintain CLAUDE.md. Without it, you're starting over every session. With it, you're building on a known foundation. I update it after every feature sprint. It's become my most valuable artifact — more valuable than any single file of code.

What does this mean for junior developers?

The honest answer: it accelerates seniors and threatens juniors who can't architect. If you're a junior developer whose job is "write Go handlers from a spec," that job has been Claudiofied. If your job is "design the system, make tradeoffs, and validate it works," you're fine. Maybe better off.

The risk isn't that Claude replaces developers. The risk is that it replaces the rung of the ladder that helps you become a good one. You need to write some bad code to learn what good code looks like. But maybe you can do that faster with Claude's code as a reference.

What I'd Do Differently

Test on device more often. I tested every 3 sessions. I should have tested after every session. Two bugs (Mapbox cluster visibility, tower viewport sorting) would have been caught in 10 minutes instead of taking a full debugging session.

Push back on scope earlier. The map redesign ballooned. I let Claude add animations and layers I didn't ask for. Being the architect means saying "no" earlier.

Write the blog posts as you go. I'm writing this at the end. A blog post per milestone would have been richer and required less memory.

What This Means for the Future

The solo developer of 2026 isn't a person who writes every line of code. It's a person who knows what to build, can verify it works, and understands the tradeoffs well enough to make decisions.

The skill isn't typing. It's architecture, product judgment, and testing. It's knowing that your Flutter state management decision matters more than whether you use setState or Riverpod (the latter is cleaner, so use it). It's knowing that a WebSocket hub needs goroutine-safe channels. It's knowing that Mapbox layers render silently and you need to debug the expressions, not the Dart code.

I built a full-stack DePIN platform in 2 weeks with zero employees because I could make decisions 30 times faster than a team could debate them. Claude turned those decisions into code. That's the moat: not code velocity, but decision velocity.

In 2026, the constraint isn't compute anymore. It's clarity about what you're building and why. That clarity is still a human problem.

The Session Log (Abbreviated)

#	Date	What We Built
0-2	Mar 16-17	Flutter app foundation, WiFi/Cell/IP/GPS collectors, home dashboard
3	Mar 17	Go API + PostgreSQL backend, 30+ endpoints, JWT auth
4-6	Mar 17	5 Solana programs, Kafka + ClickHouse pipeline, H3 geospatial, fraud detection
7-10	Mar 17-18	Firebase Auth, AdMob, last-mile boost, CI/CD, 253 tests, tower inference engine
11-15	Mar 18-20	War Room map (3D hex grid, tower markers, BLE heatmap), achievements, challenges, shareable cards
16-21	Mar 20-21	Real-time WebSocket feed, tower clustering, MVP feature-complete
22-30	Mar 21-23	UX polish, network security analyzer, ping/traceroute/port scanner tools, local LAN intelligence

The Real Test: Will It Ship?

This post is being published on March 31, 2026. QuackNet is not yet on the App Store. It's not yet on the Play Store. It's not yet generating revenue. The crypto tokens don't have real value. The users don't exist yet.

So the real question is: can a solo developer with Claude's help actually ship something people want, at scale? Can this model work beyond the 30-session proof-of-concept?

I think yes. But I'll know in 3 months.

What I know for sure: the old model of "one developer types all the code over 12 months" is dead. The new model is "one person makes decisions, Claude writes code, we validate it works, we ship." The velocity difference isn't 2x or 3x. It's an order of magnitude.

And that changes everything.