Meet the Rapid Services team at Boldare

Hi Krzysiek! Tell us in a few words, what exactly do you do at Boldare?

Hi, I’m Krzysiek, and I work as a Full Stack Developer at Boldare. I specialize in web and mobile applications written in TypeScript with React and React Native. I also create backends for them in Node.js with SQL and NoSQL databases. Speaking honestly, I get bored quickly. That’s the reason I’m trying new things all the time.

What else? Along with my team, I participate in various workshops and consultations with clients. We look at the product from the business and development point of view and then think about what we can do that’s clever.

The process of building products at Boldare was divided into phases within the overall “Full Cycle Product Development” process. Could you describe this a little?

Sure. Let’s start from the beginning – the first stage of Full Cycle Product Development (FCPD) is the Prototype. It’s the materialization of the very first idea. What exactly can be a prototype? Everything. It can be a clickable (or not) mock-up or even just a schematic that we present to attract investors. Sometimes, a simple prototype for a confidential target group can be already functional. In this case, we move smoothly on to the Minimum Viable Product phase (MVP).

The MVP focuses on hypothesis – and they can be various. We can assume the number of app users, amount of transactions, volume of sales and many more aspects of the product’s use. Our goal is to validate each assumption, which simply means checking if it is right. We draw from our experience and the clients’ needs to deliver the most usable and productive solution. At the same time, we conduct lots of workshops and discussions to ensure we’re heading in the best direction and use minimal effort, time, and money. And what if the thesis isn’t validated? Our client can always change the main features of the product and set completely new goals – what protects him from building a giant app that will crash when released on the market.

The next phase of FCPD is Product Market Fit (PMF). Here we put tests and analysis into the spotlight. As the name suggests, the main goal of this stage is to customize the product and adapt it to the market. We check if particular features should be available to the target group and, if yes, we think about how to implement them to make our solution as usable as possible. We tailor the application to its intended users, gather metrics and focus on experiments and A/B tests. All this simply means exploring the app’s environment, but in a more specific way than the MVP does. We focus on the core built in the previous stage.

Scaling is the last stage of the product development process. In Scaling phase, our app gathers more and more users and, naturally, some new challenges appear. We can face various problems, like the system’s scalability or adjusting it to a particular target group. The application is upgraded to provide clear and easy usability, data integrity and appropriate data aggregation. The overall aim is an efficient, secure product, serving a larger number of users.

Why does Boldare use the Full Cycle Product Development and what value does it bring to the team and the client?

At Boldare, we have three teams that work on product development. Rapid Services works on the Prototype and MVP stages, Product Market Fit is responsible for the PMF phase and Scaling focuses on the last stage of the FCPD process.

Why has Boldare implemented this division? In my opinion, this is mainly a mindset and approach issue. The daily tasks in Rapid Services, PMF, and Scaling are different. These stages need different approaches, and splitting the development process in this way aids gathering and sharing knowledge about how to work in a particular team, on a particular stage. For example, in Rapid Services, we often create greenfield products. At this stage, we can conduct a lot of experiments, add new experimental features and try out new libraries or solutions. In comparison, in Scaling, we work on huge expanded structures. It requires staying extremely studious, maintaining high quality at every stage, and above all, avoiding regression.

As a result of this split product development, developers build their tools and adjust their actions to an established goal. The backlog is planned in an agile and efficient way that makes our work more pleasant. We know what we can expect and what we need to focus on at each individual stage of building a product. Full Cycle Product Development helps to meet the developers’ expectations and gives people freedom of choice. They can choose their self-development path and decide where they feel the most comfortable and work best.

In what team do you operate? What is the main goal of your team?

I belong to the Rapid Services team. Here we act relatively fast because our goal is to launch the first functioning version of an app onto the market. Rapid Services is distinctive because of its creative and out-of-the-box way of thinking. We look for new solutions even before starting the main work. Nonetheless, we base our work on our experience and acknowledged solutions from the past. Often, we use non-obvious solutions and, for example, replace the whole backend with the Backend-as-a-Service. It allows us to mitigate costs by saving development time and reducing time-to-market. Sometimes, one element can steal the show and do a commendable job.

