Designing and building MVP with no-code tools
Back in November 2021, our team at Arc wanted to launch a minimum viable product, MVP. The idea was to allow companies browse a list of developers and invite them to interview right away.
The goal of the MVP is to provide a quick method to validate our business hypothesis and to improve immediately based on feedbacks. In this post, I'll go over how the MVP was designed and built with no-code tools in under a week.
Designing the process
The first step is to plan out the process and implement step by step.
- Client views list of developer
- Client invites the developer to interview
- Developer sees the interview request
- Developer responds to the interview request
- If accepted, introduce and prep both parties for interview
- If rejected, share update with client
With the process listed out, we can think about the implementation. What we found helpful is to break the process into smaller steps and list the important features of each step. This is great for project management and lets us focus on the problem we’re solving for each process.
- A list for client to browse
- Inviting developers to interview
- Sending interview request to developers
- Handling interview request response
- Recording and sharing the result
A list for client to browse
To begin, the client will see a list of available developers and have the ability to invite them to an interview. In our first iteration, we used Notion, but found it difficult to maintain and automate.
For our final version, we utilized Spreadsimple, a tool that allows you to build websites using Google Sheets. By populating the Google Sheet with developer information, Spreadsimple generates a user-friendly UI with each developer having their own card and information. This method was perfect for our use case because it allowed us to easily populate the Google Sheet with developer information.
Using Zapier, we collected essential information such as the developer's Arc profile URL, short summary, location, and tech stacks, which were then inserted into the Google Sheet. From there, Spreadsimple generates a UI for each developer with their own individual card and information
Inviting developers to interview
On the featured developer list, each candidate has a brief introduction, their key skills, and a link to their Arc profile, which provides a more detailed overview of their experience. To streamline the interview process, we added an "Invite to Interview" button on each Arc profile page. Clicking this button opens a Typeform that prompts the client to provide their company and role information, which is shared with the developer via Slack (more on this later). We use Zapier to record and organize these interests on a separate Google Sheet, enabling us to track developer responses and conduct analysis.
The final result is a streamlined process that allows clients to easily invite developers for interviews and provides developers with clear information about the role and company. The use of Typeform and Slack integration enables the process to be automated and track responses efficiently.
Sending interview request to developers
On the developer end, we use our developer community on Slack. At the beginning of each batch, we create private channels for each developer, which only they have access to. Whenever a client submits an interview request, a Slack message is sent to the developer's private channel with the client’s company and role info. This allows the developer to review the request and decide whether to accept or turn it down.
Zapier is used to record new featured developers on Google Sheets and create private channels for them on Slack. The Slack channel IDs are then used to determine where the interview request should be sent to. After sending out the interview request, we’ll also store the timestamp of the Slack message. Together with the private Slack channel ID, they’re used to identify the interview request Slack message for each developer.
Handling interview request response
On Slack’s interview request message, we allow the developer to respond simply by reacting with an emoji. Implementing the feature for developers to respond to interview requests in their private channels was challenging. We wanted to use Zapier's emoji-added trigger to record the response, but it only listens to one channel at a time, meaning a new zap (Zapier workflow) had to be set up for each private channel. However, this approach was not scalable.
To solve this, we integrated Slack's API with another no-code tool called Integromate (now Make) because Zapier's Webhook step wasn’t enough. Using Slack’s API, we were able to listen to all emojis added to Slack messages. The API response contains the channel ID and timestamp of each message, which lets us identify which emoji are responses to the interview request. The results are then recorded to the Google Sheet with interview requests info.
Learnings and conclusion
An interesting problem we encountered was when the zap was unable to identify the Slack channels recorded on Google Sheets, resulting in clients not receiving any responses. The issue was related to how Google Sheets was changing the last digit to 0 when storing the timestamp in epoch format. To resolve this, we started storing the timestamp in string format instead of the original epoch format. This was a lesson for me to be extra careful when dealing with numbers, especially longer numbers.
Looking back, I'm still amazed this was accomplished in under a week, demonstrating the power of no-code tools. However, I have to stress the importance of understanding the intricacies of the various tools you are integrating to be extremely important. You're only able to maximize their potentials by understanding them thoroughly.
The no-code version ran a little over six months, while the product team works on building and improving features based on feedback. If you'd like to find talented remote developers, please check them out on Arc.