About Qikbook

Qikbook is a marketplace built to facilitate the booking and management of counseling rooms. 

Counseling rooms are spaces designed for providing counseling or therapy sessions. These rooms are typically equipped to create a comfortable and confidential environment where individuals can talk to a counselor or therapist about their concerns, emotions, and experiences.

Building managers or owners, who usually administer several counseling rooms, often don’t benefit from an automated way of doing so, as the main players in the market are generic scheduling tools, and thus are not tailored to provide the best user experience

Qikbook stands out from its competitors by not charging a subscription fee. Instead, Qikbook charges a small commission over bookings made through the platform, making it a risk-free solution. The platform has an extensive marketplace that turns listings (buildings and their rooms) into a showroom, allowing users to window-shop listings in Qikbook before even signing up.

Meet Qikbook’s founder

Chris Sharp, Qikbook’s founder, is no stranger to the business, having ten years of experience in it. A former building owner and manager himself, he struggled with the challenges of managing these rooms on a day-to-day basis: from taking care of last minute cancellations and invoices, to singlehandedly managing the schedule of several spaces.

In the meantime, he used several apps to solve for his use-case, but none of them did the job he needed done, not by a mile. 

The Opportunity

Chris knew he had to take the matter into his own hands

In May 2014, Chris had the first glimpse of how he could help building owners and counselors. He refined his idea over the years, diving deep into each one of the user experiences his app would provide. 

He taught himself how to code, as a means to showcase everything he needed built through a prototype. There were many intricacies involved in building a tailored solution to this use-case, and the prototype was the best way to illustrate them.

The Challenge

Chris knew he had to seek support to turn his vision into reality. He initially reached out to another consultancy that worked alongside him to implement his ideas. Chris then began his journey of trying to communicate what he needed.

Communication was difficult from the start, with only the Project Manager being a fluent English speaker, although with no technical context whatsoever. This caused technical directions to constantly get lost in translation. Out of the two developers allocated in the project, only one of them could communicate with Chris on a basic level. This led to catastrophic consequences to the frontend, as the detailed business logic couldn’t be grasped by the other developer. 

Their lack of English-fluency wasn’t the sole issue though. While the backend code was at what we could call an acceptable level of quality, 80% of the frontend code would later need to be rewritten by our team due to its poor quality. For the more tech-savvy, there were places in the React code that had up to 55 useStates in a single component.

On top of that, this consultancy allocated a DevOps professional on a one-off basis with the purpose of setting up the deployment pipeline and the production infrastructure. The production environment used VMs, which are resource-intensive compared to containers, have less efficient scaling, have labor-intensive maintenance, added infrastructure complexity and limited isolation. For context, the industry trends favor containerization in the growing shift within DevOps. 

Unfortunately, they couldn’t accomplish the mission and Chris was left stranded. It was time to restart.

The Answer

Qikbook reached out to Vinta to get their MVP up and running

When Chris reached out to us, he had a half-built Django-React-based product and a backlog document with almost 30 pages of descriptions of bugs, improvements and features to get through. We knew this would be a considerable task upfront, as there were many parts of the codebase that had been implemented with low-quality code, leaving us to navigate the minefield without many references. 

Although this was a challenge, we had no doubt that our experienced full-stack team could handle it. Before we had our kickoff meeting, we took Qikbook’s backlog document and turned it into a structured tickets list, ranking features and bugs according to their complexity and priority. This allowed us to be more efficient when discussing focus areas. We had a first meeting with Chris and double-checked our assumptions about priority, and with an ordered backlog, we were ready to go.

We then got to work, with our team collaborating daily with Chris to get his product out as soon as possible. We worked alongside him for almost two months, polishing the product and making sure it was up to his expectations. Chris knew exactly what it would take to get his vision out in the world, and we were there every step of the way.

To make sure we got it right, not only did we send daily async reports to guarantee Chris was aware of our progress and blockers, but we met every week. Even with the drastically different time zones (GMT -3 vs GMT +13), we all valued the synchronous moments that would allow us to do product demos, collect feedback and align on requirements.

This journey was not without its challenges in that sense. We’re fortunately battle-tested in asynchrony as a remote-first company, and made the best usage of IM to communicate and align expectations when we couldn’t afford to have face time. Still, the autonomy of our engineers and the business guidance Chris provided to us were enough for us to overcome the challenge of naturally delayed responses due to the different time zones. 

Along the way, as it’s natural for MVPs, we ended up tackling issues and features that were originally outside of the original scope, as well as tracking new tickets we would like to do before launching it. We identified this early, and reached out to Qikbook’s founder to understand his stance on how to proceed. Since he was committed to delivering a product that was more than polished, he was happy to have us go on for a couple more weeks to guarantee everything would be perfect.

