Budgeting Time for Your App

Before starting your project, it’s important to have realistic expectations of how long it takes to make custom software (and therefore how much it costs) before getting started. There’s nothing more disappointing than getting partway through a project only to realize you need to pause because you’re just too busy to dedicate the time it requires.

Full Transcript Below

Cris:

Hey, everyone. Welcome to another episode of Bixly Tech Tuesday. We’ve got Andrew and I sitting down to talk today about budgeting your time.

Cris:

So Andrew, how do you go about figuring out how to actually best budget time on a project?

Andrew:

Sure. That’s a great question. So it really depends on the nature of the project but typically projects are going to fall kind of in a three-month to six-month time frame, and as far as your time as the client budgeting it, it’s typically going to be a few hours a week that you’re going to need to be involved for stand-up meetings where you’re talking with the developers, giving status update, you’re giving the feedback from your clients as they’re testing the thing, so there’s a good amount of back and forth there. So it’s definitely not a 15-minutes-a-week kind of thing, but it’s also not a 15 hours kind of thing.

Cris:

Okay. That seems reasonable. But also, though, why can’t I just go sign up for some service? I mean, we live in the world of obviously like SAS, so why can Company X charge $19.99 a month for me to use the service, but you’re telling me, Andrew, if I custom build it for myself it’s going to take me three to six months and sounds like probably be pretty expensive. Why is that?

Andrew:

Sure. So now we’re kind of getting into what is custom software versus what is off-the-shelf software. Custom software is something that is built to be a perfect fit to your needs, your unique business requirements, and custom software makes a lot of sense when there’s not an off-the-shelf product. If there’s already an off-the-shelf product that you can pay $19.99, $49.99 a month, it probably makes sense to go with that until perhaps you hit a certain scale. Maybe if you’ve got 20,000 users or it could be less than that, a subscription-based product might not be cost effective. It very likely is not. But at a smaller scale, just kind of outsourcing all that to an off-the-shelf solution tends to make sense. With custom, there’s a lot of back and forth. There’s a lot of time that goes into planning, understanding your business requirements, validating those requirements, what we build going to your users, gathering your user feedback iteration. So there’s just a lot of back and forth there that adds time, which adds cost. But ultimately it gives you the benefit of this is a perfect-fit solution that solves your very unique problem. So that’s why it’s time consuming, and the time consuming part is most of the time why it costs so much.

Cris:

Got it. So we’re budgeting this time because of the fact that we are building something completely custom and not just an off-the-shelf sort of thing. That’s why we’re talking about budgeting time. We’re dealing more with either having to custom build something fixed cost or I need to go some sort of time and materials model, but either way you need to build out some sort of an estimate or quote, which involves allocating for time as you’re developing.

Andrew:

I think something that people don’t take into consideration, too, when they’re looking at off-the-shelf solutions or softwares of service-type solutions is the tens of millions or hundreds of millions of dollars that that company put into building this thing, and so there’s just a lot of maturity and a lot of time that’s gone into building this thing, a lot of testing, a lot of validating of user ideas, focus groups, things like that. So yes, you are paying a monthly fee, but it is not a perfect fit towards what you need. And realistically, you probably don’t have the kind of budget that Facebook has or something like that to build something like that. So you’re leveraging their service or you’re going to build something custom that yes, will take time and money, but again it’s going to be exactly what your users need.

Cris:

That makes sense. So we’re dealing with, like, when we’re building these estimates out for this custom-built software, we’re dealing with potentially days, not hours or even minutes of time when we’re building out these estimates.

Andrew:

Right.

Cris:

So again, you kind of touched on the model of I have to look over something as the client and then I send it to the development team. The development team has to process it and say, “Okay, what did you mean by that?” whether it was written down on paper or maybe even over a phone call and our stand-up meetings, or daily meetings, you’re building it as the team, you’re then validating it on some test site, you’re sending it back, so on and so forth. And again, this is all building out to hours.

Andrew:

Right. Yeah. Nothing takes less than half a day.

Cris:

Got it. I was going to say. Yeah.

Andrew:

In a professional software development environment this isn’t, like you said, a 15-minute turnaround time. There’s a lot of validation. I think something people don’t understand, too, is that when you have software that’s built and then you go make a change to it, it’s quite possible that the new change you’re making could break some old functionality or could cause something that worked before just to not gel right, and so we do what’s called regression testing because we don’t want anything new to break anything old. So we implement the new thing, we identify which parts of the software could be impacted by that, we go back and test those. So we’re constantly validating to make sure that the software is still working as it should. We do have automated tests and things like that that we can build to help kind of automate those things, but there’s always a certain amount of just kind of manual validation. So yes, it’s never a quick 15-minute-type thing. Even things that are changing colors and different things like that, we still want to make sure that it looks good with the designer, we didn’t just switch from green to blue and it wrecks our color palette kind of thing. So there’s a lot of validation we do to make sure that everything looks good, it works right, and it fits your user’s needs.

