Blog / Business / outsourcing development

Startup Survivorship Bias: Things you shouldn’t do

  • Rating — 4.9 (10 votes)
  • by Tony
  • Updated on February 28, 2019
  • Read —
    8-9 minutes
survivorship bias

When you decide to start the development of a project you are reading lots of articles and books about how to make it right. Usually, it’s the success stories that people are reading and are searching for the magic formula of what startups did right and are not thinking that these startups maybe just didn’t do wrong things.

We have been working in software development for almost 7 years now and over this period there were successful clients that became huge corporations or were bought out by big market players but at the same time there were projects that were not that lucky and lost their investment, gave up on their idea, chose a different way to resolve the problem.

And since most of the companies are afraid to tell about such failures (and we consider client’s failure to be also our failure) showcasing only success stories, we decided to share our experience of bad practices for your businesses connected with the software development.

  1. Tech teams and reading minds
  2. Lying to yourself about deadlines and budget
  3. Aiming for perfect product
  4. Aftermath

Tech teams and reading minds

Too many vague requirements not well explained.

A client started the development of a pretty big project with us on Time and Material basis and spent 2 years developing it with the team of project manager and developers. The number of the team varied over these 2 years from minimum 1 developer and maximum of 12 developers + the team of QA engineers, designers, slicers, etc.

In 2 years client reached to me with a concern that his investors are not happy with how the development goes because they are spending the time for the development but at the same time not getting a result. Our client wanted to see the working end product. When I went to project manager and logs of work over these two years resulted that all requirements were too descriptive and client rushed team up to start the development based on descriptive requirements instead of spending time to analyze things and plan them before their actual development. And project manager at the same time was never pushy enough to make client follow the procedures within the company.

Even though this fact itself was already painful to the project, client was overpromising to his investors much more functionality that team could possibly provide without checking neither the timeline that scope required nor if the promised functionality was possible at all. As result investors were promised with a big scope and they were not seeing it. And since client was getting pushed by investors, instead of finishing current scope client demanded to stop the work on current scope and start the new sprint (scope) as high priority one. You understand the result of this: no finished functionality only partly finished things that you cannot release or demonstrate.


  • Make sure that team and you are on the same page in terms of how user story will be working in the end BEFORE the development.
  • Make sure to check with the team the realistic timeline when the sprint/milestone/etc will be completed and take a couple of days for backup. Even the best team sometimes are too optimistic about their estimations.  
  • Remember the golden rule of investors management: it’s better to under promise, rather than over-promise.
  • You should take part in forming of the sprint (scope of work for selected period, we recommend not bigger than 2 weeks) together with the team. Join the meeting, tell the priorities, make sure you understand the risks told to you. If no one is telling you about the risks, ask them. You need this info to manage investor’s expectations.
  • Your team should give you the Gantt chart using which you can track the progress. If you are using Jira or similar project management tool correctly and follow the agile methodology, they allow making agile reports on progress like burndown charts and similar that should give you an understanding of how things are moving with the project.

Lying to yourself about deadlines and budget

Praying that the team will meet the deadline and budget that you pushed them to accept.

We had a client who made deadline commitments to his end client (we were working as subcontractors in this particular case). This deadline could never fit the scope of work that client initially wanted to go forward with. As a result when the duration of a project for 6 months of development (at least) was presented client was disappointed and crushed since he made promises.

A similar case happened to another client of ours who managed to get funding for the estimation that we gave based on unfinished specifications. However, once the specifications were finished and they got extended to bigger functionality than initially intended, the budget increased almost 3 times and here of course client was furious since money only for initial estimation was raised.

In such cases the human factor plays a huge role, since the team wants to find the way out,  project managers are sometimes building too optimistic project plans and developers are giving too optimistic budgets, trying to satisfy the clients demands when they see how important it is for the client to meet the deadline/budget.

In the end, these optimistic deadlines and budgets never work because development is what it takes and without decreasing the scope maximum you can win (at least based on our experience) by optimizing the project processes, adding additional more experienced team members is only 20%. The rest is the actual time you need to spend for writing the code.


  • Never go with this compromise on timeline and budget. Always keep in mind the worse case scenario.
  • You can tell your client or investor what he or she wants or needs to hear to manage their expectations, but be realistic about the situation and be honest with the deadlines for yourself.
  • Don’t lie to yourself, if you see the team is not making the deadline, have the backup plan. For example, plan the releases into mini-releases, so that certain functionality can be released without waiting for other things to be finished (read about lean development, it should help you out with how to do this properly).  
  • Define the top priority functionality that is absolutely vital for the project from the functionality your project can live without. And put the least for the end of development
  • Never promise anything on deadlines or estimations until you receive the final confirmation on those from the development team based on full specifications. No team can give you accurate estimation out of conversation or even the wireframes. Please believe our 7 years experience, accurate budget can be formed only based on the minimal set of detailed use cases and wireframes. All estimations till then are just guessing.
  • It’s important not to change your current team to the new one that promises you better deadlines or costs especially in the middle of development. I promise you, the realistic deadlines and budgets are always not the ones within your expectations, they are usually big and expensive and if someone is promising you better price and deadlines, usually this is by sacrificing quality or by missing important things in scope or procedures.
  • Remember that 9 women won’t deliver a baby in a month. A woman needs full 9 months. Same with the project no matter how many people you add to the team, well planned and big projects still need their time for planning and architecture development if you want your system to be scalable.

