folk technical introduction

This document aims at providing a description of the technical organisation of folk.

At folk, we believe that for an organization to thrive it needs to expand and maintain its network. It’s by having engaging conversations with others that new ideas and opportunities appear. folk is a Saas tool supporting its users in this process by allowing to:

• create rich lists of contacts
• engage with them via messages
• track and follow up

We focus on making folk a collaborative tool to empower teams better manage their relationships. To better serve our users, folk embraces a no-code approach which stands for a simple UI allowing to create rich highly-customized processes.

Product structure

The product is structured in 3 layers:

1. the database layer allows users to collaboratively visualize and manipulate their data. The challenge is to make it very simple to understand and to update.
2. the intelligence layer cleans and enriches the database with missing emails and phone numbers. Also suggest how you can categorize your contacts. It’s setting you up for suggest.
3. the engagement layer allows users to explore and engage with their network. We allow to create personalized email at scale and getting the delivery stats to update the conversation process. The challenge is to provide the right information to them so they can target the right people.
4. the automation layer allows users to automate process by triggering any kind of action from any event. The challenge is to make it simple to automate any part of their workflow and to integrate with all their other tools.

Technical stack

The technical stack is built in a typescript ecosystem. We are currently relying on these frameworks: ReactJS, tRPC, fastify, prisma, Postgresql, AWS (currently removing GraphQL/apollo)

The only thing that really matters to us is quality. This translates into unit tests, integration tests and E2E tests, PR approval process, clean code, continuous integration and other classic development approaches.

Above all for us quality is about producing the best product for our users. The engineering team is strongly encouraged to challenge the specifications they are given, to focus on the value rather than the implementation, to contribute by suggesting improvements, always keeping in mind reliability and performance.

Roadmap management

We build our backlog in a very classic way through user feedback, market analysis and gut feeling. We use 2 processes to handle this roadmap:

• the cadence is a 3 weeks iteration during which a duo of developers is assigned a new feature or a major improvement. Their mission is to release this new feature at the end of the iteration. They have complete ownership of the project and their first task is to challenge the specification and commit on a (sub) scope. This allows us to focus on the value rather than the details. Every 3 weeks, our users see a major increment in the product, ensuring a good rhythm. 👀 if you want to learn more about the Cadence, here's an article we wrote about it.
• all other engineers work on continuous improvement of the product. It can consist in bug fixing, UI improvements, minor improvements, removing technical debt. It is not about increasing the scope of the product but rather to make what is already there even better.

We spend roughly 30% of our time on the cadence and 70% on continuous improvement.

The identification of technical projects and long term vision building is done by each member of the team through architectural notes which are reviewed and commented. When needed the team discusses some important topics to make a decision or an action.

Our philosophy

We focus on 3 things at folk:

• rhythm: we ensure the product and the company evolve at a good pace. We don’t want to go slow but we don’t want to go too fast either. We want to make sure our users can have time to master new features before introducing new ones.
• focus: nothing great can be achieved without focus. Each team member is responsible for their time. We have a very limited amount of meetings per week (~2h30) so we allow engineers to get “in the zone”.
• delight: bringing that extra little delight that will please our users. It can only happen if the team’s environment is delightful. That means we pay attention to our developers’ experience and remove any roadblocks that could create a negative energy.

The team

We have built a team of senior engineers - that have had various experiences on various products and environments. Some of their previous companies include: FreeNow, Payfit, ManoMano, Gorillaz, Codingame, Gymlib…

We are looking for people who want to contribute and are highly autonomous. This allows us to get to the bottom of things quickly and tackle large projects of any kind.