Tanibox Product Development Lesson

After several iterations, finally, the version 1.0.0 of our GRO Planter app has been released to Google Play Store and Apple App Store. The development of this applications was done by a team of 2 persons, a backend engineer and a front-end engineer. This is our second product after Tania, that we’ve open-sourced earlier this year.

During the development process, we’ve learnt valuable lessons about product development with a distributed team.

Communication is Important

There’s no over-communicate if you’ve team spread around different geographies with different time zones. Tools aren’t that important if the team is not communicating well. We’ve set a chat room based on Telegram to communicate about product development.

Team-Wide Product Knowledge

Team members discuss the development of a product in a chat room in public. Most of the discussions are open for other team members to see. This way, there’s no real segregation between the technical vs non-technical team. They’re all team members. The developers should know how the product works, and the product person should be able to communicate the product rules and behaviours to the engineers.

Software should be able to adapt

Even if our startup just started, we’ve been experimenting with a lot of tools to develop. Our first version of Tania is written using PHP. We immediately face challenges when we want to deploy our app on a small machines running on non-Intel processor when we started our partnership with QNAP later last year. The decision was to rewrite our entire app in Golang with Domain Driven in mind. The reason was both business and technical.

We embrace our second degree of ignorance, as we don’t know what will happen in the future, we design our app to be able to be as adaptable as possible. Tania is totally protocol and storage-agnostic. We can run Tania on SQLite to RDS on a small embedded Linux machine to the big server in the cloud. We can change HTTP to gRPC without changing a lot of our domain logic. We can even able to separate our domains to “microservices” if we want in the future (we don’t at the moment) as our domain layers share nothing and communicate by sending and receiving events.

The Gro Planter backend was made by adapting Tania to B2C use cases. Although we don’t plan to open source it, most of the code was extracted from Tania and we do it in a very short amount of time.

Conclusion

It has been quite a journey for Tanibox team this year as we’ve released both our products to the market. As the time goes by, we hope we can share more about what we learn when we build products in the future.

Comments on Facebook