Pitching a robotics or physical AI startup to accelerators and early-stage investors

Robotics and physical AI pitches face two tests at once. Like hardware companies, they are asked whether the system works in messy real environments, at a cost a customer will pay. Like AI companies, they are asked why a foundation-model lab, a chip vendor's robotics platform, or the equipment maker will not absorb what they build. Strength on one test rarely compensates for weakness on the other.

This guide is for founders building robots, manipulation and mobility systems, drones and autonomous vehicles, navigation, robot training and simulation tools, and the AI models that run them. It explains how evaluators judge these companies and how to prepare. It draws on patterns observed across early-stage selection interviews and builds on the general pitch preparation guide.

How robotics pitches are judged

What you own is the first question. Much of modern robotics is built on open models, open simulation tools, and widely available hardware. Evaluators ask, more often than anything else, which part of the system is yours and which part anyone could download.

Field proof outweighs the demo. A polished video or a controlled lab demonstration is the starting point, and evaluators move quickly to what happens in a real site with real variation.

Builders in the room cut deep. Selection groups for robotics often include experienced robotics founders and hardware engineers. They recognize an open-source stack with light modifications on sight, and their verdict tends to carry the room.

Pedigree does not rescue vague answers. Strong credentials and impressive hardware still lose ground when the buyer, the economics, or the proprietary core are unclear.

Scale is tested against the giants. Evaluators know how much capital is flowing to the largest robotics and foundation-model companies. A small team pitching the whole stack is asked how it will compete with companies that have raised billions.

What is actually yours

Prepare a clear answer to which parts of the system you built, which you licensed, and which come from open source.

• Draw the stack. Show every layer of the system, from hardware and perception through planning and control to the model and data pipeline, and mark which pieces are proprietary.
• Pick a layer to own. Teams that try to build every layer at once are judged as overreaching. A specific layer where you can be clearly better, with partners for the rest, reads as a strategy the team can execute.
• Own the core component. Licensing the capability your product depends on, or reselling another company's hardware, invites the conclusion that the supplier can work around you.
• Explain what open source can't give a competitor. If you build on open models or simulators, name what you add that a capable team could not reproduce in a few months, such as proprietary field data, a validated process, a safety case, or deep integration with a customer's operations.
• Answer the foundation-model question. Evaluators will ask why the equipment maker will not do the same, and why a robotics foundation-model company or a chip vendor's robotics platform will not either. Name the structural reason, as you would in any AI pitch.
• Use hardware only where it earns its place. If a phone, a commodity sensor, or an existing robot could do the job, expect to be asked why you are building custom hardware.

Proof that counts

• Real sites, real variation. Evidence from a customer's facility or another operational environment, including field tests, carries far more weight than lab results. Expect questions about the conditions that break robots: worn or damaged parts, misalignment, poor lighting, weather, terrain without features, and changing seasons.
• Numbers on the metrics that matter. Success rate per task and interventions per hour give evaluators something to check. So do uptime and accuracy against a named incumbent, along with hours or miles of operation.
• Comparison against the incumbent. Show performance against the current product or method the customer uses today, under the same conditions.
• Accurate descriptions of events. A demonstration at an open testing event is useful, and calling it an engagement with a government customer is a mistake evaluators will catch.
• Consistent figures. Pilot sizes, unit prices, and contract values should match across every conversation and document.

Unit economics

Robotics companies are asked to show the economics per unit and per task, early.

• Cost per task against the alternative. Compare your cost per pick, inspection, delivery, or bolt against the human labor or existing equipment it replaces, with the assumptions shown.
• Bill of materials and the path down. State today's unit cost and what it becomes at volume.
• Maintenance and uptime. Who maintains the robot, how often it fails, and what downtime costs the customer are standard questions.
• Robots as a service or outright sale. Many buyers prefer service pricing, especially for seasonal or variable demand. Service pricing helps the sale, though it does not answer the question of what you own.
• Product or services. Deployments that need your engineers on site for every customer read as a services business with a limited ceiling. Show how integration effort falls with each deployment.
• Venture scale. A profitable niche can still be judged too small. Show the path from the first application to a much larger market.

The buyer and the first deployment

