Bloo's Senior Software Engineer, Chanlito (also known as Bruce) is interviewed and brain-picked on his methods and principles when it comes to developing software products like Bloo.
You were one of the first people who joined Bloo and built the software product from scratch. What compelled you to enter this journey from the start?
C: This is definitely a question that takes you down the memory lane. I remember being at the desk alone with a sticky note written ‘Blue’ on it. “Bloo” only developed our branding later on. It wasn’t hard to forget the enjoyment of building the software product from scratch and the possibilities it brought along. I was, as you termed, compelled because of those possibilities and the prospect of working on something that could make work lives better.
That sounds fantastic! So what was the first feature you built in Bloo?
C: This is an interesting question. It’s hard to answer it without bringing up the story of how the idea of Bloo started. Our Founder had been using other tools to manage team and projects before, and they were complex to use and got very expensive as the team scaled. So he thought of building a more affordable and simple-to-use project management software, and that’s when I joined in the vision. One of the first features we built was an update feature, simply because we needed a tool for teams to stay updated without hosting daily meetings. Its first version was straightforward and simple, team members can easily post their progress status without much training needed. It’s as simple as posting a Facebook status.
Wow, very interesting indeed. So who was the first customer using Bloo?
C: Our Founder owns a design agency called Mäd, and their team members were the first ones using Bloo. And they’re also our beta testers every time we release new features.
So, if you didn’t have a feature request, how would you decide which feature to build first?
C: Well, for us, the first principle is about the needs for that feature. We would host a team meeting every quarter to ask ourselves “What would be stupid not to have?” and we would come up with a list of features we think would fulfill the basic needs for a project management software, then we would prioritize which one we build first. The second principle is related to our engineers’ capacity. We want to make sure a feature isn’t too complex to build that we spread our effort thin on a mediocre-functioned feature rather than placing our effort on important and greatly functioned features. So the bottomline is:
- The feature is much needed.
- Our engineers have the capacity to do a superb job at building it.
The third principle would be making it as simple to use as possible. Simplicity is at the core of Bloo, and that must be our first priority when releasing a new feature - making sure it’s easy to use enough that users can build a daily habit around it.
How do you know if a feature is much needed?
C: Well, we often ask for suggestions from current users and they would give us some ideas of what problems they need solved. So we could draw up some features needed from those ideas. Second, we often get inspired by other tools in the same industry; we look at them and we analyze why they build a certain feature. Other than that, we use our common sense. We try to emphasize with users by placing ourselves in their shoes - what would we need to manage projects and teams effectively? - because after all, we’re also our own users.
This is great. Can you tell us a little more of how you use Bloo to build Bloo?
C: Haha, that’s a good question. I think it’d be best to show you our Kanban Board. First of all, we use a general Kanban workflow - Ideas, Backlog, In Progress, Under Review, Done. But we customize it with lists like:
- Bugs: We list down all spotted bugs there for our engineers.
- Design: All new or re-designs needed for a feature is listed here.
- Development: What our team is currently developing.
- Q2: Our goals for each quarter; Right now we’re at Quarter 2.
I suppose you could structure it however fits your team; For us this workflow works best as our engineers have a clear idea on what to build or if there’s any bug that requires urgent attention. I guess, we also use Bloo to experience Bloo as customers. This way we spot errors, bad UX, or bugs before they go out to the other users.
What technology does your team use to build Bloo? What framework do you use to decide that?
C: Our team uses Vue JS, Vuetify for its UI component library, GraphQL, and Node JS. In addition to that, we write everything in Typescript. We decide those tools by two simple rules:
- They have modern, cutting-edge features necessary to build a great product.
- They are easy to adopt fast, meaning that our engineers can get started fast without much training needed. Since we’re a startup, we do not have a lot of resources for training, so we must be strategic on adopting new tools.
The Bloo development team has four people, with Chanlito leading the pack. There are three web engineers and one mobile engineer.
Work Better, Together.
The best way to experience Bloo is to sign up for a free trial.