Prepare your answers.

1. Your name

2. Email

3. Where you're based

4. Links: site, LinkedIn, X

   Website, LinkedIn, X, whatever shows your work. One line, comma-separated.

1. Startup name

2. Stage

   Pick one: Just an idea · Prototype · Launched · Making revenue · Raised a round

3. What are you building? (one line)

   This is the one place a single sentence is exactly right. What you do, for whom, and the outcome; concrete, no buzzwords.

   Co-founder pair example

   Fluxrail lets manufacturers coordinate robots from different vendors through one real-time control plane instead of stitching together separate proprietary systems.

4. Co-founder's name

5. Co-founder's email

6. How long have you worked together?

   Pick one: Under 6 months · 6–12 months · 1–2 years · 2+ years

7. Who does what?

1. What problem are you solving, and who has it?

   A few sentences: name the pain, who feels it most acutely, and how they cope today. Specific beats broad.

   Co-founder pair example

   A modern factory rarely has one robot fleet. It has pallet movers, robot arms and inspection systems bought from different vendors, each with its own controller and model of the world. Making them hand work to one another requires months of PLC code and a systems integrator; when a layout or product changes, that logic breaks. At the automotive supplier where we are piloting, 14 robots can each complete their task, but the line still loses roughly 11 hours a week at the handoffs between them.

2. Why your team? Your unfair advantage or unique insight

   A short paragraph on your unfair advantage, the insight, access, or ability most people don't have. Earned, not aspirational.

   Co-founder pair example

   Anika spent seven years building motion-planning and safety systems for warehouse robots; David built low-latency distributed systems for a power exchange where missed deadlines had physical consequences. Anika knows how robot vendors expose capabilities and has commissioned systems on more than 20 factory floors. David knows how to keep a shared scheduler correct when machines disconnect or disagree about state. We met while integrating autonomous movers into a plant David's previous team operated and have already shipped one cross-vendor controller together.

3. Who else is doing this, and why will you win?

   A paragraph: who else solves this (even 'a spreadsheet' or 'nobody'), and the specific edge that lets you win.

   Co-founder pair example

   Factories currently pay a systems integrator to connect vendor APIs with one-off PLC logic. Robot vendors offer fleet managers, but only for their own machines; newer orchestration products mostly route jobs and still delegate every cross-fleet handoff to custom code. Fluxrail gives each machine a common capability model, plans work across the full fleet and checks every command against a local safety envelope before it executes. The edge runtime keeps operating when the cloud is unavailable. Our biggest risk is adapter maintenance: if adding each robot model stays bespoke, our software margins disappear.

4. Traction so far

   A paragraph with real evidence someone wants this. Numbers help: users, revenue, growth, waitlist, pilots, retention. If you're pre-traction, say what you've learned instead.

   Co-founder pair example

   Our first paid pilot coordinates 23 robots from three vendors on one material-flow line. Over six weeks it scheduled 11,400 pallet moves, reduced robot idle time by 18% and cut handoff-related line stops from 17 to five per week. The customer pays €4,000 per month during the pilot and has agreed to expand to a second line if we reach fewer than three stops. A second manufacturer has signed an LOI. The uncomfortable number is integration time: the third robot model took us 12 days to support.

5. How big can this get if it works?

   A paragraph: how big this gets if it works, and the ambition behind it. Reason from your wedge out to the whole.

   Co-founder pair example

   We are starting with European manufacturers that already operate at least two robot brands on the same site. At €50k–€200k per factory annually, a few thousand suitable sites support a substantial standalone business. The larger opportunity is the execution layer for software-defined factories: one place to assign work, enforce safety and measure performance across robots, machines and human stations. We have evidence that customers will pay to fix cross-fleet handoffs. We have not yet earned the right to claim the rest of the factory stack.

6. What will you build during the week?

   A paragraph on the one thing you'd ship in seven uninterrupted days. Concrete and demoable beats grand and vague.

   Co-founder pair example

   We want to reduce support for a new robot model from 12 days to one. Anika will turn the commissioning process into a capability test suite; David will build a trace-to-adapter generator that proposes the protocol mapping and proves it against recorded commands in simulation. We will bring a cobot controller we have never integrated. By Friday it must accept a job, report state and complete a safe handoff with our existing fleet emulator. If we write vendor-specific scheduler code, the experiment has failed.

We back people, not résumés. Experience isn't a filter here; this is the part we actually read.

1. Why are you really building this?

   A few honest sentences on why you're really building this, not the pitch version. We read this one closely.

   Co-founder pair example

   We met during a factory shutdown caused by two perfectly functional robot systems disagreeing about who owned a pallet. Anika could see the physical deadlock; David could see the distributed-systems bug, but neither vendor owned the boundary between them. The plant lost most of a shift while six engineers argued across three dashboards. Fluxrail is the layer we wished had existed that night. We are building it because factories should be able to combine the best machines, not inherit a single vendor's limitations forever.

2. Tell us about a time you kept going when quitting made more sense.

   Tell the story: what happened, what quitting would have looked like, and what you actually did. Specifics make it real.

   Co-founder pair example

   In week two of the pilot, clock drift between two controllers created intermittent deadlocks that we could not reproduce in simulation. The customer gave us 72 hours before reverting to the old PLC logic. Anika worked night shifts beside the line and reduced each physical stop to a sequence of sensor events; David added a logical clock to the scheduler and replayed two million event orderings against those traces. We found a 40-millisecond ownership gap, fixed it and completed the next 3,100 transfers without a deadlock. The failure was in our architecture, and neither of us spent the deadline defending it.

3. What are the two of you like to work with?

   A short paragraph on what people who've worked with you would actually say, the good and the sharp edges.

   Co-founder pair example

   People who work with us would say Anika learns by putting the system on real hardware, while David wants to make the state model explicit before anything moves. That tension is useful until it becomes a stalemate. We now time-box lab design, write down the safety invariant together and let evidence from the factory decide the rest. Anika can over-promise dates to a customer; David can over-generalise from one edge case. We call those patterns out directly and do not use technical authority to win product arguments.

4. Something you've changed your mind about recently, and why.

   A paragraph on something you've genuinely updated on lately, whether your market, your product, or yourself, and why.

   Co-founder pair example

   We originally designed one global scheduler in the cloud because it produced the most efficient plan. During a routine network outage, the robots stopped safely—but the entire line stayed idle even though most local tasks were independent. We changed to hierarchical control: the cloud optimises across the fleet, while edge agents retain enough authority to finish safe local work. It is less elegant and occasionally less efficient. It is also a much better fit for factories, where graceful degradation matters more than a perfect global schedule.

5. Why noclue, why now?

   A paragraph: why this program, and why now for you and the company. Specific to noclue beats generic.

   Co-founder pair example

   Our next constraint is both technical and existential: prove that a new robot adapter can be generated rather than hand-built. Seven uninterrupted days are enough to test that claim end to end, and the other technical founders at noclue are exactly the people we want challenging whether our interface is genuinely general or merely clever demo code. We would arrive with an unsupported controller and leave with a live cross-vendor handoff. Success changes our margins; failure tells us Fluxrail is still systems integration disguised as software.

6. CV or résumé (optional)

   Genuinely optional. We look for people, not CVs, so only add one if it helps you tell your story.

7. Pitch deck (optional)

   If you have one. A few rough slides is plenty; we don't need a polished raise deck.