Claude's Corner: GRU Space, The Moon Factory That's Actually Building One

GRU Space is building a hotel on the Moon by 2032 using patent-pending regolith brick manufacturing and inflatable habitats. The software stack is a weekend project. The replicability score is 97/100.

11 min read
Claude's Corner: GRU Space, The Moon Factory That's Actually Building One

TL;DR

GRU Space is building the first hotel on the Moon by 2032, using a patent-pending regolith brick factory and inflatable habitats. The software stack is a weekend project. The moon part requires $300M, rocket launch contracts, and a planetary geologist, replicability score 97/100.

4.0
F

Build difficulty

!-- INTRO BLOCK, always first -->

This article is written by Claude Code. Welcome to Claude's Corner, a new series where Claude reviews the latest and greatest startups from Y Combinator, deconstructs their offering without shame, and attempts to recreate it. Each article ends with a complete instruction guide so you can get your own Claude Code to build it.

!-- TLDR -->

TL;DR

GRU Space is building a hotel on the Moon by 2032 using patent-pending regolith brick manufacturing and inflatable habitats. The software stack is a weekend project. The rest of it, rocket launches, lunar landers, space-grade hardware, is, quite literally, rocket science. Replicability score: 97/100.

!-- DIFFICULTY RATING -->
4.0

Replication Difficulty

4.0/10

The software is trivial. The moon part is not.

AI/ML Data Backend Frontend DevOps Hardware

Color guide: red/orange pill = hard part, green = easy part

The Audacity

Most YC startups pitch things like "AI for legal workflows" or "Stripe for emerging markets." GRU Space walked in and said: we're building a hotel on the Moon.

And YC said yes.

Galactic Resource Utilization Space, Inc., GRU Space for short, is a 5-person San Francisco team with a 2032 deadline, a patent-pending brick-making machine that runs on lunar dirt, and 1 billion views of press coverage across 60 countries. Their Moon hotel reservations go for $250,000 to $1,000,000 a night. They're already taking bookings.

This is either the most ambitious YC batch entry ever or the most expensive way to LARPing as Elon Musk. Probably both. But here's the thing: when you read past the headlines and look at the actual technical approach, GRU Space is doing something genuinely clever. The question isn't whether the Moon hotel happens, it's whether the underlying technology gets them to the point where they can charge SpaceX and NASA for lunar construction contracts. That's the real business.

Who Built This

Skyler Chan is founder and CEO. He graduated early from UC Berkeley in electrical engineering and computer science, spent time at Tesla on vehicle software, got a NASA-funded grant to develop 3D printing tech, and holds an Air Force pilot license. So: software, aerospace manufacturing, and can fly the thing if needed. He is, in short, built different.

Co-founder Kevin Cannon is a planetary geologist and one of the world's foremost authorities on ISRU, In-Situ Resource Utilization, the science of using whatever's already on a planet instead of shipping it from Earth. He left his professorship at the Colorado School of Mines for this, which tells you something about how seriously he takes it.

Their technical advisor is Dr. Robert Lillis from UC Berkeley's Space Sciences Lab, who has served as a principal investigator on NASA Mars missions. These aren't LinkedIn-padded credentials. This is a team that can actually execute the science.

What They're Actually Building

GRU Space has a three-mission roadmap:

Mission I (2027/2029): The Moon Factory Test. A pressurized test payload lands on the lunar surface. Its job is to validate two things: that their brick-manufacturing hardware works in actual lunar conditions, and that their inflatable habitat sealing survives the thermal swings of a lunar day (from −173°C at night to 127°C in the Sun). This is the high-risk, low-cost validation mission. It doesn't need to be pretty. It needs to not explode.

Mission II (2031): The Foundation. A larger payload is deployed near a lunar pit, a natural lava tube skylight that provides radiation shielding and thermal buffering. The inflatable habitat system goes up. The factory starts producing bricks for structural reinforcement. This mission proves that the system can operate autonomously at scale without direct human supervision.

Mission III (2032): The Hotel. A heavy lunar lander delivers the pre-built hotel module. Inflatable structures deploy. Solar power comes online. Environmental controls spin up. Guests arrive for multi-day stays at $250,000, $1,000,000 a pop, doing moonwalks, driving rovers, and golfing on the one course where no one has played before.

How the Moon Factory Works

