• Tomasz Soroka

Instruction for a startup owner. Part 3

Recap in a previous article from series, we discussed a problem space with some hypothesis which Mark was going to solve by developing a great mobile app. We did it to help Mark to understand how the development process should look like and how to avoid problems as Mark had. You can read about the whole situation in Part 1 and in Part 2.


In the current article, we discuss a solution space. Whenever you are going to develop an application, you should have in mind that first - you need to address a problem you next are going to solve.

This is a crucial thing in the whole game. When you find a problem, and you know that it's not only a bunch of your hypothesis but that the problems are real.

There is a lot of practical methodologies like lean startup, customer development, where you can read about techniques on how to validate your idea. I wish also recommend you a book - "Disciplined Entrepreneurship with Bill Aulet." In this book, Bill Aulet leads through a whole process from validating hypothesis up to releasing a product on the market. So you understand the problem you are going to solve, you know that it's not a hypothesis, but you already collected feedback from the market, and you are sure that hypothesis is right. What more - you described it in the form of requirements in your new great app.

So now we need to go to solution space - HOW to answer on problems - what kind of solution propose to make users happy.

In software development, a solution is discovered together with a team who develop it later. So this is a mix of different skills involved.

In Mark's case, he had mockups prepared together with UI/UX designer, final designs, prepared by a graphic designer. It was a base where developers, after some explanation, started working on a final solution.

Mark's problem was that he forgot about some essential pieces of the puzzle, and as you can read in the first article from series, after some time it caused enormous trouble for him.

Business domain understanding

Good understanding of the business domain is one of the first and essential things for developing a great and right solution. The goal is that developers will understand concepts, which are essential in the business domain.

In Mark's case, it was knowledge of housekeeping world. How they work how they are defined, how we use them in each stage of the process?

For example:

In most cases, clients are looking for long term housekeeping services. Most of them are done by people who have no official business registered, so for example, invoices are not required whenever housekeeping services are delivered. Additionally, the business model shouldn't rely on any payments from users. However, the idea that it relies on a monthly subscription from service providers is a good idea. So good understanding of this how service is offered, performed, and billed is very important to design and deliver a proper solution. If developers understand it deeply, then the proposed solution is better and well tailored to market needs.

All used concepts, relations between them should be well implemented in software. If it is done right, then it will be much easier to maintain a final product and develop it in the future.

Components of the solution

Every modern software solution is built from many different pieces - we call them in software components. For example, a mobile app for IOS and Android, connected through API with a backend. Backend built from many different components across three business domains. Everything backed with external APIs for payments, invoicing as well as sending emails and SMS messages.

But these pieces needs to be well described to be sure that in the future for new developers and at least everyone in the project, it will be clear to understand without reengineering everything from scratch.

Patterns and good practices for chosen technologies

Patterns and good practices are the next crucial topic. I saw it many times when someone decided to go with technology "A" and developers started working on a project. They were using the same technology, but after some time, you could easily see that every developer was using this technology in a slightly different way. Without let's call it synchronization. It means that even the same technology can be used differently. You can have the best tools, but if you use them wrong, then you always be in trouble after some time.

If you are not technical I try to explain it even more - let's imagine that you write 300 pages book in Microsoft word and you don't use headers, footers, headlines, but you style everything manually - together with page numbering. In the beginning, it's a very straightforward and easy - and it doesn't matter If you use more advanced features of word or not. However, when you arrive to 200 pages and you have to change something page 53 then your whole puzzle collapse. If you use MS Word properly, then it is easy to change anything regenerate your heading, table of contents and it works like hell. Everyone who has experience knows it, and for me, it's very strange why in case of software development in many cases it doesn't work like this. Developers are building in parallel a very big word document, and after some time they struggle with any changes. Of course, it's simple comparison and software development is much more advanced that operating in word but more or less this is like this.

Deployment environment, releases

This is the next crucial topic, which is quite often underestimated. When Mark started testing fixes in an application in the same environment where developers were working on new features. This is one of the biggest mistakes which can cause delays in development and introduce many problems. So this is so important to have the order also here. You need in an average project at least three environments. First one for heavy testing of increments, one called staging for testing everything that is going to production and last - production environment where a fully working solution is deployed. It was also issued in Mark's case. He was testing features in a solution when in parallels developers were working on some new features. It was very problematic because when Mark was trying to test something, very often it was not working or was already changed by develoopers. It was a source of frustration to Mark and his team.


In this article, we discussed a solution space. Problem -> Solution. It's nothing new, but all the time people have a mess here. The funny thing is that especially in those days people don't understand how to describe the solution properly. Many people think that the agile approach can replace a solution specification. It doesn't work like this because it was developed for solving a different issue.

In the next article, we will discuss the remaining pieces of the puzzle - communication flow, project management, change management, and documentation storing.

In this area, Mark also had some troubles, so we will show him how they can be easily solved.