Foundercraft

Turn a raw idea into a real venture—and learn the skills to make it successful. From idea to venture. From founder instinct to founder craft.

Comment

Inspiration

"I don't just want to build an app. I want to build a business—and learn the skills to make it successful."

This recurring sentiment from first-time founders is the core inspiration behind Foundercraft. Today, building software with AI is more accessible than ever. However, the true bottleneck to success isn't writing code—it's founder judgment. Aspiring entrepreneurs often alternate between unstructured AI chatbots, scattered advice communities, blank templates, and premature prototype-building. These tools can produce output, but they fail to preserve evidence, challenge reasoning, or make the next learning step obvious.

Foundercraft realized that founders don't need an AI cofounder to make decisions for them; they need an AI-native school that helps them develop their own judgment. Foundercraft is the place where founders learn the craft of finding an opportunity, designing a business, building a product, and taking it to market—all by actively building their own venture.

What it does

Foundercraft is an AI-native learning studio that turns rough, tech-enabled venture ideas into well-reasoned, build-ready businesses. It replaces generic AI chat with a structured, artifact-led workspace.

Key features include:

  • Opportunity Signal: Founders start with a raw idea. The system parses it. Every inference is revisable, and correction is treated as visible founder progress.
  • The Value Engine: An interactive lesson where founders model business value, test assumptions about price, cost and willingness to pay and make judgment calls on a worked case before applying it to their venture.
  • Evidence Lens & Builder Craft: Founders record claims, countercases, and decisive tests. They also design bounded AI capabilities, turning vague agent ideas into apps or workflows with clear inputs, failure modes, and rubrics.
  • Codex / MCP Integration: Through the Model Context Protocol (MCP), founders can continue their venture work seamlessly in their IDE via Codex, with full state parity between the web app and the editor.

Foundercraft ensures a founder leaves with a commercially literate venture rationale and a spec-driven build package, not just a prototype.

How we built it

We architected Foundercraft for resilience, speed, and strict domain integrity. It is built as a TypeScript workspace on Google Cloud Platform (GCP) with two stateless Cloud Run services:

  1. Frontend (Web): A Next.js App Router application providing a fast, Server-Side Rendered (SSR) interactive studio. We prioritized SSR to ensure a robust first-session experience without a client-side loading waterfall.
  2. Core API: A Fastify API that acts as the single source of truth for domain commands. It handles HTTP requests from the web and Streamable HTTP requests via MCP.
  3. Database: PostgreSQL on Cloud SQL, accessed via Drizzle ORM. We deliberately chose a relational database over document stores (like Firestore) because venture development requires relational ownership, revision history, and evidence tracking.
  4. AI Integration: We integrated Vertex AI (Gemini) through a provider adapter to generate structured JSON outputs for synthesis, rubrics, and feedback. Crucially, the system never silently upgrades an AI assumption into "customer evidence."

We strictly adhered to a Specs-First, Test-Driven Development (SDD-TDD) approach, governed by a project constitution that enforced parity between web and MCP commands for most of the core features.

Challenges we ran into

Building a platform that balances AI assistance with human agency presented several deep technical and product challenges:

  • State Parity Across Interfaces: Ensuring that a change made in the Next.js web app instantly reflected in the Codex IDE (via MCP) required strict architectural discipline. We solved this by forcing both adapters to use the exact same typed domain commands and Zod schemas, with no independent state living in the UI layer.
  • Preventing AI Sycophancy: Generic LLMs tend to praise bad ideas. We had to build evaluation fixtures and strict provider adapters to ensure the AI acted as a constructive adversary.
  • GCP Deployment Hurdles: During the final hours of the hackathon, we encountered deep IAM configuration issues with Google Cloud Artifact Registry that blocked our production push. We had to rapidly pivot to running the Fastify core locally while securely tunneling it to the live Vertex AI API to ensure the demo remained fully functional.

Accomplishments that we're proud of

  • The "Journey-First" Studio: We successfully avoided building "just another chatbot." The interface feels like a professional workspace where artifacts compound in value.
  • True MCP Integration: We implemented a real, authenticated Model Context Protocol (MCP) server that shares exact domain logic with the web app, proving that learning and building can happen simultaneously across different surfaces.
  • Architectural Discipline: Despite the tight hackathon timeline, we maintained strict SDD (spec driven development), enforced a project constitution, and kept the frontend entirely decoupled from direct database or model provider access.

What we learned

We learned that AI in education shouldn't do the work for the learner; it should make the learning and the work visible. By forcing the AI to show its work (labeling inferences and unknowns), founders naturally stepped up to correct it, thereby engaging in the exact critical thinking we wanted to teach.

Technically, we learned the immense value of shared Zod contracts between a web frontend, a Fastify backend, and an MCP server. It eliminated entire categories of bugs when moving data between the browser, the database, and the IDE.

What's next for Foundercraft OS

The Build Week prototype proves the core loop: Idea → Opportunity Signal → Value Engine → Build Package.

Next, we plan to:

  1. Expand the Content Library: Add more curated frameworks (like Porter's Five Forces) and specialized rubrics for different venture types (e.g., Enterprise SaaS vs. Marketplaces).
  2. Portfolio Comparison: Build out the view where founders can compare multiple venture ideas based on evidence strength and feasibility risks.
  3. Full OAuth for MCP: Upgrade from personal access tokens to full OAuth for seamless enterprise IDE integrations.
  4. User Testing: Put the product in the hands of our first cohort of real first-time founders to validate our Product-Market Fit hypothesis: that founders will return to revise their artifacts because it genuinely improves their business decisions.

Built With

Share this project:

Updates