What’s great about Rapid Services? We have quite a big dose of freedom. While looking for new solutions, we can use tools that we’ve always wanted to try out. A wide range of experiments leads us to share knowledge with others by taking part in various webinars and chapters. We test new options, tools, process, design and architectural patterns, and then discuss their effectiveness in technical retrospective and Validated Learning meetings. We ask what we can change in each particular solution and look at what other products it might turn out to be useful for. All these actions bring us precious knowledge to use in cooperation with the next client.

Speaking about new tools and flexibility – they give us a great boost throughout the year. That flexibility, and the way we share our expertise with each other, builds confidence and a real sense of accomplishment. In addition, working with a smaller group of teammates eases the implementation of new things.

How does the Rapid Services team differ from the others?

The Rapid Services team involves lots of Product Strategists and Process Guides. Developers work on complex issues, so they naturally have a tendency to act in Full-Stack roles. In Rapid Services, if you don’t have the required knowledge, you just learn it through practice under the supervision of more domain-experienced developers. To assure the quality of your software and solutions adequate to needs, you always get the support of other devs: code reviews, software and architecture design meetings, brainstorming and mentioned before tech-retro sessions. It boosts the career and spreads the wings because we’re never stuck in a bubble.

Also, numerous meetings and workshops with clients tend to broaden the perspective — during these events we deeply meet the vision of the product, work on thesis, and debate on ideas. As a result, Rapid Services members truly impact on the final version of the product and learn about more pragmatic and business-oriented approaches. For me, this is the right way to release my own product in future.

In retrospect, during the year, I’ve learned and experienced a lot. Rapid Services is different from the other teams. If you’re currently spending years on the same project, legacy is killing your vibe, or you need much more freedom in the creation process, you would probably appreciate the Rapid Services team at Boldare. There are no code monkeys here. You can forget about repairing mistakes made five years ago. The most exciting thing is you can focus on creating.

What did you gain by working in Rapid Services?

Above all, I gained a broader perspective and lots of inspiration from the sense of purpose that RS people bring to their work. Also, we operate with various tools, so I had to learn and adapt new concepts, solutions and use some low-code tools and external services to which we delegate heavy-lifting jobs. What is more, being involved so deeply in the creation process (from the idea to implementation) of each product gives an incredible understanding of the developed projects and results in more accurate decisions regarding software architecture and tooling. Finally, regular contact with clients gave me confidence in my communication skills.

What are the biggest challenges that Rapid Services faces?

The constant novelty. A new product is often unique, it becomes something new on the market, and it requires looking for totally new solutions. We depend on our experience, but also focus on searching for solutions outside our environment. Sometimes, we need to compromise. For example, test coverage above 80% is not something that is our top priority. Of course, we care about high quality, security, clean code, but still, perfectionists can feel some kind of anxiety and become a little tired of one novelty after another.

A strategic approach to product development and staying in touch with the business side adds a sense of purpose, but it also results in little less programming (in comparison to other teams). Don’t worry, you won’t become a product manager here (for the record, at Boldare there are no managers at all). Although, for some people, it can turn out to be quite difficult: out-of-the-box thinking and working on adrenaline.

Who would be a fit for this team, and who wouldn’t?

People who have the strength to accomplish their goals will fit Rapid Services perfectly. This is also the team for programmers who like to implement new things and like to see results within a relatively quick span of time. Working here demands turning a blind eye to features which are not crucial to the product’s stability and purpose. If you need freshness and novelty, and your horizon is broad, you will feel like a kid in the candy store here.

On the other hand, the Rapid Services team is not the best environment for those who like to control everything. There’s no space for digging into one topic. To become efficient in this team, you will need a lot of flexibility.

What will you advise those who want to join Rapid Services?

Prepare for a big dose of knowledge and exploration. Who knows what kind of solution you will implement for the next product? I like to compare Rapid Services to interval training; sometimes, you need to push harder for a short amount of time, then slow down, look around and push again. But the results are visible very quickly.