a startup readiness checklist

use it before the next commitment

work through this with your co-founder or the person responsible for the next milestone. for each question, record what you know, its date, the source and what would change your mind. mark it as observed, estimated or unknown. an early-stage business should have unknowns; hiding them makes the decision harder.

this is a preparation tool, not a score or an investment threshold. a completed checklist does not establish that a company is ready for funding.

eight questions worth answering

• customer: who experiences the problem, when did it last happen and what did they do about it?
• impact: what would improve compared with that current approach, for whom, and how could you measure the difference?
• access: can you reach a specific group to test the idea? distinguish a possible introduction from agreed permission to run a pilot.
• product: what is the smallest useful result you can deliver? what must work reliably for a customer to trust it?
• revenue: who pays, what would bring them back and what does delivery cost? separate evidence from the model you hope to build.
• international potential: which other market has the same need, and which parts of your first-market advantage might not travel?
• people: who owns the next decisions, what relevant work have they done and where is help needed?
• next commitment: what decision will the next test inform, what resources does it require and what result would make you stop or change course?

match the evidence to your stage

build: bring a defined problem, an initial customer observation and a testable hypothesis. revenue is not required to begin the conversation.

accelerate: show your product or meaningful validation, the constraint you face and what improvement would matter. customer behaviour is more useful than a list of activities.

series a: support the growth case with dated operating evidence. explain retention, revenue quality, distribution, cash needs and the next market. describe inconsistencies rather than smoothing them out.

turn an uncertainty into a decision

suppose a team believes that maintenance managers will pay for fewer unplanned stoppages. “customers like our dashboard” does not resolve that hypothesis. a better test identifies a specific equipment class, an agreed baseline, the person who can authorise a pilot and what an improvement would be worth to the buyer.

this is an illustrative example, not a lab2sky portfolio case. choose a test that can disprove your assumption. record the cost and time limit before starting, then compare what happened with the decision rule you agreed.