AA148 - An Introduction to Software Development Finances

This podcast is your ultimate introduction to the cryptic, mysterious, and sometimes clandestine world of software development finance.

Join Product Manager Brian Orlando and Enterprise Business Agility Coach Om Patel as they explore the finance-side of the house with special guest and CPA, Newton Owi!

Listen as we discuss the ins-and-outs of software-finance, including an explanation of Capex vs Opex, an overview of capitalization, an in-depth review of Internal vs External Use Software, and a discussion of Technical Feasibility. We wrap by reviewing strategies for R&D Budgeting and why, how you might save money on MVPs, and it wouldn't be the Arguing Agile Podcast without an in-depth discussion of how Cross-Functional Teams benefit from having access to financial expertise.

= = = = = = = = = = = =
Watch it on YouTube

Please Subscribe to our YouTube Channel

Apple Podcasts:
https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596

Spotify:
https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3

Amazon Music:
https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-Podcast
= = = = = = = = = = = = 

Transcript

0:00

Software, finance, capitalization, CapEx, OpEx, that's what we were talking about today with Newton. This is an exciting topic, believe it or not. It's a critical topic and one that other podcasts out there aren't really. I feel nobody's talking about it because it is perceived as a difficult topic. I don't I don't think it's that difficult. I just think that that most teams. Don't have the skill they need to deal with this topic properly. This, yeah, let's reframe a little and say most teams don't have the skill set on their team to do but, somebody needs to know it. And somebody needs to care. At least be aware. Everybody needs to be aware. The finance folks Do really care about this, but they may not be on the team. Right. Well, that is a problem. That is a problem, and we're gonna, we're gonna talk about it today. Newton, you're you're a CPA. Is that your background? Yes, I am. What's your background? Well, I am a CPA wrestled many years in corporate finance and corporate accounting with capitalization. I've seen how it has evolved over many years, the past 20 years. Wow. And survived to tell the tale. That's right. Yes. That's right. It's awesome. Now, the logic hasn't changed. If it's got a future use, you capitalize it. If it's got no future use, you expense it. So, the logic hasn't changed, but they've gotten more granular on how to determine what it is. What is the purpose of capitalization? We should cover that first because I feel everything else is going to build on that in this podcast. Well, it comes from the old accounting rule. to match your expenditure with the revenue. So, if you have software that can continue to produce revenue for another three years, they want you to capitalize it for, so that you can expense it over those three years. I mean, they call it amortized. So you amortize it over those three years. If it's got no future value, they want you to write it off, or, I mean, the, the, the regular case is the case of software for sale. If there's no futures, It's got no future value yet, so you expense it. So they want you to mark the revenue against the costs. That's really it. Are are you trying to, that that's interesting.. Wait I don't know how, I don't know where I want to go from here. I want to ask a million questions. I think you need to capitalize on my camera. Sorry, man. Everything in my business is cash. We're a strictly OpEx operation here at the Arguing Agile Podcast. Cash accruals. So when you capitalize you have future income and you're trying to basically offset. The capitalized cost is something you did in the past with the income that you're getting today. Yes, they like you to match the expense against when the income is coming in. And if they don't have those rules, it's totally open to manipulation. You know, so I can decide to build 1 million software, and because my revenue is too high, I can decide to expense it. Now, if my revenue is not there, I may decide to defer a 100, 000 expense. For many years, when it has no future value. So the rule is simply say, match it against basic accounts and principle, matching, matching principle, matching expense against when the revenue comes in. Things get a bit things get a bit gray. A lot. Great. When you talk about solutions rather than just software. So in this definition, I'm saying the solution is you're selling a piece of software, but you're also bundling some services in there as well. Say what we've seen in the industry for a few decades now is the move away from software to services. Many companies made that switch, right? You know, a lot of time you and I were both at IBM. That switch was being made. They would sign up billion dollar contract, for example, and initially in the early days, they would go about and declare that go. We just got this contract a billion dollars, but it's not billion dollars in your pocket yet. It's over 10 years, right? But the market sentiment is different. Like they look at this stuff and the stock market does its thing. But anyway, so today, fast forward to today, you still have that scenario where people are selling Solutions, software and services, which makes it even more difficult to kind of get a handle on what are you what are you capitalizing versus what are you not? Big challenge. Big challenge. Sometimes the challenge for accountants is. The CEO or somebody else who is, the guy who has the budget, like the head of development, wants you to lease an item for some reason because of cash flow, but the accountants , don't want to expense it, or they want to capitalize it. Totally against its own interest, depending on what the situation is. So this argument has been going on for, since accounting was born. I understand that the finance follows like the business strategy that you're kind of going for like the, and what the world that I come from. You have CapEx and OpEx, and you have reasons to pursue more of one or less of the other or whatever. Those two buckets, and OpEx capEx, capital expenditures. OPEX operational. This is your operational budget. What I understand about your operational budget is, your operational budget is things that you have to pay for immediately out of pocket. In, in the current year. Things that, things that you cannot capitalize. Well, well that's, that's one way to look at it. But the exact definition is stuff for which the value , expires in one year. Oh, okay. Okay. That's much better. So you may decide to put it on the credit card and pay it over five years. But if the value expires in one year it's still operational expense. But if it's If the value expires in five years, and you pay cash, it's still CapEx. Because it's got a life more than one year. Yeah, like that's, that's the mind blowing part of this for me, is that, is that I bought a network switch, and I'm gonna use that network switch for five years, Probably, likely more than five years, but I'm going to use it for five years. But when I bought it, I bought it with cash. Like I took cash out the drawer and I threw it down and there it is. But when it goes on the ledger. Like now, it's, it's, yes, it's not, it's not like, it's not 100, 000. It's 20, 000 for this year and then for the next four years in advance. And then to make life more confusing, the rules for IRS. For the tax authorities are different from the rules for accounting. So you have to also, and the IRS rules go by politics too. Yeah. And the accounting one, my opinion is, the accountants do a thorough job, especially in the U. S. I'm not familiar with the foreign guys, but the FASB guys do an extremely honest job in trying to make this thing to be as pure as possible, and to avoid Manipulation. Now, sometimes you say, well, this is too anal this is too, too, too much detail, but they do a thorough job. Yeah. And because the system, the business is evolving the business is evolving. They are working extremely hard to catch up with it. to shift us into talking about software. Most software that I, I have worked on in my career has use over a longer term. So, I could see you want to apply capitalization to your software development. What I know about capitalization, because again, I was at a company that, that got bought by a private equity firm, and the first thing a private equity firm wants is they want to capitalize everything. They're like, you got a lint in your pockets, we want to capitalize it. Everything's getting capitalized. And so I had to quickly learn the rules of internal use software versus external use software and how to capitalize the different categories. And I try to prepare for this discussion and I pulled that, that I know the FASB or whatever it was, the article, the article I sent , I can't remember what it was, the, the, from 1985. I was like, wow, this is from 1985. Yeah., they have updated it, to be honest. But I don't think it's, it's. It's updated to the point where it's current as of now in the new modern world of software being something that People can lease, rent, and whatever else, pay per use all of that stuff, I don't, I don't think it's updated for that. Also, there's no amount of updates that can take out human judgment. Right, yes. And you can't, there's no amount of, with all the smart people who are doing software, you never know what features are coming down the pipe. So, I mean, how many years ago, 20 years ago, did we have cloud computing? So, it's changes, it's difficult for the accountants to keep up with it. Internal use software versus external use software. External use software being software that you plan to sell. Sell, yes. Right. I pulled a couple graphics that I probably will roll into, let me see, let me find them, but it's not just software that you're selling. I know this is a nuanced discussion, but it's software that you're renting as well. Right? Instead of just paid out selling, people are using it. You're not shipping anything, right? You're just giving them time to use your software, and you're charging for that. I mean, everything that we know of today X, AAS whatever. Software as a service, platform as a service, etc. People are renting that. But the accountants would like to look at the economic life of the rent. Exactly. And it's a finite compared to the old days of shipping software. That life is finite, but recurring. It could be. So you might decide that you are renting. Software X, and you only pay in every year, but chances that you may want to keep it for three years or four years. So the question is, do you expense every year's payments? Because the payment is not equal to the economic life of the asset. True. This is where things get challenging. Challenging. Yeah. that's one that I am less concerned about. clear on is if I decide that I want to for all my employees, I want to buy what's it called? Like the Microsoft suite of tools, like office 365, right? Yeah, I want to buy that. It all lives, the subscription all lives in the cloud now. So do I have to put that on OPEX every year because I renews every year does that work? Like, I think the same thing is like cloud computing. If I buy, if I buy bandwidth in the cloud, like AWS, a lot of people use AWS as their backend, like the, the operational expenditure. of running my AWS server farms every year. Like, am I now, because I'm paying that as a service, do I have to put that OPEX every year? Or am I saying like, Oh, this year's run of all my servers is actually, I can leverage that over a certain number of years. Yeah, I think it's the former. That I don't know. I don't know, but I think it's the former because otherwise things, how would you know? Otherwise things will get just completely out of the way. My, my sense is that, well now, without looking at the actual accounting ruling, and most times accounting ruling follows common sense, but sometimes you're wrong. But my sense is that, They would look at, I mean, what is the chances that I would buy a cloud contract, cloud system, or everything from IBM or so, and get rid of it by the end of this year. That's a huge churn. Probably very, very close to zero. Now, the good thing, though, is for you and I, mom and pop, guys, the rules don't always apply to us because there is some de minimis rule. Sure. If it's too little, just expense it. Right. But then, like you mentioned, the, what is it, the venture capital firms that buy, buy businesses, some of them like to capitalize everything, so net income looks really great. That's the first year. And, and that I bring that up because that's been my direct exposure to this is, is PE firms that private equity firms, venture capital firms, whatever. Basically, firms run by accountants. That are trying to make the books look as good as they can with no regard to the future because two years from now, we might get to two years from now and revenue will have dropped, but we've incurred those expenses from previous years that now we're still paying down. So the things that we've capitalized from two years ago. And now we've lost 50 percent of our businesses Oh, now we, suddenly there's no money for raises and no money for new equipment and no money for anything because we're still paying stuff from two years ago when like two years at a P. E. Backed firm is like, that's like two dog years. Yeah, it's like, that's like 15 normal years that you go back for a second round of funding for just like dead. Debt cap space on the football team. Yeah, right, you know you pay for you hire this great quarterback paying But five hire him for five years and then after one year you kick him out. You've got debts Yeah, you still got to pay that money exactly now on the other hand. I am also aware of many CEOs who have the different, the CFOs, who have a different philosophy. So I'm buying this business, I want to start fresh, I don't want any expenses, I want the next few years to look good. They will bury everything the first year. Write off everything, so if anyone says, Wow, this year is bad. Yeah, we are cleaning house, so that we can look better next few years. That's especially true if they're looking to flip the company. Huh. Right? Looking to sell it pretty quickly. Year or two. Then that's exactly right. Because now your bottom line looks so good. And the company looks attractive to purchase. Wouldn't your, let's pretend for a second that I'm I'm co CEO in Brian and Om's development, software development company. And like, Om is like, capitalize everything, I want the books to look as good as possible. And my, my outlook is I want to book everything this year. Every scrap of extra cash I have. I want it to go into, straight into the software to make a better product because two and three years from now, I expect more revenue to come in two and three years from now than is coming in now. And we won't have Any expense carried over in any of the years. So, so all those other years will be pure, but I'm going to say they're pure profit. I know in actuality we have maintenance costs. We have other things we have to pay, right? But, we'll have those maintenance costs. On top of all of our capitalized costs, right? So my strategy is, I don't know what the market's going to look like in two years. I'm looking at the economic outlook and whatnot. I don't feel good about it. I want the next two years to be unburdened from all these capitalized costs. Because I'm worried about what's going to happen. And if everything turns out great, and like we have all this extra money laying around, Maybe we can kick off some R& D activities, or maybe we can kick off some extra lines of service, or extra pieces of software, or whatever. You know, spend some extra cash., I have too much money is not a problem that I've ever had. Never! Never! Now, the topic you are talking about, it's driven also sometimes by lots of external items. So the venture capital is borrowed money from a bank, and they have these governors that say your net income cannot go below this. So they may decide to capitalize everything. But your philosophy is the one I would like, because you don't know what tomorrow is. Go with a clean balance sheet. So, but some of them have a Contracts, I tell them, you can't go, I would think it's even short sighted to try and measure you on the first year because the first year you used to be cleaning house. Right. Yeah. You know. For external software, this is, this is my experience. We were producing external use software and we were going through a ramp period where we had all of our internal teams plus some offshore teams and we were capitalizing everything from every single team as heavily as possible. Every single dollar as possible because we, we said there's going to be a solid. probably 18 months, maybe two years ramp period where we're just spending money like crazy. And then we heavily use a capitalization strategy so we can build, build, build. And then there will be a tipping point where we will start rolling off the offshore team and taking the internally. But you know, the internal team is like, we're not replacing people when they leave. And so that so that the we'll get to a point where we're bringing in revenue and the internal team that we have that stabilizes over time, we'll be able to maintain the solution that we have. And then all the debt that's been leveraged, all of the things that have been amortized with our current profit that's coming in will be enough to run the business, make a profit and maintain all the employees that we have. That was the strategy. It didn't work. It didn't work at all. But that was what they were going for, you know. Now, the irony of all this is that what we are discussing has nothing to do with cash flow. Right, right. Yeah, which is what runs the business. And private companies, when you're not owing too much money outside. Focus entirely on cash flow and they say damn, CapEx or OpEx. So they do it the right way or they clean house and sometimes excessively clean house in their accounting. Yeah. But they don't care because they don't have to report to the stock market. Mm hmm. Okay. But some of it even the stock market depends entirely on your communication. If the stock market expects That this year is going to be bad because you're a cleaning house. They might even raise your stock. That you're going to be such a great company in the near future. He's got a cleaning house, no old equipment, everything will be brand new. So, it's, it's changes from market environment. And also the philosopher of management. The other way that I've seen things done is you're getting close to the end of the year and that opex is way higher than you want it to be. So the thing that I see whenever I see like especially in agile, like I'm su super sensitive, that when I see people cutting jobs and cutting like hundreds of employees. Like that they see as quote overhead Spotify just that we try not to name company names on the podcast, Spotify deserves it by the way, like they're like, oh we need people that are quote Producing or what? I can't remember what the CEO said in his thing. It's like no, that's not what you're doing You're you're you're going to the end of the year and your opex is a little high So you're trimming it down so that by the end of the year that like the when you book out And you finish, that number looks good. That, I think, is what they're doing. Like, does that, first of all, does that financially work? Can you do that? Can you just be like, You know what I'm gonna get to like the end of November and I'm gonna fire like three quarters of my staff listen, there's nothing to stop you from doing that. Right? It's not just that company. Others have done that. There's nothing illegal about doing that. I'm not talking about morality or anything. There's nothing illegal. In fact, in that specific instance, they immediately turned around and made a profit because of that. Which is what happens when you get rid of people, right? So yeah, can they do that? Yes. There's nothing wrong with that. Now, I don't like it, because you're not talking about resources and cells, especially if you're talking about real, live human beings with families and whatnot, so I don't like it for that reason. And some of them fire the guy, and next day he's back there as a contractor. Right, yes. Now, it's easier in the United States, because most jobs are at will. In foreign countries, it's hard to do. To fire a person in England or France takes forever. So, and and now here is the other thing though. Sometimes when they do that, they actually may have to report a loss because severance payments. You know, when a person, when you fire a whole bunch of people, you buy out contracts, severance payments and those severance payments are usually more than their actual salary between November and end of December. But because the market now hears that you are getting leaner in the future, your stock still goes up. The reason I bring this up is because Om and I in previous podcasts have talked about the development teams, the, the teams producing your software. Slash running big segments of your business because development teams can scale to like large groups or whatever for sure. They need to have all of the skill sets that they need to actually produce the software that they're trying to produce and the teams are supposed to be self managing. Which means that the teams, now the teams need additional skill set outside of software development. They need to be able to hire new people in. They need to be able to deal with the financial numbers of their software. They need to be able to, and again, I'm the product management side of the podcast. So when I talk a lot about business dysfunction, I'm saying like, well it sounds like your business has no solid strategy. Right? Like your strategy is, I've got some customers, they pay me money, and that's as far as I've thought about it. And then product manager Brian's like, no, that's not good enough. Like, you get those customers could disappear tomorrow. If a competitor rolls in who's a little savvy and understands your market, or snatches a couple of your employees who are your experts like that. Things could disappear tomorrow, right? So, so one of the things that I, I pretty firmly believe is the, the, there are experts in your business that need to intersect with these teams. To help them develop the skill that they don't have. Finance is one of these skills, but I'm not going to use that because it's not in my wheelhouse. I'll, I'll use something that's way close to my wheelhouse, which is marketing. A lot of product managers, especially people like me who come from the development side of the house, They don't have the marketing skills that they need to be successful. So if you were to take someone off the development side of the house and be like, Hey, you're going to create software now and I need you to talk to customers. Cool, I can do that. I need you to vet requirements. Cool, I can do that. I need you to go out and position yourself in the market as the software to take care of this problem or whatever. I have no idea how to do that. So I need someone to help me. Like, I'm not saying I'm not willing to do it. I'm not saying that's not my job. I'm not coming at it with a crappy attitude. What I am saying is I've never done that before. I need someone who has done it to come onto my team. I'm willing to pay, right? Oh, maybe hire somebody, maybe pay a contractor, help me and my developers learn that skill, try different things. And now over a couple of months, now we can do marketing. Now we own the marketing for our own products. HR Hiring people when people leave our team. Interviewing, good interviewing techniques. What to say in an interview, what not to say in an interview. How to get rid of employees that are a problem or whatever. That's a skill. Now my team members and I have that skill. I think of finance the exact same way. How, how is what we're doing contributing to the bottom line? If you're Spotify, okay, we're getting to the end of the year. Our OpEx is about, I don't know, 8. 3 percent short. Let's go fire 8. 3 percent of our people and make that money up. Boom. Like that. Yeah. Great idea. Great idea. However, Why don't I just go out to my teams and say like, can we make up this reduction from what you spend team members, can every team go out and kind of tighten their belts for 8. 3 percent or whatever, whatever number we're trying to make up. Right? I feel people wouldn't even appreciate that. Approach their teams because most teams don't have that skill set to look at their budgets to understand what we're talking about now and say, Oh, we can contribute rather than firing 8 percent of all these people that let's be honest, 18 months from now, they're going to be Spotify is going to be hiring. We can like Siri set a reminder for 18 months. Yes. And we'll go look at Spotify's job boards to see if they're rehiring all these positions. Yes. Right? Yeah. Beginning of the year. But this podcast is real big on distribute those skills to the teams, let them help you achieve whatever your goals are. And if your goals are, we need to reduce 10 percent of our costs across the board. Ask the teams how they reduce. yes, this sounds great. But, the guys who are making the firing and hiring decision are so far from the front line. We often touch on the podcast about how they're rewarded and all of that organizational design. All of that plays into it. Like they're not rewarded to engage with the teams. They're rewarded in some other way. So they're going to follow the patterns of behavior that Maximize their reward. That's right. He or she wants bonuses at the end of the year. Now, it's not every business that is doing that. There are some people who are, it's a little bit of an adversarial relationship in some businesses. But I think some CEOs are going all the way down. Yeah. To engage their staff. I mean, I've been in businesses where they actually encourage you to come with suggestions on how we can cut costs, and they give awards for people who came with some of the great suggestions. Now, they're having a lot of abuse of that system, too, but some CEOs do that and when they can't make any more, then they cut heads, and cutting heads is. At the end of the year is that not too late because you've already paid twelve, eleven months, ten months of salary. I bring it up to reiterate that it is extremely important For people to understand, especially when they're on teams that contribute to the bottom line in the development, the product teams that they're on contribute to the bottom line. It's extremely important to understand these things. Again, it's like marketing is someone else's job. Sales is someone else's job. Finance is someone else's job. Understand that these are some of the most critical business tasks. These things are super critical. So that's why I want to highlight them. I'd like, I spent enough time preaching. let's actually dig into the, to the main part of the podcast I wanted to get to, which is when I first was exposed to this, I learned that there are two categories external use software, meaning software that's meant to be sold. Used by clients customers, end users, whatever, and internal use software. There are two categories, and I have worked on projects that capitalized for both. I think the easier one to talk about conceptually is internal use, this is the internal use graphic, which is this is the preliminary stage where you're supposed to do all your requirements or whatever, and then this is the actual active development, and then this is when it's out technical feasibility is reached, intended use is reached here. And then, then you can count it, like that's, that's, that's a very straightforward to understand. The other one is all of the internal, like this is, everything here and here on this graphic is under this R& D category. And then Technical Feasibility Establishment is here for external use. So in order to talk about external use software, we have to have a discussion about R& D. What most companies don't have a concept of R& D. I think the government has a concept of R& D. The government accounting has a concept of R& D. Like, when you're a government Customer and you pay for R and D costs. That is something different. Normal corporations, I don't know if they even use R and D. So I don't, I don't understand what R and D is. So maybe you can shed some light on R and D if you want to talk about external use first. Because I think the easier case is internal. Yeah, I agree with that. That is easier. So, I think there's a lot there, right? So first of all, you gotta figure out, before you even start all of this. What is the potential return at the end of it, whatever the end means, right? Two years, three years, five years at the end of it. And based on that correspondingly, you're going to invest, right? So before you get, before you make a single dime on that product, let's just say any software we're speaking about, but that, there's nuances, so we'll get to those later. So before you even do that, if you don't have that idea up front, you're just going blind, right? Because the market can change just like that. Like you said earlier, a competitor comes in and now you're completely off rails. But as far as costs, this one here, costs expensed as incurred. So in the early days. You're going to have some serious expenses, right? You ramp up the production of whatever it is you're going to sell. It's not until you sell it, really, that you start capitalizing it. Now, it says here, preliminary project stage complete, right? That could, that, this graphic is simplistic in nature, meaning That's closer to the start date, but in practice it doesn't have to be. Mm-Hmm., that could be way over to the right. Well, a, again, I like the, the graphics that I'm on, and when we do the podcast, you, you guys can't see the screen, the, the podcast screen. But when, when we when I post the podcast, what I'll do is I will put these graphics up as an overlay over us. Yes. For when we're talking and what I think when these were. invented. The concept was you did all of the software planning and then you did all the software architecture and then you wrote up all your requirements and then you did all that. You know what I mean? Like there was a phase before any active development started and then you brought it to your developers and then they started actually writing code. And then there was like purely again 1985 was the original document that I posted for this. Right that like you, it was purely waterfall development in its finest. You know, example of waterfall development, that that's how you get these phases is like a project start date. Basically. There's money in a pool somewhere. You start your people planning and whatnot and all those activities. The lifecycle was also. Correspondingly long back then, you didn't have, you'd have the situation where within a couple of months, six months or less, the market changed so much that you'll get in trouble. I mean, it was pretty much stable where you knew what mark, what the market was, and it didn't change substantially despite some new entrance in the market space. You're talking about. Many months to years back then, 1985, before you saw anything, right? So you have to have deep pockets to get there and have the patience to go through it and withstand all of that expense before you start turning that into into profit. That's changed now. I'm not sure what the original intent was, but the way I look at it is when you're just poking around, that this might be a good idea. You know, having beer, having coffee, or having different people doing requirements, talking to different customers, trying to see what the market might need. I would consider that R and D because you're not sure what you want to do. And I would think that once you finally determine what you're going to do and you have actually designed some features and I'm in my mind. I'm wondering if design some feature is the same as having an MVP. Is it a viable product? If you have already a viable product, then, should, is that when you start capitalizing it? That's the way, that's the way I like to do it. I like to expense as much as I can. Until, I know this is really a viable product. If it's not viable, Move on to the next end and expense all of that. Yeah. The, the MVP that you speak of is, is a product, is a pro, is a product increment that can be used. Right. So that's in that top image that is ga general, general release to customers. Yeah. You may have a small group of customers a focus group or whatever. That's fine. Or a pilot, but. You start capitalizing well before then. As soon as you have feasibility established. That I have done this for external use software is that we had a lot of, before we did any capitalization at all, we had a big discussion, a lot of back and forth over a couple weeks about technical feasibility. And really the, it wasn't a difficult concept. It was, but it, it only was drug out over a couple of weeks because we all had to agree. Together. What we were going to call technical feasibility, because even in your discussion just now, you pointed out I think Om was like oh, only during GA when it sent out this to the customers. But for me, I'm like, theoretically, if I have like a closed beta where I only invite a couple customers to use it, that could be technically feasible. Like, it may be super buggy and I might have more maintenance costs or whatever, but The moment that is, it is made available for a single customer to be able to use it. Meaning that customer, like when that customer meets that software, right, to use it. It is now technically feasible. That, that, that is what we settled on at the business that I was at, where we had to deal with this. That's an earlier point than in my argument. They wanted it, they wanted it to be as early as possible. Of course. It makes sense. Of course. They had, listen, they had yachts to buy and we were not getting in the way of that. Were you a private company? They were, yeah. So, I don't understand. I still don't understand when privacy was CFO's. Like to capitalize anything. Oh, I think it's because they have boats to be financed. They don't buy themselves. Yeah, right. Oh, okay, so they are. It's, yeah, there's a motive. There's a motive behind it. Now, of course, the accounting geeks might say, I mean, we all recognize that there might be 200 conversations going on around the country on what's the right point. But I think the key point is usually to say be consistent. If you say this is the definition of, don't come back tomorrow because your net income is low, and change it, or because your net income is high, then try and manipulate it. Yeah, and that's why the conversation was spread over a couple weeks, because we had to decide what was more advantageous. It really was mainly on the development department. I remember those conversations. It was mainly on the development department to decide what was going to be more advantageous to the business. We had internal use software. We had a couple different mobile apps. We had a couple different enterprise applications. So we had a couple different pieces of, Actually use software with any finance folks in that conversation. Oh, absolutely. Absolutely. Absolutely. Yeah. We needed their input to look at the finances over a longer period of time to decide once we make this decision. And it applies to all products, what will be most advantageous. And that, that is definitely something that we were not comfortable making just on our own. So, we needed to bring the finance people in. And we needed to give them as much information as possible. Luckily, we had a, we had a ALM tool that all this information was in. Super easy to just get the numbers redo the numbers or whatever, based off of whatever we wanted to do . So over a couple of weeks, we just crunched some numbers, had a couple of sessions and we decided what would work best across all of our product lines, and it was, it was to just try to go up with technical feasibility as soon as possible, as soon as we can get customers onboarded. it wasn't quite as early as sprint reviews. It wasn't quite that early, but it was, it was pretty close to that. It's pretty, it's safe. Fairly agile shop where our technical feasibility was done. Not in like software release phases, like a, like a waterfall type phases. Cause this shop released features. So the technical feasibility was done at a feature level, which is a little wrinkle in this, this chart that we're looking at, because now it's not just like, Oh, project start date and project finish date and delivered to customer date and maintenance end of maintenance date. You got a continuum there, right? Because the. because all now all of your software has to be bucketed as features. Yeah. So yeah, but but that gave us as a company a lot more control over our finances. Now, some businesses in this conversation would even bring in their external auditors. We did. Yeah, absolutely. I would think that when you start the project Oh, to start When you're determining what the company policy should be, sometimes it's a good thing to have the external auditors, or even the internal auditors. Most current internal You know how the old days, internal audit used to be Gotcha, right? But modern internal audits is more like in a helping mood. They want to make you to stay with the law. So, sometimes it's good to have their means so that You know what they can handle, what they cannot. How aggressive can you be and not get into trouble? You get external help as well, right? In cases like this, you get a a finance company to help you out. Maybe one of the big four, whatever. Depends on the size. Yeah. This will be the time to do it because You make the wrong decision here. There is no going back. There would have definitely been consequences to making the wrong decision. I don't think they reached out for any help because again, I think they were concerned with at that point. Yeah, that makes sense. in external use software, which is the R& D are there, are there tax breaks for R& D? I don't understand why you record things as R& D. Is that some kind of Well, the trouble is that R& D, by your rules, are different from tax rules. Tax rules are usually, it's political, whatever the politicians say you can do. We all know r and d when you see it. Mm-Hmm.. But IRS would allow things that gap may not allow or the other way around. Mm-Hmm., so they all know what r and d is, but they may have, they may have different thresholds, so for the purpose of. Externally used software. They say, anything from when you started the project until you've reached technical feasibility. And again, at my company, technical feasibility was, it's available to a customer, a customer can use it. So, it's like, it's in production. It was your, it was your definition no matter how minimal the feature is, it's in production, someone can use it. I mean, that's a lot of activity that you're saying, this is R& D. Yes. Because we're going to pivot here in a second to talk about internal use software. So I guess is the advantage here? That, if a software project comes to a certain point and just like, doesn't work out, you can write the whole project off? Is that the reason to have it in an R& D bucket? That's the entire, that's the entire reason. Oh. No use capitalizing an item that doesn't have any future value. Huh. I think the basic rule is always, if it has no future value, expense it. Yeah, I mean, it's basically sunk cost at that point. That's right. And sunk costs are never recoverable. Never recoverable, yes. How would I handle it if I worked for three months on this software project and it ended up like no one can use it, I don't, I just want to get rid of it. I mean, are you the, are you the contractor or are you the owner? Let's say I'm the owner. I'm the company. So usually you would, you would expect, you were expensing it anyway. Yeah. So it just continues to expense it. Once the project ends, that's it. You, you expense the last amount. You record a loss that year, basically. On that project. Yeah. You record a loss on that project for that year. So, you just keep expensing it. There's really nothing to do. Now, on the other hand, you may have decided that, wow, I've got a feature, let me capitalize it. Come next year, you find out, well, that was a mistake. Then you end up having to write it off. So the judgment is not usually very, your judgment is not usually very perfect. Yeah. So you see businesses writing off, and you know, it's not usually a bad thing to write off anything. Right. Because the market says, wow, they're getting leaner. That's why they're writing it off. Yeah. Yeah. But you asked a good question earlier, when you said you know, are there incentives for, I think in certain markets there might be. You know, I'm trying to think about some of the cutting edge, like maybe you're getting into one of the alternate energy markets or something imagine way back when people were first coming up with the solar energy you might have some kind of subsidy from the government or whatever. Okay, so you've just, you've just touched on another reason why people like to claim it's R& D. So the average Joe guy who watches on CNBC say, Wow, this business has spent so much on R& D. They must be coming out with something great next year. So you could bump up your stock. So sometimes this, I mean, you may think accounting is just numbers, but the CFOs who have to Pleased the CEOs you also have games to play too. You can see those in the financial statements. Again, I'm the product manager on the podcast. So I live in reality, which is a lot of businesses run with no strategy at all. So I'm glad somebody has a strategy. It doesn't if it, if it's the accountants that have the strategy in the business. It does worry me that they're the only ones with a strategy, but I'm just happy that I found someone that has a strategy in the business. They have a really good toolbox, right? These people that are making these, These financial statements, they just call them forward looking statements. They're forward looking. There are no guarantees. There is a thing at the bottom, a disclaimer. Past performances, no guarantee of future results. I mean, it does make a lot of sense. Let's go back to the Brian and Om's software development example. Like Brian, Brian, With Newton, who he has a CFO. That's right, that's right. Welcome to our company. Welcome to our company, Newton. Don't ask for raises. We don't care. We, like Brian wants everything on opex because I want the future completely clear for us. So like but om wants you know, CapEx everything all day long. So this year Om wins in budgeting. Brian came in with a hangover that day or something. I don't know what happened. Mm-Hmm.. But on the balance sheet, we have some extra money that's going into the end of the year. So rather than you know, I was gonna say firing people rather than hiring a bunch of people that we're that we can't afford next year. Well when everything balances out I'm gonna, I'm gonna use that money to maybe try out some new things that are somewhat risky. I'm gonna, I'm gonna try to generate some new features that. Maybe we throw them away. Like, I'm already 50 50 whether these new features are gonna work out. So, they go on the R& D section of the budget of risky things that Brian has started that he doesn't really think is gonna turn a profit, but he wants to do it anyway. Sorry, like that's too long of a title on the budget. All the characters won't fit into Great Plains. Like you need to, oh, okay. R and D fine. Fine. That's the way that I'm starting to envision the R and D categories, but if it doesn't work because our profits are over here and it's not going to exceed You know zero at the end of our budget at the end of the year hey, I'm willing to throw some money. I think that risk has to be a calculated risk, obviously. Sure, sure. It's calculated by how much money I'm willing to throw at it. Yeah, how much can you bear to lose? Yeah. So this is the casino technique, right? How much are you going to put? I'll look at Newton and say, how much money are we willing to lose? And Newton will be like, well, this is Well, first thing Newton will say is What did we decide on what is R& D, what's not R& D at the beginning? You know, so how much wiggle room do we have? You know, I mean, CEOs, CFOs, and controllers are always pushing the limit, the boundary to see how much, how much room they have. Well, if we look at the top chart, it's everything short of technical feasibility. So there's a, there's also a strategy here of Stopping short of technical feasibility with a, with a, we did a podcast before where we talked about, testing MVP to make sure that there's a signal there in the market, right? So like I could run 10 MVPs, find that there's no signal in the market, and now all that is R and D budget. Like it's, hey, I tested all these ideas. They're all garbage. We're writing all of that off. So you go back and become R&D. You write it off. Exactly. Exactly. So, okay, so that's making a lot of sense to me. And we're stopping short of technical feasibility. So the, the confusing part for external use software for me when I was doing this was you can only capitalize the tiny piece between technical feasibility and general release to all your customers. When it's a normal feature that's in your software. And I, I, like when I originally heard that I was like, wait a minute, like We're an agile development shop. That, that, that phase is so tiny that you're almost capitalizing nothing in that, in that phase. I, I agree. And then on top of that, if you throw in the fact that this isn't a singular product. You've got features that you're trying to do this with, then it's a continuum, right? You're always doing that for every feature. So it's a kind of rolling wave, superimposed, this line's not one line. There's maybe, I don't know, 30 lines, right? It gets very difficult to focus away from that and say, where is that? Point is that point varies per feature. Nothing wrong with that. We can, we can still do that, but it's just harder to get to grips with. Yeah. So some features that costs capitalized bracket would be More towards the left. Right. Some more towards the right. So, and it depends on how you defined it at the beginning too. Right. So, I, yeah, and one would think it would have to be consistent in how you define it and apply it across all the features. Yeah. Right? This has been a big point of contention when I've done this and I've reported , capitalizable metrics. One place was we developed this strategy where we, we, if you think about a feature like if you, it depends on the ALM tool you're using because like whatever epics break down the features, which break down the stories or whatever, but that, that's kind of semantics for this discussion. Anyway, the idea is you have a big bucket of work that's very similar to each other. I'm going to develop a new feature. You're going to be able to go to our website and sign up on your own. Like, that's the new feature. You can go to our website and sign up on your own. Okay, new, new sign up functionality, right, for external users. And I have a, a very basic form. You can put in your information, hit go, and now you're signed up on the website. And that's like, technical feasibility. The first customer does it, they can sign up, great. Except when you sign up on our website we want to the first customers we open it up to they can sign up and get in for free. And we'll deal with their payment outside of the system. But we always know that you have to pay to use our website. So, pay by credit card, pay by ACH, pay by something else. You know, pay by corporate account. Like, there's all kinds of additional features now. So like, we introduced the first, the first piece of technological feasibility in the feature. And now, we're, we're both adding features and doing maintenance on the features that exist. After that, until we book out all of the work in the quote, Project of allowing people to sign up for the website. So, it seems like there's not a lot of wiggle room in here. But in actuality there's a lot of wiggle room if you really get There's definitely wiggle room there. So, yeah. Yes, and, right, here's the other thing that you could say to that piece of functionality. You could say, well, it's a freemium model, so you can sign up, but in order to do anything meaningful. You gotta pay, but sign up pieces later, so you're in, because we want to grab your details so we can spam the hell out of you. Right? Until, until you actually become a paying customer. So it's like, at what point, at what point do you then say, this is when we start capitalizing? It's very tricky. I don't know how that's done, to be honest. Lots of judgment. And no two businesses are the same, and it's a dark art. That's why I'm, I'm, I'm big on having the auditors sit in on the decision making. Or present whatever you've decided on. Because they're expensive folks, so just present it to them. So this is what we think. Yeah. Yeah, it's kind of a standardization thing once you've decided on something. Hey, we're going to, we're going to deliver the first feature, and then a couple other features behind it will kind of qualify for what we're talking about. But again you can get in real trouble with this. Because like, how many what do you get? How many features are you going to get in line behind this once you deliver the first one? Like a hundred? Exactly, yeah. At what point does it become another product? Right? Right. Yeah, yeah. Right. Also in, inside of this is the concept of You're going to be doing maintenance on these things. It's a given for a while. Yeah. And none of that maintenance is capitalizable unless, unless you're in that period, right? That, that period in between feasibility and your general release when you're, when you call it done. Right. That's the only time that is. Yes, that's that's not. Yeah. All right. So that's pretty clear to me. I'd like to pivot again to internal use software. Internal use software seems really straightforward to me because this This is when I introduce this concept to people that have never heard it before. I introduce internal use software because internal use software seems really straightforward. You have the beginning of the project. You have all the planning activities before you actually start any development. And what I tell people is, any planning cost, any cost of you sitting in meetings deciding how to do something, before code is written, not capitalizable. The this is, this is an interesting topic because like the daily standup, for example. The daily scrum, for example, if you're using scrum. The daily scrum is supposed to be. a planning session of how we're going to do our work for the day. Okay? So, that is, that is, it's not a planning session meaning like, we have to talk about architecture and concepts. It's a planning session meaning my direct work that I'm working on right now. Most people don't get grain, they just say, just exclude the planning and all that. But that type of planning is not like conceptual, you know divorce from software. It's software design. As part of actually doing coding. It's part of development. It's part of development, yeah. Mm-Hmm.. Yeah. So, so the that, again, most people just say like, Hey, if you're meeting and you're not actually sitting here, desk coding, don't count because it's easier. Don't count it. Yeah. Because it is easier. And it, and I'll tell you, it is easier to do it that way. In fact, I, I do it that way. In the spreadsheets that I showed everyone before we started here, I was doing it that way. I was counting that time away from the capitalized cost. But the idea is. When you start, when things are ready to start and development actually starts, like I do this with the beginning and ends of sprints just to be super easy to have a real clear start and end, right? Hey, we've done backlog refinements. We've done planning on these things, but now the sprint is going to start. We start the timer on the capitalized cost. And when we deliver the feature for its intended use, when we deliver that, I know the language here doesn't say technological feasibility but we were using it when we originally did this, when I, when I did the original planning for this. When the feature is delivered for its use and a customer can use it, again, we agreed on the standard that's when the amortization started. So again, this is a lot more straightforward than external use. Yeah, I mean, you can generalize it and say until the product starts taking shape, right? So when you're developing, you just do a mock up screen, put up Hello World, but that's getting somewhere. So at that point, you can start it, but until then, it's just all planning. I would include even the business case, the vision in session when you're trying to determine. Realization planning and trying to determine what the business case is would, because if it's internal use, I suspect in any large firm, they have a group of people determining if it's going to be of any value. And that could take three months, six months. Especially if you're at scale, that could be a substantial number. I mean, even the daily stand up, right? If you think about it from a team perspective, that's one thing. It's a reasonably sized team, but what if you have a team of teams? And there's lots of teams. See, it adds up. I'm not sure that you can do that because like, what I think of Like what you just brought up Newton about I, I, I think I see that as architecture, right? And in agile development. Like, let, let's, let's look at agile development versus waterfall development. This is the reason I say that. I don't think you can do that because in waterfall development, the way that the graphic that we're looking at outlines it is you have this big primary phase. That is all operational expenditures. It's all, it's all immediately expense of, I have a lot of planning time up front to decide what business requirements that I'm going to work on, what architecture is going to be built to do it. Basically a big phase before my actual coding begins. In Agile development, the architecture is done as part of the work. The architecture emerges as the work. So I see a need to extract those little architecture sessions, those little ad hoc playing sessions. Out of the phase of development, and on paper, move them over here where they should, where they would have occurred at the beginning of everything, to say, this is all expensive. And then and separate it. That's a, that's the way that I've done this when I had to, when I had to capitalize for internal use software. Now, the way it happens in corporations is, some guy who is the user, who intends to be the user of the product, of this new feature you're developing, would come tell management that we need to develop A. Sure, yeah. So, they would set people out there to do business cases. They would bring in experts like you. Then they would bring finance folks, potential users to see, is this of any value? Well, the guy who suggested it would always say that it's valid. And then the finance guys will say, look, this is no value, or it is no value. So when you're capturing all that, even before your first sprint, even before your first sprint, there's a whole lot of work done before management agrees to even hire a development group to do sprints. So all that work, I would suggest, should be in the expensing phase. Because there's nothing out there, they're simply thinking of what to do. So the product hasn't formed yet. It's what I'm saying. If you can touch and feel the product, so to speak, right, you can't touch software. But if it starts forming at that, to me, that's a simple trigger. And that's when you say, okay, now we're starting to make it, right? Right. Yeah. Well, I guess another way to say what I'm saying is When we finish this software, and we disband the team and get rid of it, or whatever, or you know, spin it down to just a maintenance team, or whatever. What you're going to be left with in your in your ALM tool whatever you use, Azure DevOps, or Jira, or whatever you use. You're going to be left with , all the requirements that it took to generate the system that you built. And the way that this graphic is written, and originally probably interpreted, right, and originally probably written, was you did all those requirements and everything that was intended to be done before any developers came on board. You're right. Yeah. So I'm just saying you're taking that and you're just piecing it up along all the sprints and all that kind of stuff. So that's why I say like, you probably need to just take those hours out of whatever you're reporting for capitalization for internal use. And again, it's doable, right? I mean, ALM tools allow you to do that by role, by WBS code or whatever. So may I ask you, would you have the sprint team do requirements gathering? Yes. So, when you, generally the way I have seen it, most times, the corporations would not even hire a team to do requirements gathering until they've got a business case to say, Sure. Go ahead. Sure. So now requirements gathering, is there any point when you start requirements gathering? When you will decide that you don't want to continue. Continue the software? Yes. I mean during requirements gathering space. It can happen? Yes. So if, in that case, I would even consider expensing requirements gathering. Sure. Sure. So, after your first meeting with the product owners. You know, when you're building the backlog initially, I would say that's preliminary work. I'll give you, I'll give you an example of what I do, every week, my team does at least one hour of, backlog refinement. Okay. And my backlog refinement may be spent on talking about problems, potential solutions to problems that we will never implement. Like I mean, I will say I think that this business process and I'll, I'll bring subject matter experts from across the business or we'll reach out to a customer or a business development person or a customer representative sometimes. So I'll bring different experts from around the business into my backlog refinements who are experts on the subject that I want to talk about. And I want to say. The software currently operates like this. These are the gaps I see. To do your job well what will we have to add to the software? So what will we have to add to the software? And we might, we may burn the whole hour, and not produce a single story. So to the business, that's like, that's a complete waste of money. You know, they completely got to write off that whole time for everyone in the meeting, because we produced nothing in that session. See, that would not be my standard. If you've already started You've set up your sprints and you've set up developing application and it's just out of caution you bring in guys to try and look at it to define the backlog, then I would say that's part of application development because you're already doing it. You just want to make a better product. But that, that happens every single sprint. This isn't a one off, right? Every sprint, you're going to do that refinement. I do it, yeah. Every week, yeah. I mean, I would say once you started coding, like you said, once you started coding, I would, I would not expense anything. Sure. I mean, I would, I would capitalize everything for application development. Internal use. Yes, for internal use. It may not matter for internal use. I think the takeaway here is there's some flexibility. You know, there's a lot. Arguably, there's a lot more flexibility here than there was for the other category. But, but also I've been in, I've been. Partnered in small, very small businesses, where the CFO just says I'm not dealing with all this, I'm just going to capitalize 50%, and I'm done. It's not publicly traded. No one's going to look at it. Yeah, they don't want to deal with all the nuance of what we just talked about. They don't want to deal with that. They just pick a number and that's what they capitalize on. Yeah. So if, if they have no loans, and nobody else cares about their financials, he can do whatever he wants. Because the focus really should be on the cash. You know, the basic thing. thing is focus only on the cash flow. Forget about accounting, accounting numbers, capitalization and expensing. That's really what it is. The capitalization and expensing is for the other consumers of the reports. The market folks, the banks, they're interested in net income. When really the business runs on cash. Yeah, that, and that, that was, that was exactly my experience. And why, why I've done this so many times is I've been at these firms that are owned by private equity and they, they are very, Concerned about getting getting their money back for their investment and they want to, yeah. Yeah, and they may have conditions, as you said. They may have conditions, yeah. For the loans. Right. So, yeah. Yeah. I mean, I have another, I have another category Newton, you just wrapped this up pretty perfectly right there. Okay. What category do you have as a matter of interest? I have a leading versus lag, leading versus lagging indicators for software finance. Anything that we can do to, to, to watch out for with leading versus lagging indicators. I think that's a great topic for the next podcast. I agree. I think you're right because I think a lot of people just don't know what to look for with their software finance of, of, of leading indicators. Because anyone can look at how much cash we have. After the fact, after the year closes, and say, Oh, it looks like we're not doing too good. But it's too late by then. It's too late, yeah. So in your sprint, how many of your development team even gets involved in the discussions on capitalization? None, none, none, only because I have experience doing this for my team. The the, the reason I have experience doing this for my team is because I was a manager in that organization where the company got bought by private equity, and I volunteered to work with the finance people to figure this out because I was super interested in You know, not only why we were doing it, but I wanted to actually understand how we did this because it was something that was completely foreign to me. I was like, this is really cool. Because I've never done it before. I've never heard any software development team. All the networking events I ever go to, I've never heard anyone bring up any of this. I'm like, I don't quite understand how to capitalize on this. Which is why we do on this podcast. But to your point though, right, somebody, especially in your role. Product management. I think product managers should be savvy on this stuff because whatever they're doing is impacting the bottom line for better or worse. I'm thinking also of the product owner. Mm hmm. So it could be the product owner also. I mean it depends because he, on a theoretical basis, he's the guy who, who Who has direct contact with the owners of the business. And he has their best interest at heart. Which includes also the financials. Right. So I would think the product manager, the product owner. Most product managers I know don't usually care too much. Right. They should. That's what I'm saying. They should. If you're a product manager, you're managing the product. You, you, you, you have to have finance, so there, there, there are two things that we believe on the podcast. I, I think, I'm going to speak for Om for a second. You have to have financial literacy but financial literacy is not good enough. Teams without financial information cannot make financial decisions. That's a that's a Mike Miller special right there So if you hide the financials from your product owner to the team How is your product owner and how is the team? Going to make good, sound financial decisions. do we build versus buy this feature? Do we spend more time on maintenance of this feature, or do we just cut it off? Do we decide that we'd rather just build a whole new feature and not maintain this anymore? Or, or do we decide, there's no value in this. We're not gonna keep continuing doing this. That, when you take away finances from the team and if the product manager or product owner is a representative of the team with regard to these finances if you take away finances from that person and and the whole team your team now becomes blind exactly to the most to the arguably arguably right we could argue about this arguably the most important metric which is finances the power of that team how much you bring in How much does it how much does it cost to run the team? How much does it cost to produce each feature? And how much are you bringing in based on the features and everything? Like, now you don't have the information you need. How can you decide to run a business that way? You, you're basically muddling through at that point. It's like taking the compass away from you know, the captain of a ship, right? It's just like, you just go somewhere. Everything looks the same. Everything's a horizon, right? Whichever way you go. It just makes no sense to me. But that, unfortunately though, Is the reality. I don't see that on the ground too much. So really that's why I'm, I'm, I'm, I advocate for the decision support model. Which means that the CFO has to have some of his staff integrated with someone in development. Maybe it's not every day he's not doing sprints with them. But once every few weeks there's somebody in finance who understands all their pains. All the, all the gray areas. So he can go back to the CFO. And explain with some kind of expertise on the issues down there and then come back and give the same, the developers also why the CFO has some net income targets to meet. So he has to do truthful, of course accountants don't fix, don't maneuver anything. So the CFO has to figure out a way truthfully to meet his targets with the help of the development team. So I really don't believe in this idea of separating them and then hoping for the best. Hoping for the best, you know. I think in practice, this might be like a this might be a delivery manager or somebody like that who has that. The financial chops to do this, right? Working with the finance arm of the organization. Maybe PMO, I don't know. I would rather work directly with a finance person to get that skill onto the team. Right. But again, in practice that doesn't happen. So I'm thinking, what is out there that can be leveraged to get to that end state? So what does the product owner do on things like this? What does a product manager do? Manager backlog. I was gonna say, get, get, get fired at late November, early December when it comes time to make up that, make up that OPEX. Not a lot. So there's two sides. One is, yes, they don't have the information, right? And then the second side is they don't have the autonomy to make decisions. Right. You need the information to make decisions. But you also need to empower them to make those decisions. The division I see is the product owner is in bed with both the team and the finance folks. Yeah, ideally. So that's what he should do. Ideally that would be best because you don't have any middle layers getting in the way. Right. But again, hierarchical company, that doesn't happen, right? That's the sad part. We always give good advice on this podcast. In those scenarios, we say, Hey, keep that resume updated. Alright, so this was a topic that has been on our minds for some time. Hopefully, You've stayed with us this long. Let us know what you think down below in the comments and let us know if your experiences are You know different or the same we'd love to hear from you or if you manage a budget like that would be nice Yeah, that would be good too. And don't forget to subscribe and like while you're there