AI startup pitch checklist for accelerators before demo day

Why polished AI pitches can fool a room

On stage, almost any AI product can look better than it is. A founder types a clean prompt, gets a clean answer, and the room sees speed and confidence. What the room does not see is the stack of failed prompts from rehearsal, the hand picked sample data, or the quiet reset five minutes earlier.

That is why a smooth demo is weak proof on its own. AI products look best on the happy path, where the input is tidy, the question is expected, and the model has seen something close to it before. Real users are messier. They paste broken text, ask vague questions, and expect the product to recover when it gets things wrong.

Founders know this, so many rehearse the exact flow that gives the strongest result. That part is normal. The problem starts when judges treat stage confidence as evidence that the product works outside the room. A sharp speaker can make a fragile product sound ready. A quieter founder with a real product can lose attention for no good reason.

AI makes this worse because the output feels intelligent even when the system under it is thin. The app might be little more than a wrapper around one model call. It might have no checks, no fallback, no cost control, and no sign that customers will keep using it after the novelty wears off.

One weak invite costs more than a few minutes on stage. It takes time from stronger teams, lowers the standard for the whole cohort, and can leave investors with the wrong idea about what your accelerator rewards.

A simple screening checklist fixes some of that. It shifts attention from showmanship to proof. If a team can only win when everything goes right, they are not ready for demo day. The room should reward products that still make sense after the script breaks.

Start with customer truth

A startup can show a slick AI demo and still have no real buyer. Before you look at models, prompts, or slide design, ask who pays for this now and what problem hurts enough that they will keep paying.

Founders often answer with broad claims such as "support teams save time" or "sales gets faster." Push past that. Ask for one customer type, one daily task, and one cost of doing nothing. Good answers sound concrete: a claims team cuts manual review from 45 minutes to 12, or a recruiter handles more applicants without adding staff.

Then check whether people use the product more than once. One friendly pilot proves very little. Friends, design partners, and innovation teams agree to experiments all the time. What matters is repeat use: weekly logins, renewed contracts, more seats, or a team that built the product into a real process.

You also want to know what the product replaces. If the honest answer is "nothing yet," the startup is still a demo. If it replaces a spreadsheet, an outsourced step, or a human review queue, you can test the claim against actual behavior.

When a deck says "cuts onboarding time by 80%," compare that number with the customer's own words. Customers rarely talk like slide writers. They say things like "we stopped chasing files by email" or "our ops lead no longer spends Sunday cleaning data." Those plain sentences tell you more than polished numbers with no context.

A short review usually reveals the truth. Who pays now? What pain do they feel this week? What did they use before? Did use continue after the pilot? Do customer quotes sound like real work, or like marketing copy?

If those answers stay fuzzy, keep digging. Demo day slots are scarce. A startup with rough slides and honest customer pull often deserves the stage more than one with a perfect demo and no proof that anyone needs it on Monday morning.

Look at the model, not just the app

A polished interface can hide a weak model choice. Two startups may show the same workflow, but one runs on a model that fits the job and the other runs on a cheap default that falls apart on long prompts, messy data, or unusual cases. Ask which model runs the product in production today, not which one they tested last month.

That question tells you a lot about how real the product is. A serious team can explain why they picked that model, what it does well, what it costs, and where they had to add rules or fallback steps around it. If the founders stay vague, the app may be doing more theater than work.

Failure matters as much as success. Ask where the model breaks and how the team learned that. Good answers are specific: it misses handwritten fields, invents facts in summaries, or loses accuracy when users switch languages. Better answers include evidence from pilot reviews, internal test cases, or support logs.

Human review matters too. If the product writes advice, changes records, ranks people, or sends messages that affect money or access, someone should check risky outputs before a customer acts on them. That review can be simple, but it needs clear rules.

Keep the model review plain. Which model runs the product today? Where does it fail most often? When does a person review the output? What happens to private data, stored prompts, and user consent?

Privacy deserves direct questions. Ask what data goes into the model, whether prompts or outputs are stored, who can read them, and whether customers agreed to that use. If the startup depends on outside model APIs, ask whether data leaves their system and what control the customer has.

If a team cannot answer those questions in plain language, the product is not ready for a live stage demo. A clean UI does not reduce model risk.

Put the demo under stress

A smooth demo proves very little. Founders rehearse one path, on one laptop, with one prompt, and the room sees a magic trick. You need to see what happens when the script breaks.

Ask for one live task the team did not prepare in advance. Keep it fair. Use a normal customer request, not a stunt. If they say the product summarizes calls, give them audio with cross talk or a speaker who changes topic halfway through. If they sell document analysis, swap in a messy PDF instead of the clean sample from the deck.

