Feynman: First Principles for Deep Tech

By Yug Gupta · Published Sep 10, 2026

Apply Richard Feynman’s approach to first-principles physics: estimate physical limits, test assumptions, and build better deep-tech experiments.

First-principles thinking means starting with defensible constraints and reasoning toward a design. For a deep-tech founder, its value is practical: it helps identify which part of an ambitious idea deserves the next experiment. Richard Feynman offers a useful starting point because his writing combines physical imagination with unusually direct demands for evidence.

The challenge is to turn that combination into an engineering habit. A promising idea needs both room to grow and a test that could reveal why it fails.

What Feynman actually did with first principles

In his 1959 talk, There's Plenty of Room at the Bottom, Feynman explored manipulating matter at very small scales. He estimated whether information could fit into tiny physical structures, then considered how it might be written and read. He distinguished what physical laws permitted from what available manufacturing methods could accomplish. He also examined how shrinking machines would change the relative importance of different forces. Read the original talk.

That sequence suggests a useful engineering workflow: state the desired capability, calculate a bound, and identify the missing mechanism. This is an interpretation for product development, rather than a startup formula proposed by Feynman.

For example, “make this sensor last longer” leaves almost every decision open. “Measure once per minute for a week using a 10 watt-hour battery” creates a budget. Every proposed feature must now fit somewhere inside it.

A toy calculation for a battery-powered sensor

Consider an imagined environmental sensor. The numbers below are illustrative assumptions, not measurements of a commercial device.

Assume the battery provides 10 watt-hours of usable energy. The system consumes 2 watts while measuring and transmitting, and 0.01 watts while sleeping. Ignore startup overhead, battery aging, temperature effects, and conversion losses for the first calculation.

At continuous active power, the ideal operating time is:

time = energy / power = 10 Wh / 2 W = 5 hours

A week contains 168 hours, so the average power budget for a week is:

average power budget = 10 Wh / 168 h = about 0.0595 W

Now suppose the device can complete its measurement and transmission in one second, then sleep for the remaining 59 seconds of each minute. The average power becomes:

average power = (2 W × 1/60) + (0.01 W × 59/60) = about 0.0432 W

Under those assumptions, the ideal runtime is roughly 232 hours, or 9.7 days. A one-week target looks plausible in this simplified model.

The decisive assumption is the one-second active period. It includes everything required to produce and deliver a useful measurement. If connecting to the network takes several additional seconds, the energy budget changes. If the sensor needs time to stabilize, the proposed sleep schedule may be inappropriate.

The calculation therefore gives the team a specific experiment: measure the energy consumed by a complete sampling cycle, including startup and retries. That is a much more useful next step than debating battery life in the abstract.

Find the assumption with the greatest effect

Keep the same imagined device, but increase active time to five seconds per minute. Its average power rises to about 0.176 watts. Ideal runtime falls to approximately 57 hours, well short of a week.

This small sensitivity check changes the development priorities. Improving the enclosure will not resolve the energy shortfall. Reducing transmission time, storing measurements for later upload, or changing the sampling requirement might. Each option carries a product tradeoff: delayed data, reduced coverage, or less frequent observation.

A practical first-principles model should make these tradeoffs visible. Use a few variables you can explain, keep units attached to every number, and write down where the estimates came from. A complicated spreadsheet with unexplained assumptions can hide more uncertainty than a rough calculation exposes.

The model also has a boundary. Energy arithmetic does not tell you whether customers need minute-by-minute updates. That requires conversations and observation. Physical feasibility and usefulness need different kinds of evidence.

Design experiments that can disappoint you

In his 1974 address, Cargo Cult Science, Feynman argued that scientific integrity includes reporting details that might undermine a preferred interpretation. He emphasized alternative explanations, conflicting evidence, and enough information for others to judge a result. Read the Caltech text.

Applied to the sensor example, that means recording failed connections alongside successful ones. Before testing, define the required runtime and the conditions the device must tolerate. Report the spread of results across repeated runs. Preserve the raw measurements so a teammate can inspect them.

An impressive demonstration can still be useful, but its scope should be explicit. A device that works beside a router has established something narrower than a device tested across the intended deployment environment. Describing the narrower result accurately makes the next uncertainty easier to investigate.

Make physical reasoning part of building

A useful discussion in a founder community such as Variance could start with three items: the governing constraint, the most uncertain assumption, and the cheapest experiment that would change the decision. A one-page calculation can give collaborators something concrete to challenge.

The same discipline helps with bigger questions. Discussions of the technological singularity and intelligence explosion need explicit assumptions about what accelerates and what remains constrained. The relationship between models and measurements also connects to why mathematics describes physics.

For an engineering project, the immediate task is smaller: make one prediction clear enough to test, measure what happens, and revise the design accordingly.