Get to know Mark. Mark is an entrepreneur who decided to build a great startup. The idea was around an application for connecting service providers with clients in the housekeeping industry. Because he is quite an experienced business developer, he started by evaluating if his business idea can be transformed into a monetized business. Good move!

 

He began checking groups of potential service providers and clients. He found them mainly on Facebook and Instagram – many people who might be interested in is a great idea. Whoa – according to the Lean Startup approach everything was in place. The problem, solution, value proposition, unfair advantage, and the rest. People started asking him when the platform will be ready and when they can start using it. He had a feeling that he is on the perfect path to go.

 He even invited some sales and marketing people who were very very interested in disrupting this not touched by the technology market. They started together digging deeply into it and found very fast that the potential market is even bigger than they thought. Two of them joined Mark’s company as people responsible for marketing and sales from day 0.

Until now Mark didn’t spend on his startup too much money. We can even say that the most significant investment was his time and some time of his friends.  

Looks promising? Of course! 

What’s more – Mark started talking with people who might be interested in investing in his brilliant idea. He found very fast that it is not a big problem to get some money from investors. On another side, he also was aware that investors should be involved as late as possible and that’s much better to spend his own and close family money and work on better evaluation before any external investment round.

Let’s build the product

The only missing that needed by Mark was a product. It was the next step in this journey, but… an essential one. I should mention here that Mark is not a technical person. He knows a lot about marketing and sales, but ‘hard tech’ things were not his genuine skillset.

Mark started looking for someone who can help design and then develop his product. Of course, the budget was minimal, so hiring an internal team was not an option.

He started looking for a software house that can develop what he needed. After sending some RFP’s, he decided to talk with two potential suppliers. They offered a similar fixed price for development, and after some squizzing – one of them decided to give Mark an attractive discount – a 30% lower price than the competition.

Mark was so happy – **in the next three months** his product will be delivered and ready to sell. He spent some time working with a supplier on wireframes, preparing designs, and writing down user stories, which were included in the contract.

Start of the development

Contract signed. We start development. The scope is defined as user stories, and designs are ready, let’s go forward and start coding! 

During a project kickoff, Mark was informed by developers that they are going to use the SCRUM methodology to deliver a solution faster and better. Whoa! Great! He heard many times that it’s an agile approach and that’s much better than old skull waterfall.

Software house was making 2 weeks sprints. 

Pressure from potential clients, early adopters, started to be higher and higher, so Mark focused on business development and was asking every three weeks about progress. 

The project Manager every time was telling me that everything is fine and that solution will be delivered as expected. After three months Mark and his colleagues received the first version of the app. The excitement was in the air – even if there was a small delay. Mark installed the app on his device and was trying to add himself as a service provider. After five crashes he decided to stop and ask developers what was going on. In the meantime, he realized that some features which are surprisingly working – are not working as expected. He was sure that a few months ago he explained to the company that they should work differently. However, now after a time, he wasn’t sure what was agreed. Of course, he looked at user stories, but they were not clear enough to be sure what was agreed upon.

He had to tell early adopters and potential clients and investors that there is a small issue in development, and release will be postponed for one – max two weeks. 

He started intensive communication with the software house about finishing the project, and then he got much feedback about the defined and agreed scope which now was looking a bit differently in the software house’s eyes than Mark’s eyes. 

Ping-pong drama

They started a game called ping-pong drama. Developers were asking for a list of comments for the current beta version of the app. So Mark spent much time with his two people involved in a startup on taping on screens, writing down issues in Word files, and sending them to the supplier. After a few or maybe more days, they were getting a new release. Moreover, the whole game was starting again. Some features were fixed, and some others stopped working – but Mark was sure that before that they were working as expected. He even learned that in the tech world, they call it a ‘regression’.

 After the third ping-pong iteration, Mark was pissed off. He was told that some items on his bugs list are not bugs because developers understood them differently and they implemented them as they thought. If Mark wishes to change them then it will be a ‘change request’ and Mark will have to pay additional money.

Dead-end

It was too much. Mark decided to stop collaborating with this band of amateurs. He asked them for source code and documentation – and after some days he got access to **git repository with code** and a list of **user stories** from a signed contract. I should mention that Mark also received access to design source files.

Mark started looking for a new software house, and after some calls, he has a strange impression, that software houses need to dig into code before they overtake the development. 

After investigations, he got an answer from three different software houses that the code delivered is a piece of shit, that the quality is inferior, and that they need to rewrite the whole solution from scratch. No one was open to developing his solution further based on this what was done until now.

Life after the dead end

Mark realized that after spending much money, all his savings, money from family, he has in his hands a bunch of files with code. Before the start of the project, he wasn’t even aware that files with code are regular text files with different extensions.

That he lost much time, and trust from early adopters, and that probably will be very hard to convince investors to invest in his company.

Is your name Mark?

Ask yourself if you can put yourself in Mark’s position. Have you had problems in the past like Mark? I’m pretty sure that many of you had. What was wrong? What happened? Why in the beginning everything seemed to be so good, why even during development everything looking promising – and suddenly it finished like in the Titanic movie?

I saw it so many times in my business practice. We have new technologies each year, so many of them are great, but still, so many projects fail.

In the next article, we will dig into details and analyze where Mark made mistakes. How he could avoid them and if software development is such a complicated one?

Share your experience in the comments – I wish to get you as much feedback as possible and include it in the guidelines for everyone who is going to build any software product. Let’s help people to avoid mistakes!

Ps. Please also share it with all people who struggle with software development. Thanks!