Small changes expose weak spots fast. Rewrite the prompt in plain language. Upload a different file type. Use noisier audio. Remove one field the model seemed to depend on.

Then watch the team when the answer goes wrong. Strong founders do not freeze or pretend the miss did not matter. They explain the limit, show the fallback, and tell you what a real user would see next.

Ask them to recover live. Can they retry with a better instruction? Do they flag low confidence? Can a human step in when the model drifts? Recovery matters more than a perfect first pass because customers rarely behave like demo data.

Their wording matters too. If they blame the model and move on, that is a bad sign. If they say, "This input is outside our current range, so we stop and ask for confirmation," they probably understand the product and its edges.

Speed matters as well. A tool that looks smart after 45 seconds may still fail on stage or inside a sales call. Mild pressure tells you whether you are looking at a real product or a polished scene.

Ask what happens after the pilot

A pilot can look great because the founder does everything by hand. They clean the data, watch every answer, and jump in when something breaks. Demo day should test what happens when that extra attention disappears.

Ask the startup to walk through a normal customer's first week. Keep it simple. Who sets up the workspace, connects data, writes the first prompt, and trains the team? If the answer is "we help closely at first," ask how that works with 20 customers instead of two.

A few checks tell you most of what you need. What does a customer do on day one, day three, and day seven? How many users come back after the first trial or first month? What happens to model cost if usage grows ten times? Who owns support when answers drift, integrations fail, or output quality drops?

Retention matters more than a polished first run. Many teams can win a trial because users are curious. Fewer teams can keep people coming back after the novelty fades. If the startup cannot name a repeat action, such as daily summaries, ticket replies, or lead scoring, the product may still be a demo in disguise.

Cost is where weak plans show up quickly. A founder may say each request is cheap today. That is not enough. You want to know what happens when one customer becomes ten, or when one team uploads full documents instead of short prompts. Margins disappear fast if model calls, storage, and human review all rise together.

Support is the last test. Answers drift. APIs change. Customer data gets messy. Someone needs to catch that, explain it, and fix it. A good answer names the owner, the response time, and the fallback when the model gives a bad result.

A simple example makes the gap obvious. An AI support copilot works well in a six week pilot with one careful client. Then the client adds three more teams, each with different rules. Response quality drops, tickets pile up, and the founder starts answering Slack messages at midnight. That is not scale. It is a rescue job.

Give more credit to a startup that knows these weak spots and has a plan for them. After the pilot, repeat use, support load, and unit cost decide whether the product has a business at all.

Run a simple review in six steps

A fast screen beats a long debate. Most weak pitches show their problems in one hour if you test the right things. Use the same review each time so founders get a fair shot and your team can compare startups on one page.

1. Read the deck with a pen in hand and mark every claim you can test. Circle lines like "90% accuracy," "fully automated," or "already used by enterprise teams." If a claim cannot be checked in a call or demo, flag it instead of giving it credit.

2. Call one real customer before you send the invite. Ask what they use the product for, how often they use it, and what broke in the first week. One honest customer call tells you more than ten polished slides.

3. Ask for one page that explains the product in plain words. You need to know where the model sits, what data it needs, and where a person still reviews output. If the answer stays fuzzy, the team may be selling a story more than a product.

4. Run one unscripted demo with your own inputs. Bring a messy example, not the founder's best case. Paste in a noisy document, an odd customer request, or conflicting data and watch how the product reacts.

5. Score three things on one sheet: model risk, demo risk, and customer truth. Use a 1 to 5 score for each, plus one sentence on why.

6. Decide right away: invite, waitlist, or reject. Add short notes so your team remembers why. "Strong customer pull, weak live demo" is enough.

One mismatch matters more than most teams expect: a startup that looks smooth on stage but still depends on manual work behind the scenes. That gap usually shows up in the customer call or the unscripted demo, and it is often enough reason to wait.

A realistic screening example

Picture a startup that says it cuts sales research from three hours to ten minutes. The founders show a smooth product: paste in a company name, get a short brief on the buyer, recent news, and outreach ideas. In a pitch room, that feels convincing.

Then you change the test. Instead of the clean sample accounts from the deck, you give them five real company websites. One has an old homepage. One loads slowly. One hides product details in PDFs. One has broken metadata. The tool still works on two sites, but the output for the other three turns thin, wrong, or strangely certain. That is not a side issue. Sales teams pay for help with messy inputs.

The customer proof looks softer too. The startup has two beta users who like the product and answer quickly when you ask for feedback. Neither one pays. Neither one can show a hard result like time saved each week, more meetings booked, or better reply rates. Friendly users matter, but unpaid praise should not carry a startup onto the stage.

