Minimum Viable Product · Project management

Considering a web development firm - embrace or proceed with caution?

Trevor Collins Crowdfunding Entrepreneur & Co-Founder of 100 Danish

October 9th, 2013

I found a potential web development firm to build out an MVP for the startup I’m building, However, there are a couple aspects of the deal that have raised questions and perhaps a yellow flag of concern.

I’d love to get thoughts and guidance.

This firm has just set up shop here in Boston, with a newly assembled team. I like the lead project manager and trust his input. As his 2 developers have extensive experience.

So I sat down with the team and described the idea for my platform that is going to integrate live streaming video (using the OpenTok api), archiving of those video streams, user accounts & profiles, and scheduling & payment capabilities. In the end, the team loved the concept and the prospect of building it out.

The concern, though, is that they put together a quote for only $15k. My expectation was something closer to 3-6x that range. Also, they expressed that it should only take 6-8 weeks. Again, expectation tells me that 3-4 months is more realistic.

When I asked the lead project manager the motivation behind the pricing, he mentioned:

  • the firm is new & untested and needs to build up a portfolio
  • they know I’m in a lean startup that has a limited budget
  • his team needs something to get there feet wet and not sit around twiddling their thumbs
  • obviously for the next client they would charge more than $15k

Is this an opportunity I should embrace? Or what do I need to look out for or keep in mind? I’m not a developer myself, but do have a couple local friends who are willing to look over code and general architecture.

Cheers in advance, Trevor


October 9th, 2013

If they really are lowballing the project in order to get traction as a new company, that can work really well. But, underestimating the project is a sign of an inexperienced team. Good developers don't make good estimators all the time, so this can really get tricky. If you want to take a chance on them, my advice would to help them succeed by: - breaking the project into distinct, simple phases - have them bid on each one individually - encourage them to really consider the estimation (if they are losing money, your project will suffer) Then hold on to that budget, with the expectation that they'll need more payment. It can work out fine, but a gross underestimation is a major red flag.


October 9th, 2013

I think it is impossible to judge based purely on a quote. Some tips on dealing with vendors:

- Get somebody technical you know to ask them technical questions to evaluate the proposed solution, architecture, technologies. Basically evaluate their skills and solution. 
- Start small. Give them an even smaller project to get started with and see how they do. Perhaps you want a landing page? 
- Manage the project carefully. Clear short term milestones. Regular demonstrations (weekly). 
- Clearly define the scope of the project - write use cases, acceptance criteria, wireframes and visual designs. Define done. This is your contract. 

Abigail Watson Clinical Applications Architect, Bioinformaticist

October 9th, 2013

I'm just wrapping up a very similar product... website using OpenTok, includes user accounts, scheduling, payments, etc..  A few points:

- Your concept of MVP from a business perspective may not be their concept of MVP from a technical perspective.  

- As an example:  'scheduling' can mean different things.  It can mean simply slapping on a Google calendar, or it can me an actual resource scheduling system that's integrated with OpenTok API that can schedule rooms/sessions.  The Google option is a one day solution, the integrated jQuery/Database option is a multi-week solution.  Scheduling is one of those things that often is far more difficult than business folks anticipate.  

- Your description of the financial aspects of the bidding indicates there's actually no real discrepancy.  If they're underbidding on both time and money, roll with it, and simply look at the job as a two-part contract.  There will be a MVP of the technical component ($15K at 6 to 8 weeks), and then there will be a MVP on the business components, which includes copy writing, debugging, marketing, bank accounts, monetization, search engines, infrastructure, etc.  And the balance on the business components.... that's where the 3-6x cost comes from.  Go into the project with a try-before-you-buy perspective.  If they can deliver a technical demo at $15, then consider the additional $30 to $75 investment.

- Also, unless they've actually worked with the OpenTok API or used other streaming video products, you may want to simply explain to them that streaming video can often be more difficult than one initially expects.  The API instructions are fairly self explanatory, but if you're trying to bring any other technologies into the mix and do something clever, it can devolve into a quagmire rather quickly.  Doing things like 'disconnecting from one session and logging into another session without page refreshes or dropping the streams'... easier said than done.  It's the page refreshes, page reloads, and dropped streams that will have everybody frustrated.

- As the entrepreneur, be aware that most of the errors using OpenTok will have the same symptom.  It will all be 'theres no video stream and I cant talk to anybody'.    Multiple causes lead to the same symptom.  Your developers will get into this process of fixing bugs, but it won't *appear* like they're fixing bugs.  If they get the server asking for a token from the OpenTok servers correctly, and the session gets generated, but users still can't subscribe to a stream...  well, the video stream still doesn't work.  They'll have fixed a bug.  Yet it still won't work.  This cycle of all the bugs having the same symptom led to a lot of demoralized workers on our project.   They won't be expecting that maybe, unless some of them specifically have experience with OpenTok.

- Be sure to sandbox the OpenTok API functionality in a separate utility before building the full application. This is what they're trying to do with the $15k bid.  They understand the MVP as being a sandboxed OpenTok API demo.  You understand it as being something of a turnkey MVP solution.  However, they're the ones being more pragmatic about the steps needed to actually bring the product to market.  And they're correct in their approach.  If you all can't get the sandboxed version working, you won't be able to build out the rest of the app.  

