So, you have a unique idea and you need a new web and mobile application. In the marketplace of design and programming services, the buyer wants to get as much value for as little money as possible, while the seller wants to provide as little service for as much money as possible. This, my friends, is human nature. Is it possible to find a middle ground without one of the parties getting the short end of the stick? The answer is, yes, it’s possible! With some trust, give-and-take, and a bit of planning, it can be done.
The first thing to do as a client is to establish a foundation of trust with your prospective development partner. Yes, I said partner because the firm you choose will be in it with you for the long haul. If you’ve been given a referral and connect with the firm’s references, testimonials, and prior work, that is awesome! Without some trust, the buying experience will look something like this. The development team will ask you what your budget is. You’ll say you don’t have one or “that’s why I came to you.” From the developer’s point-of-view, they’re thinking, “Is this a giant waste of time or not?” Then the developer puts together a proposal, that they aren’t going to spend much time on, and will be padded like crazy in case the project is bigger than they thought. They show you a number. You freak out. After that, you go to developer number two with even less trust for them because of your recent experience with developer number one. It doesn’t have to be this way!
Budget and Pre-qualification
Imagine building a new home using the above process. Yikes! Both sides have a piece to own in making this work so let’s look at it from the home builder’s point-of-view. The first thing a builder is going to ask you is the budget question. In this circumstance, it is quite normal to share your thoughts on how much you think you can afford. Since this isn’t the builder’s first rodeo, he or she is going to help you get pre-qualified. After working with the bank, you find out you can afford a $300,000 home. Maybe you only want to spend $250,000, so you work with that number. Now we have a starting point. You explain to your builder the kind of amenities you want such as marble countertops, tile floors, a swimming pool, and so on. Right away, the builder is going to tell you a swimming pool isn’t going to fit in the budget based on experience. With some give-and-take, you work with the architect to keep the price per square foot under control so you can get as much as you can with your $250K budget. Once you sign off on the plans, it’s time to build! When it comes to developing a web or mobile application, the buyer and seller can use this same approach. Between you and me, we know that everyone has a budget in mind for what they want even if they are simply guessing. Don’t be afraid to share that with your developer — remember, you should trust them a little at this point. Your developer should ask more questions to “pre-qualify” you such as:
- Do you have investors?
- How do you plan on making money with this?
- How fast do you need your app to go-to-market?
- What does the Minimum Viable Product (MVP) look like at launch?
Once your development team has the answers to these questions, it’s time to create a “blueprint.” Since developers sell time rather than drywall, lumber, and tile, in some ways it is easier to estimate how many hours it will take to develop your application. The hard part is, since nobody has created your app before, there are no “comps” to look at. Comps in real estate are comparable houses and what they have sold for recently. Now you need to look at your app as if you’re building a custom home that nobody has ever built before. What your developer will do, while having your budget in mind, is to break down what was learned during the discovery sessions into tasks and then assign an average number of hours to each task. Some tasks are easy to estimate and some, well, not so much. This is where the risk comes in for the developer. The more details a developer can get up-front, the better. If all you have is a napkin sketch, that’s OK. A good development team will help you get more detailed by creating a prototype and some documentation. These comprise the blueprint so expect to pay for the time needed to create it. Just as you wouldn’t build a house without a blueprint it would be foolish to start programming without a blueprint in place. Part of the plan is a Statement of Work that would include the number of estimated hours per task and a timeline with milestones and a final deadline. The hours are multiplied by the development team’s hourly rate and that is how the final price is calculated. If it doesn’t fit the initial budget constraints, it’s time to ask what can be left out but still be able go-to-market with something that will make money. This is known as the minimum viable product or MVP and is where more give-and-take comes in.
Fixed price vs paying by the hour
Everyone I know, including myself, wants a fixed price when buying something. If your plan is well detailed, your development team should feel comfortable giving you a fixed quote with a 15% +/- under/overage clause. If your plan is vague, the developers take on the majority of the risk, which isn’t fair and can lead to a lot of friction later in the project. Because of that scenario, developers will require you to pay by the hour since they don’t have a firm grasp of what they’re getting into. This puts the majority of risk on the buyer.
Plan, plan, plan
Again, a home builder shouldn’t start hammering nails into boards without a blueprint and detailed manifests of the materials to be used. Similarly, a development team shouldn’t start programming without wireframes, a prototype, and at least some high-level documentation. There’s a lot more than meets the eye when it comes to developing a complicated web or mobile application so don’t be afraid to share your budget and spend money on having your blueprint created. You won’t regret it!