Cris:

Gotcha. So projects take time is basically what we’re saying, and we do the best we can, obviously, to build out these estimates and give an understanding of as we’ve established more days and potentially months as these projects build on rather than just hours and minutes to do those features. But obviously, we’re going to run into delays at some point. Something’s going to come up, something’s going to delay your project, something’s going to delay a project that we’re working on. So Andrew, what are your thoughts on reasons that delays can kind of pop up and then also how do you deal with those?

Andrew:

Sure. So delays can come up because of miscommunications. Perhaps as the client you didn’t clearly communicate to me what your objective was or what you’re trying to achieve here, and so maybe you said, “Do XYZ”, we did exactly that, and that didn’t really fit your business needs. Yes, we did get XYZ done, but it wasn’t achieving your overall objective. So by communicating your objectives and really just kind of what is the success criteria, what does winning look like, it helps us make sure that if we have any questions about what you’re doing or your suggestion seems inconsistent with that, we can help give you feedback. So communication’s a big one. Also, too, sometimes clients will just put off making decisions. So they need to select whether credit card processor A or B, whether they’re Stripe or Square, is going to be more widely accepted by their user base, but they don’t take the time to do that. Then last minute we don’t really have a decision on which direction we’re going, and so now we have to wait for that or kind of reprioritize at that point.

Andrew:

So there’s decision points that need to be made by the client, some research that they need to do with their users, and so it’s just important that we as the developers communicate to you what those decisions are you have to make so you have plenty of time to think about it and process that, and that you do those things in a timely manner.

Andrew:

There’s also accounts that need to be set up. Many times there are several third-party services that are used throughout a project because it doesn’t make sense to build everything from the ground up. There’s many third-party things we can leverage, but we need those accounts. We need proper access. We need access to the hosting server and domain name. So there’s any number of things that could cause delays.

Andrew:

As far as, how do we deal with those? We try to prevent them proactively as much as possible by when we do our project planning phases identifying things that are potential blockers or that could be delays. So perhaps we’re working with a third party who’s providing an API for loading funds or something like that. If we’re going to need to work with that team, we don’t want them to know two days before that okay, we need your help doing that, so we need your help modifying the API. They need to know that 30 days in advance or maybe longer so they can plan accordingly.

Cris:

So we can estimate and we can give you these timetables because you’re describing a lot of things to me, and as you can see and as you can obviously see if you’re watching this video, Andrew is describing a ton of stuff here that takes days to sometimes get feedback from the third parties, to communicate the expectations properly. If you’re telling me or I say, “Hey Andrew, how long is this going to take?” and I don’t give you all that information, your estimation is not going to be wrong, it’s just going to be inaccurate on the larger picture. So that can be perceived as a delay in a way.

Andrew:

And that’s a big advantage with working with an experienced development firm like Bixly is just we’ve seen all the different things that can go wrong with projects. We’ve seen the delays that can happen, and so we are experts in risk mitigation and we can help tell you, “Look out for these potholes.” When people go intending to do things themselves, I think a lot of times they don’t really calculate the cost of what are some very expensive mistakes that could cause delays, could cause added expenses and things like that, and we help our clients look out for those things. We say, “Watch out for this danger over here, watch out for this over here”, and so it’s hard to quantify how much we’re saving you by holes you would have fallen in on your own, but we can definitely use our experience to help guide you through that minefield.

Cris:

Cool. So we’ll obviously estimate a project out or maybe even in the idea of going fixed-bid model, we’ve laid out a very clear roadmap with costs associated, actual deadlines that need to be met, delivery dates, the whole thing, but something changes. There’s some requirement that changes within the project or just the client starts to see the feedback and they have a different direction, probably user feedback. You’ve touched on that a lot and you have to pivot the project. How do you actually go about dealing with those pivots and still keep true to estimates in a way?

Andrew:

Sure. Well, if we’re doing agile-type methodology or staff augmentation, then it’s usually just a matter of we take this feedback, we put it in the backlog, and we help prioritize these things and determine okay, is it going to be in the next sprint, often the next two-week iteration. But we try to avoid stopping everything we’re doing now and jumping over and doing that, because a lot of gear switching just kind of wastes time. So again, we use the backlog to kind of groom those things and make sure they’re handled in the upcoming weeks or perhaps we identify that this is something that needs to be done but it doesn’t need to be done in this version. So as we get close to a release date, many times there’s multiple releases, there’s a version one, there’s a version two, there’s a version three, and so as we’re looking at these features or changes we’re constantly asking ourselves and the client, “Does this make sense to put it in rev one? Does it make sense to put it in rev two? Is this a rev one time-permitting sort of thing?” That’s also a common one.