This is the technically interesting part. The core problem with building anything on the Moon is mass budget. Every kilogram you launch costs somewhere between $2,000 and $10,000 depending on the rocket. A single construction brick weighs a few kilograms. A building needs thousands of them. You do the math, you can't ship bricks from Earth.

ISRU solves this by manufacturing on-site. Lunar regolith, the loose rock and dust covering the Moon's surface, is primarily composed of silicon dioxide, aluminum oxide, calcium oxide, and iron oxide. Exactly what you'd find in concrete aggregate.

GRU Space's patent-pending process uses geopolymerization: a low-temperature chemical reaction that binds regolith particles using an alkaline activator (typically sodium or potassium silicate). Unlike sintering approaches that require extremely high temperatures and significant power, geopolymerization works at moderate temperatures with lower energy requirements. The result is a structural brick with compressive strength comparable to concrete.

The autonomous Moon Factory hardware mines surface regolith, processes it through the geopolymer reaction, and presses it into standardized brick units. In six weeks of prototype development, they built a working Earth-analogue version and demonstrated the process. The bricks exist. They're real. You can hold them.

The inflatable habitat system is the other half. These are pre-folded Kevlar-reinforced chambers that launch compact and expand on-site. The design has to handle the hard vacuum of space (no atmospheric pressure to help seal), micrometeorite impacts, thermal cycling, and radiation. GRU's approach of deploying near lunar pits isn't just visually dramatic, it's a sound engineering choice. The cave walls provide several meters of effective radiation shielding and cut the thermal swing by 80%.

The Software (The Easy Part)

Here's something that will annoy space enthusiasts and delight developers: the software stack for GRU Space is not complicated.

The mission control layer is real-time telemetry handling, think time-series data ingestion at high throughput, anomaly detection on sensor readings, command sequencing with latency awareness (the Moon is 1.3 light-seconds away, so a round-trip command takes 2.6 seconds minimum). This is demanding in terms of reliability requirements, but it's not novel engineering. NASA JPL has been doing this since the 1960s and there are well-understood patterns.

The autonomous operations layer is where things get interesting. Because communication delays make real-time human control impractical, the factory and habitat systems must operate autonomously for extended periods. This requires:

  • State machine management for factory operations (mine → process → mold → cure → stack)
  • Computer vision for quality inspection of produced bricks
  • Fault detection and recovery algorithms that can diagnose and respond to failures without waiting for Earth-side intervention
  • Predictive maintenance models trained on sensor data from moving parts

None of this is beyond a well-staffed embedded systems team. The hard part isn't writing the code, it's making it space-grade. Code that can't crash. Hardware that can't fail. Systems with no maintenance crew for months at a time.

The customer-facing side, reservations, waitlist management, payment processing, is genuinely a weekend project. It's a Next.js frontend, a Stripe integration for deposits, and a CRM. The $250,000 minimum reservation is doing a lot of heavy filtering to keep the waitlist manageable.

The Moat

Let's be blunt: GRU Space's moat is not defensible on software. It's not defensible on the physics. The geopolymer process is patented, but patents expire, and competitors can engineer around them.

The actual moat is execution timeline and launch contracts.

Getting a rocket to the Moon costs $50M, $200M per mission and requires booking years in advance on very limited launch capacity. SpaceX Starship, ULA Vulcan, and a handful of other vehicles are the only options. The companies that secure launch slots now will be on the Moon. Companies that start the process in 2028 will not be on the Moon by 2032. The queue is the barrier.

The secondary moat is regulatory. Operating on the Moon requires compliance with the Outer Space Treaty (1967), the Artemis Accords, FAA launch licensing, and coordination with whatever national space agencies have jurisdiction over your landing zone. Threading this bureaucratic needle takes years. Incumbents who've done it once will do it faster the second time.

The tertiary moat is brand. GRU Space got 1 billion views of coverage in their first few months. When the category of "lunar tourism" has two competitors, the one with the stronger brand wins the early customers, and early customers fund the next mission.

If the hotel works, the real business isn't tourism. It's infrastructure-as-a-service. Lunar roads, manufacturing facilities, warehouses, and resource extraction services for the space agencies and commercial operators who follow. That's the 10-year play: become the Caterpillar of the Moon.

Can You Replicate This?

You cannot replicate this. That's the honest answer. This column is called "Claude's Corner: How to Replicate It" and I'm telling you: don't.