Aiming for perfect product

Too many changes and additional requests during development.

Everything started really well. We spent lots of time for planning, we had over 100 pages of specifications. Designs were also prototyped and we confirmed the budget and the scope. The project consisted of 9 milestones, client wanted the mini-version of uber like app.

What we noticed is that on the delivery of each milestone we faced a huge problem with the acceptance of milestone from the client because he was changing designs and adding things and this was in circumstances of strict deadline where each addition is very painful.

The additions were mainly concerning the change of designs (which were prepared by client’s designer by the way) and we had to reslice things almost every milestone to new interface. This was pushing the deadline forward and finally once three milestones were delivered the client stopped his project due to too many additions that led to extension of budget and pushing the deadline.


  • If you don’t want to wait with writing all those use cases and “all this looks like waterfall and we are in the age of agile, where you can write stories as you go”, go with Time and Material budget scheme then, not with fixed price. Because you need agile budget to keep the development agile too.
  • Remember Reid Hoffman’s words “If you’re not embarrassed by the first version of your product, you’ve launched too late.” This means no need to change interface thousands of times during the development, especially if you developed it with designer over a few months.
  • It’s a bad idea to start improvements before actual release. First release absolutely vital things, add desirable things later.
  • Remember that you might be developing improvements that your users won’t even need.
  • You can’t compete with uber, facebook or similar platforms with budgets hundreds of times smaller compared to theirs. You need to be different and this is what you need to concentrate on.  Don’t go into development with $10k for facebook like app.
  • Remember that once your app is developed you need to maintain it, service its servers, update to most recent OS versions and API updates (if used) and this will require money.


We learned how to manage each of such situation and when we see it coming we always tell this to our clients and in most of the cases they are very open to improvements and collaboration with us.

We were lucky to meet the customers that were working with us to deal with such failures instead of putting the blame on us, they accepted where they were wrong while we accepted where we were wrong. And we learned how not to make same mistakes together with them and both our clients and us paid good money as result of these failures sharing the negative experience. So hopefully reading this article will prevent time and money losses for you and your team. Be better together.



Tony Tony Sol is the business development manager of GBKSOFT, overseeing the production of all writings for both internal blog and external platforms. He is technical-driven person always looking for new benefits of merging business and software.

Leave a comment

Leave a Reply

Related services


All articles Business Company News Marketing Tips StartUp App Ideas Tech UI and Design

People are talking about

You've got
a project in mind

What's next?

Send us a message with a brief description of your project.
Our expert team will review it and get back to you within one business day with free consultation and next steps.


Nothing can be better than getting a review from our happy clients
who recommend us and trust us their business.

GBKSOFT did a good job to manage the project. They put in a good effort to communicate with us and make it easier for us to communicate with developers. Good Job
My Project with GBKSOFT gave me the ability to develop my software while keeping a busy schedule. Ana, who was my project manager, was very professional and was always understanding of my vision and what I wanted. I would recommend GBKSOFT again to any other company or person who has a vision for their web application. Thank you GBKSOFT! Recommend
I think they do great work. I haven’t yet given them something that they were unable to do. Great
Gireesh, USA
One word...EXCELLENT.
Very well thought out and articulate communication. Clear milestones, deadlines and fast work.Patience. Infinite patience. No shortcuts. Even if the client is being careless (me). The best part...always solving problems with great original ideas, especially with this strange project where we are making up new words every day!
They proved to be very good and they’re very reliable as well. They are quite conscientious. They will go the extra yard to make sure we're happy. Reliable
I’ve been using GBK Soft for the past 3 years and they have been great. Communication is unparalleled to other app development companies. I’ve continued to return to them to improve my iOS app countless times and I will continue to do so in the future. I highly recommend this company! Improve
More good work from team GBKSOFT. All well executed. The support within GBKSOFT is excellent. Communication is good too, spoken English as well as written. Support
They write clean code, adhere to deadlines, and communicate extremely well. I strongly recommend anyone from the GBKSOFT agency and hope to work with them again myself. Clean Code
GBKSOFT’s performance has been very strong. We've referred them twice, which says all anyone needs to know about them. A referral is the ultimate signal we can give that these guys are great. Strong