Having run an interactive agency for several years, we receive a lot of enquiries about building websites. These enquiries take various forms – sometimes it is a message saying “I would like a copy of Allegro, how much does it cost?”, sometimes they are quite meticulously prepared enquiries, but unfortunately they are rarely complete enough to be able to quote a price for creating a website.
I would like to show you what mistakes you should avoid before investing several years of your life in developing your company’s website.
Usually, clients want to start working on the portal with the graphics and devote 90% of their attention to this. Then they evaluate the functionality of the portal by placing elements on the graphics. STOP, this is not the right stage. In order to get to the stage of creating graphics, several previous, extremely important stages must be prepared.
Where to start?
The first step should be to define the relationship, i.e. answer the question “why are you coming to the agency?” What scope of competence do you expect and what level of trust are you able to give to the subcontractor? It is not without reason that I write about giving each other trust, because without it, our relationships and the comfort of cooperation will suffer, and as a consequence, this will translate into a loss of the time you have invested. Of course, I am far from saying that an agency as a subcontractor should take over 100% of the decision-making and work on the project – I believe that each party must define what it expects and determine the scope of control over the design process.
There are two paths. Either you believe you know everything and want to make decisions about the website yourself, or you trust professionals who have experience. You can demand justification and explanation for each of our decisions, or you can save your time by commissioning us to do the work and trusting that we will do it as effectively as possible. You can always hire one agency to control another. This is exactly the role I am hired for in projects. Unfortunately, it is often too late, because it turns out that the project has been poorly managed from the very beginning and, despite beautiful graphics, we have a project that is completely ill-conceived in terms of business and usability.
If you only want blind replicators of your website design, do not hire an agency, because you pay an agency for, among other things, experience, know-how and ideas. Commission a programmer and test it. Be prepared for the possibility that you may find out the hard way that a graphic designer and a programmer are not a team capable of creating an e-business on the internet. If, on the other hand, you are counting on a professionally made portal, you must also take into account the costs and the large team of people involved in the project.
Let me point out right away that creating any serious websites on WordPress, Drupal or other free solutions is a complete mistake, and this is a topic for a separate article.
Stage I – preparation
Let’s start with the question contained in the business model: “How is the portal going to make money?”. 70% of clients who submit an enquiry have very little idea about their own business plan and how they will make money. We often hear “paid accounts, advertisements, sponsored articles”, but there are no specifics to follow – how many campaigns, articles, what parameters, how we want to manage the data. There is nothing wrong with that, it often happens that someone has a really good idea but does not know how to implement it and needs help. If you need advanced help, you also have to expect an advanced price. I recommend that you familiarise yourself with Alexander Osterwalder’s methodology for creating business models, known as Canvas – we follow it in our projects. http://www.businessmodelgeneration.com/canvas/bmc
How a portal is supposed to generate revenue determines a number of functionalities that then need to be designed and coded. In order to prepare a quote for the work, we need to have a detailed description of all the functionalities that are to be included in the portal – ideally, we also need a description of how they are supposed to work.
Here we have two solutions:
- The client creates a description of the functionalities themselves and submits it to the agency for a quote
- If you do not have a detailed business model, you can commission its preparation – then someone will develop it for you. This is a very broad topic for a separate article, so I will mention a few things. We create a Canvas model in a workshop setting, which allows us to write down the entire business model, diagnose the problems of the target group and determine the key functionalities for creating the so-called MVP (Minimum Viable Product – i.e. a product, service, programme or offer that is minimally ready to be launched on the market).
Where do you start when preparing a business model?
“Learn from your mistakes, preferably those of others.”
Who do we learn from? From the competition, of course! We review the competition in Poland and abroad, check how they operate, how they make money, observe and analyse what they did right and what they did wrong. It often happens that someone writes to us about their fantastic, innovative, unique idea, asking for confidentiality, but they haven’t checked the basics – how many such portals are already on the market, what the user registration process looks like, payment accounts, costs, what resources we need to start the project, and how we should forecast costs, etc. These are things that the portal owner needs to know or work out in workshops. In order to price the project, we need a clearly presented list of functionalities that will need to be implemented, or we can suggest them, but this requires our time, which in turn will be reflected in the cost estimate.
If everything has gone perfectly so far, we should have:
1) researched competition and market research;
2) a developed business model;
3) a prepared list of portal functionalities;
4) defined portal objectives, user groups and what we expect from visitors to the portal from each user group. For example, we run a car classifieds portal. Our user groups will include people who post ads, people who browse ads, people interested in advertising on your portal, etc.
Is that all? It would seem that everything is clear up to this point, but now the first misunderstanding may arise. What should be done? Clarify the documentation.
This means describing how specific functionalities should work, both on the user and administrator side. The quality of the documentation determines whether the agency can undertake the valuation – if the documentation is very sketchy, it will need to be rewritten. No one will write it for free, because it is a huge amount of work. It is in your interest to provide the agency with documentation, because if we work according to clear documentation, there should be no misunderstandings, the project team has clear guidelines, and neither we nor you waste the time invested. The documentation you prepare can be audited and settled. The advantage is that the documentation is a closed project stage and at this stage you do not have to continue working with the agency. However, if you decide to continue working with the same agency, the costs of the documentation may be much lower, as it is only part of a larger joint project.
Market research is a separate project stage – this is a very broad topic that deserves attention in a separate article. In a few sentences, I can say that research is often considered unnecessary, but it is research that accurately diagnoses what problems the target group has and how it has solved them so far. Once we know the problems and solutions, we know where to start with the Canvas business model, and once we have Canvas, we can find connections that will solve 80% of the target group’s problems with 20% of the functionality. This allows us to create a much cheaper MVP, thereby reducing project costs until it is validated by the market. From an investor’s point of view, it is better to do research, create a Canvas model and incur lower project costs for programming work than to create something that only fulfils the originator’s assumptions, is not reflected in the research and has no business model.
