Added research pages

content/research/automating-your-workflow.mdx

@@ -0,0 +1,69 @@
+---
+title: 'Automating your workflow with KittyCAD'
+excerpt: |
+    What if you could design physical objects by simply describing what you wanted? That’s the idea behind Text-to-CAD. It’s a system that takes your text (“Make a flange with six evenly spaced holes”) and turns it into a fully parametric CAD model, written in KCL, our in-house CAD programming language.
+coverImage: 'documentation-assets/api-first-approach.jpg'
+date: '2025-02-10T12:28:40Z'
+author:
+    name: Frank Noirot
+    picture: '/documentation-assets/franknoirot.jpg'
+ogImage:
+    url: 'documentation-assets/api-first-approach.jpg'
+---
+## Geometry Engine In A Nutshell
+What if you could design physical objects by simply describing what you wanted? That’s the idea behind Text-to-CAD. It’s a system that takes your text (“Make a flange with six evenly spaced holes”) and turns it into a fully parametric CAD model, written in KCL, our in-house CAD programming language.
+
+But let’s get one thing straight: this isn’t just about spitting out a mesh for you to admire. Text-to-CAD generates precise, engineering-grade B-Rep geometry. This means you’re getting something real, editable, and ready for the next step – whether that’s tweaking dimensions, running simulations, or sending it straight to a CNC machine.
+
+*It’s CAD, but faster. And more intuitive.*
+
+## Why Did We Build This?
+
+Why indeed. Aren’t CAD tools already powerful? Yes, but here’s the thing: CAD is often stuck behind a wall of complexity. Most tools expect you to be fluent in obscure workflows, menus, and mouse clicks. If you’re not, you’re in for a long learning curve (or you’re outsourcing your ideas to someone who is).
+
+<Quote title="We thought:">Why can’t people just say what they want?</Quote>
+
+This isn’t about replacing CAD tools; It’s about making them more accessible. Automation is at the heart of our philosophy, and Text-to-CAD aligns perfectly with that. By turning natural language into code, and then into geometry, we’re lowering the barrier to entry while speeding up workflows for everyone, from seasoned engineers to total beginners.
+
+As [Jess mentioned in her first post](https://zoo.dev/blog/mechanical-cad-yesterday-today-and-tomorrow), this is why most CAD software is not extensible. Most of them have assumptions about software that were true in 1990 but aren't anymore: that the internet doesn't exist; that GPUs don't exist; that clicking is easier than typing for most user interactions[^1].
+
+Even more importantly perhaps, the assumptions *about users* have completely changed since then. Assumptions such as: how readily someone could author extensions to software; how well they might understand keyboard shortcuts; even how well a user could type, have all shifted dramatically in the last 30 years. And those assumptions about what users can do and what they want from their software influence architectural decisions in the software itself, which can be very hard to change later.
+
+
+## Adding an infrastructure layer to hardware design
+
+We think the hardware design industry needs a new layer of people who focus on those underlying architectural assumptions and keep them up-to-date, even as the industry finds new and better ways of making software.
+
+KittyCAD has assembled experts in software infrastructure to deal with all the complexity of making flexible tools for hardware design, so that software developers can focus on just building good user experiences. Like [Docker](https://www.docker.com/) did for devops and like [AWS](https://aws.amazon.com/) and [Vercel](https://vercel.com/) have done for web development, we are opening up an area of software development that has been inaccessible to most teams by handling the bottom of the software stack for you.
+
+If you want to get started building hardware design tools, we have everything you need. You can call our API directly over HTTPS just like any web service, or use one of our SDKs to build tools in the programming language you love to use (we love Rust ourselves!).
+
+Or if you want a starting point to jump off of, use one of our open-source tools to see how easy it is to incorporate KittyCAD into an application and unlock new CAD capabilities.
+
+
+## KittyCAD eats its own dogfood
+
+We are an infrastructure-first company, but we are building several end-user applications as we go in order to “[dogfood](https://en.wikipedia.org/wiki/Eating_your_own_dog_food)” our Geometry Engine and API infrastructure. [Zoo Modeling App](https://zoo.dev/modeling-app) is where most of our engineering efforts are going now, but we are also building our [Diff Viewer Extension](https://zoo.dev/diff-viewer) and other similarly niche tools in parallel[^2]. 
+
+These applications will all be open-source. This build-in-the-open approach does several things:
+
+
+
+1. They show the hardware design industry what is possible to build when you reimagine the foundation the tools are built on, widening [the adjacent possible](https://link.springer.com/referenceworkentry/10.1007/978-3-319-98390-5_100-1).
+2. They provide us with more users today to load test our API and find bugs early, before someone builds a business-critical functionality on top of us.
+3. By being open-source, they provide users the option to either contribute back to the project, or use our code as a starting point for their new idea.
+
+This development model is table stakes for the software industry, and we are proving that it can work for hardware design tool companies too. We have been thrilled to see community members already contributing improvements to the Modeling App, as well as ideas and feedback on our roadmap. I can’t wait to see a specialized modeling app get made based on ZCMA (Zoo Modeling App): if you’re building one, tag me on GitHub with any UX questions!
+
+
+## Imagining is the hard part
+
+Building an API-first offering allows our team to focus on solving the irreducibly hard problems in crafting hardware design tools and getting those solutions into the hands of software developers. Dogfooding our infrastructure by building our own open-source tools helps us validate our approach as we build services, and we hope gives engineers solid starting points to build their own tools and companies on our infrastructure.
+
+We believe we’ve validated our thesis that a modern reimagining of the hardware design industry can and should be done. What we have yet to do is imagine all the new kinds of tools that are made possible by taking an API-first approach. That’s where you come in.
+
+My role as a Design Engineer is to help build these new interfaces, and to make onboarding into this new paradigm for hardware design as easy as possible. I’m excited to see what you build with KittyCAD, and the rest of the team and I here to help you do it!
+
+[^1]: and of course that Y2K will doom us all.
+[^2]:
+    we’ve also decided as a team that we’re going to keep giving all our groundbreaking tools the most boring names possible.

content/research/geometry-engine.mdx

@@ -0,0 +1,69 @@
+---
+title: 'Geometry Engine: A new approach to CAD'
+excerpt: |
+    What if you could design physical objects by simply describing what you wanted? That’s the idea behind Text-to-CAD. It’s a system that takes your text (“Make a flange with six evenly spaced holes”) and turns it into a fully parametric CAD model, written in KCL, our in-house CAD programming language.
+coverImage: 'documentation-assets/api-first-approach.jpg'
+date: '2025-02-10T12:28:40Z'
+author:
+    name: Frank Noirot
+    picture: '/documentation-assets/franknoirot.jpg'
+ogImage:
+    url: 'documentation-assets/api-first-approach.jpg'
+---
+## Geometry Engine In A Nutshell
+What if you could design physical objects by simply describing what you wanted? That’s the idea behind Text-to-CAD. It’s a system that takes your text (“Make a flange with six evenly spaced holes”) and turns it into a fully parametric CAD model, written in KCL, our in-house CAD programming language.
+
+But let’s get one thing straight: this isn’t just about spitting out a mesh for you to admire. Text-to-CAD generates precise, engineering-grade B-Rep geometry. This means you’re getting something real, editable, and ready for the next step – whether that’s tweaking dimensions, running simulations, or sending it straight to a CNC machine.
+
+*It’s CAD, but faster. And more intuitive.*
+
+## Why Did We Build This?
+
+Why indeed. Aren’t CAD tools already powerful? Yes, but here’s the thing: CAD is often stuck behind a wall of complexity. Most tools expect you to be fluent in obscure workflows, menus, and mouse clicks. If you’re not, you’re in for a long learning curve (or you’re outsourcing your ideas to someone who is).
+
+<Quote title="We thought:">Why can’t people just say what they want?</Quote>
+
+This isn’t about replacing CAD tools; It’s about making them more accessible. Automation is at the heart of our philosophy, and Text-to-CAD aligns perfectly with that. By turning natural language into code, and then into geometry, we’re lowering the barrier to entry while speeding up workflows for everyone, from seasoned engineers to total beginners.
+
+As [Jess mentioned in her first post](https://zoo.dev/blog/mechanical-cad-yesterday-today-and-tomorrow), this is why most CAD software is not extensible. Most of them have assumptions about software that were true in 1990 but aren't anymore: that the internet doesn't exist; that GPUs don't exist; that clicking is easier than typing for most user interactions[^1].
+
+Even more importantly perhaps, the assumptions *about users* have completely changed since then. Assumptions such as: how readily someone could author extensions to software; how well they might understand keyboard shortcuts; even how well a user could type, have all shifted dramatically in the last 30 years. And those assumptions about what users can do and what they want from their software influence architectural decisions in the software itself, which can be very hard to change later.
+
+
+## Adding an infrastructure layer to hardware design
+
+We think the hardware design industry needs a new layer of people who focus on those underlying architectural assumptions and keep them up-to-date, even as the industry finds new and better ways of making software.
+
+KittyCAD has assembled experts in software infrastructure to deal with all the complexity of making flexible tools for hardware design, so that software developers can focus on just building good user experiences. Like [Docker](https://www.docker.com/) did for devops and like [AWS](https://aws.amazon.com/) and [Vercel](https://vercel.com/) have done for web development, we are opening up an area of software development that has been inaccessible to most teams by handling the bottom of the software stack for you.
+
+If you want to get started building hardware design tools, we have everything you need. You can call our API directly over HTTPS just like any web service, or use one of our SDKs to build tools in the programming language you love to use (we love Rust ourselves!).
+
+Or if you want a starting point to jump off of, use one of our open-source tools to see how easy it is to incorporate KittyCAD into an application and unlock new CAD capabilities.
+
+
+## KittyCAD eats its own dogfood
+
+We are an infrastructure-first company, but we are building several end-user applications as we go in order to “[dogfood](https://en.wikipedia.org/wiki/Eating_your_own_dog_food)” our Geometry Engine and API infrastructure. [Zoo Modeling App](https://zoo.dev/modeling-app) is where most of our engineering efforts are going now, but we are also building our [Diff Viewer Extension](https://zoo.dev/diff-viewer) and other similarly niche tools in parallel[^2]. 
+
+These applications will all be open-source. This build-in-the-open approach does several things:
+
+
+
+1. They show the hardware design industry what is possible to build when you reimagine the foundation the tools are built on, widening [the adjacent possible](https://link.springer.com/referenceworkentry/10.1007/978-3-319-98390-5_100-1).
+2. They provide us with more users today to load test our API and find bugs early, before someone builds a business-critical functionality on top of us.
+3. By being open-source, they provide users the option to either contribute back to the project, or use our code as a starting point for their new idea.
+
+This development model is table stakes for the software industry, and we are proving that it can work for hardware design tool companies too. We have been thrilled to see community members already contributing improvements to the Modeling App, as well as ideas and feedback on our roadmap. I can’t wait to see a specialized modeling app get made based on ZCMA (Zoo Modeling App): if you’re building one, tag me on GitHub with any UX questions!
+
+
+## Imagining is the hard part
+
+Building an API-first offering allows our team to focus on solving the irreducibly hard problems in crafting hardware design tools and getting those solutions into the hands of software developers. Dogfooding our infrastructure by building our own open-source tools helps us validate our approach as we build services, and we hope gives engineers solid starting points to build their own tools and companies on our infrastructure.
+
+We believe we’ve validated our thesis that a modern reimagining of the hardware design industry can and should be done. What we have yet to do is imagine all the new kinds of tools that are made possible by taking an API-first approach. That’s where you come in.
+
+My role as a Design Engineer is to help build these new interfaces, and to make onboarding into this new paradigm for hardware design as easy as possible. I’m excited to see what you build with KittyCAD, and the rest of the team and I here to help you do it!
+
+[^1]: and of course that Y2K will doom us all.
+[^2]:
+    we’ve also decided as a team that we’re going to keep giving all our groundbreaking tools the most boring names possible.