118. Climate and Deeptech Startups

Climate and deeptech startups are not normal software startups with slower sales.

They often combine scientific risk, engineering risk, manufacturing risk, regulatory risk, field deployment, pilots, grants, enterprise buyers, and capital intensity. The reward can be large, but the founder has to manage a different clock.

In software, a rough product can sometimes reach users in weeks. In deeptech, the path from lab result to deployable product can involve years of proof, certification, supply chain work, service networks, and financing.

The Core Question

The core deeptech question is:

“Which risk is still unproven: science, engineering, manufacturing, market, regulation, or financing?”

If the answer is unclear, the team may be working hard on the wrong milestone.

Risk Types

Risk	Question
Research risk	Does the underlying science work reliably?
Engineering risk	Can the concept become a usable product?
Manufacturing risk	Can it be produced at quality, cost, and scale?
Market risk	Will buyers adopt and pay?
Regulatory risk	What approvals, standards, or policies matter?
Financing risk	Can the company fund milestones before revenue?

A deeptech founder must know which risk is being reduced each quarter.

Risk Burn-Down Board

Deeptech teams should maintain a risk burn-down board. The board makes the company honest about what is known and unknown.

Risk	Current evidence	Next proof	Owner	Decision after proof
Science				Continue, narrow, pivot, or stop
Engineering				Continue, narrow, pivot, or stop
Manufacturing				Continue, narrow, pivot, or stop
Buyer				Continue, narrow, pivot, or stop
Regulation/standards				Continue, narrow, pivot, or stop
Financing				Continue, narrow, pivot, or stop

Review it monthly. The board should change as evidence appears. If the same risk stays vague for months, the team may be avoiding the hard question.

For founders coming from research, the buyer risk may feel less intellectually interesting than the technical risk. Do not postpone it. A brilliant technology without a buyer path is a research project, not yet a startup.

Milestone-Based Company Building

Deeptech companies should be managed around evidence milestones, not only calendar plans.

Examples:

Lab proof that the core mechanism works repeatedly.
Prototype proof under realistic operating conditions.
Unit-cost proof that manufacturing can become viable.
Pilot proof with a real buyer and clear success metric.
Safety or standards proof where required.
Commercial proof that the buyer will move from pilot to purchase.
Financing proof that the next milestone can be funded.

Each milestone should answer one risk question. If a quarter’s work does not reduce a named risk, the company may be confusing activity with progress.

Milestone Financing Map

Deeptech founders should connect each proof milestone to financing before the cash is needed.

Milestone	Typical capital question
Lab proof	Can founders, angels, university support, or grants fund repeatable evidence?
Prototype	What capital buys engineering talent, materials, testing, and iteration?
Field pilot	Who pays for site access, installation, monitoring, safety, and support?
Commercial pilot	Can the customer, strategic partner, or grant share the cost?
First deployment	Does the company need inventory, working capital, project finance, or debt?
Repeatable deployment	Can gross margin, financing, and service model support scale?

If a milestone has no financing path, the technical plan is incomplete. The founder should know how much proof the current cash can buy and what evidence unlocks the next capital source.

Research And Technical Risk

Research risk asks whether the underlying science works. If the answer is still uncertain, do not pretend the company is only a GTM problem.

Milestones should be evidence-based:

Lab results.
Prototype performance.
Reliability.
Safety.
Cost.
Efficiency.
Reproducibility.
Field performance.

Technical risk asks whether the concept can be engineered into a usable product. A lab demo, paper, or prototype may be far from a deployable product. Track reliability, environment, maintenance, unit cost, scalability, and integration.

Market And Buyer Risk

Deeptech founders can fall in love with technical novelty. Buyers care about cost, risk, uptime, regulation, payback, procurement, and operational fit.

The more complex the technology, the more clearly you must explain:

Who buys.
Why now.
What budget it comes from.
What economic outcome improves.
What risk adoption creates.
What proof is required.
What happens after the pilot.

The buyer does not buy novelty. The buyer buys lower cost, higher revenue, compliance, resilience, safety, or strategic advantage.

Buyer Economics Memo

Before a pilot, write the buyer economics in plain language.