At that point, a fair review does not need drama. You can tell the founders to come back with one paid customer, even if it is a small pilot, and a safer fallback for weak source data. That fallback could be simple: show a low confidence warning, limit the output to verified facts, or let the rep upload source files when the website is too messy.

If they return with a paying customer and a demo that stays honest when the data gets ugly, the story changes. Now you have proof that the product can survive outside a slide deck. If they cannot clear that bar yet, they may still become a good company later. They just are not ready for demo day.

Mistakes that waste demo day slots

The easiest way to waste a slot is to reward polish over proof. A team with a smooth deck, a fast demo, and crisp answers can still be selling very little. Some founders practice the stage version so well that reviewers stop asking plain questions like who pays, who uses it every week, and what broke last month.

Logo slides create the same problem. A startup may show five known brands, but one short pilot or a chat with an interested manager is not the same as real demand. Speak to at least one buyer or operator who uses the product. If the team cannot make that happen, treat those logos as marketing, not evidence.

Cost often gets ignored until someone asks the one question that changes the mood: can this business make money at scale? Many AI products look cheap in a demo because the founder hides inference spend, human cleanup, and support time behind the curtain. If a team cannot explain what it costs to serve one active customer, they are not ready for a main stage slot.

Model brand names can hide weak answers too. "We use GPT" or "Claude handles that" says almost nothing. Ask what the model actually does, where it fails, how the team checks bad output, and what happens if the provider raises prices or has an outage. A famous model can make a thin product look smarter than it is.

A good review puts customer truth, cost, and failure handling ahead of stage polish. The teams worth inviting may look less flashy at first. They usually sound more grounded, and they answer simple questions without hiding behind logos or model names.

Quick checks before you send the invite

A final screen should take 15 minutes, not a week. If a startup cannot pass a few plain language checks now, the cracks usually get wider on stage.

Use these checks before you lock the lineup:

• Ask for one real buyer who can describe the problem in simple words. If that person falls back on vague claims like "better efficiency" and cannot name the annoying task, the pain may not be strong enough yet.
• Ask the founders where the product fails. Strong teams answer directly. They can name weak inputs, bad documents, edge cases, or places where a human still needs to step in.
• Change something during the demo. Swap the prompt, upload a different file, or ask for a new user role. If the product breaks outside the scripted path, you are looking at stagecraft.
• Ask what it costs to run, what data it touches, and who helps customers after the sale. You want straight answers, not a tour through buzzwords or hand waving.
• Ask someone on your team to explain, in one minute, why this startup deserves the stage. If the answer is only "the demo looked impressive," keep digging.

A small example makes the difference clear. One team says, "Law firms use us to sort contracts faster." Another says, "A three person immigration practice uses us to pull missing clauses from intake packets, and the lawyer still reviews the final draft." The second answer is easier to trust because it sounds like real work.

If founders stay calm under these checks, that is a good sign. They do not need perfect answers. They do need honest ones, a demo that bends without snapping, and a reason your team can repeat to the audience without dressing it up.

Next steps after your review

Once the review is done, the main job is consistency. A startup that sounds smooth in one room should face the same standard as a quieter team in another. Use one scorecard for every AI applicant, keep the wording fixed, and score the same categories every time.

That sounds basic, but it changes the quality of demo day quickly. It stops mentors from rewarding confidence over proof. It also gives founders a fairer shot, especially when a team has a strong product but a less polished pitch.

Before demo day, send the review standard to every mentor, judge, and operator who will meet founders. If one person cares about customer proof and another only cares about stage presence, your screening turns into guesswork. A shared scorecard keeps the room honest.

After scoring, sort teams into simple groups: invite now, invite if they send one more proof point, hold for later, or pass.

For strong teams, ask for one more piece of evidence instead of a longer pitch. A five minute product tour rarely answers the real concern. One screenshot of live usage, one customer reference, or one week of retention data tells you much more.

This is also where outside review can help. If your accelerator sees a startup with bold AI claims, fuzzy infrastructure costs, or a demo that looks fragile, a second technical review can save a wasted slot. Oleg Sotnikov at oleg.is works as a Fractional CTO and startup advisor, and he helps startups and small teams review AI architecture, infrastructure costs, and the operating reality behind a polished demo.

Keep your reply to founders short and direct. Tell them what passed, what did not, and what proof would change the decision. That makes your process easier to trust, even for teams you reject.

A good review ends with a clear decision, not an open loop. If a team needs more evidence, ask for one thing. If they are ready, send the invite. If they are not, move on and protect the stage time for startups that can back up what they say.