If you have $45K to $90K of liquidity available, I could put you in touch with the folks I've been working with.  I'm not sure if they'd want to do a work-for-hire, equity split, or tech license.  But I do know they've been looking for investors.  Might be worth a conversation....

Robert Clegg

October 9th, 2013

After reading some of the prior comments, I may have assumed you know the phases of development and how to formulate that into a contract. Here's what that looks like:

Pre-Production: the first paid phase of the contract. You are paying the other experts to take your requirements and detail a production plan for you. This production plan breaks down the project into time and resources dedicated to each feature and function of the product. This will translate into a deliverable timeline so you can see or test each function or feature as you go.

Deliverables: Design Document covering all features of the product
Production Plan detailing time and resources for each feature

Note: You will be able to see how many man hours each task will require and see the team members they are putting towards that task. Your experts will be able to tell if what they are proposing is accurate.

Note: In your contract you should have something like a "key man" clause. Which states that the exact personnel represented to you to be working on the project are in fact working on the project.

Production: This is the execution phase of the contract. Once you agree in phase 1 what needs to be done and what deliverables are acceptable, they begin production. Progress on milestones should be made weekly. Deliverables for acceptance can vary of course. 2 weeks for deliverables is short. 3 is achievable, 1 month is long but on a 12 month project that's appropriate. Weekly communication is key.

Alpha: First build. Make sure the main features are there in the alpha. Beta should be secondary features and graphics. Your testing and tire kicking should inform what needs to be added for Beta. Note that I said added. The production plan can always change but ONLY on your approval. You may realize x, y, and z need to happen to make it actually work.

Deliverables: Updated Design Doc
Updated Production Plan (changes must be approved)
All features committed to in original Plan

Beta: Full feature set with only a few very minor features left to implement during the Beta period. 

Deliverables: Updated Design Doc
QA Plan

QA: Final lock down period where only bugs are fixed.

Final Deliverable: Final approval period where all features are tested against requirements.

Support: Period where they agree to fix bugs

Deliverable: Support Plan - anticipated fixes or problem set, personnel on staff dedicated to support, response times, etc.


October 10th, 2013

This is really good advice. I have been holding my tongue reading all these comments about penalties and ways to protect yourself from vendor screw-ups. There is some value there, but in the end I agree with Robert's advice. Reality check: you can't 'contract' your way out of risk. A penalty won't make an inexperienced or incompetent vendor any better, it just puts more pressure on them which doesn't help a vendor who is already struggling. I have done nothing but outsourcing for the last 15 years and I can tell you: if you are going with a company that is new, and you are willing to take some risk with them, then the strategy is not to play 'defense' but instead to partner with them, get into the mix, and do everything you can possibly think of to help them out. Sure, don't put all your money up front. But, instead of threatening them with some penalty (which serves nobody) why not help them to make a plan, structure a flexible payment term, and schedule standing meetings with them to make sure they stay on track. Projects are partnerships, whether you see it that way or not. It's very rare to get a 'set it and forget it' project where your contract is so strong that you just write a check and the vendor comes back with a finished product.

Chayim Kirshen DevOps Focused Software Professional

October 9th, 2013

Trevor, I'm all for getting second (and third) quotes in order to size the reality of the situation. Making a choice from a sample size of one is terrifying, and not something I'm comfortable doing. Although they're not in Toronto, I would recommend the folks at Rangle.IO (disclosure: I know the founder, but don't work with them in any way). cheers, --c


October 9th, 2013

Trevor, you always get what you pay for. They could be amazing developers, but they will also learn on your project, which means making mistakes (time or quality). As Ray said, having a technical product manager on your team will help you a lot.

Luis Avila Owner/Fullstack Architect at IdeaNerd LLC

October 9th, 2013

The devil is in the details. Make sure you get a detailed list of deliverables. For example, will they just be writing code to meet the requirements or be creating unit tests and integration tests? Will they setup a server(s),  Will they setup a code repository, automation scripts, etc. Of course all this adds costs to the project. They may not be including them in the estimate.

Dave has a great suggestion... breakup the project into phases and make sure the contract allows you to exit if you are unsatisfied.

Also, seems like they were honest about the reasons for the low quote. That's a good sign. 

Karl Laughton VP of Finance at Insightly

October 9th, 2013

Hi Trevor,

I'm leveraging a firm here in San Francisco who was recommended to me by the folks at Carbon5 for mvp builds. I was quoted 50k on a delivery schedule of 5 weeks (they have a proven track record and strong team for agile based projects). Furthermore, I'll be hands on throughout the project. Hope this helps level set.

I'd say give them a shot and have your friends review deliverables as they hit milestones on the back end. You should be recruiting a technical team in parallel. At a minimum they can give you something to raise with, and you can scrap it after you've raised to build scale and foundation on establishing product market fit for the next round. 

Hope this helps,


Joel Magalnick Storyteller. Innovator. Leader.

October 9th, 2013

I'd also have them keep the code posted on GitHub, weekly at the very least, so you and/or your tech buddies can check progress and make sure nothing's running off the rails before they get too deep into the development. Plus you will always have access to the code.