ForgeFlow

• 

  ForgeFlow

• 

  AI reads each drawing

• 

  Forge; One conversation with full operational context

• 

  Manage multiple items

• 

  Intake from different interactions

• 

  Manual entry when needed

• 

  Quote Comparison

• 

  AI Cost control

• 

  Real Solidworks connection

Inspiration

Manufacturing projects rarely fail because nobody can create a drawing or send an email. They prolong or fail in the space between understanding engineering demands, sourcing, suppliers, quotations, purchasing, delivery, and assembly.

I have spent years managing physical-product development and manufacturing. The same problems kept repeating: drawing packages had to be interpreted manually, product trees were rebuilt in spreadsheets, missing information was discovered too late, supplier communication lost context, and every project depended on one person remembering what should happen next.

I am a manufacturing and procurement professional with zero experience in software development. During OpenAI Build Week, I used Codex to turn that operational experience into a working product.

What ForgeFlow does

ForgeFlow is an AI-native execution system for physical-product engineering, sourcing, and manufacturing.

A user can upload an engineering drawing package and ForgeFlow:

1. Reads the drawings and proposes a cited product tree.
2. Identifies assemblies, manufactured parts, standard items, quantities, materials, and missing evidence.
3. Lets the user review and correct proposed facts.
4. Records whether items will be manufactured internally, purchased separately, or supplied as part of an assembly.
5. Matches items with one or more supplier candidates.
6. Prepares supplier-specific RFQ packages and communication drafts.
7. Receives quotations from pasted text, manual entry, PDF, or Excel.
8. Aligns and compares supplier offers by project item.
9. Generates editable purchase-order drafts and issued PDF documents.
10. Tracks receiving, internal assembly, completion, and project archiving.

A persistent project copilot, Forge, understands the projects and can explain blockers, supplier involvement, purchasing history, and the next recommended action.

How we built it

ForgeFlow is a local-first, browser-based application built as a modular monolith.

The application uses:

• Python and FastAPI for the application and domain-command layer.
• React and TypeScript for the web interface.
• PostgreSQL for canonical business records.
• A managed local file vault for drawings, quotations, and generated documents.
• OpenAI models for drawing analysis, structured extraction, review, communication drafting, and conversational assistance.

Engineering and commercial records remain local. Only the selected analysis payload is sent to the configured AI provider.

AI never writes arbitrary database records. It proposes structured changes, while deterministic application commands validate identifiers, hierarchy, quantities, sourcing decisions, quotation lines, and document states. Material changes require explicit user approval.

Building with Codex and GPT-5.6

Codex, powered by GPT-5.6, acted as the software engineering partner throughout the project.

I supplied the manufacturing knowledge, workflow decisions, acceptance criteria, and continuous real-world feedback. Codex translated those decisions into architecture, database migrations, APIs, user interfaces, tests, diagnostics, and recovery paths.

The collaboration was highly iterative. I tested the product as an actual purchasing user, reported confusing behavior and incorrect assumptions, and Codex investigated the canonical state, identified root causes, implemented narrow fixes, and checked established workflows for regressions.

Codex accelerated work that would otherwise have required a complete software team, while I retained responsibility for product direction and every manufacturing decision. I felt like a CEO of a tech company.

Challenges

The hardest challenge was preventing a fluent AI response from becoming false business truth.

Engineering packages contain ambiguous title blocks, repeated items, incomplete BOM tables, missing drawings, uncertain revisions, and assemblies that may be purchased complete or built internally. We learned to preserve evidence, expose uncertainty, and separate AI proposals from approved canonical records.

Another major challenge was maintaining one coherent workflow. The product tree, conversation, sourcing decisions, RFQs, quotations, purchase orders, receiving, and project status could not behave like separate applications. Every action had to update the same underlying project state.

Finally, screen space mattered. Manufacturing projects contain dense technical and commercial information, so completed stages collapse while the current decision and next safe action remain visible.

What we learned

The most important lesson was that useful enterprise AI is not merely a chat window.

It needs trusted tools, current operational context, evidence, explicit authority boundaries, deterministic validation, and a clear path from recommendation to reviewed action.

We also learned that a domain expert can build serious software when an AI engineering partner understands both the product intent and the consequences of implementation decisions.

What's next

The next steps include deeper supplier discovery, email integration, reusable catalog intelligence, supplier-performance learning, and a local SolidWorks companion that can convert Pack and Go packages into manufacturing-ready PDF and X_T files before ForgeFlow begins its engineering and sourcing workflow.

Built With

• alembic
• api
• automation
• codex
• fastapi
• gpt-5.6
• manufacturing
• openai
• postgresql
• procurement
• python
• react
• sqlalchemy
• typescript
• vite
• workflow