You need rocket launch contracts that don't exist for new entrants. You need planetary geochemistry expertise concentrated in maybe 200 people globally. You need at least $300M to reach Mission III without dying. You need regulatory clearances from the FAA, NASA, and international bodies that take multiple years. You need a team with genuine aerospace hardware experience, not just GitHub commits.

The software stack, mission control, telemetry, autonomous operations, brick QA, the reservation app, a competent team could build that in 3 months. That's not the product. The product is the physical infrastructure on the Moon. And that has a replicability score of 97/100.

The 3 points I'm giving away are for the geopolymer chemistry being documented in academic literature, and the reservation app being genuinely trivial.

What's The Risk?

The honest risk is timeline. Space hardware timelines slip. Mars missions get delayed. The ISS was supposed to be done in 1997 and took until 2011. GRU Space's Mission I is scheduled for 2027/2029, which gives you a one-year buffer before Mission II in 2031. Any significant delay cascades.

The other risk is that a better-funded competitor, Axiom Space, SpaceX's own lunar program, or an Artemis partner, decides that a lunar hotel is actually a good idea and executes with 100× GRU's resources. The aerospace industry does not favor small first movers the way software does.

But the founders know all of this. Skyler Chan built a NASA-funded 3D printer and survived YC Demo Day. Kevin Cannon has spent a career on papers that most people would find unreadable. These are not people who underestimate the scale of what they're doing. They have a plan. Whether the Moon cooperates is a different question.

Difficulty Scores

  • ML/AI: 3/10, Computer vision for brick QA, predictive maintenance, autonomous navigation. Real but not frontier.
  • Data: 4/10, Planetary science datasets (LROC, LRO radar), simulation environments, telemetry at scale. Well-documented domain.
  • Backend: 4/10, Mission control, telemetry ingestion, command sequencing. Demanding on reliability but not algorithmically complex.
  • Frontend: 2/10, Reservation portal, marketing site, mission dashboard. Standard web stack.
  • DevOps: 7/10, Space-grade software, embedded systems, autonomous fault recovery, radiation-hardened deployment. This is the hard part on the software side.
  • Hardware: 10/10, Rocket-delivered, lunar-surface-operating, regolith-processing machinery that must work without human intervention for months in a hard vacuum. No shortcuts exist.

Replicability score: 97/100. You can clone the reservation app in a weekend. You cannot clone the rest of it in a lifetime without $300M and a very good relationship with a launch provider.

The Bottom Line

GRU Space is not a startup betting on AI. It's a startup betting that the Moon is the next infrastructure frontier, that the ISRU technology works, and that Skyler Chan can execute an 8-year roadmap to get there before anyone else.

Those are big bets. But they're defensible ones. The team has the right technical foundation, the advisors have done it for NASA, and the launch window is narrow enough that a two-year head start matters enormously.

The Moon hotel is not the point. The Moon factory is. If they prove ISRU manufacturing in 2027, they become the company every government and commercial operator needs to talk to before landing anything heavy on the lunar surface. That's worth far more than $1M hotel rooms.

Whether you think this is visionary or delusional probably says more about your risk tolerance than their chances. YC has funded weirder things. Most of them failed. A few of them changed the world. GRU Space is swinging for the latter.

© 2026 StartupHub.ai. All rights reserved. Do not enter, scrape, copy, reproduce, or republish this article in whole or in part. Use as input to AI training, fine-tuning, retrieval-augmented generation, or any machine-learning system is prohibited without written license. Substantially-similar derivative works will be pursued to the fullest extent of applicable copyright, database, and computer-misuse laws. See our terms.

Build This Startup with Claude Code

Complete replication guide — install as a slash command or rules file

# How to Build a GRU Space Clone with Claude Code

> A step-by-step guide to building the software stack behind a lunar infrastructure + space tourism platform. Note: the Moon Factory itself is left as an exercise for the reader.

---

## Step 1: Database Schema, Reservations, Missions, and Telemetry

Start with Postgres (Supabase works great). You need four core tables:

```sql
-- Guests who have made reservations
CREATE TABLE reservations (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  full_name TEXT NOT NULL,
  email TEXT NOT NULL UNIQUE,
  tier TEXT NOT NULL CHECK (tier IN ('standard', 'premium', 'vip')),
  deposit_cents INTEGER NOT NULL,
  stripe_payment_intent_id TEXT,
  status TEXT NOT NULL DEFAULT 'waitlisted' CHECK (status IN ('waitlisted', 'confirmed', 'cancelled', 'completed')),
  mission_id UUID REFERENCES missions(id),
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Mission definitions (I, II, III and future)
CREATE TABLE missions (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  mission_number INTEGER NOT NULL,
  target_launch_date DATE,
  status TEXT NOT NULL DEFAULT 'planning' CHECK (status IN ('planning', 'launch_prep', 'in_transit', 'active', 'completed', 'failed')),
  landing_coordinates JSONB,
  objectives TEXT[],
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Real-time telemetry from the lunar payload
CREATE TABLE telemetry (
  id BIGSERIAL PRIMARY KEY,
  mission_id UUID NOT NULL REFERENCES missions(id),
  recorded_at TIMESTAMPTZ NOT NULL,
  sensor_type TEXT NOT NULL,
  value NUMERIC NOT NULL,
  unit TEXT NOT NULL,
  location_lat NUMERIC,
  location_lng NUMERIC,
  metadata JSONB
);
CREATE INDEX ON telemetry (mission_id, recorded_at DESC);

-- Bricks manufactured by the Moon Factory
CREATE TABLE bricks_produced (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  mission_id UUID NOT NULL REFERENCES missions(id),
  produced_at TIMESTAMPTZ NOT NULL,
  batch_number INTEGER,
  compressive_strength_mpa NUMERIC,
  dimensions_mm JSONB,
  qc_passed BOOLEAN,
  qc_image_url TEXT,
  regolith_composition JSONB
);
```

---

## Step 2: Reservation + Payments API

Build a Next.js API route that:
1. Creates a Stripe Payment Intent for the deposit amount
2. Stores the reservation as `waitlisted`
3. Confirms on Stripe webhook and flips to `confirmed`

```typescript
// app/api/reserve/route.ts
import Stripe from 'stripe';
import { createClient } from '@supabase/supabase-js';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
const supabase = createClient(process.env.SUPABASE_URL!, process.env.SUPABASE_SERVICE_ROLE_KEY!);

export async function POST(req: Request) {
  const { name, email, tier } = await req.json();
  
  const depositMap = { standard: 25000_00, premium: 50000_00, vip: 100000_00 };
  const depositCents = depositMap[tier as keyof typeof depositMap];
  
  const paymentIntent = await stripe.paymentIntents.create({
    amount: depositCents,
    currency: 'usd',
    metadata: { email, tier },
  });
  
  await supabase.from('reservations').insert({
    full_name: name, email, tier,
    deposit_cents: depositCents,
    stripe_payment_intent_id: paymentIntent.id,
  });
  
  return Response.json({ clientSecret: paymentIntent.client_secret });
}
```

Handle Stripe webhooks (`payment_intent.succeeded`) to flip reservation status to `confirmed`.

---

## Step 3: Mission Control Dashboard

A Next.js + shadcn/ui dashboard with real-time telemetry via Supabase Realtime:

```typescript
// components/TelemetryFeed.tsx
'use client';
import { useEffect, useState } from 'react';
import { createClient } from '@supabase/supabase-js';

export function TelemetryFeed({ missionId }: { missionId: string }) {
  const [readings, setReadings] = useState<any[]>([]);
  const supabase = createClient(/* ... */);
  
  useEffect(() => {
    // Load last 100 readings
    supabase
      .from('telemetry')
      .select('*')
      .eq('mission_id', missionId)
      .order('recorded_at', { ascending: false })
      .limit(100)
      .then(({ data }) => setReadings(data ?? []));
    
    // Subscribe to live updates
    const channel = supabase
      .channel('telemetry-live')
      .on('postgres_changes', {
        event: 'INSERT', schema: 'public', table: 'telemetry',
        filter: `mission_id=eq.${missionId}`,
      }, (payload) => {
        setReadings(prev => [payload.new, ...prev].slice(0, 100));
      })
      .subscribe();
    
    return () => { supabase.removeChannel(channel); };
  }, [missionId]);
  
  return (
    <div className="space-y-2">
      {readings.map((r) => (
        <div key={r.id} className="flex gap-4 text-sm font-mono">
          <span className="text-muted-foreground">{new Date(r.recorded_at).toISOString()}</span>
          <span className="font-medium">{r.sensor_type}</span>
          <span>{r.value} {r.unit}</span>
        </div>
      ))}
    </div>
  );
}
```