Question	Answer needed
What cost, revenue, risk, compliance, or resilience problem improves?	The buyer’s real reason to care.
What is the current alternative?	Incumbent technology, manual process, fuel, labour, outsourcing, doing nothing.
What is the buyer’s switching cost?	Training, downtime, integration, behaviour change, maintenance, approval.
What payback or ROI does the buyer expect?	The economic bar for purchase.
What proof does the buyer trust?	Field data, third-party testing, reference site, certification, pilot result.
Who owns the budget?	Sustainability, operations, plant head, procurement, R&D, CSR, government, business unit.
What could kill the purchase after a successful pilot?	Procurement, price, safety, service, financing, policy, incumbent pressure.

If the founder cannot fill this memo, the pilot may become technical theatre rather than commercialization.

Standards And Certification Path

Many climate and deeptech products must satisfy standards, certifications, safety tests, customer audits, or procurement requirements before scale. Identify these early.

Map:

Area	Founder question
Safety	What could physically, financially, environmentally, or operationally harm the customer?
Standards	Which industry standards, customer specifications, or test protocols matter?
Certification	Is third-party certification required for sale, insurance, procurement, or trust?
Data credibility	Who trusts the measurement method and instrumentation?
Warranty	What performance is the company willing to stand behind?
Procurement	What documents does the buyer need before purchase?
Regulation	Which approvals, permits, reporting, or environmental rules may apply?

Do not wait for the first large buyer to discover the certification path. If certification takes months, it belongs in the financing and milestone plan.

Pilots

Pilots can create proof, but only if they have structure.

A serious pilot should define:

Start date.
End date.
Success metric.
Data access.
Buyer or sponsor.
Technical owner.
Paid or unpaid status.
Conversion path.
What happens after success.

Pilots without conversion criteria can become graveyards. They keep the team busy while avoiding the purchase decision.

Paid And Customer-Funded Pilots

A customer-funded pilot is powerful because it tests seriousness. It does not always need to cover full cost, but it should create commitment.

Useful pilot terms:

What the customer provides: site access, data, equipment, staff, permissions.
What the startup provides: prototype, installation, monitoring, reporting, support.
What success means: cost saved, output improved, emissions reduced, downtime avoided, accuracy, reliability, or payback.
Who decides after the pilot.
What commercial path follows success.

If a buyer will not pay anything, provide data, or commit decision-maker time, the pilot may be more curiosity than demand. Non-paying pilots can still be useful for technical proof, but call them technical pilots, not market validation.

IP And Commercialization

IP may be central.

Decide what should be:

Patented.
Kept as trade secret.
Licensed from a university or lab.
Assigned by founders.
Protected through manufacturing know-how.
Protected through data, deployment, or relationships.

Do not delay IP thinking until after public disclosure or investor diligence.

Commercialization also needs a path:

Direct enterprise sales.
Channel partners.
OEM partnerships.
Government programs.
Project finance.
Licensing.
Manufacturing partnerships.
Service contracts.

If nobody knows how the technology becomes a repeatable sale, the company is still a project.

Manufacturing And Service Reality

For physical or hardware-linked deeptech, product does not end at prototype.

Plan for:

Bill of materials.
Supplier reliability.
Manufacturing yield.
Quality testing.
Installation.
Maintenance.
Spare parts.
Field failure.
Warranty.
Training.
Service network.

Many deeptech startups underestimate the service layer. A product that performs well in a controlled demo can fail commercially if installation is hard, repairs are slow, or customers cannot operate it safely.

Field Failure Review

Field failures are not embarrassment. They are the bridge from prototype to product.

For every field issue, record:

Field issue	Review question
Environment mismatch	Did lab conditions miss heat, dust, humidity, voltage, terrain, operator behaviour, or usage pattern?
Installation issue	Was installation too dependent on founder expertise?
Operator error	Was training, documentation, UX, or safety design insufficient?
Component failure	Is there supplier, quality, or design weakness?
Maintenance burden	Can the customer or service partner handle it without founders?
Performance gap	Did the product underperform the promised metric?
Data gap	Was monitoring enough to diagnose the problem?

The goal is not to hide failure from customers. The goal is to turn field reality into a better product, clearer promise, and stronger deployment process.

Capital Strategy

Capital should match the risk stage.

Potential sources include:

Founder capital and angels for early proof.
Grants or non-dilutive funding for technical milestones.
Strategic partners for pilots or deployment.
Venture capital for large market and scalable company building.
Project finance, debt, or customer financing for deployment-heavy models.
Government or institutional programs where aligned.

Do not let grant availability define the company. Grants are useful when they fund the next proof point. They are distracting when they pull the team away from the buyer and commercialization path.

