For AWS re:Invent 2026, infrastructure software teams need more than a polished booth presentation. Build a short demo around one operational problem, show the workflow that resolves it, prepare answers about architecture and security, test a fallback for unreliable connectivity, and give every relevant visitor a way to revisit the experience after the event.
Our recommendation is to prepare two connected assets: a presenter-led technical demo for questions that need discussion, and a self-guided walkthrough for the booth, follow-up email, and internal sharing. DemoGo helps teams create step-by-step SaaS walkthroughs on desktop without browser plugins, customize them for different audiences, and self-host them on their own website. The walkthrough should clarify the product story, not stand in for a live validation of performance, integrations, or deployment claims.
The checklist below moves from story selection to technical rehearsal and post-event follow-up. It applies whether you sell observability, cloud security, developer platforms, cost management, or another infrastructure product. AWS re:Invent 2026 is scheduled for November 30 through December 4 in Las Vegas. Before planning travel or booth operations, check current details through AWS event guidance.
What is an infrastructure software demo checklist?
An infrastructure software demo checklist is a release-readiness test for the experience a buyer will see. It covers the story, the working environment, the evidence behind each claim, the presenter’s ability to answer technical questions, and the next action after the conversation. A demo passes only when those parts agree with one another.
That standard matters because infrastructure value is often hard to see directly. A screen might show a deployment approval, an alert, or a cost recommendation, while the buyer is really evaluating a larger question: What data entered the system, who had permission to act, what changed, and what would happen in our environment? A useful conference demo makes that chain visible without pretending a guided preview is a production proof of concept.
At DemoGo, we use a simple planning frame for these conversations: problem, action, evidence, boundary, next step. State the operational problem; show the action in the interface; point to the evidence a buyer can inspect; explain what the demo does and does not establish; then propose the appropriate deeper evaluation. This keeps a short tour credible even when the underlying system is complex.
Before you build: choose the buyer and the proof
1. Choose one question the core demo must answer
Do not begin by choosing screens. Begin with a buyer question: How does an operator investigate a change? How does a developer request infrastructure? How does a security reviewer see who approved an action? A question gives the presenter a stopping rule. If a feature does not help answer it, save that feature for another conversation.
Write a one-sentence objective that names the audience, workflow, and evidence. For example: “Show a platform engineer how a service request moves from submission to an approved result, including the review point.” That sentence is a hypothetical demo brief, not a claim that any particular product supports that workflow. Replace it with a sequence your product actually performs.
Decide separately what success means for the event team. A booth interaction might aim to secure a technical meeting, identify a relevant use case, or help a prospect evaluate a workflow later with colleagues. Avoid treating every scan or tour start as a qualified sales conversation. Define the action you want, then make the demo capable of leading to it.
2. Give each audience a different entry point
Infrastructure buying groups rarely ask the same first question. A platform engineer may want the configuration path; an operator may want the incident workflow; a security reviewer may ask who can access data; a finance stakeholder may need to understand the cost decision. Build a shared core story, then vary the opening and the evidence rather than creating unrelated product presentations.
- Platform and developer teams: Start with the request or change, show the steps a user takes, and identify what requires administrator involvement.
- Operations teams: Start with the signal that prompts action, then show where investigation happens and what the operator can do next.
- Security teams: Start with the data and access questions. Show applicable controls in the product and explain which questions need a separate security review.
- Engineering leaders: Start with the operational decision and the work it replaces. Describe outcomes your team can substantiate, without inserting an unsupported time-saving figure.
Use a simple opening question at the booth, such as “Which part of this workflow is hardest for your team today?” Then select the closest path. For a more detailed approach to presenting hard-to-see systems, see our guide to making invisible infrastructure understandable in a demo.
3. Inventory every claim before it appears on screen
Make a claim sheet for each demo path. List the exact statement, the screen or artifact that supports it, the product version being shown, and the person who can approve it. Separate three categories: what the interface visibly demonstrates, what your documentation explains, and what requires a live evaluation in the buyer’s environment.
For example, a guided tour can show the sequence for reviewing a proposed configuration change. It cannot, by itself, establish how long a real deployment takes under a buyer’s load or whether every integration behaves the same way. Do not attach a performance, security, or savings claim to a screenshot just because the interface looks convincing. Put the proof burden where it belongs.
Build a demo that shows cause and effect
4. Open with a recognizable operating situation
Many infrastructure demos open on a dashboard full of graphs and assume the buyer will infer why they matter. Give the screen a job instead. Name the event that brought the user there, the decision the user needs to make, and what could go wrong if they choose poorly.
Imagine an operations team investigating a service alert. A useful opening identifies the alert, the affected service, and the question the operator is trying to answer. The next screens should show the investigation and the resulting action, not an unrelated tour of every navigation item. If your product does not support that exact flow, choose an operating situation it does support.
Keep sample data credible but controlled. Use names that make the relationships between services, environments, and users understandable. Remove customer records, credentials, tokens, internal addresses, and private architecture details before capture. A fictional dataset should look like a coherent workflow, not like a collection of dramatic numbers added for effect.
5. Show input, decision, action, and result
For each key step, ask four questions: What entered the product? What did a person or system decide? What action followed? Where can the buyer see the result? These questions expose gaps that a feature-led presentation can hide.
- Input: Show the request, signal, policy condition, or other starting point.
- Decision: Explain which information the user considers and who is authorized to decide.
- Action: Show the actual product interaction, not merely a slide naming a capability.
- Result: Point to the state change or recorded output and explain what it means.
If a workflow crosses another system, show the handoff clearly. Name the source and destination only when those integrations are part of your actual product. Explain what travels between them and what the buyer would need to configure. Our integration demo playbook offers a useful way to prepare that explanation without making a fragile external service the centerpiece of the booth experience.
6. Make the short version complete
A conference conversation can end at any point. Design a short path that reaches a meaningful result and a clear next step without requiring the presenter to unlock a longer sequence. Keep a deeper version ready for a scheduled technical discussion. The deeper version can examine configuration, permissions, integration boundaries, exception handling, and implementation requirements.
Write short on-screen instructions that describe what the visitor is about to learn. “Review the proposed change” is more useful than “Explore our powerful workflow.” Give each step one purpose. If the explanation needs a long paragraph, break the workflow at a natural decision point or move the detail into a technical follow-up resource.
Then rehearse both versions with someone who did not build them. Ask that person to explain what changed at the end and what they would still need to validate. If they remember the feature names but cannot describe the operating result, revise the story.
Technical readiness: test the failure modes, not just the happy path
7. Audit the environment and every dependency
Make a dependency list for the presenter-led demo: device, display, browser, network, authentication, test tenant, data refresh, external integrations, and any account used to trigger actions. Assign an owner and a recovery step to each dependency. If a session expires, does the presenter know which account to use? If a dataset is reset, will the first screen still make sense?
Rehearse on the hardware and display arrangement your team expects to use. Check whether text can be read from a standing distance, whether pop-ups appear off screen, and whether the path still works when a presenter is interrupted mid-step. Avoid relying on sound to explain a key action in a noisy setting.
Prepare a separate fallback for the core story. A controlled, self-guided walkthrough is valuable when a live tenant or external dependency fails, but label it as a guided product preview rather than presenting it as a live system response. A fallback protects the conversation; it does not replace a buyer’s opportunity to examine the real product later.
8. Review data and access with the right owners
Conference preparation should include a review of what is visible in captured screens as well as what is accessible in the live demo account. Check account names, notifications, logs, URLs, and small text around the focal area. Sensitive details often sit in the background, not in the button the presenter intends to show.
Use role-appropriate demo accounts where your product supports them. Confirm that the presenter can show the intended path without exposing administrator-only controls unnecessarily. For a shareable tour, review every captured screen before publishing and repeat that review after substantial product changes. Our demo review workflow for marketing, product, and security can help clarify who signs off on each type of change.
Self-hosting gives your team control over where a tour is published, but it does not remove your responsibility for access decisions, asset review, or website configuration. Treat a public walkthrough as public content unless you have deliberately restricted access to it.
9. Prepare concise answers to the questions a tour cannot settle
Keep a technical answer sheet beside the demo, with an owner for unanswered items. Infrastructure evaluators may ask where data is processed, what network access is required, how permissions are managed, which deployment options exist, what happens when an integration is unavailable, and how implementation is tested. Write answers for your actual product and avoid improvising commitments at the booth.
Use the answer sheet to route rather than overexplain. If a visitor needs a detailed architecture review, offer one and record the exact question. If they ask about a control the presenter cannot substantiate, say what will be checked and who will respond. A crisp handoff is more credible than a confident guess.
Package the walkthrough for the booth and beyond
10. Build one self-guided path per priority problem
A useful post-event tour mirrors the conversation a visitor actually had. Someone investigating operational visibility should not receive a generic company overview; someone evaluating an administrator workflow should see the relevant actions and controls. A small set of focused paths is easier to maintain than a single tour that attempts to cover the whole platform.
DemoGo is particularly practical for this part of the plan: teams can capture pages, add guided steps, customize the narrative, and share the resulting walkthrough. Its desktop creation workflow does not require a browser plugin, and self-hosting lets a team publish tours on its own website. Use those capabilities to keep the follow-up experience consistent with the booth story while leaving space for a separate live technical evaluation.
Before publishing, check the tour on the devices visitors are likely to use. Test the opening step, navigation, any lead capture you choose to use, and the final call to action. Have a colleague read it without hearing your booth pitch. The tour should still explain the problem, show the outcome, and make the next step understandable.
11. Make the invitation match the context
At a booth, an invitation can be as direct as “Explore the investigation workflow.” In a follow-up email, connect the link to the question you discussed. On a website, use the problem the page addresses. Avoid a QR code or button that says only “Learn more” when you can name the workflow the visitor will see.
Place the tour where it can help someone continue independently, but do not make scanning a code a condition for a useful conversation. Some visitors want a live explanation; others need a short experience they can share with a colleague. The best event plan supports both. Our guide to self-guided conference demos accessed by QR code covers that handoff in more detail.
12. Decide when to request contact information
Lead capture works best when its purpose is clear. If the visitor has not yet seen the workflow, asking for details may interrupt exploration. If they want a technical assessment, a meeting, or a tailored follow-up, contact information serves a specific next action. Match the request to the stage of the conversation rather than using the same gate everywhere.
Record the problem the visitor raised, the path they saw, and any technical question requiring follow-up. Keep that context with the lead so the next message does not restart discovery from scratch. If your team uses tour engagement data, interpret it alongside those notes. Opening a walkthrough indicates interest in its topic; it does not, on its own, establish budget or purchase intent. For a fuller measurement approach, read how to separate tour engagement from purchase intent.
Run the booth with a repeatable handoff
13. Train presenters to qualify, show, and stop
Give presenters a small set of opening questions and permission to choose the most relevant one. “What prompted you to look at this category?” and “Which system or team owns that process today?” usually reveal more than a long introductory pitch. After the answer, show the matching path and stop when the promised result is visible.
Rehearse how to handle interruptions. A visitor may jump straight to deployment, pricing, or a particular integration. The presenter should be able to answer within their knowledge, return to the workflow if useful, and arrange a deeper discussion when necessary. Do not make them finish every screen to declare the interaction successful.
Agree on a handoff note format: visitor role, problem, relevant product path, unresolved question, and agreed next action. Those fields are more useful to the next person than a badge scan with no context.
14. Set distinct next steps for distinct levels of interest
A visitor asking an architectural question may need a solutions discussion. A visitor exploring the category may benefit from a self-guided tour. An existing customer considering another workflow may need an account-specific conversation. Decide which team owns each route before the event and make sure the presenter knows how to offer it.
Do not pressure every visitor toward the same meeting request. A precise next step might be “Let’s review the data flow with your security team” or “I’ll send the operator walkthrough you asked about.” The aim is continuity, not a larger count of loosely defined leads.
After the event: keep the technical thread intact
15. Follow up on the problem, not the badge
Use the conversation note as the first line of your follow-up. Restate the workflow discussed, link to the relevant tour, answer any question you can substantiate, and name the person responsible for outstanding technical detail. If the visitor asked about a specific integration, avoid sending a broad product overview as though it answers the question.
A good message is short enough to forward internally. The walkthrough gives absent stakeholders a common reference, while a separate architecture or security discussion handles questions the guided experience cannot resolve. See our champion follow-up kit for a way to organize those materials.
16. Review the questions that the demo failed to answer
After the event, compare presenter notes with tour behavior and meeting requests. Which question came up repeatedly? Which step required verbal explanation every time? Where did visitors ask to see the underlying system? These are useful signals for revising both the product story and the supporting technical resources.
Do not judge the experience by views alone. Review whether the right audience reached the intended result, whether the follow-up matched their interest, and whether technical questions reached the right owner. Assign someone to update the tour when the interface or claims change. An outdated walkthrough can undermine the credibility earned in a strong booth conversation.
Best practices to apply at every stage
- Show the result before touring the navigation. Buyers need a reason to care about each screen.
- Use real product behavior for technical claims. Treat a guided preview as an explanation of a workflow, not evidence of production performance.
- Make sample data coherent and safe. It should support the story without exposing customers or internal systems.
- Keep an explicit boundary between the core story and deeper validation. This makes it easier to finish a short conversation without evading difficult questions.
- Write for a reader who was not at the booth. Follow-up tours must stand on their own when forwarded to another stakeholder.
- Assign ownership for changes. If the UI, integration behavior, or approved messaging changes, the demo needs another review.
Final pre-event checklist
- One buyer question and one completed workflow anchor the core demo.
- Each priority audience has a relevant opening and next step.
- Every on-screen technical claim has an approved explanation or evidence source.
- Sample data and captured screens have been reviewed for sensitive details.
- The live path has been tested on expected event hardware and accounts.
- A clearly identified fallback can explain the core workflow if a dependency fails.
- Presenters know how to route architecture, security, and integration questions.
- The self-guided follow-up has been checked without presenter narration.
- Lead notes capture the visitor’s actual problem and agreed action.
- An owner is assigned to follow-up and to maintain the demo after the event.
Frequently asked questions
What should an AWS re:Invent infrastructure demo show first?
Start with the operational problem and the decision the user needs to make. Then show the relevant input, product action, and visible result. Opening on a dashboard without context makes the buyer do the interpretive work.
Should we use a live environment or a guided walkthrough at the booth?
Use a live environment when the conversation requires inspection of actual behavior and the environment is ready. Use a guided walkthrough for a consistent short story, for self-service exploration, and as a clearly identified fallback. Keep a path to deeper technical validation.
How do we demonstrate an integration if an external service is unreliable?
Prepare a controlled explanation of the data flow and handoff, using an approved product path or guided preview. Be clear about which part is illustrated and arrange a separate live validation when the buyer needs to test integration behavior in their own setting.
What belongs in a post-event interactive demo?
Include the problem discussed, the actions that lead to the result, a concise explanation of the boundary or control the buyer cares about, and one relevant next step. Avoid sending the same broad tour to visitors who asked different questions.
Can self-hosting replace a security review?
No. Self-hosting determines where the walkthrough is published. Your team still needs to review its visible content, decide who can access it, configure its hosting environment, and answer the buyer’s separate questions about the infrastructure product being evaluated.
How should we measure whether the event demo worked?
Look at the quality of the follow-up, not just the number of interactions. Compare the visitor’s stated problem with the path they saw, the next action they accepted, and the technical questions resolved afterward. Use tour engagement as context, not as automatic proof of buying intent.
Conclusion
The strongest re:Invent demo is not the one with the most screens. It is the one a visitor can explain to a colleague: this was the problem, this is what the product did, this is what we still need to test, and this is the next conversation. Build that story first, then test its technical dependencies and make the same focused explanation available after the booth closes.
If your team needs a shareable version of that story, DemoGo offers a free starting point for creating step-by-step interactive SaaS walkthroughs on desktop, with plugin-free creation and an option to self-host the finished tour.