Andrew:

If this is a project and we’re doing a fixed bid, then that’s going to be addressed in terms of a change order.

Cris:

Got it. Okay.

Andrew:

So the client’s going to let us know what they want. We’ll work with the developers to figure out a cost estimate for it. We’ll come back and say, “Okay, this is going to be X dollars and take roughly X amount of time”, they’ll sign off that they approve that, and then we’ll work with them to determine again does this need to go within the next two weeks? Can it go in V2, does it need to go with the next two months, that kind of thing.

Cris:

Gotcha. Obviously, this isn’t completely just a catchall kind of a statement here but in your opinion, Andrew, if you’re going to build something custom and you need to obviously estimate out time and a cost associated with it, what are your thoughts? I’m going out to the market with a custom-built piece of software. How long is that going to take me? How much is that going to cost? If I don’t have this much time and money ready to go, what are your thoughts?

Andrew:

Yeah. So we can just talk in terms of bare minimums. So we’ve already touched on this as custom. Custom takes time. It’s going to be a perfect fit. So the general parameters I’ll tell people if I’m on an initial sales call with them is you should have a time frame of at least three months to allow for proper back and forth, proper planning, proper testing, and you should have a development budget of a minimum of $60,000.

Cris:

Gotcha. So again, not $19.99 a month.

Andrew:

Right.

Cris:

Unless that works. But if I’m custom building something, I need to plan for a few months of time and I need to plan for about 60K. Now- I’m sorry.

Andrew:

It just depends, too, on the scale, right? So if you come to us and say my minimum product has got to be able to support a million users in this heavy wall. You’re not going to be talking $60,000.

Cris:

Right.

Andrew:

We’re going to have to have a much-

Cris:

That’s a big caveat.

Andrew:

Much bigger architecture here. But if you’re really looking at a smaller group of people or kind of reducing your scope initially then yes, we can kind of fit something in for that and help you come up with a plan to grow it. So that’s another thing to keep in mind, too, as the client is do you need to push this out to everyone at once or can you do it to a smaller subset of people, learn from that, solve their problems, and then build it out, and what do those phases look like in your rollout?

Cris:

Gotcha.

Andrew:

Because some people feel like they have to shoot for the stars on the first one which is, of course, going to take more time and cost more, and it’s usually almost always not the best way to do it.

Cris:

It’s always good to roll out iteratively and get the feedback from the customers. That makes [crosstalk 00:14:11] very well. So overall, I think as we kind of wrap up here and we’re talking about estimates and time to actually build custom software, I think the big key takeaway points is that we’re talking days and months. Obviously we said the 60K, three months to build a project, but we’re talking days, weeks, as opposed to just hours to get features done. Our Bixly mantra is nothing takes less than half a day of work, obviously. It’s something that you, as the customer, we sort of touched on it, like all this feedback here, there, and stuff, you can’t just kind of set it and forget it. You have to communicate with us either throughout the entire process if we’re going the time and materials model, or you need to set aside some really clear road mapping at the front to basically lay out exactly what’s trying to be built and have that strong communication. But as a client, you have to be involved.

Andrew:

Absolutely.

Cris:

So if someone’s wanting to build with us, they need an estimate. They want a quote. They basically just even maybe want an idea of how to kind of get started with Bixly. How would they go about doing that?

Andrew:

Sure. So the easiest way to do that is to go to our website and you can find on there, there’s a way to contact us. You can sign up for a free consultation with someone like Cris who is going to help validate your idea, make sure that you even stand a good chance of being successful, because we only want to do projects that we feel like are going to be a win for our client kind of thing.

Cris:

Sure.

Andrew:

So Cris will help you validate those ideas. He’ll talk about your time frame, your budget, what does winning look like, and help you determine, “Okay, am I on the right path for success?” Also, we have a free custom software guide on our website, and that’s really useful because it helps you look ahead and see what this journey is going to be like that you’re going to go on with us and what are the different phases, what to be aware of, and just help you really kind of count the cost and make sure that you do have the time to do what it is you need to do.

Cris:

Cool. That seems reasonable. Any other closing thoughts, then? Otherwise, we’ll let people obviously go check out bixly.com.

Andrew:

No, I think that’s it.

Cris:

Cool. Well, everyone, I appreciate you taking some time to talk with us about basically budgeting your time on a project. And again, I want you to walk away with the understanding that building custom software just takes time. So again, please feel free to check out bixly.com, go get that brochure for our custom software and download that either from our site, you can find it on the contact page, or we also have it conveniently linked in this video.

Cris:

Thank you very much, everyone. I look forward to chatting with you all again on the next Bixly Tech Tuesday.