Task:
Please review the following video transcript and perform a comprehensive edit to ensure it meets professional standards.

Instructions:

1. Correct Grammar, Punctuation, and Spelling:
- Identify and fix any errors in grammar, punctuation, and spelling throughout the transcript.
- Ensure that sentences are structured correctly and convey the intended meaning clearly.

2. Verify Terminology and Concepts:
- Check that all technical terms and concepts relevant to the video's subject matter are accurately used.
- Replace any incorrect or ambiguous terminology with appropriate and accurate language.
- Ensure consistency in the use of terms throughout the transcript.

3. Enhance Clarity and Precision:
- Rephrase any awkward or unclear sentences to improve readability.
- Eliminate unnecessary repetition or redundancy.
- Maintain the original meaning and intent behind each statement.

4. Preserve Original Meaning and Tone:
- Retain the speaker's original tone and style to the extent possible.
- Ensure that the edits do not alter the intended message or nuances conveyed in the transcript.

5. Format for Readability (Optional):
- Organize the content into clear paragraphs.
- Use headings or subheadings if it helps improve the structure.
- Consider adding bullet points for lists or key points to enhance readability.

Objective:
The final edited transcript should be a polished, accurate representation of the original video content, easy to read and understand for the intended audience.
"""
And we can start letting people in And I think that's good Yeah You want to just go ahead and let people in I'm going to turn off the Yeah Yeah I'm going to turn off the noise that it makes when they come in cuz that's going to drive me insane Awesome Welcome everyone We're going to uh give people a few minutes to get here you you can feel free to chat with us in the chat I've got my co-host here Robin She's graciously agreed to help us manage everything I'm going to make Kelly a co-host as well so she can unmute herself as she likes Here we go Awesome Um Well while we're waiting for people to show up if anybody has any questions to get started or any any hopes or wishes that they want us to uh to cover today and in case I forgot to put it in my list I'd love to see anything that you're curious about Kelly how's it going You still can't unmute I thought I made you a co- co-host Let me see hang on Oh it keeps switching people there's so many people jumping in at the same time Oh yeah it looks like I did Okay I asked you to unmute All right I'm just uh a few more seconds and then we'll get started While we're waiting uh Tanya said if you had something you were specifically wanting to have her address anything that was missed in uh the you're really hoping that you get see it's always good to put that in the chats uh or you can ask a or ask any questions that you have and this way she can answer it throughout the thing throughout the presentation Yep perfect Yeah and Robin you can feel free to interrupt me as I go I like to I like to have um questions as they come up that way they're asked in context So All right Kelly did it work this time Hey Hey Hey Hey Hey Awesome How's it going Hi everyone Good I'm super excited to get started All right let's let's do it I think 2 minutes is enough time If uh if you have any questions I'm I as I'm going just go ahead and ask them and Robin will let me give me a shout and let me know Um let's begin Okay first I wanted to to introduce myself and give you my bubble background So I started bubbling in August of 2020 it was that beautiful initial quarantine time and I wanted a vacation but I couldn't go anywhere so I did a staycation and decided to learn bubble instead and never went back to what I was doing before Um I joined the partner program in Airdev as a developer in January of 2021 I quickly advanced to product manager uh I was promoted to product manager trainer and meanwhile while doing all of that I was busy founding this thing called Pro No Coders which is my business that I run now We started with office hours in February of 2021 and that is our flagship product and what we're known for It's where we meet right here on this Zoom seven times per week We have never canceled or postponed a session and I conducted the 945th one this morning and I'll be doing 946 tonight and we'll be at 1000 on May 8th and I'm super excited about that Our members are allowed to join any of our Zoom sessions in office hours and ask any no-code question that they like And uh to give you give you some stats today we had five members join each got to ask their question and two stuck around and got to ask a second question No-Code School is another product of ours We started it in March of 2022 We have over 200 hours of curriculum We ran the full curriculum live twice It includes a full course on what I'm about to cover today So whatever I can't cover in 1 hour is covered in 20 something uh maybe closer to 30 something hours in uh the product management course And now I sell the recordings in the No-Code School membership So if you wanted to catch those recordings they're available And then finally we are launching our code development program It's being it's been formalized this month It's our brand new program and we're going to be helping people build their own apps with bubble but in a more formal way and it all begins with this very conversation that we're going to have today on how to scope your app exactly how I demonstrate it here So Um our for our presentation this recording is going to be submitted to Kelly at DevDay as soon as possible after we finish If you have questions please don't hesitate to put them into the chat and Robin will communicate them to me Um I prefer to answer questions in context rather than at the end Um stay tuned until the end so you can get a copy of this workflow and other supporting materials that I have for you And I have a request So your first job if you would please use the chat to suggest an existing app feature that I can easily access for the final live exercise which is called forensic scoping So I'm going to take a brand new screen maybe one that I've never seen before maybe one that I've seen a thousand times and I'm going to do a forensic scope of it It's an exercise I like to do to uh teach people to reverse engineer the scope which is the first approximation to doing your own scope writing your own scope Please include the link in your message in the chat so Robin can send it to me when it's time And then go ahead and vote on the suggestions you like You can vote for as many of them as you want with a heart reaction The one with the most reactions will be chosen All right That's it for intro stuff So let me close it all up cuz I like to keep things tidy while I'm talking So why Why the heck would you do a scope Um I uh honestly as long as I've been doing scopes I uh I find it pretty funny that people are like I don't need a scope Why would I use a scope Um the first reason is it it serves as a source of truth for the work So um in this presentation I'm going to be talking about the scope as as if there are multiple people who are collaborating and working together including a product owner product manager and so forth If you're the only person who's working on it you can pretend that you're switching hats right Um the scope is going to serve as the agreement between the product owner and the person or team who is building the app even if all of those people are the same person This is going to help prevent scope creep So once you have an established and agreed upon scope then you know what fits in the scope and what doesn't fit in the scope If you don't have it written down if you haven't thought through everything you're going to end up in an awkward situation where the product owner expects more than the developer or the team agreed to do Um even if you're serving as both I can't tell you the how many times that I've I've worked with people who have been working on the initial builds of their app for way longer than they need to Um simply because they didn't have the scope written out they hadn't thought through it Um it helps to establish a finish line So this is to help uh prevent build creep So scope creep is talked about a lot where people keep adding to what you're going to build Build creep is a different beast It's where the developer wants to start building things in they see opportunities and so it might not be in the scope but they or might not have been talked about but because it wasn't scoped out there's some ambiguity and they end up building things that aren't really needed or wanted Uh so if you have a scope if it's in the scope you get it done If it's not you can add it to the backlog for consideration in future builds and sprints And uh it keeps you on time and keeps you much more effective and efficient The scope serves as an anchor for pricing work So if you're working as a freelancer or an agency and you need to price the work for a client if you don't scope it out all you have is the ability to take a wild guess and to how much it's going to cost and how much it's going to to um take how much time it's going to take That's going to put you and the client both in a really awkward position because it's not fair one person or the other will end up frustrated The client might uh be frustrated because they thought it was going to get done faster or cost less money And the developer might be committed to things uh that they didn't know it was going to take that long and they agreed to do it for less money than they should have So don't do that Scope instead Um the scope also acts as an anchor for communication So whether you need to see how much progress you've made using the scope as a checklist of things to get done can make it a lot easier for you to see how far you've gotten Um or if there's a dispute if the if you're in a client builder relationship and the client says hey you should build this and you don't think you should you can look at the scope and see if if the client's right or if you're right Um for progress the scope can be used as a checklist for multiple roles not just the developer So you have a UX designer a UI implementer a developer and QA they can all use the scope to figure out what should be done For disputes a properly scoped defines requirements clearly so you really can clear things up So who's involved in this whole scoping process Well we're using the scope all of these roles So product owner product manager project manager UX designer UI implementer developer and QA whether you're playing all of the roles or one of the roles Um all of these different roles uh interact with the scope in my experience What is a scope Well a scope is an organized document delineating the product or feature that is going to be built It can be comprehensive and incorporate every part of the app That's what we do when we do an initial build We scope the whole thing out Or if you're just taking on a single feature and building a single feature you might need to scope just that feature and see how it's going to interact with the rest of the app Um it generally includes both written and visual components So uh usually it's not enough to just write what needs to happen Most of the time we need a visual component to help communicate the idea fully to the developer Um and the anatomy of a scope like the different parts of an a full initial build scope here include a purpose The purpose is going to be like your long-term vision for the app in general It includes an objective That's the short-term like what are we going to accomplish in this particular build Differentiating the users So I do this by user experience So if two users have distinctly different experiences within the app then I usually like to separate them into different roles including like an app admin a standard user or sometimes there's two different kinds of standard users like a buyer and a seller I've worked in apps with as many of as seven different roles So pardon me a moment I'm going to take a sip of water Then uh the anatomy of scope also includes a list of the actual bubble pages that you're going to going to be working on And then within the bubble pages you you also have to include the different sections I usually like the sections to be in their own reusable Then you're going to talk about the general functionality like the header and footer So these persist across different pages so I separate them out You're going to list out the different kinds of notifications and the different methods of notifications that you're going to include in the in the app For the design part of the scope generally determine call colors fonts and the hierarchy of both along with logos Then um you use the scope that you've done for the pages and the general functionality and notifications to inform the database So you design the database before you ever touch the app And then you delineate which services are going to be used This can help the client or you figure out how much it's going to cost to run your app And after you get all of that done then you kind of decide which things you're going to build first I like to call them milestones you can call them uh features whatever you like to do I tend to try to chunk out the work in weekly uh sections and then price it uh as per week You have to be uh you have to be as realistic as possible because if you're not realistic as you're scoping it's going to be unfair uh to someone either the client or to the developer it's going to be unfair to someone So you have to be as realistic as possible That said you cannot beat yourself up for getting it wrong because I don't think I've ever worked on a project where we nailed it and we got it right I think I've only ever worked on one project where it was uh it was over estimated It didn't take as long as we thought it was going to be It happened one time So Um page scoping examples So what does a scope look like Well a couple years ago I did a forensic scope of Google's homepage And then recently I've also done one for an Instagram um post preview And so give you context pretend you're arriving at the homepage of google.com as a logged-in user and in this case as a logged-in user with a workspace google uh email The purpose of the page define the purpose just like I just talked about the purpose of the page is a little bit different than the purpose of the whole app Um define who can stay on that page And then you define the view and activity And the purpose of showing you this scope isn't really to just show you what a scope could look like It's actually to make a different point entirely So when we go to Google here if you look at it and somebody said hey I want you to build this page in bubble and we are always forever getting people who say I want a clone of some kind of app right I want a an Airbnb clone I want an Etsy clone right People want clones all the time If someone came to you and asked you for a clone of this page right And said I just want my app to be like this page and to work like this page and we'll use an API to get the search working you don't have to actually build a a um an indexing software It looks pretty easy but looks can be deceiving because when you start actually going from top left to top right and across and you identify all of the pieces of what's happening on this page you suddenly end up realizing Okay well if I click Gmail it's going to take me to the Gmail That's just navigation That's not too hard Same with images but I click this nine dots icon here and now I have a different screen And actually if I scroll down I have two different sections of the screen and I have this button at the bottom So I have to scope this out And then if I click on my initial here I look and I say oh there are actually lots of different things I can click on in this interface I have to scope this out too to make sure that the developer knows exactly what I want to have happen on each of these things And then you even think oh well this looks simple and my sister just had a baby yesterday so I was looking at baby names Um so you see the the search the search queries here and you think oh well that's easy enough They're just going to enter a few words and that's going to be what they do But actually if you get into it it's much more complicated than that And suddenly you're looking at this view and activity 
section and I didn't even finish it. It was too much for me to finish doing all of these different pieces. But, the formula is the same. The formula is you start at the top right of the screen, and you find every interaction that the user can have on the page, and you define what the interaction is and what happens when the user does it. And that turns into a big, long list of all of the stuff. And it keeps going and it keeps going and all of it Like I said, I didn't even finish it. And this is just for this simple Google page. So, if you think you don't need to scope, even on simple pages, be careful because looks can be deceiving. So, give you a look at the at the Instagram one as well. If I can find the top here. So, Google homepage, so the Instagram one. If I just open that up, you can see looks simple enough. Not a whole lot of different things you can do in here. Or, at least it seems that way, but once you start interacting, you start realizing that there's a lot more to it. So, where does the scope exist? We're actually going to go into more detail in the live exercise where I'm forensic scoping, so you'll get to see how I think about each of these things. So, the scope is a process. It starts with the first meeting that you have with the product owner, and it continues through all of your meetings and some homework that you have to do to get it done. Um, so, the first is getting getting the meetings done, then you go off and you write it, and then you communicate with the product owner, and they tell you what changes they want. It takes time. And it's important to take that time to knock out a great scope. I believe that these steps earlier in the process should not be rushed as the time you spend on spend on the earlier steps cuts down on the time you have to spend in the future fixing things. Um, meetings I prefer to do in Zoom. For communications, I prefer Slack over email, and then within some other software like Workflowy and Airtable, uh, for files, I prefer Google Drive. And I usually make a PDF of the whole scope and add it as an addendum to the contract before the build begins. When should you scope? First thing, it starts from the very first conversation you have with the product owner, even if you are the product owner yourself. Um, I I only ever do fixed costs uh on initial builds. I just wanted to toss that in there, because I talk a lot about how important it is to scope out before you quote a price. If I'm quoting a price it on an initial build, it would be a fixed price on a on an addition to an app. It would not be It would be an estimate. And it's important to make that distinction to protect yourself. The reason is because on an initial build, you don't have tech debt that you have to work against. So, how to how to scope. Here are the steps that I take in scoping. The first one is discovery. The product owner informs a part the product manager about their ideas for the app. Can include the general concept, the short- and long-term goals, ideas for features, inspiration from other sites and apps. Then, the product manager offers the scoping estimate in a timeline, and the product owner can choose to engage. Um, I charge for scoping, and it's non-refundable because it's a lot of work as you might have noticed when I was scrolling through endless pages of it just above. I base the cost of the scope um on 10% of the estimated total cost for the build based on what I know at the time that I start uh scoping. While it's not refundable, if the client chooses to continue with the build with me, then I apply what's been paid for the scope toward the cost of the total build. The next step, if they choose to engage, is uh we've done the discovery, is we move into Mad Lib scoping. Mad Lib scoping is a term I coined 2 years ago in No Code School. And, uh informed about the idea, the product manager conducts a Mad Lib scoping interview, what I call it. It's where the product manager takes their expertise and asks a series of questions to the client or the product owner. And, it's about critical choices the product owner needs to make before doing the scope. So, there are several points when you're making decisions building an app that once you make that decision, if you decide to change your mind later, if you want to go back and and do it a different way, it's going to cost a lot of time and a lot of money to make that a different choice. So, it's really important, I think, to identify those critical choices to the client or product owner when you start so that they understand that it's not just how you feel in the moment. You need to take a step back and really think through how you want your app to be and be confident in your choice, because if you make the wrong choice here, it's going to cost you later. An example of some of those choices for a two-sided marketplace would be, um, what and how to sell. So, if someone says, "Hey, I want to I want to develop a marketplace, and I want them I want some users to buy things from other users," right? That's a very common thing. Um, when we get when when we get down to it, we say, "Okay, well, what kind of sale is it going to be? Are people buying things one time, or are they buying a subscription?" If it's a subscription, are they is it going to be monthly or annual, or both? Do we need to worry about prorating like moving from monthly to annual? Should there be prorations? Um, are we doing If it's a subscription, monthly subscription, do they get a certain amount of something, either quantity or credits of something? Is there a free trial? All of these things are really important because they they inform how you plan out and scope your payment system. Another thing would be, okay, well, you're going to sell some things. Is it physical good? Is it a virtual good? Is it going to have any variations? So, maybe I'm going to sell a single physical or virtual product, and it's not going to have any variations. That's much more simple than selling either multiple of the same thing or multiple things with variations. Each Each point here gets more and more complex. But, even within selling a single physical or virtual product without variations, you still have to say, "Okay, well, do I really need a shopping cart if I'm just going to buy one thing," right? Um, what kinds of sales am I going to do? Direct sale where uh you see you you see it, you want it, you buy it, like Ariana Grande. Um, or maybe we're going to do auctions, like on eBay, and see how much we can get by having people bid, and a timer runs out. Uh, multiple physical virtual products without variations. Now, we have to worry about inventory and shopping carts, so where someone can increase the number of things that they're purchasing or decrease. So, you have to manage You develop an inventory system that's going to add a lot of complexity. Um, maybe we're going to have a single shopping cart. Are we going to allow multiple sellers' products into the same single shopping cart, or does each seller get their own shopping cart per buyer like who wants to shop from them? Is there a single checkout for all of your shopping carts? How are you going to design that? Because there's a lot of ways to do it, and it can get very complicated very quickly. When you start dealing with product variations, you might decide to step back and be simp more simple with your checkout pro- process, right? So, maybe you only want a single shopping cart if you're going to allow variations because variations there can be a lot of them. Maybe there's different sizes, maybe there's different colors. Maybe there are different uh features or benefits that you can add or subtract, like if you're buying a car. Then, is the marketplace going to be um general or niche? So, anyone can sell anything, like Amazon is a very different proposition than someone can sell cat T-shirts, right? Like the the more narrow what the more narrow you are in what is being sold, the marketplace the easier it is to to build the marketplace. Then, you need to consider promotions. So, um, in addition to how are they going to pay, one-off, subscription, and which payment processor are you going to use, you have to think through the method of promotions. If you're going to If are you going to have promotions? If so, what method are you going to do? Coupons, or sales, or are you and who's going to drive drive the decision to run a sale? Is it going to be the app that decides, or are you going to give the seller the ability to to run their own sale, right? Uh, an example of that would be Udemy often runs a sale for the entire site, and they let they let their uh course creators opt out of those sales sometimes, or opt into them. So, is it the app that's going to drive the sale, or is it the seller who's going to decide, "Hey, I'm going to put a sale everything is 10% off of my shop." So, these are the kinds of critical questions that you can't change very easily once you get started. If you decide to change it, it's going to be uh scrapping everything you built and starting over, or refactoring what you've built, and a lot of work to do that. So, once you have the Mad Lib scoping exercise done, you move into the scoping outline. This is the combination of what you found in the discovery by asking the client a bunch of questions. Um, everything you discovered in the Mad Lib scoping interview, and also the anatomy of the scope that we covered above. This defines the pages and sections that need to be delineated in the scope, which is the majority of the work in the scoping process. The scoping itself fill out the scope outline with the stuff of the scope. There's the written part, right? So, you've got the written part, which is bullets on what the user can do and what happens when they do it. And then, you have the wireframes. Um, like the rough sketches of the interface. For the written part, for initial builds, I like to use Workflowy, which is this program that you see me using right now. I think in hierarchical lists, so it's ver I'm very compatible with Workflowy. I've been using it for a really long time. It's also really inexpensive. It's like $5 per month. For subsequent work, I actually prefer to use Airtable, so that I can assign statuses to things. An example of an Airtable that I used with a client, I've got here like the task name, um, notes. We've got the type of task, the status of the task. I can do my points estimates. So, I'm This is the template that I use, and if you stick around, you'll find out how you can get a copy of this template. Uh, for the wireframes, I am not a designer. Uh, maybe you can tell, because I'm using Workflowy that I It's design is not my thing. Making things look pretty is not my thing. Making things work logically is my thing. So, I communicate visually best with Balsamiq, which I find much simpler and much easier to use than Figma and other things. It's only $9 per month for two projects, and I only use one project for all of my different screens. Other people like Figma and other platforms better. You choose what works for you and what makes you the most capable of communicating the visual parts of of the scope to the client or product owner and the UX designer. Once you have the the the written part and the um and the visual part done, you can turn it over to the product owner for review and approval. Once the scope is written and mocked up, the product owner gets to review and flag anything that needs to be reworked. Once the product owner is satisfied, it can be finalized and utilized in a contract. I like to use I have like an extension, like full-page screenshot that will do like a really long screenshot. So, I usually take a screenshot, make it into a PDF, and stick it into the contract as the source of truth to outline the deliverables of the development work. Then, comes the UX design part. Um, I'm not a designer, but I think it's really important to do this part where you get really high-fidelity mockups before you build the rest of it. So, after the contract is signed and the first payment for the first milestone is made, in my process at Pro No Coders, I hand it off to my UX designer, and he builds designs in Figma, but he does not build everything in Figma that I did in Balsamiq. Usually, what I do is, as I hand off some Balsamiq wireframes that look like this, and I choose very specific ones. I choose the ones that are going to include like a table, and then the overall layout of a portal, um any of the specialty uh the specialty screens that are looking different because I need something specific. So, I just hand off a few screens to the designer, always a form, and then I have the designer go through and create the high-fidelity mockups. And then, I have my UI implementation specialist take these mockups, just these few screens, and create them in Bubble. And then, everything that I put in here can be copied and pasted um elsewhere in the app, and that's how we build out the rest of the designs in in Bubble. And so, this is an example of uh the tables and things that we were having built for Rosie Recruits. And then, you can see um this is what's actually in Bubble that my UI implementation specialist did. So, I've already kind of explained how that works. It goes from UX design, and then UI implementation, and then there's development. There's not much to say about it. You just use what's there and develop the logic to make everything work as per the scope. And, finally, we've got QA. So, both the internal QA person and the product owner test the app, and add tasks to the backlog in Airtable, which I've shown you. And then, the developer categorizes the tasks as being either a bug, a missing feature, something to refactor, or a feature request. Bugs are in scope and not working as scoped. Missing feature is in scope and missing from the app. Those get taken care of automatically in initial build uh because it's We've agreed to build exactly what we scoped. Refactoring and feature requests go into a backlog, and maybe we fit it in, and maybe we don't. Um, it depends on how long things are taking. Um, uh Tanya, can I interrupt? Um, Andy had a question, just a clarifying thing. He said he wanted to know did you say that you copied from Figma to Bubble? No, I don't. Um, I have the UX designer design in Figma, and then I have the UI implementation specialist recreate the designs in Bubble. So, Yeah. He says, "Got it. Thank you." Good question. Yeah. And then, uh the rest of the tasks uh that are like the refactoring, feature requests are collected in full Oh. So, about the timeline of working on these. If you have a breaking bug or a missing fee 
feature when you're building and it's critical to testing everything else. You fix those immediately because you have to because it bottlenecks the entire project. But the rest of the tasks are collected in full, categorized, prioritized and then worked on within the capacity of the build. And that brings us to a that's that's the whole process of of what we do when we build an app um at ProCoders. And now we can do the live exercise of forensic scoping. How did it go, Robin? Did we decide on something? Yeah, um so we had uh so um we had two things. One person asked if we could do a feature that uses a map to locate bikes for rentals. And then, I submitted uh the hotel location information like uh like to be able to see room rates on a hotel, but the bike feature had uh well, it looks like well, it had more but it looks like some of them went away. So, it looks like it's kind of a tie. So, but I don't know if you wanted to do the the the bike features for a feature that uses maps to locate bikes for rentals. I don't know if you need more information on that. Oh, is there a an existing app that does this? Uh, Daniel, go ahead and um let us know if there's if you already have an existing page that Tony can jump into. Um she said she doesn't know, so I think uh it was just an idea. Oh, gotcha. Okay. Yeah, so I'm thinking about an an app that already exists. So, something that already exists that you want to see. All right. And then uh somebody said a tip out of one out of maybe 20 bubble projects, one converted to an end from Figma to bubble. And uh that was only during the first day. So, um but so, we could Did you want to people to submit other ideas of like existing websites of like how to reverse engineer that or Yeah, or different things I guess we can come up with something. Let's see. Um I've already done Instagram and I've done Google. Maybe we do uh what what did you I mean I was I was hoping to outsource this decision. So So, let's see. How about um Let's do one with a map feature. Let's use one that we're that we are um Somebody just suggested the dev dave . live The dev dave live app. Ah, yes. Okay. Let's do it. I love that idea. That's a great idea to search. All right. So, I'm sorry, let's Sorry. Let's start with what it was yesterday, so Oh, even better. Even better. Okay, so I'm going to make First, I'm going to just make a screenshot of the top of the page here. And then I'm going to take this in Workflowey, and I'm going to say um dev day day . live. And I'm going to say screen collapse. This is a a part of using Workflowey. I have my own conventions, and I'll explain uh why I do the screen collapse, and then paste the screenshot. And then, I tag it as screen. And the reason I do that in Workflowey is because when I search and I say screen collapse, I can see where all of my screens are very quickly. And then, if I do my hashtag screen, then I can actually see the screens and navigate through my scope faster. So, that's why I do that. So, now I've got this screen collapse, I can come in here, open it up. And so, I'm just going to start from the very top left and go over to the right, and I'm going to look and I'm going to say, oh, there's this button. There's the log out button. I'm just going to assume that if I click it, it's going to log me out. I don't want to be logged out right now, but I'm just going to pretend that that's the case, and Kelly can correct me if I'm wrong. So, user can click the log out button. Logs the user out. Right? You might think that you shouldn't have to spell that out, and maybe you don't. But, I can't begin to tell you how many times I end up in pop-ups that have an X icon that doesn't work because the developer just forgot to add it in. But, if the developer had it as a bullet point in a scope, the developer would notice that they didn't do it because they'd go and test, and they'd realize, oh, I can't do that, so I need to do that. Then uh next up, the next interaction on the page here, I can read all of this stuff, but I don't need to write that down. But here, I can start to click on things. So, the user can click on a tab, and it changes the view. Right? So, I can describe those tabs, and I can say user can click on the all tab. Opens all of the sessions or filters to all of the sessions. Filters to all of the sessions. User can click on the what's the next tab here? On attending. On the attending tab. Filters to only sessions sessions for which the user has RSVP'd. User can click on the hosting tab. Hosting tab and then, that filters to only sessions for which the user is the host. Right, and so forth. Let's move to here. So, user can click on the join here, navigates to a different page. I'm going to open it in a new link. Oh, that's the zoom. Then uh how to join sessions, another click. Oh, this one's not actually a click. Oh. Oops. This one I should have been able to click into do the email. No, it's fine. I can always copy and paste. So, this is this is the how the the forensic scoping works is you would go through and say, okay, well, I'm I'm I'm hovering over here. So, user can hover over a a title, and they can click the hosting sessions. So, you would describe that. You would say user can hover over a session title um reveals the host a session button. User can click the button. The button. And what does it do? It probably gives us a form. It scrolls down to the bottom. It's broken. It's broken. It's okay. Yeah, yeah. That's That's okay, but here I can I I have control when I'm scoping. So, I can I can highlight and say it should do this instead. I wanted to do something different instead, right? So, it should show a form is what it should do. But, yeah. Yeah. Shows the um the host a session or opens the host a session pop-up probably, right? No, it's like a section of the page. It's actually at the very bottom now, but it used to be at the top, so it It would scroll to it. A session form. Right. Yeah. Yeah. And then um on another title that's showing here, I can click I can click the bookmark, so I can bookmark something. So, user can click the bookmark icon. Um saves the session to the user's bookmarks. User can click the share icon. I think that's a share icon, right? Mhm. Just copies a link. Share icon copies the link to the session to the user's clipboard. User can click the RSVP button. Button RSVP's the user to the session. Right. So, this is the best way to learn how to scope is to just take several pages and and do that, write everything out. Apparently, it's also a really good way to to find bugs, right? Because you'll find things that aren't working, and to learn the app because you're finding all of the places you can click click, and you can enter something um into. So, um if you're interested in the the materials here, so that you can see the whole presentation including all of the example scopes, and this forensic scoping exercise, you can kind of get uh a good handle on how I handle certain things on in a repeating pattern. And to do that, just go ahead and email me at team at pro coders, and let me know if you want the Workflowey link or the air table template. And uh yeah, that's it. That's how I keep on the same page for myself and with partners and clients when I'm building apps by using scoping. So, I'll open it up for any remaining questions that we have. I think the biggest question that you know, Andy had was, well, you know, this is so great this this workflow workflow document, and like, how can I get it? And you just answered that question. Um if you have other questions, go ahead and post them in the chat. Um and we and Tony would be happy to answer them. Um Yeah, or raise your you can raise your hand if you want me to unmute you. I'll I'll throw one out while people are thinking. Um I've had uh a couple of clients before sort of like, you know, you scope out the whole thing, you even build the whole thing. And then, they're like, well, of course, it needs to do this other thing. Like, to them it's so obvious that it's and they don't necessarily understand that what you scoped out is all of it. Like literally all of it. So, I wonder I don't know if that's something you've come upon or in having it so detailed that communicates that if it's not in here, it's not happening. So, I usually have a pretty frank conversation with uh my with my clients when they're reading the scope, and I can't I mean people don't like to read, right? I've I've learned this a long time ago. People just don't like to read. But, I warn them, and I say, look, this is going to serve as part of our contract. So, it's really important that you think clearly about everything that's written and decide if you want to change because if you want to change, it's likely going to cost you more. But, if it's in the scope and we've written it out and we've agreed on how it's going to go, when you get to it and you say, hey, this is a a bug, it's not working the way that was scoped, I'm going to fix it because you're right, it's in the scope. And, if it's a feature that's in the scope and it's missing from the app, I'm not even going to I'm not even going to blink, and I am just going to go and and add that feature because it's acting as our source of truth. So, I explain the process and exactly how we're going to take their feedback, keep the backlog of anything that that they want to change. And then, I'm also going to explain that, you know, I'm not going to like save everything to the backlog and charge you more. The things that I can do for you that fit within the capacity of the scope, which I'm adding a little bit of buffer to, right? I will do. But, uh the bigger things, I won't be able to get to without charging you more. So, it's important to read the scope. But Thanks. Yeah, it's it's a it's a good question. So, how do you handle when a client is saying something like that I know I know I kind of wanted to work like this, but they're like, you know, maybe they're not quite sure how how they want to have something display or they're not sure what the functionality of bubble is to fully describe it for you to scope. How do you do you handle that through like a call or how do you usually work through that process with clients? Yeah, that's actually that's that's a really good um question as well. So, I don't expect the clients to know how they want certain features to work. I just expect them to come to me with like, I want the user to be able to accomplish this thing. And, they might have an idea of how they want it to look or might have an idea of how they want it to function or how the database should be changed. But, sometimes they just they just have the general idea, and that's where I come in, and I suggest how we could accomplish it in the interface, and then also with the logic. That's really helpful because I think sometimes, especially if somebody comes from a non-programming background, they don't they might not realize that one thing is really difficult to really expensive to do. And, one thing, you know, we could go a different path and have a much less expensive, much better MVP kind of option. Yeah, I think that's actually one of the pieces of the air table template that I love so much, and I I don't have it in this particular example, but I use the point estimator um here, and it's just a number, and um I've I've moved to doing a one-to-one. So, I when I estimate points, I'm estimating the amount of hours that it's going to take to complete um a particular uh a particular task. And then, what I instruct my clients to do is use that information, realize that it's an estimate, right? It's not written in stone. I'm not telling you that it's going to take exactly that long, and it will only cost that much. I'm telling you, hey, I think I can get it done for this amount of time, which is really a heuristic for um for how complex I think the task is going to be. And then, they can use that information, once they have it, they can use that information to decide whether they want task number six or task number seven to go first. And so, when I'm when I'm I'm in the part of the of the build where uh after the build has been done and they're giving feedback on something or they're coming up with different ideas on what they want to build, um even before I can give them a point estimate, I do not scope it out before I do the point estimate um because I only want to scope so far into the list because scoping takes time, and it takes um energy, and it costs money for the client. So, I want to make sure that it's what they want before I scope it out. So, I'll do the point estimate to start with, and then, when I scope it out, the point estimate might actually change. But, it's giving them a really good idea on a really good idea on which are the low-hanging fruit tasks versus the more complex tasks. I think that's really helpful. Um Daniel wanted to let you know that it's a wonderful presentation, and and thank to thank you. Oh, thank you. Yeah, so Um, and then there might be somebody like sitting in my chair that's looking at their app and being like, yeah, I didn't really do a very good job scoping everything out. What would you say like the the benefit I know you said to to debug, but if maybe somebody is working on an app, and maybe they're trying to figure out what the next step or if it's worth them going back to do this forensic scoping, what would you say to somebody that maybe they had a rough outline, but they didn't do things in depth the way that you have outlined here? Mhm. So, if you have an existing app, there's um I would probably recommend doing an audit and deciding whether your app is salvageable um or if it would actually be faster to re to scope it out and rebuild it. Um rebuilding comes with I mean, there's there's positives and negatives to both refactoring and rebuilding. Um but, generally like I just had a conversation with a client earlier, and he he chose um he he started building his app 3 years ago before the new responsive editor was available. And so, 
his his app is still in the old responsive editor and it has a lot of tech debt from multiple developers and so we're looking at rebuilding the app versus refactoring the app and that's going to start with a forensic scope of what he already has right so you can use the forensic scoping exercise I just did forensically scope your app to see what you already have and that that can actually serve as the foundation and that's what we're planning to do with this app from from earlier today we'll use the forensic scope as a starting place for a new scope and then make the decision whether it's cost and time effective to refactor versus rebuild Awesome And uh we've got a question um from Besaran and um I but we can go ahead and ask him to unmute I don't know if we need to make him Oh sure Yeah I can find him Hang on Let me Hi Tonya Hi Besaran how are you Hey good good Thanks Thanks for the presentation that was great Uh-huh Just quick question um do you usually start from the front end or the back end uh when you are designing um And when you are building the application for the client Um also do you always have to use Figma because I don't usually use it I start right away from bubble Um no So if you're building it yourself you don't you don't necessarily have to use Figma and if you're good at design and you like doing the design I don't actually do the design implementation in the apps that I work on Um I have team members who who are way better than I am at that Um so the answer would be when you first start working in your app it's the front end first So it's the design stuff the design implementation before the database the database before the logic Okay cool I guess I'm on the right path Thanks Yeah Yeah no worries All right Any other questions Feel free to raise your hand or put it in the chat if you aren't in a location where you feel comfortable unmuting Um But this has been a really I think this has been really helpful and I think it will save people a lot of time It can I know that I'm always tempted to just rush ahead I'm I'm doing that right now on a project but this is a good reminder of you know uh an reminder of the messes that I have made from the times that I did skip over that and especially when you're working with clients how powerful it is to making sure you don't get end up in a sticky situation um with expectations or upset or you know and protecting your reputation Yeah And just know that uh nobody is perfect at this I have never met anybody who is perfect at this So it's a it's work in progress always Um but do if you if you want copies of the materials go ahead and email me at team at procodeurs.com and I'll try to get those uh answered today by the end of the day And And uh if that's it for questions I hope everybody has a great day I'm headed over to Eli's session so I will see you all there Thank you everyone for being here Thanks Tonya Thank you for such a great presentation Thank you Kelly See you guys Bye