• Name who pays and from which budget. Identify the asset owner, operator, or service contractor who signs, and whether the money comes from operating or capital budgets. In many industries, a service contractor who already does the work is a faster buyer than the asset owner.
• Go narrow and deep first. One facility and one task, done thoroughly for one customer, is more convincing than a list of industries. A customer under acute pressure, whether from labor shortages, safety mandates, or cost, makes the best first site.
• Count paid pilots. A small paid contract or proof of concept is received well. Pilots described as "lined up" or unpaid count for little, and a polished product with no buyer after a long time in market is a serious warning sign.
• Use regulation as a driver. Safety standards, inspection mandates, and compliance requirements can create the reason to buy. Name the specific rule.
• Plan certification honestly. Aviation, medical, automotive, and similar approvals take time. Optimistic certification timelines are noticed and discounted by anyone who has been through the process.

Defense and dual-use buyers

Many robotics and drone companies have a defense application, and defense buyers can fund development faster than commercial ones. Evaluators with defense experience expect specifics.

• Name the program office. "The Department of Defense" is not a buyer. Identify the specific command or program that has the problem and the budget.
• Build first, then approach. Defense customers respond to working prototypes. A concept awaiting a contract is weaker than a system already flying or driving.
• Choose the channel. Selling directly, through prime contractors, or through manufacturers that already supply the military each has trade-offs. Have a view on which you will use.
• Consider non-dilutive funding. Government research grants can fund early development better than venture capital for some companies, although grant revenue is not treated as commercial validation.
• Know your export and ownership position. Export controls and foreign ownership affect which customers you can sell to and whether you need a domestic partner.

A dedicated guide to space and defense startups covers these buyers in more depth.

Safety, liability, and permission

Physical systems create risks software does not, and evaluators will raise them.

• Permission to operate. Using someone else's infrastructure, airspace, or premises needs their consent and sometimes a regulator's. Show you have it, or how you will get it.
• Liability and insurance. Explain who is liable when the robot damages property or injures someone, and how the risk is insured.
• Operating conditions. Robots that work around the public, in stores during opening hours or on sidewalks, face extra scrutiny.
• Public perception. Drones overhead and robots in public spaces draw resistance. Have an answer before you are asked.

The team

• Robotics experience on the founding team. Founders who have built and deployed robots answer the field questions crisply, and evaluators notice when they don't.
• A commercial lead. Strong engineering teams without someone who sells draw the same question in every meeting.
• Full-time founders. A technical co-founder still employed elsewhere, or absent from the pitch, counts against the company.
• Clear ownership. An equity split that takes several minutes to explain suggests unresolved questions.

Questions to rehearse

Technical

1. Which parts of the system are proprietary, and which are open source or licensed?
2. Why won't a foundation-model company, a chip vendor's platform, or the equipment maker build the same capability?
3. How does it perform in real field conditions, and what breaks it?
4. What are the success rate, intervention rate, and uptime at a real site?
5. How do you compare with the incumbent product on the customer's own task?
6. Where does the training data come from, and how much of it is real-world?
7. What do you build, and what do you integrate or license?

Business

1. Who pays, and from which budget?
2. What does each task cost compared with today's method?
3. Who maintains the system, and what does downtime cost?
4. How much of each deployment is engineering services?
5. Who has permission to let you operate, and who carries the liability?
6. For defense: which program office, through which channel?
7. Who are the competitors, including the ones you didn't name?

Red flags to avoid

• An open-source stack with light modifications presented as proprietary technology
• A full-stack plan with a small team and no partners
• Licensing or reselling the core capability
• Custom hardware where commodity hardware would do
• Lab or video demos presented in place of field results
• Unpaid pilots described as traction
• A finished product with no buyer after a long time in market
• A test event described as a customer engagement
• Figures that change between conversations
• Legal or permission problems not yet considered
• Optimistic certification timelines
• Well-known competitors missing from the slide
• A defense pitch with no named program or working prototype

Checklist

• Stack diagram marking proprietary, licensed, and open-source parts
• One layer chosen to own, with partners for the rest
• Structural answer to the foundation-model and incumbent question
• Field results from a real site, with success rate, interventions, and uptime
• Comparison against the incumbent on the customer's task
• Cost per task against the current method
• Unit cost today and at volume
• Maintenance, uptime, and downtime cost addressed
• Service pricing or sale decided, with integration effort falling per deployment
• Named buyer and budget, and a narrow first deployment
• Paid pilots separated from planned ones
• Permission, liability, insurance, and certification plan
• Defense program office and channel named, if relevant
• Competitors named, including the obvious ones
• Robotics deployment experience and a commercial lead on the team