Deeptech Stage Plan

Deeptech progress should be planned around proof, not optimism.

Stage	Main risk	Evidence needed
Lab proof	Scientific or technical possibility.	Repeatable result under controlled conditions.
Prototype	Engineering feasibility.	Working prototype in realistic conditions.
Field pilot	Operational performance.	Customer site data, reliability, maintenance, and user feedback.
Commercial pilot	Buyer seriousness.	Paid pilot, success metric, decision-maker, and conversion path.
First deployment	Delivery capability.	Installation, service, warranty, support, and economics work.
Repeatable deployment	Company scalability.	Similar customers buy with similar proof, cost, and timeline.

Each stage should have a kill, continue, or pivot decision. If the result is weak, do not hide behind future improvements. Ask which risk remains and whether the company still has the capital, team, and buyer pull to solve it.

Pilot To Purchase Path

A deeptech pilot is useful only if it leads somewhere.

Before accepting a pilot, define:

What problem the buyer wants solved.
Why the buyer cannot ignore it.
What success metric matters commercially.
Who pays for the pilot or contributes resources.
Who owns site access, safety, data, and operations.
What procurement step follows success.
What budget line funds purchase.
What timeline the buyer will commit to.

Pilot success should not be “the technology worked.” It should be “the technology worked well enough for this buyer to make the next decision.”

If the buyer refuses to define a next decision, the pilot may still be useful for technical learning. But call it technical learning, not sales validation.

Deployment Playbook

A deployable deeptech product needs a repeatable deployment playbook.

Document:

Step	What to define
Site qualification	Which customer/site conditions are acceptable or risky?
Pre-installation	Data, permits, measurements, safety checks, staff readiness
Installation	Who installs, tools needed, time required, failure modes
Commissioning	What test proves the system is ready?
Training	Who must learn to operate, monitor, and escalate?
Monitoring	What data is collected and how often it is reviewed?
Maintenance	Scheduled work, spare parts, response times, service owner
Failure response	What happens if performance drops, safety risk appears, or customer operations are affected?
Handover	What documentation and acceptance criteria close deployment?

If deployment requires founders every time, the product is not yet scalable. Founder involvement is fine in early pilots, but each deployment should teach what must become process, tooling, partner training, or product simplification.

Manufacturing Readiness

Hardware-linked and physical deeptech companies need manufacturing readiness earlier than founders expect.

Track:

Area	Founder question
Bill of materials	Which components drive cost, lead time, and risk?
Supplier base	Which parts have single-supplier dependency?
Yield	How many units pass quality checks without rework?
Testing	What test proves the unit is safe and ready?
Installation	Who installs, how long it takes, and what can fail?
Maintenance	What breaks in the field and who repairs it?
Warranty	What failure risk is the company carrying?
Documentation	Can someone outside the founding team operate and service it?

A prototype can be impressive while the product is not manufacturable. Manufacturing readiness turns invention into delivery.

Supply Chain Risk

Deeptech companies can be blocked by parts, vendors, imports, testing capacity, equipment, fabrication partners, or service capability.

Review:

Which components have long lead times?
Which parts depend on one supplier, geography, or imported material?
Which vendors understand the quality requirement?
Which parts are likely to fail in Indian field conditions?
Which items need inventory before deployments?
Which costs change materially with volume?
Which processes must be brought in-house eventually?
Which service partners can repair or maintain the product?

Supply chain risk is company risk. A product can be technically validated and still commercially blocked because the team cannot source, make, install, or maintain it reliably.

Grant Strategy Discipline

Non-dilutive funding can be extremely useful, but it needs discipline.

Before applying for a grant, ask:

Does this grant fund a milestone we already need?
Will the reporting burden distract the technical team?
Does the grant push the roadmap away from customer demand?
Does it create IP, publication, or partnership constraints?
Will it help future investors or customers trust the company?
What happens if the grant is delayed or not awarded?

Use grants to buy time for proof. Do not use grants to avoid buyer conversations. A company can become excellent at applications and still weak at commercialization.

Technical Diligence Pack

Deeptech founders should maintain a technical diligence pack before fundraising or strategic partnerships.

Include:

Problem statement and buyer economics.
Technical principle explained in plain language.
Evidence so far, including failed experiments.
Prototype performance and test conditions.
Comparison with alternatives.
Unit cost assumptions.
Manufacturing or deployment plan.
IP ownership and filings.
Safety, standards, or regulatory questions.
Next three proof milestones.
Capital required to reach each milestone.

