Getting Good Estimates from Developers

Start with a Functional Summary

In the course of our business, we evaluate a lot a product ideas and are frequently asked to prepare estimates and quotes for development costs. Like any complex construction or manufacturing process, the answer to the cost question is always: “it depends”.

The cost to produce an “app” or “website” all depends on what that website does, what it requires to function (input data, 3rd party integrations, etc), the durability / longevity expectations (is this a beta/MVP or does this need to be a polished product), the expected user or data volume, and the number of supporting systems required (onboarding wizards, marketing funnels, customer support services, etc.).

In order to give an accurate estimate - which is necessary for both our customer’s bottom line and our own - a lot of work needs to be done upfront to define these things. This definition phase can often require research, preliminary software architecture or visual design, prototyping for feasibility, etc. That is why - as a company practice - we begin all of our engagements with a Discovery and Product Design service - where we work with clients to thoroughly document their idea (delivering a complete Functional Specification) and prepare a true cost estimate and realistic road map to release.

However, we also recognize that it can be hard to commit to a paid service without even having a ball park figure to start from when determining whether to work with objectstudio or any development team for that matter.

To that aim, we’ve outlined the process below to help you write a Functional Summary - a document describing your idea in the way a developer needs to see it - that will allow any developer to evaluate your idea and provide you a more accurate initial estimate.

Writing your Functional Summary

A Functional Summary is just a Word/Google doc and possibly some sketches. It can be pretty informal and include outlines/bulleted lists and short descriptions. Often it is good to make multiple passes through the document over the period of a week or so to fill in things you forgot on earlier iterations.

1. List the people that will use your product

Don’t just think about the key users/customers – think about how the system is supported and administered, how you will operator your business and evaluate financials and KPIs, how your sales or marketing teams will interact, etc.

2. For each of those people, list the interfaces they will use

Who will access the site from their desktop? From their mobile? Is there anything unique about their environment (inside network with firewalls, limited connectivity, etc.)?

3. For each of those people, list the features they will use (and identify on which interfaces)

Start by just listing the names / brief descriptions of the features – we’ll dig in further next. If it is useful, you can group them or write as an outline for main features and sub features or functions.

4. For each of those people, write out the user journeys / workflows for how they access each feature

Start at the first page/screen they see and list the steps to walk through how they get to that feature and in what scenarios (ie they have to have an account, or have a previous order placed, etc.). Sometimes using sketches can be useful to tell this story – though sometimes simply describing is sufficient. If a group of features have similar initial steps (like say logging in to the dashboard), simply write the initial steps as a workflow and refer to it in the specific feature workflow.

5. For each of the named features, describe more details

Describe the feature briefly, list the users who use it, list the interfaces its on, list the pre-reqs or input data required for it to work, list the expected user outcome and/or data outcome of using it. List sub features of major features. If you have a sense of how it should look or the desired UX, make mention of it or link to an example. The will be some overlap with Step 4 – but aim to be thorough even if there is repetition.

If you have algorithms or complex business logic, this is good to introduce in the section. While you may not have a grasp of the technical implementation of the algorithm, you may be able to identify the “steps in the process” of how information is used to create an expected outcome.

6. Visual Design/UI/UX

For the product in general, it is often useful to provide links or screenshots of competitive or inspiration products that you’d like to emulate and then articulate what you like and don’t like about each link.

For specific pages/screens or workflows, sometime creating sketches is helpful.

What’s next?

A document like what is described above should super charge your conversations with your developer. A competent development team should be able to use this document to dig in to specifics and ask you key questions that will impact your budget.

When working with objectstudio, we can use this document to provide a ball park product estimate and it will serve as the foundation of the Discovery and Product Design Process - where we dig in to find technical implementations to fit your solution.