Reviewing proposals to build digital products

What to pay attention to when you received a proposal for building a digital product.

This week I was asked to review a proposal for a quite simple web application and noticed a few things which were not mentioned in it. In the past, I’ve spent a lot of time writing and reading proposals to build mobile and web applications. So decided to write a blog post on how to review and analyse a proposal to build a digital product.

This post will be general enough to review any digital product proposal. But it’s tailored to someone who wants to build a digital product. I also assume it’s the first version of the product.

I will not cover the presentation of the proposal or a medium - i.e. site, PDF, etc, I’ll focus on the content.

Usually, the proposal would include the following parts:

Must have:

• Product overview/specification
• Technology Stack
• Team overview
• Testing / Supported platforms
• Support / Maintenance
• Costs

Optional, but useful:

• Testimonials
• Basic Wireframes
• Next steps
• Processes

If you have any questions get in touch with me via [email protected].

Specifications

This is the part you want to focus the most as it describes what you will get in the end. It’s more about the list of features at this point, and not how it works or looks.

It’s helpful if they send basics wireframes to illustrate how the product might work.

The worst situation for you is to sign off the proposal, pay for the development and down the road you find out some critical part of the application won’t be build as it wasn’t in the spec. This would result in a delayed project and increased costs of the product.

Remember, there is always more context about your product in your head than you can communicate. Make sure you’ve communicated enough and they understand your goal.

Also, before you send the brief, it’s best to talk to the potential users, learn about the problem. You can share these insights together with the brief. In this case, the team creating the proposal has more insights and as a result, can create a better reply.

Technology Stack

If you are a non-technical product owner this might be a bit harder for you to analyse.

The team that sends the proposal should include the reason why they decided to use the tech they propose. A short description of the community behind the technology and how mature it is.

The largest red flag to notice is if they say something like Facebook or Google build this technology and released it a few months ago.

You are not Facebook nor Google and don’t have the problems they have.

Dev shops want to build using new tech as they’d be able to include this in their portfolio and show an example for this technology. The newer the technology, the more risks there are. Always choose mature technology when building a product from 0.

You can always ask how many projects they’ve built with this technology and you can ask to see the demo or use the app if it’s available.

Testing and supported platforms

Make sure the team covers how they plan to test your product and what are the devices, operating systems (OS), browsers they’d support.

As a rule of thumb - your product should support two most recent OS or browser version.

Some teams might include bug-free warranty period, i.e. they will fix any bugs found within 30 days for free. Later changes and fixes usually covered by support and maintenance.

Security

If you plan to save users data somewhere either on the device or on the server you’d want to know how it’s secured, who from the team will have access to it.

Also, you want to have servers secured, with strong security practices. Otherwise, you might end up with your database left exposed to the world.

Take into the account the EU GDPR policies, this does increase some operations, coding, legal and compliance time. To be honest, if you don’t target EU citizens you’d still want to have a strong policy of how you use the data as it on its own can be a good selling point.

Costs

Cost depends on the scope - the more you want to build, the more expensive it will be, as simple as that. Some places around the world have cheaper overhead, thus they will be cheaper as a result.

Also, it depends on the technology stack you choose and the team experience.

Be aware the software development (any kind) usually costs more than initially planned. Make sure this is covered in the proposal, or in the contract.

I.e. if it’s a fixed price project and it takes 50% extra time, your supplier might cut corners and you might end up with a) ruined relationships with them, and b) worse quality product.

If the team charges you hourly or the daily rate you will still have ruined relationships with them and it will cost you more. And if you are on a tight budget you will want to ship as soon as possible and potentially compromise on the quality.

You might want to check if the project includes any extra time (contingency), for small changes in the end. For example, wording, some small elements and design tweaks.

If your application has server side you’d want to know how much it costs. And also check if there are any other services like sending emails, you will need to pay for.

For daily rates, in London, a few years ago, the daily rate was around £500. Depending on the agency structure and experience the cost might go up to £750 per day or more.

If you have a budget, I’d advise working with a local team, having a face to face conversations is always a plus.

Support and maintenance

After you release the product it will need support and maintenance. The software world moves fast, even though the code might stay the same, the 3rd party libraries, tools might change. As a result, you will need to make changes to the code.

Think about new iOS releases - each time a new version is released the developers will need to adjust their code to support it.

You’d want to find out how much time and monthly costs would be.

If you plan to build the future versions of your product straight away you might want to skip it. Both changes and fixes can be included in the next release of your product anyway.

Testimonials

You can ask the supplier if they’ve done similar projects or if they’ve worked on building custom applications before. For web development, many suppliers specialize in building simple web pages. Although the skills for building a web app is similar, there are more to it than displaying the content.

Also check when the testimonial and the project were completed, if these are not recent testimonials (1 year or newer) that might be a red flag.

Marketing

Even if you plan to build a project there is no guarantee you’ll have users from day 0. It helps if you already have a list of users who would want to test it.

In any case, you will need a separate budget for marketing, so might want to check if the team can help you with it too.

Also, check with the team if they can help you with the branding for your product. They will usually have some basic branding skills.

Other tips and notes

• Some teams use online presentation tools, they can see if you open the proposal, and how much time you spend on each section.
• Check with the team about the code ownership, i.e. who owns the code.
• Do they provide the code, design assets, etc after you pay the invoice?
• It’s always useful for the supplier to know your budget or budget range. They can propose a different solution if you have a larger budget. For example native vs non-native mobile applications.
• Plan to charge for your product? Ask if they can help with pricing strategy.
• You can ask to see any open source code repositories the team have contributed to. Then hire a senior freelancer who can review the code and provide feedback. It doesn’t need to be an in-depth review, jump on a 15-30 min Skype call and see their reaction. The worst you can see is “OMG, who wrote this s*it”.
• Keep in mind your first product won’t be perfect and it’s ok. Launch, learn, improve, repeat.