The pack is not only for investors. It forces the team to separate what is known, what is assumed, and what must be proven next.

Climate Models

Climate opportunities can appear in:

Energy.
Carbon.
Agriculture.
Mobility.
Manufacturing.
Waste.
Water.
Circular economy.
Adaptation.
ESG software.

Each has a different buyer and adoption barrier. Energy requires payback and reliability. Carbon requires measurement credibility and verification. Agriculture requires distribution, seasonality, and farmer economics. Manufacturing requires quality, downtime risk, procurement, and supply chain fit.

India Angle

India offers large climate and deeptech opportunities because of energy demand, manufacturing growth, agriculture scale, water stress, urbanisation, mobility shifts, and public infrastructure needs.

But adoption can be price-sensitive and operationally messy. A product may need financing, service networks, local manufacturing, government relationships, or channel partners to work.

Indian founders should ask:

Can the buyer afford the upfront cost?
Is payback clear enough?
Who installs and maintains the product?
What happens outside ideal lab conditions?
Are components and manufacturing reliable?
Does the customer need financing?
Are grants helping milestones or distracting the team?

Metrics To Watch

Useful climate and deeptech metrics include:

Technical milestone completion.
Prototype reliability.
Unit cost trajectory.
Field performance versus lab performance.
Pilot conversion rate.
Payback period for buyer.
Manufacturing yield.
Installation and maintenance cost.
Grant or non-dilutive funding progress.
Customer-funded pilot percentage.
Time from pilot to purchase decision.

The scoreboard should show risk reduction, not only activity.

Milestone Financing

Climate and deeptech companies should finance risk reduction, not vague progress. Each round, grant, pilot, or revenue contract should answer: which risk will this capital remove?

Common risk milestones:

Risk	Milestone
Scientific risk	Principle works under controlled conditions.
Engineering risk	Prototype performs repeatedly outside ideal conditions.
Manufacturing risk	Unit can be produced at target quality and cost trajectory.
Deployment risk	Product can be installed, operated, and serviced in the field.
Buyer risk	Customer pays, renews, or expands after pilot.
Regulatory or standards risk	Required certification, testing, or approval path is understood.
Financing risk	Customer can afford adoption through capex, opex, leasing, subsidy, or partner finance.

Raise or spend against the next proof point. Do not use capital only to make the technology more impressive if buyer risk remains untouched.

Field Pilot Design

Deeptech pilots often fail because the pilot is not designed as a decision. It becomes a long demonstration with no buyer commitment.

Before a pilot, define:

Buyer sponsor.
Technical owner.
Site conditions.
Success metrics.
Failure thresholds.
Data collection method.
Maintenance responsibility.
Safety and compliance requirements.
Commercial next step if successful.
Date when the buyer must decide.

Pilot success should not be “the product worked once.” It should be evidence that reduces the buyer’s adoption risk.

Paid Versus Free Pilots

Free pilots can be useful for learning, but they are weak evidence of willingness to pay. Customer-funded pilots are stronger because they reveal seriousness.

If the pilot is free, get another form of commitment:

Access to real operating environment.
Named executive sponsor.
Data sharing agreement.
Public reference if successful.
Written rollout criteria.
Time commitment from buyer team.

Without commitment, pilots become founder entertainment.

Commercialization Path

Technology does not commercialize itself. Write the path from lab to repeatable revenue.

Step	Founder question
Technical proof	What has to work reliably?
Buyer proof	Who pays and why now?
Economic proof	What is the buyer payback or strategic value?
Deployment proof	Who installs, trains, maintains, and supports?
Manufacturing proof	Can units be made with quality and predictable cost?
Financing proof	Can customers buy without impossible upfront burden?
Channel proof	Who sells and supports at scale?

The commercialization path may reveal that the real company needs financing partners, service teams, channel partners, manufacturing partners, or government relationships as much as it needs better technology.

Manufacturing And Supply Chain Readiness

For hardware or physical deeptech, manufacturing is not an afterthought.

Track:

Bill of materials.
Critical components and alternate suppliers.
Import dependencies.
Lead times.
Quality testing.
Manufacturing yield.
Installation process.
Maintenance and spare parts.
Warranty assumptions.
Field failure data.

The first working prototype is not the product. The product is the repeatable system that can be made, delivered, installed, maintained, and supported at economics that work.

Grant Discipline

