How to Demo Your Application to a New Development Team: A Helpful Guide

When you start working with a new development team, one of the first and most valuable things you can do is walk them through your application. It's more than just clicking around—it's about sharing the story of your app: what it does, who it serves, and how it's built.

We’ve seen a lot of client-led demos, and we’ve learned what makes them effective—and what leaves teams guessing. This post outlines a simple framework for walking a development team through your application. It includes key talking points to help you deliver a clear and helpful overview that saves time and builds shared understanding from the start.

We’ll cover:

• How to introduce your business and users.
• What technical details are most beneficial to share early on.
• What’s changed in your app recently—and what’s coming up.
• How to prepare the team for emergencies and escalations.
• What kind of support you need from the dev team week-to-week.

By the end, you’ll have a helpful checklist for your next application walkthrough.

1. Start with the Big Picture: Your Business and Your Users

As the new team onboards to your application, it will be important to highlight the technical aspects of what the application does. However, something people often miss when demonstrating to a new team is explaining the why behind the application.

• What business purpose does your app serve?
• Who are your users?
• What problems does it solve for them?
• How do you interact with those users?

Start from the 30,000-foot view:

→ “Our users are [x] who want a way to [y].”

Then, take on the personality of a daily user:

→ “So if I want to get [y] from the app, I would log in and navigate to [critical page #1] or [critical page #2].”

Finally, show how your team engages with those users:

→ “As a customer service representative, we can pick up a user’s case and [do x] or [do y].”

This context helps the engineering team understand why they’re building and supporting the product, making it easier to navigate the app with purpose instead of aimlessly clicking around.

2. What Does the Application Do?

After covering what the application looks like for users and administrators, it is time to move over to the more technical functions of its structure. A senior engineer, CTO, or technical project manager would best lead this section of the demonstration.

Here, we should aim to answer questions like:

• Where is the application hosted?
• Is there up-to-date documentation on how to set up the application?
• Are there important services that the onboarding team needs to be aware of (like Sidekiq Pro or AppSignal)?

Here are a few key areas to touch on:

Hosting and setup:

→ “When we have a new engineer starting, the first thing we ensure they have access to is [x].”

Application history:

→ “This started as a basic [code framework] app but has since expanded to include [other frameworks/tools].”

Important services:

→ “We use Sidekiq Pro for background jobs and AppSignal for monitoring.”

Known quirks or exceptions:

→ “An important thing that may not be super clear in the documentation is [x], which exists for [y purpose].”

Build process:

→ “When a change is ready, the testing suite runs and then [x] happens.”

These insights give the onboarding team a strong technical foundation to begin working efficiently.

3. Where Does the Application Stand Today?

After giving the team an idea of what the business does and how the application is set up, it’s time to get into the current state. This section aims to give the team a healthy understanding of what new features have been implemented recently, any ongoing issues, and cover important things to be aware of for future work.

What’s new:

→ “In the last three months, we added a new way for users to [x].”

What’s wrong:

→ “We’ve been having issues with [x] and [y], which we [have/haven’t resolved yet].”

What’s bothering you:

→ “It hasn’t happened in a while, but every few months, I worry about [x].”

What’s coming:

→ “In the next two months, the Ops team would like to see [x] happen.”

This helps the team prioritize their focus areas and understand where they can add the most value.

4. Preparing the team for emergencies

Emergencies are never fun, but they happen. Use this part of the demo to walk the team through what to do when something goes wrong.

• What do you do when things go poorly?
• Where do you look if there is an outage?
• How have outages historically escalated to the engineers?
• Have there been recurring themes in the recent outages?

How escalations happen:

→ “Historically, [x person/people] are the first to tell us when something is wrong.”

Where to look:

→ “When we get a report, we start by checking [x]. That usually tells us [y].”

Recovery process:

→ “If we need to rollback to a previous version of the app or database, here’s how we typically do that.”

Sharing your existing process gives your new team a sense of confidence and preparedness for when things break.

5. Helping Teams Help You

Finally, wrap up your demo by discussing what a successful working relationship looks like. Be clear about how you like to work, how you prefer to get updates, and what you expect from your dev partners.

For more on how to build collaborative and inclusive developer relationships from day one, check out this episode of Maintainable Software Podcast with April Wensel, where she shares thoughtful insights on navigating legacy code with empathy and intention.

Cadence:

→ “Every Tuesday morning, our operations team meets to review priorities and plan the next few weeks. I need updates on [x] and any [y] incidents before that meeting.”

Preferred processes:

→ “It’s easiest for me if updates are made in [x-way].”

Escalation protocols:

→ “If there’s a new incident or outage, I’m responsible for notifying [x-people]. For that, I need to know [y] and [z].”

Making it happen 🚀

Demos don’t have to be polished or perfect, but they do need to be intentional. A clear, thoughtful walkthrough of your application helps your new engineering team get up to speed faster, make fewer assumptions, and deliver better work sooner.

The more context you give, the more your development partners can support your business goals effectively.

---

We Think You’ll Also Enjoy Reading…

• Develop Your Project Requirements with Four W’s
• 5 Questions to Ask Your Ruby on Rails Support Team
• What Value Is A Ruby on Rails Code Audit?

FAQ’s

Q: Before demoing my application to a new development team, what should I prepare?

A: Before your demo, jot down a few notes about your app’s core users, business goals, recent features or bugs, and any known technical quirks. Sharing key links (like documentation or staging credentials) in advance is also helpful.

Q: Who should lead the application demo on our side?

A: Ideally, the demo should be a team effort: a product owner or project manager can provide business context while a senior engineer or technical lead can walk through the architecture and infrastructure details.

Q: What if I don’t have documentation for some parts of the app?

A: That’s totally okay—your demo helps fill in those gaps. The development team can also assist you in documenting things as they go. Check out our post on Ruby on Rails Code Audits: 8 Steps to Review Your App to learn how we uncover undocumented parts of apps.

Q: How long should the demo be?

A: Plan for around 30–60 minutes, depending on the complexity of your app. It’s okay if not everything is covered in one sitting—this initial demo is just the start of the onboarding process.