The idea of the ChildrenGo app, an aggregator of children-friendly places, came up to me and my husband in March this year.
It comes from our own problem which was a pretty simple one. We’ve tried to find a coffee place to visit with our son. He was 11 months old back then and, like many other toddlers, he was (and still is!) very active, curious, and willing to explore the world. So, we had a strange list of requirements for a cafe: a special transforming table, a place to crawl and play for the kid, and tasty coffee for us. And we thought it would be great to have an app where you can look for a place, which meets all our requirements.
We began with a conversation with our potential customers — with other parents. We had to understand if they have a similar problem too. So we drafted a survey and sent it to all our friends and acquaintances, to online communities. And we have got a lot of replies! It convinced us the idea is interesting for other parents.
After that we… No, we haven’t write any code yet. We interviewed parents who reply to our survey to meet. We wanted to know what is important for them when they are looking for a place to visit with children. And how we could help them.
Thanks to those meetings we’ve got a lot of new ideas too. We found out that some parents rely on reviews, while other parents are more interested in photos. Some parents look mainly for outer places, while other parents spend their free time in museums.
The next step was to go through all the replies, all the notes from the meetings and made a list of the functionality that is needed to get started. Minimal, so that it can be done quickly.
And only then we started writing code.
Looking back I think even at that stage it was too early because it was possible to start with a list of places in google.docs. But what’s done is done.
We used Python for the backend, and React Native for the mobile app. No regrets, both are great for a quick start.
We tried to follow the Agile ideas but we didn’t follow rituals strictly. For example, we had sprints and we tried to limit it in time. But it didn’t work out. Development in the evenings after the main work does not contribute to this.
We prioritized tasks, did what users asked for first. There were no retrospectives and evaluations of tasks, no strict time limits. We just worked as fast as we could.
The test version was done in about a month and we were ready for the alpha test. But that’s another story.