The Product

Qikbook is a marketplace with buildings and rooms (listings) on one side, and users (usually counselors) on the other. The platform allows building owners and managers to not only manage their listings, but control granular aspects of how they want to run their business, they can:

• Set cancellation policies that best adapt to their needs;
• Choose other users to manage their listings for them;
• Manage and set special conditions for VIP users;
• Book and cancel rooms on behalf of users;
• Choose whether to keep their listings public or private to their own clientele.

Qikbook’s scheduling experience is comprehensive, having been a substantial challenge to implement. Our developers had to resort to extensive Redux use and state-of-the-art JS to guarantee a high-performing UX. We’ll go more in detail about technical aspects in the section below.

Tech Development

We had a variety of technical challenges with Qikbook. Beyond replacing those 55 useStates with 5 useSelectors and migrating the deployment pipeline from VMs to DigitalOcean App Platform, enabling scalability, reliability, trivial maintainability, as well as Continuous Delivery for a better DevEx and delivery velocity, we could help their company with a variety of technical challenges, as described below.

The first one was implementing their all-encompassing scheduling options, which involved dealing with the availability of listings and rooms, restricted dates, existing bookings, canceling rules, permissions, due payment/refund calculation logic, all of that in a single screen! The use of modern Redux tooling like Slices, Selectors and Immer were essential to making the frontend performatic and with organized complexity.

We implemented payment and refund calculation code from scratch, in a ledger-like manner so as to simplify the refund logic. Another point to be mentioned is that all of our booking logic ended up with a test coverage close to 100%, with the intent of guaranteeing correctness.

Adapting the booking flow to support all timezones was also needed, as it would enable global usage for the platform. This was possible through integrations that allow us to find out the Listing’s timezone through its address, as well as correct timezone usage at the database level, business logic and frontend touch points.

We implemented an automated system to collect Qikbook’s commission through monthly Stripe invoice issuings. Since the system is timezone-aware, it was built to run every first day of the month considering the Listing’s timezone, and calculate the due commission considering all of the bookings from the month prior. For that, we used Huey async tasks to schedule and execute the automation, although it was necessary to extend Huey’s crontab to make it timezone-aware. The invoices are generated within the system and then integrated to Stripe Invoices. When they’re paid through Stripe, our system is also automatically updated via webhooks.

On top of that, there were also security issues to be solved, like frontend-only incorrect validation, permissions that had been wrongly implemented in the backend, incorrect usage of JWT expiration and refresh tokens, among many other issues. Our team had to fix and reimplement all of this, making reviews a main part of the job. We would test existing code and reimplement it when we deemed it necessary and strategic.

Finally, as it’s our custom, we made use of existing open-source tools to speed up the delivery of key features. Examples include:

• dj-rest-auth, which helped us reimplement the login, passwords, logout and JWT logic;
• Mantine table, which helped us reimplement the Booking & Logs listing and filtering pages;
• django-safedelete, which helped us speed up our implementation of soft-deletion, allowing admins to easily restore data;
• Custom Django Admin, with several actions to make admins’ lives easier.

Product Consultancy & Investment

As a marketplace, it was expected that Qikbook would face a set of challenges compatible with the business model. However, choosing a side (supply/demand) to focus on first was not one of them. Many of the building owners would already come with a roster of existing customers, ensuring that every supply acquisition came with its own demand. Chris was well-aware this strategy would help him get where he wanted.

The validation method he would use for his idea was crystal clear to him: he would knock on door to door and offer his services to hundreds of building managers who found themselves in a similar situation to him years ago. In cases where more product discovery and development is needed, we like to offer our Product Management services, so we can dig deep into strategy, validation methods, research, metrics and among others.

As an intentionally bootstrapped company, Chris wasn’t after investment at first. He sought to validate his MVP and go through the revenue route upfront. Cases of self-funded ventures are becoming more common each day, as investment is harder to come by. With Chris’ clear vision on what he thought it would take for his business to take off, we worked hard to make sure everything was in accordance with the product’s philosophy: simple, yet powerful features, and no subscription fees.

The Result

“Vinta’s work is exemplary. At the end of the day, it’s about the quality of work.” – Chris Sharp

By the end of our cycle with Qikbook, we tackled over eighty tasks, between bugs, improvements and new features. With our work, Chris was able to launch his system and bring it to real users’ hands. His next big challenge is validating the idea out in the market, collecting feedback and learning. Software is never really done, and iterative approaches increase a product’s survival rate.

In the meantime, we’re rooting for Qikbook and eagerly await for future collaborations.