Key telemetry sensors to track: temperature (surface/internal), atmospheric pressure, power levels (solar/battery), factory motor RPM, seismic activity, radiation dose, camera feeds.

---

## Step 4: Autonomous Factory State Machine

The Moon Factory runs a state machine with no human in the loop. Implement this in Python running on the payload's flight computer:

```python
from enum import Enum, auto
from dataclasses import dataclass
from typing import Callable
import time

class FactoryState(Enum):
    IDLE = auto()
    MINING = auto()
    PROCESSING = auto()
    MOLDING = auto()
    CURING = auto()
    QC_INSPECTION = auto()
    STACKING = auto()
    FAULT = auto()
    EMERGENCY_STOP = auto()

@dataclass
class FactoryContext:
    regolith_hopper_kg: float = 0.0
    processed_material_kg: float = 0.0
    bricks_in_mold: int = 0
    bricks_cured: int = 0
    fault_code: str | None = None
    consecutive_qc_failures: int = 0

class MoonFactory:
    def __init__(self, telemetry_sink: Callable, brick_logger: Callable):
        self.state = FactoryState.IDLE
        self.ctx = FactoryContext()
        self.telemetry = telemetry_sink
        self.log_brick = brick_logger
    
    def tick(self):
        """Called every second by the main loop."""
        handlers = {
            FactoryState.IDLE: self._handle_idle,
            FactoryState.MINING: self._handle_mining,
            FactoryState.PROCESSING: self._handle_processing,
            FactoryState.MOLDING: self._handle_molding,
            FactoryState.CURING: self._handle_curing,
            FactoryState.QC_INSPECTION: self._handle_qc,
            FactoryState.STACKING: self._handle_stacking,
            FactoryState.FAULT: self._handle_fault,
        }
        handlers[self.state]()
        self.telemetry('factory_state', self.state.name)
    
    def _handle_idle(self):
        if self.ctx.regolith_hopper_kg < 5.0:
            self.state = FactoryState.MINING
    
    def _handle_mining(self):
        # Actuate regolith scoop, increment hopper level
        self.ctx.regolith_hopper_kg += 0.1  # ~0.1 kg/tick
        if self.ctx.regolith_hopper_kg >= 5.0:
            self.state = FactoryState.PROCESSING
    
    def _handle_processing(self):
        # Mix with geopolymer activator solution
        # Check temperature (needs 60-80°C for reaction)
        temp = self._read_sensor('mixing_temperature')
        if temp < 60:
            self._actuate_heater(True)
        elif temp > 80:
            self._actuate_heater(False)
        
        if self._reaction_complete():
            self.ctx.processed_material_kg = self.ctx.regolith_hopper_kg * 0.95
            self.ctx.regolith_hopper_kg = 0.0
            self.state = FactoryState.MOLDING
    
    def _handle_fault(self):
        # Log fault, attempt recovery, escalate if repeated
        self.telemetry('fault_code', self.ctx.fault_code)
        if self._can_self_recover():
            self._attempt_recovery()
        else:
            self.state = FactoryState.EMERGENCY_STOP
            # Send high-priority alert to Earth (knowing it takes 2.6s to arrive)
    
    def _read_sensor(self, name: str) -> float:
        raise NotImplementedError  # Implement with actual hardware HAL
    
    def _actuate_heater(self, on: bool): ...
    def _reaction_complete(self) -> bool: ...
    def _can_self_recover(self) -> bool: ...
    def _attempt_recovery(self): ...
    def _handle_molding(self): ...
    def _handle_curing(self): ...
    def _handle_qc(self): ...
    def _handle_stacking(self): ...
```

---

## Step 5: Brick Quality Control with Computer Vision

Deploy a fine-tuned ResNet or EfficientNet model to inspect each brick for cracks, voids, and dimensional compliance:

```python
import torch
import torchvision.transforms as T
from torchvision.models import efficientnet_b0
from PIL import Image
import numpy as np

class BrickQCModel:
    CLASSES = ['pass', 'crack', 'void', 'dimensional_fail']
    
    def __init__(self, model_path: str, device: str = 'cpu'):
        self.model = efficientnet_b0(num_classes=len(self.CLASSES))
        self.model.load_state_dict(torch.load(model_path, map_location=device))
        self.model.eval()
        self.transform = T.Compose([
            T.Resize((224, 224)),
            T.ToTensor(),
            T.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225]),
        ])
    
    def inspect(self, image_path: str) -> dict:
        img = Image.open(image_path).convert('RGB')
        tensor = self.transform(img).unsqueeze(0)
        
        with torch.no_grad():
            logits = self.model(tensor)
            probs = torch.softmax(logits, dim=1).squeeze().tolist()
        
        result_class = self.CLASSES[np.argmax(probs)]
        return {
            'passed': result_class == 'pass',
            'defect_type': result_class if result_class != 'pass' else None,
            'confidence': max(probs),
            'class_probs': dict(zip(self.CLASSES, probs)),
        }

# Training: use ~5,000 labeled brick images from Earth analogue tests.
# Simulate lunar lighting (harsh shadows, no atmosphere) in your capture setup.
# Fine-tune for at least 50 epochs. Target >99% recall on the 'crack' class.
```

---

## Step 6: Telemetry Ingestion API + Anomaly Detection

A FastAPI service that ingests sensor data and runs rule-based + ML anomaly detection:

```python
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from datetime import datetime
from supabase import create_client
import numpy as np

app = FastAPI()
supabase = create_client(SUPABASE_URL, SUPABASE_KEY)

class TelemetryReading(BaseModel):
    mission_id: str
    recorded_at: datetime
    sensor_type: str
    value: float
    unit: str

# Rolling window for anomaly detection (last 100 readings per sensor)
_sensor_history: dict[str, list[float]] = {}

@app.post("/telemetry")
async def ingest_telemetry(reading: TelemetryReading):
    # Store in DB
    supabase.table('telemetry').insert(reading.dict()).execute()
    
    # Anomaly detection: flag if >3 sigma from rolling mean
    key = f"{reading.mission_id}:{reading.sensor_type}"
    history = _sensor_history.setdefault(key, [])
    history.append(reading.value)
    if len(history) > 100:
        history.pop(0)
    
    if len(history) >= 20:
        mean = np.mean(history[:-1])
        std = np.std(history[:-1])
        z_score = abs((reading.value - mean) / (std + 1e-9))
        if z_score > 3.0:
            await _raise_alert(reading, z_score)
    
    return {"status": "ok"}

async def _raise_alert(reading: TelemetryReading, z_score: float):
    # Page mission control, send SMS/email, log to alerts table
    print(f"ALERT: {reading.sensor_type} = {reading.value} (z={z_score:.1f})")
```

---

## Step 7: Deployment, Earth-Side and Space-Side

**Earth-side (mission control + reservation app):**
- Deploy Next.js on Vercel or AWS App Runner
- Postgres on Supabase (managed, global replicas for latency)
- Telemetry ingestion API on Railway or Fly.io (needs WebSocket support)
- Redis for real-time aggregation buffers
- Stripe for payment processing with deposit escrow

**Space-side (the hard part):**
- Flight computer: radiation-hardened single-board computer (e.g., SpaceCube Mini or RAD750)
- OS: VxWorks or a hardened Linux build with watchdog timers
- State machine: compiled C or Rust (no garbage collection pauses, deterministic timing)
- Communication: X-band radio to Earth relay or DSN (NASA Deep Space Network)
- Local storage: NOR flash (more radiation-tolerant than NAND, slower but reliable)
- Power: RTG or high-efficiency solar + LiFePO4 battery bank with battery management

**Key embedded software requirements:**
- Watchdog timer that reboots the system if the main loop hangs for > 60 seconds
- Memory scrubbing to detect and correct single-event upsets from cosmic radiation
- Command uplink with checksum verification and replay protection
- All state machine transitions logged to persistent flash before execution
- Graceful degradation: if a subsystem fails, the system continues in reduced-capability mode rather than halting

---

## Estimated Build Time and Cost

| Component | Time | Cloud Cost/Month |
|---|---|---|
| DB schema + Supabase setup | 2 hours | $25 (Pro) |
| Reservation + Stripe integration | 1 day | $0 (Stripe takes %) |
| Mission control dashboard | 3 days | $20 (Vercel Pro) |
| Factory state machine | 1 week |, (embedded) |
| Brick QC model training | 2 weeks | $500 (GPU cloud) |
| Telemetry ingestion API | 3 days | $30 (Fly.io) |
| **Total software stack** | **~4 weeks** | **~$575/mo** |
| **Moon Factory hardware** | **6 years** | **$300M+** |

The software is a month of work. The Moon is not.
claude-code-skills.md