Grants and non-dilutive funding can be powerful, especially in research-heavy companies. They can also distract the team from customers.

Use grants when:

The grant funds a real technical or field milestone.
Reporting burden is manageable.
The milestone strengthens customer or investor proof.
The grant does not force the company away from the market.

Be careful when:

The team starts writing grant proposals instead of selling.
Grant milestones do not match buyer milestones.
The company confuses grant approval with market validation.
The funding delays hard commercial conversations.

A grant is fuel, not proof of demand.

Deeptech Continue/Pause Gate

Deeptech founders need optimism, but they also need hard gates. Without gates, the company can spend years improving technology while commercialization remains vague.

Set gates by risk type:

Risk	Continue signal	Pause or redesign signal
Scientific/technical	The core mechanism works under defined conditions.	Results are unstable or only work in ideal lab settings.
Engineering	Prototype survives realistic use cases.	Performance collapses outside controlled demos.
Manufacturing	Cost, yield, supply, and quality have a plausible path.	Prototype cannot be made repeatedly or affordably.
Buyer	Buyer has budget, urgency, and a deployment path.	Interest is academic, CSR-driven, or non-committal.
Pilot	Pilot has paid commitment, success criteria, and next-step path.	Pilot is free, endless, or detached from procurement.
Financing	Next milestone can be funded without magical assumptions.	Capital need jumps before evidence improves.

At each gate, decide:

Continue with current plan.
Narrow the use case.
Change buyer or deployment path.
Seek partner/grant/customer-funded milestone.
Pause a technical direction.

Deeptech progress is not only invention. It is risk burn-down. The company becomes stronger when each milestone makes the next financing, customer, or deployment decision easier.

Climate And Deeptech Commercialization Board

Deeptech founders often have strong technical conviction before the commercial system is clear. That conviction is necessary, but it can also hide weak customer pull. A commercialization board keeps the company honest by tying technical progress to buyer value, deployment reality, and financing milestones.

Use this board for every major milestone:

Area	Evidence to review	Founder decision
Technical proof	Lab result, prototype performance, field test, reliability, repeatability.	What risk has actually been retired?
Buyer value	Cost saving, yield improvement, compliance, uptime, energy saving, revenue, risk reduction.	Is the buyer’s economic reason strong enough?
Deployment path	Site conditions, installation, training, service, downtime, integration, safety.	Can the product work outside controlled demos?
Manufacturing path	BOM, yield, suppliers, lead time, quality checks, assembly, spares.	What must be true for repeatable delivery?
Standards and approvals	Tests, certifications, customer acceptance criteria, safety reviews.	Which gate can block purchase or deployment?
Pilot conversion	Paid pilot, success criteria, decision maker, procurement step, next contract.	Is the pilot designed to become a purchase?
Capital milestone	Grant, customer funding, equity round, debt, working capital need.	What evidence unlocks the next capital source?

The board should separate three different kinds of interest:

Interest type	What it sounds like	How to treat it
Curiosity	”This is exciting technology.”	Useful for learning, weak as validation.
Strategic interest	”This could matter to us someday.”	Ask for access, data, pilot design, and decision path.
Commercial pull	”If you prove these criteria, we can buy or expand.”	Build milestones around this.

For climate and deeptech companies, the most dangerous pilot is the endless friendly pilot. It gives access and encouragement but no purchasing path. A strong pilot has:

Named buyer and technical owner.
Written success criteria.
Timeline and operating context.
Data access and responsibility.
Paid component or serious internal resource commitment.
Next commercial decision if criteria are met.

India can be a powerful place to build deeptech because large problems, cost sensitivity, engineering talent, manufacturing depth, and public-sector needs can create meaningful opportunities. But the market will not reward technology merely because it is impressive. It rewards technology that survives messy deployment and creates measurable value for a buyer with budget.

At every milestone, ask:

After this milestone, what becomes easier: customer purchase, manufacturing, certification, financing, deployment, or hiring?

If the answer is “we will understand the technology better,” that may still be valuable. But do not confuse internal learning with external progress. A startup milestone should move the company closer to a funded, bought, deployed, and supportable product.

Pilot Contract Term Sheet

Deeptech pilots need more structure than a friendly proof of concept. The best pilots teach the startup and move the buyer toward a commercial decision. The worst pilots consume founder time, hardware, travel, engineering, and credibility without a next step.

Before starting a pilot, agree on a short pilot term sheet:

Term	What to define
Buyer owner	Business owner who cares about the outcome, not only the technical sponsor.
Technical owner	Person responsible for site access, data, integration, or field operation.
Success criteria	Quantitative and qualitative criteria that decide whether the pilot worked.
Baseline	Current cost, downtime, energy use, yield, defect rate, process time, or risk.
Data rights	What data can be collected, stored, analyzed, shared, and published.
Responsibilities	Who provides equipment, access, training, safety approvals, operators, and support.
Payment	Paid pilot, material reimbursement, deployment fee, or committed internal resources.
Timeline	Start date, review checkpoints, end date, and decision date.
Next step	Purchase, expansion, joint development, grant application, or stop decision.

If the buyer will not define success criteria, the pilot is research, not validation. Research may still be worth doing, but fund and manage it honestly.

Manufacturing Scale Readiness

A working prototype is not the same as a product that can be manufactured, installed, maintained, and supported repeatedly. Climate and deeptech founders should bring manufacturing thinking earlier than feels comfortable.

Use a readiness ladder:

Stage	Proof needed
Prototype	Works once under founder or lab supervision.
Repeatable prototype	Works multiple times with documented setup and known failure modes.
Pilot unit	Can survive field conditions, operator variability, and basic service needs.
Small batch	BOM, suppliers, assembly steps, quality checks, and spares are documented.
Deployable product	Installation, training, support, warranty, and safety process are defined.
Scalable system	Lead times, working capital, supplier risk, and service economics are known.

The founder should track:

Bill of materials and cost uncertainty.
Supplier lead times and single points of failure.
Quality control steps.
Field failure causes.
Installation and service time.
Working capital required per deployment.
Warranty or replacement risk.

If every deployment needs founder heroics, the company has not yet built a scalable product, even if the technology works.

Grant-To-Revenue Discipline

Grants, incubators, challenges, and government programs can be valuable for deeptech companies. They can also become a distraction if they replace buyer discovery.

Use this rule:

Every non-dilutive funding effort should retire a risk that customers, investors, or deployment partners care about.

Before applying for a grant, write:

Question	Answer
What technical or commercial risk will this money retire?
Which buyer or deployment partner cares about that proof?
What milestone will exist after the grant period?
How will this milestone support revenue, financing, or certification?
What founder time will the application and reporting consume?

Do not optimize the company around winning programs. Optimize around proof, deployments, revenue, and capital readiness.

Pilot-To-Procurement Conversion Review

Deeptech and climate founders often collect pilots but struggle to convert them into purchase orders. The pilot feels like progress because real customers are involved. But a pilot that has no buyer, no budget path, no success criteria, and no decision date is often unpaid consulting or research.

Run a conversion review for every pilot:

Review area	Founder question
Economic buyer	Who can approve a paid deployment after the pilot?
Technical owner	Who will judge whether the solution works?
Operational owner	Who must install, maintain, run, or support it?
Procurement path	What vendor onboarding, compliance, budget, legal, or safety process exists?
Success metric	What baseline and target decide success?
Evidence package	What report, data, photos, logs, savings, yield, uptime, or quality proof will be produced?
Commercial next step	What paid step follows: purchase order, expansion, joint development, paid pilot, or service contract?
Decision date	When will the buyer decide, and what happens if they do not?

Create a pilot closeout packet:

Packet item	Purpose
Baseline vs result	Shows measurable change.
Cost and ROI estimate	Helps buyer justify purchase.
Failure modes	Builds trust by naming limits.
Installation and support effort	Makes scale operationally credible.
Buyer testimonial or internal note	Gives the champion language to sell internally.
Next-step proposal	Converts learning into commercial action.

If the customer refuses to discuss procurement, the founder should label the pilot honestly. It may still produce technical learning, but it should not be counted as sales traction.

Technical Risk Burn-Down Ledger

Deeptech companies carry many kinds of risk at once: science, engineering, manufacturing, certification, deployment, safety, cost, supply chain, and market adoption. Founders need a way to show that risk is being retired, not merely discussed.

Maintain a technical risk burn-down ledger:

Risk	Why it matters	Current evidence	Next test	Success threshold	Owner	Date
Core performance
Field durability
Manufacturing yield
Unit cost
Safety or compliance
Installation and service
Buyer adoption

Review the ledger with investors, advisors, and pilot partners. It should make the company easier to understand. A good ledger says:

Here is what was risky last quarter.
Here is what we proved.
Here is what remains risky.
Here is the next cheapest credible test.

This discipline is especially useful for Indian deeptech founders because capital, lab access, manufacturing partners, and buyer patience may all be constrained. The company cannot afford vague progress. It needs proof that unlocks the next resource.

Common Mistakes

Tech without buyer.
Long pilots.
No commercialization path.
Weak IP strategy.
Underestimating capital.
Poor manufacturing planning.
Treating grants as market validation.
Ignoring service and maintenance.
Not planning for certification or standards.

Reader Action

Create a deeptech risk map:

Proof area	Next milestone	Evidence required	Owner	Cost	Date
Scientific proof
Engineering proof
Manufacturing proof
Buyer proof
Regulatory proof
Financing proof

Use this map to decide what the company must prove next, not what feels most exciting to build.

Deeptech Commercial Readiness Review

Deeptech progress can look impressive while commercial readiness is still weak. A prototype may work, a grant may arrive, a pilot may generate excitement, and still the company may not know who will buy, who will operate, who will maintain, and what scale will cost.

Before raising a larger round, expanding pilots, or committing to manufacturing, run a commercial readiness review:

Area	Evidence needed	Founder question
Technical proof	Test results, failure modes, repeatability, performance under realistic conditions.	Does the solution work outside the best-case demo?
Buyer owner	Named economic buyer, budget source, procurement path, decision criteria.	Who can actually approve payment?
Use-case priority	Pain severity, regulatory pressure, cost saving, revenue upside, strategic need.	Why would the buyer move now?
Pilot design	Success metric, timeline, buyer resources, data access, conversion terms.	Is the pilot designed to become a purchase?
Unit economics	BOM, service cost, installation, maintenance, logistics, gross margin path.	Does scale improve the economics or reveal hidden costs?
Manufacturing or delivery	Suppliers, quality control, capacity, lead times, installation capability.	Can we deliver reliably after the first few units?
Certification and standards	Tests, approvals, buyer requirements, insurance or safety needs.	What must be true before a serious buyer can adopt?
IP and defensibility	Patents, know-how, data, manufacturing learning, partnerships, switching cost.	What remains defensible if a larger company notices the market?
Capital plan	Milestones tied to technical, commercial, and manufacturing proof.	Does each rupee remove risk that matters to the next funder or buyer?

A good deeptech pilot has a commercial path built into the contract or memo:

Pilot term	Strong version
Success metric	Clear performance, cost, reliability, or operational target.
Buyer involvement	Named owner, access to site or data, weekly review.
Timeline	Short enough to preserve urgency, long enough to test reality.
Conversion path	Purchase order, paid expansion, preferred vendor step, or procurement trigger.
Cost sharing	Buyer contributes money, equipment, data, people, or operational access.
Learning rights	Founder can use non-confidential learning to improve product and fundraise.

If a buyer will not contribute anything meaningful to a pilot, ask whether the problem is urgent. Free pilots can be useful when they unlock hard evidence, but they can also become a polite way for large organizations to learn from startups without buying.

The deeptech founder has two products to build: the technology and the adoption path. If the adoption path is weak, even good technology can remain trapped in demonstrations.

Deeptech Proof-To-Capital Map

Deeptech founders should connect each proof milestone to the capital it unlocks. Otherwise the company may spend scarce money on impressive work that does not reduce the next financing or buyer risk.

Use this map:

Proof milestone	Evidence	Unlocks	Does not prove
Lab proof	Controlled test result, repeatability, failure conditions	Technical credibility	Field reliability or buyer urgency
Field pilot	Real environment performance, user/operator feedback	Deployment learning, buyer trust	Scalable economics
Paid pilot	Buyer contributes cash/resources	Commercial seriousness	Repeatable procurement
Certification/standard step	Test report, compliance path, advisor review	Buyer confidence, regulated adoption	Market demand
Manufacturing prototype	BOM, suppliers, quality checks, lead time	Scale planning	Margin at volume
First repeat order	Same buyer expands or repeats	Value and trust	Broad market pull

Before spending on the next milestone, ask:

Which risk does this milestone reduce?
Who cares about this proof: buyer, investor, grantmaker, regulator, partner, or manufacturer?
What decision becomes easier after this proof exists?
What proof would be more valuable than this?

Capital efficiency in deeptech is not about spending less on everything. It is about spending on proof that changes buyer, investor, or manufacturing reality.