What I learned from developing a Competitive Online Singing Game
The app must be finished and deployed on Monday — No excuses!
In March we slowly started distancing from each other. In April we went into lockdown. As people started getting disconnected from each other and we got way more free time on our hands we saw it as an opportunity.
We had a plan. One weekend — one app. After an intensive brainstorming session we had an idea to accompany that plan. We created Warbly — A competitive karaoke guessing game.
Keep reading to learn the most important lesson we took away from this development session.
Simplify
It is no secret, that things don’t always go according to the plan and schedules you set for yourself. Software development is no different. As any developer can tell you, we have a lot of unfinished projects.
To make sure this project does not get piled on the ever-growing stack of unfinished ones we had one simple rule:
- The app must be finished and deployed on Monday — No excuses!
This rule made sure we work efficiently and cut away all unnecessary features.
Before development
At our kickoff meeting, we started with application breakdown and work distribution. When we had all the application features laid out in front of us, one thing was certain — We can’t develop and deploy all of this by Monday.
The rule was working. By taking another look at the features and game flow we discovered two things:
- The flow can be simplified by not affecting the game too much.
- We have features that take hours to develop but add no value.
The rule helped us simplify the game, remove bad features, rework user flow, and speed up development already.
During development
When developing we had new ideas. Many of them. And all of them were “great”. The problem was we couldn’t develop them by Monday.
We had a personal attachment to all our ideas, but the rule held us back. We simply did one thing:
- We wrote them down and forgot about them. We keep them for the next version of Warbly.
The rule helped us beat feature creep — a tendency for product or project requirements to increase during development.
After development
After development, we focused on usability and reliability. The app worked, it had everything we had decided to implement and it was reliable. We just needed a name and a domain.
Coming up with the perfect name can be a pain. It has to be fun, short, memorable, and most importantly — not taken. The problem was Monday was just around the corner. So we decided on two things:
- The name must be unique and somehow connected to singing.
- We are not using .com as the domain.
This made it super easy to come up with a name that fit all the criteria. And by using a .fun domain we were sure it wasn’t taken. And if it was we would simply use .app or .io or any other, that is not as saturated as .com
These are just three cases where this rule helped us develop and deploy Warbly in a matter of days. There were countless others.
The rule works. But it can also be stated differently: Simplify
Try Warbly out here 👉 http://warbly.fun
