Hello, I am Anton Kolomiychuk, a CTO at Purrweb. In this case, I’m going to tell you how to maintain team performance if a manager quits a project, and how to develop a marketplace for photographers.
Fun fact: it took me less time to go to Amsterdam and drink beer with the client than to gird myself to write these memoirs 🙂 Can’t go to Amsterdam now, so check it out!
Here comes the story.
In May 2017, we got a request from Domien, a marketer from Belgium. The task was to develop web and mobile apps for photographers. The main idea was to offer photographers a new way to sell their works. Instead of selling a session before shooting — do the opposite.
Domien is all about marketing and has worked with e-commerce platforms mostly — he has never dealt with product development before. There were several development agencies to choose from, but “Why did he decide to work with us?” That’s what I think when looking at the project in retrospect: we worked hard from the very beginning to accurately estimate the project and we proved ourselves during the discussion phase.
At that time, most of our clients were finding us on Upwork, a freelance marketplace. This is the platform where you can find contractors for any type of work. Some of them are more expensive, others are less — choose what works for you and get it started.
So, it was on Upwork. The client knew nothing about technology, and we tried to explain what needed to be done and how. We proved to him why the other team’s offer to ‘do it all on the cheap’ sounds unreasonable. We gave him a lot of advice on marketplace development and suggested how to integrate a payment gateway because he didn’t take this part into consideration. Helped to solve all business model-related questions as well — told Domien about the prices of image hosting services and payment systems fees. The client appreciated such engagement and hired us.
Working with a ‘finished’ design
At the time, when Domien approached our company, he already had a finished design. To be more precise, he had 300 random screens that we should stick together to build a working product.
To figure out if it’s possible to create something decent out of the existing design, I decided to examine every single screen thoroughly and group them all into large functional blocks. I did a big job and even wrote an article about it.
As a result, I found a whole lot of inconsistencies. For example, the designer made a list of messages on Messenger but didn’t illustrate how the messages would be displayed in the dialog box. The point is that the designer didn’t understand how the process of transferring money is going to work in Daiokan and designed something absolutely weird. So, we had to completely redesign it.
We analyzed all the screens and decided to focus on 100 particular screens. To stay within the budget and create something functioning, we agreed to follow the MVP approach — implement only the necessary features. The most important things for the marketplace development project were a session manager (storage of photos categorized by clients), a payment gateway, and a mobile app. We agreed to add bonus features only if they fit the budget — for example, we could easily put off the blog and the notifications until the next release.
What is Daiokan
It’s a marketplace that helps photographers and their clients find each other
How it works:
— A photographer signs up in the web app and gets ‘uniform’ offline.
Needed to stand out from the crowd and find those who wanted to get a picture
— The photographer finds a client. Then in the mobile app, they create a session just for that client (all the photographs from the shoot will be stored there) and indicate the first shot. One session for one client. If the photographer has 5 shoots a day, he creates 5 different sessions.
— Camera, action! — The photoshoot begins. By the end of the shoot, the photographer indicates the last shot. This way the photos of different clients won’t get mixed up.
— When the work is done, the photographer gets back to the web app and uploads all images. Since the photographer has already created sessions in the mobile app, it will take about 5 minutes.
— The photographer sends clients links to the gallery with their photos. The clients pick shots they like, add them to the cart, and pay for the purchase.
Team workflows
The project started with a manager who later moved to Moscow. We still had 3 developers, a designer, a QA specialist, me as the project lead, and a new manager. All in all, it was a full-project team.
That’s what we did to make the work easier for everyone:
In the first place, after the selected screens were approved by the client, I printed out the key user flows: registration of the photographer, admin approval, and photography purchase.
These flows were our key guidelines
At first, it was hard to prioritize tasks, since the first manager dropped out. To resolve this problem, we agreed to take up any tasks from the created flows.
The idea was that whatever you do, it will definitely be useful for the project
In the second place, we described tasks related to every flow. Frontend tasks were set out in user stories, backend tasks — in free form. This way, the developers could take up the tasks themselves — no need to figure out what exactly must be done. Plus, it defined the scope of every task, which helped us a lot at the stage of project estimation.
In the third place, we switched to the Kanban Tool. With the first manager, we used Trello to manage the marketplace development project.
That’s pretty much the way it looked
It was inconvenient to plan parallel work with Trello for this project. I noticed it when trying to plan frontend, backend, and layout. Kanban Tool looks more like a classic Kanban board. Instead of columns, it has a working space which makes it easier to visualize tasks.
Although Kanban Tool isn’t as beautiful as Trello, our client liked the idea of monitoring the progress of developing marketplace for photographers there
In the fourth place, we initiated everyday stand-up meetings to discuss the current progress, questions, and problems. To avoid mindless chatter, we set a time limit of 3 minutes per person.
Plus, we put off super technical topics because not everyone on the team needs them
At first, the team had doubts about the idea of meetings but in the process, it became a great tool for keeping the team members focused on the overall project goal and synchronizing the work on different fronts.
In the fifth place, we created an Extended Burndown chart that helps predict when the work will be finished.
An example of a report for the client
To create EBDC, we practiced two things: making a detailed description for a task that we plan to do, and a rough description for large functional blocks that we put off.
By the way, it was the first project when we tried using weekly sprints. Our team doesn’t work like that anymore, because it takes a lot of everyday effort like notifying the client more often, planning more often, and reporting a lot more. All in all, this method requires a lot of motion but works well 🙂
Payment gateway
Domien needed the app to support multiple currencies and credit cards, so at first, we were aiming for PayPal.
In the process, we figured out that PayPal’s Mass Payments only works for companies registered in the USA. The problem was that our client decided to set up his business in Hong Kong. To solve this problem, we tried using different versions of PayPal’s API.
When we were searching for an appropriate API, we found out that there were very few options — the first one was official PayPal’s Payments API which didn’t work well outside the USA and Canada. However, their website says that you can contact them and they will connect you to the API. Another one was Adaptive Payments API, you also need to contact their account manager first. Both options were not great because they didn’t allow accumulating money in our PayPal account. But for us, those were the only available options.
The time to find a solution was limited — Domien wanted to launch the product and show it to the first users as soon as possible. We had 3-4 weeks to handle this unclear situation with PayPal.
We decided to do this — after clients purchase photos and transfer money to the company’s PayPal account, Domien sends the money to photographers manually after charging the company fee. This approach greatly sped up the working process and helped meet the deadlines.
A surprise twist: the day our team started testing payments on real money, we figured out that PayPal stopped supporting credit card payments through API.
We decided to try Braintree, this service already worked in Hong Kong at that moment. We spent time on integration and tried to get the production keys (to start testing payments right away) and Braintree blocked us — they claimed that the business was too risky. We tried talking to them and revealing the business plan and business model, but nothing would convince them. What a cruel twist of fate on the final step.
How the story ended: it didn’t work out with Braintree and we released the MVP with PayPal without credit cards —we needed to launch the product as soon as possible.
Why not Stripe? There are two reasons:
-
- Firstly, as we said before, the business was registered in Hong Kong. Stripe Connect didn’t work there when we were integrating the payment gateway.
- Secondly, the app needed to accept payments from as many countries as possible, while Stripe only worked in China and Hong Kong, at that time.
Factors to consider when developing a marketplace for photographers
I’m not dramatizing here — just listing problems we encountered and solutions we found while working on the project.
Limit on photo upload
At one of the meetings with Domien, I expressed my fear that photographers could use the service as a free photo storage. Initially, there were no limits on photo upload, so such situations might actually happen.
As a result, we decided to set a limit — 300 images or 2 GB for one session. The main idea was to set this limit even if it’s very abstract. A more ‘meaningful’ limit could be defined after the release.
Blocking photographers
Since we were developing marketplace for photographers, we couldn’t just block access to an account. Even if a photographer is blocked, the clients can still purchase photos from the app. We decided to ban them from creating new sessions and uploading new photos.
Hosting images
It would be too expensive to host all the photoshoots forever. We needed to come up with some kind of mechanism that would delete the images after some time. We agreed to do this: host images on Amazon S3 for one year and then, delete them.
Invoicing
That’s how invoicing worked: customers’ money went to the Daiokan’s bank account. To make the process more transparent, we built a system that created bills for clients, photographers (when they withdrew money), and Domien (to separate his profit from other people’s money). It was a part of the admin panel. Since the app supported multiple currencies, it was really interesting.
Upselling customers
By the time of the second release, Domien planned to add a feature that would allow selling not only photographs but also products with printed photos.
Mugs, pillows, posters
We figured out that it’s easier to use an outside service for printing and shipping the products. Printful wasn’t a good solution for the MVP — it only worked in the USA, and shipping to Europe is expensive.
Another option was kite.ly. One of the downsides of the service is that it doesn’t have a builder for transferring photos on these mugs and pillows. It was unlikely that they would code the builder themselves, so there was no point in asking them. To figure out what to do next, we decided to contact their team.
After talking to guys from kite.ly, we found out that: all we needed to do was build a TIFF file from a template (without layers, alpha channels, and compression) and send it to their private API. It didn’t sound like a problem, but there were 2 more tasks for us — we needed to figure out how to create the product preview and the builder. Domien’s plans changed and we couldn’t finish the task, but we developed an action plan and would definitely get the job done if required.
In conclusion
We worked on the Daiokan project for 8 months. The web and mobile apps were finished — everything worked properly. As a cherry on top, Domien could raise $250,000 in investments, thanks to our work.
How did the story end? The investors brought their own team of developers from Belarus. We contacted them and successfully handed off both apps.
While we were working on the project, Domien moved to London and changed the name of the startup from Diokan to Daiokan. The first name meant something unpleasant in another language — the exact meaning became a part of a story that I successfully forgot 🙂 Probably, it’s for the better.
