If you live in a big city, chances are you’ve already heard about the Wednesday dinners that bring strangers together around a shared table. Maybe you’ve even been to one. Organized by the French-based startup Timeleft, these dinners have rapidly become a fixture of contemporary urban life, now connecting tens of thousands of people each week. As swipe culture loses its appeal and adults struggle to simply make friends, Timeleft offers something outstanding.
The magic of these dinners doesn’t run on good vibes alone. At first, it ran on low code — a scrappy, effective approach that allowed Timeleft to focus on what mattered most: real-life experiences. However, as the dinners expanded to 60 cities across five continents, the technical complexities increased. That’s when Timeleft partnered with Mikki Kobvel, founder and CEO of software company Kunso. Initially brought in as a strategic advisor, Mikki now acts as full-time CTO, leading an eight-person distributed engineering team across France, Poland, and Ukraine. With a mandate to tame technical debt and standardize the infrastructure, Kobvel has helped shift Timeleft toward a process-driven product organization, all while fine-tuning the matchmaking algorithm that makes the dinners click.
In this interview, he shares his approach to building high-performing teams in fast-paced environments. He unpacks his hiring methodology — in which every role starts with a one-line job description — and explains why he champions remote work for tech teams (“My drive is always for remote because of two factors: the expanded talent pool and developer efficiency.”).
To bring structure to a company whose very product revolves around passion and spontaneity, Kobvel advocates for strong engineering leadership as the one thing standing between startup enthusiasm and operational own goals.
Grab a cup of tea — this one’s a deep dive worth your time.
TechTalents Insights: Can you give us a snapshot of the current tech team at Timeleft?
Mikki Kobvel: Ok, so here is the thing. Max [Maxime Barbier, Timeleft’s CEO] is a good friend of mine, and needed to invest in tech — they did very well from zero to one, but when they started to scale, it started to lag. And that’s when I joined, initially as a consultant and now on a daily basis.
We currently have an interesting setup. We are trying to optimize to have fewer technologies. The mobile app is React Native, and then we also use Next.js and React for the back office. We have an internal system with all the things you don’t see on the app, and that’s where the heavy lifting is happening.
The tech was built in [Google] Firestore with low code. Actually, it’s quite interesting: everything was built with low code. It was FlutterFlow, Firestore, and Bubble. It was a creative solution to free up resources to focus on product-market fit, but not a long term-solution. And a lot of webhooks, a lot of things which, from an engineering standpoint, are not scalable, but it’s quite impressive.
So, when I joined, it was the period when they moved from the low code to React Native, and now we are trying to structure it properly and standardize the infrastructure and the technology roadmap.
In fact, Timeleft didn’t use the traditional way of building software, allowing for fast growth; they accumulated a lot of technical debt, but they focused on the users and the IRL experience. Typically, in tech projects, this is not so good, but since the product revolves around the real-life experience, with the app being just a small part of that, it was actually quite clever because the accumulated technical debt allowed the business to grow really, really, really fast.
Right now, we’re at the stage where we try to consolidate the tech and add features on top of what existed. There are new things like the Timeleft Repeat coming. We play with the existing offers, but we try to make things standard so we can scale. We have begun launching new features, with many more on the way. However, we are also in the process of standardizing our infrastructure.
We currently have a Software Architect; we have the Tech Support Engineer, the one who built the low-code system. We have a Lead React Native Engineer plus a React Native Engineer. That’s our front-end, mobile team. Then we have one Lead Back-End Engineer, and we have a Full-Stack Engineer who is focusing on Next.js. And we have two QA people. So, it’s eight people, nine including me. Which is pretty lean, and that was actually my task.
We heavily rely on Google Cloud because we still have a lot of dependencies on the Firestore. From Google Cloud, actually, quite a lot of services as well, Firestore, Cloud Run... And we have quite a good deal with them. Google is quite good for startups. I highly recommend it.
Since I joined, we have also made space for more tech innovation. We tried to make our infrastructure, everything related to users, as standard as possible so we can easily hire talent, mostly people who care about the product, like, it’s no deep tech. We have a specialist working on the algorithm side, which is quite a complex problem, but it’s pretty stand-alone; that’s where we use a Python algorithm.
When I joined, we focused on creating the core team. As is typical for very early-stage startups, engineering was very much CEO-driven, and now we’re starting to create a product-centric organization where the requirements and stakeholders are aligned in a better way. Then we expand the engineering team. However, it’s going to happen soon. We can easily double engineering in half a year or even triple it in one year. It’s just that we try to play with the existing offer rather than grow engineering.
TechTalents Insights: What qualities did you prioritize when hiring your engineers?
Mikki Kobvel: I love tech, I’m a hands-on guy, I do a lot of things, but the number one skill you need is to hire the right people.
When I joined Timeleft, the hiring process was not fully matured, as to be expected with such a young company. We spent a lot of time reviewing previous decisions and building a new and more sustainable path forward. With the startups that are the best at gaining early traction, most people wear many hats but for a variety of reasons, this cannot be maintained indefinitely. It was time to enter the next phase of our technical journey.
I always start with a single-line job description: what exactly this person should do, in a tangible way, and it should be justified by a business goal.
For example, we didn’t hire QA because we had a problem with quality. We hired QA because we are migrating to a new structured database; we need someone who can make a clear judgment of when we enable features and when it’s lower risk — so we don’t have problems. It’s a very tangible thing that allows you to easily hire engineers.
Then, you can break it down into three pieces: the engineer must know data structure very well. If you say, I need to do data migration, you need to know someone who knows data structure very well, is hands-on, and can write technical scripts. Basically, they will be the foundation of the system team, so they need to be able to manage other QA engineers. Those were the three criteria. So you don’t go looking for every QA engineer.
When we hire people, we put it in one line what is the tangible thing they need to fulfill. And then we put the no-gos — why we would not hire a person. So, let’s say we had many applications. If the person doesn’t understand data structures, it’s a no-go. If they never did migration of DBs, it’s a no-go. And there are a lot of QAs who have done these things, but then, for example, they never tested a mobile app — we don’t care. For this specific role, it makes perfect sense that we don’t care, and it becomes very easy to hire in such a manner.
So, based on the business goals for Timeleft, it became very clear how we should structure the team. After six months of this hiring cycle, we feel quite comfortable. Of course, not every person you think fulfills all these three pillars will later on prove that they can execute at this level, and sometimes we make hiring mistakes. But at the beginning, the number one thing is that the person needs to 100% know and have experience in doing certain things we want to do. Because we are a fast-growing organization. We need people who’ve been there where we’re going. We don’t have time to coach people on how to use a certain framework. We need them to understand the context and just go and do it.
Obviously, AI is now one of the big requirements. So, if you know that a person does not use AI for their work, you know they’re going to lag behind. Not because they’re unproductive right now but because they will become unproductive in one year. Or in six months.
TechTalents Insights: Do you guys work remotely?
Mikki Kobvel: I can only speak for the engineers. My drive is always for remote because of two factors: the expanded talent pool and developer efficiency. So that’s why I advocate for remote work, but people come into the Paris office for the IRL connection, etc. We have a hybrid team.
TechTalents Insights: Regarding the day-to-day work, are there any tools or practices you’ve adopted that have proven efficient for productivity and team morale?
Mikki Kobvel: Yeah, so number one, first of all, when I joined, there were a lot of contractors, and one of the goals was to build an in-house team.
And then I wanted to improve communication to suit a larger and more mature team.. To nail it down, we started by making sure that all the channels had a proper structure — and that you can communicate and know where to go.
We had to find the right balance of holding in-person discussions while ensuring remote team members were kept in the loop and everything was documented and easy to find.
We started by building the RACI matrix [Responsible, Accountable, Consulted, and Informed], marking who is accountable, responsible, and who needs to be involved in the conversation.
We make sure that if I chat with someone in the office and I need my architect to be aware, I need to create a thread on Slack and make sure that they’re looped into this conversation. Otherwise, we start creating silos, and it’s damaging to the work.
So, one of my big achievements in Timeleft was closing communication gaps for tech. For every topic we discuss, there needs to be a thread on Slack within the specific channel, and everyone who needs to be looped in must have access to that channel and check it.
Similarly, if people are talking through DMs, and suddenly you need to include someone else, you invite them, but they don’t have the context, and it creates a lot of tension, and people miss out on the information. Then they want to go to the office, but when they go there, they get distracted. It’s an art to manage these conversations online and offline.
So, there is a trade-off, and it’s a bit time-consuming sometimes, but you need to work more intentionally in order to keep your remote team in the loop regarding what’s happening in the office.
Most of the project management we do is in Jira. When I joined, there were many things like Asana, Notion, Linear, but Atlassian’s Jira is a standard tool, and it’s much easier for everyone to use. Everyone knows it; we’ve used it for many years. So, there were like, five different tools, and all the tools we had when I started burned a lot of cash and the bill became big. Then, you end up using one tool that everyone knows. Some people get frustrated, but at the end of the day, you just need to put your tasks somewhere, and it just works. And you save a lot and everyone follows the same framework and pattern. We still use Notion for documentation, but for engineering, it is Jira.
And I do think all these freestyle tools don’t work for advanced teams. They are very good at the beginning when you’re like, five people. When you start growing your engineering, you need something very structured. You need to have proper planning and a proper roadmap. Yeah, so the key tooling for the engineering is Jira, Notion, and Slack. Slack is massive; the communication flow works almost like documentation in many cases.
TechTalents Insights: Do you have on-site team buildings?
Mikki Kobvel: The engineering team is pretty fresh. A few people joined recently, only two months ago. Honestly, we are working a lot, but developers don’t mind because there is no micromanagement. Again, with AI, you can generate a lot of productive code. Timeleft has quite a unique product setup, and it’s very clear when you bring the value.
One initiative we were thinking of doing is a hacker house, so we can organize a weekend or a week to test new solutions. I think we will do it once we finish our final hiring cycle, which will probably be the end of Q3. There are a lot of fresh people, and a lot of things are happening right now. And people are spread across different regions, so it’s going to be a bit challenging.
We try to minimize noise for engineers as much as possible so that they can stay focused on the task at hand. At early-stage startups, everyone asks the developers directly for things. When you ask the developer directly, they jump from something assigned by the Product Manager to immediately do what is requested by the CEO, CFO, or whoever. Then the developer gets good karma from this specific person, but then the CEO pressures the Product Manager over why something is not done, and then they strain developers. It creates this continuous pressure because you have to talk to different stakeholders and respond, and you want to be nice, you want to deliver something, and then you keep switching the focus. That’s one of the big challenges lots of young startups have, including us.
TechTalents Insights: This seems like a sensible practice, especially because sometimes non-technical people aren’t aware of the negative impact of asking developers for things.
Mikki Kobvel: Have you heard that fable about the scorpion and the frog? The scorpion asks the frog to be carried through the river, and the frog says, “No, I’m not going to do that because you’re a scorpion; you’re going to sting me.” And the scorpion says, “No, I promise I’m not going to,” the frog is like, “Ah, you’re going to sting me.” And then the scorpion promises again he won’t do that because it would doom them both. Then the frog is carrying him through the river, and the scorpion stings it [dooming them both]. And the frog is like, “You told me you wouldn’t sting me.” And the scorpion says, “What did you expect? I’m a scorpion.”
That’s what I think happens when formal processes aren’t followed; that is, everyone is really passionate and wants the best for the customers and the business but does realize the impact of jumping from topic to topic and how it causes issues later.. So, you need to have a very strong engineering leadership to make sure you build the proper framework. I’ve been building engineering teams for many, many years for huge corporations. I always meet people with some experience with software, so, usually, even if they are not big fans of Jira and processes, they understand where it’s coming from. At Timeleft, we had to build a powerful wall because people love the product so much that they feel their idea is so important that it needs to be implemented right now.
Sometimes, you have to go there and direct the conversation outside of DMs; you say, “Create a ticket, and I have a slot next week, and this person needs to be in the loop, and we talk all of us together.”
Otherwise, they don’t understand it. Because they want the product to be successful, it becomes this scorpion dilemma. They want the product to succeed, but they end up harming the product. Unfortunately.
TechTalents Insights: Talking about the app, as you say, everybody’s very passionate about the app. How does your team use the Timeleft app?
Mikki Kobvel: Our app is one of the enabling points, but the product’s core value is not in the app. The app is an enabler, providing consistent access to our offers. And the offer is the real-life experience.
Right now, the app is not rich in features. We don’t want to overcomplicate the app as simplicity can be a benefit. We create value for customers during the dinners. We have a lot of plans to create even better and better matching. That feeds our algorithm, and it helps us create better real-life experiences. But outside of that, what doesn’t lead to the experience is nothing we want to do right now because the whole point of Timeleft is fighting loneliness. When you stick to your phone, it doesn’t serve this purpose.
Of course, there are some ideas on how we can improve the chat so you can chat here and there — still, at the end of the day, we want you to have a great dinner experience. People book the dinner, and then they follow up with feedback that we use to improve the experience.
TechTalents Insights: What about the matchmaking? How does it work?
Mikki Kobvel: There is a mobile app, and there is an algorithm in the background. So, the algo is interesting because we think we know who we want to connect with. In reality, you need to have certain interests in common, but there is a lot more to that. We may have way more in common than we imagine. When two people with completely different incomes sit down at a table, but both have spent a year in Cambodia, I can guarantee they will find so much to talk about that they’ll forget everything else — whether you have three kids or I am unemployed, we share a common experience that holds importance.
That’s why dating apps are not so good, and that’s why Timeleft is much better: because we tell you to take a seat and see if the magic happens — of course, we don’t guarantee it will happen. But sometimes people underestimate how many things we have in common with other people.
It’s usually a better experience when you don’t have any expectations. If you have a lot of expectations, like, “Oh, I want a fancy dinner, and I want to have all people of exactly my age, and I want to have this and that,” — I think we already can see that, on average, people with no expectations have a better experience.
On average, if you trust the algorithm, it will do a good job. Of course, there are corner cases; sometimes people cancel, and sometimes the energy goes bad, but on average, it works well. People make friends; they have good experiences.
Then now, our questionnaire has constraints, and we can see that if we remove more of those constraints and learn more in a holistic way, we can move even further. That’s the direction that we’re exploring right now. Of course, it requires a bit more time investment, and we need to be careful because it’s already working well. But that’s what’s hot right now in Timeleft.
TechTalents Insights: There used to be individuals organizing dinners with strangers and selling this as a service, right before Timeleft took this market by storm. Timeleft pushed them out of business, among other reasons, because you have an algorithm.
Mikki Kobvel: Yeah, and the more users we have, the more we learn from them and their patterns, and that’s the biggest value we have in the long run. The more we do dinners — I think 20,000 or 30,000 people are meeting every week — the more we can understand what’s gonna be an even better table for you next week, the week after, and so on.
TechTalents Insights: Besides the Wednesday dinners, Timeleft is launching the Tuesday dinners exclusively for women. Can you talk about this launch from the technical side?
Mikki Kobvel: We have our special way of matching people. It’s a game of constraints. It’s actually easier for us because we can remove the constraint of needing three guys and three girls; we need six women, and now we allow a bigger pool for the algorithm to figure out who would be the better match.
So, the fewer constraints we have, the better the experience we can deliver to the users who come to the dinners. That’s why we talk about these LLMs in the future to try to find a way to have fewer constraints and just trust the algorithm, removing all those things and just making sure that people come with no expectations.
TechTalents Insights: And so, what is next for the tech team?
Mikki Kobvel: We have a big internal focus. We are building a back office right now. Many fun things are happening behind the scenes with the restaurant management. The magic is in the background. We have a smart algorithm matching restaurants with people because that’s another part of the equation. Managing operations is a pretty complex journey that’s invisible. From the tech standpoint, that’s an interesting task to do. There will be more offers coming to different groups — now it’s dinner, and soon it will be stand-alone drinks, so you can also go to a bar.
We will be testing other things for different types of offers. On the technology side, we will need to structure the data better, so we probably will have another hiring cycle to expand the team.
TechTalents Insights: What advice would you give to a startup looking to build a high-performing tech team from scratch? Of course, it may depend a lot on each business, but generally speaking.
Mikki Kobvel: Timeleft is such a unique, corner-case scenario. It’s not a heavy tech business yet. There’s a lot of operational efficiency; but we are getting there from a technical POV. There is a value in the algorithm and stuff like that. It’s impressive what they managed to accomplish with the low code, and I think it’s a great lesson for most people building something non-tech.
There are products in which tech is an enabler, as is the case with ours. And that’s where you should try to — especially now with the AI — generate code and do very hacky things to get to the value and to get revenue coming. Most engineers usually over-engineer, especially if they have an engineering background. You shouldn’t go fancy if tech is not your core value proposition. If your core value proposition is tech, of course, you need to invest in technology and deep technology and build around that — for example, if it’s Segment.io and all these companies where everything revolves around technology. I think in many startups, you can just copy Timeleft’s formula: try to invest less in your tech and build a solution around something where the value is. Always keep in mind where the value is, how to deliver it, and how tech can scale it — instead of using many different technologies that are not focusing on the user.
From a technological standpoint, for startups, Supabase and Google Cloud with Firestore are great solutions. It’s just my generic to-go thing. Supabase is a transactional database with a very easy UI. So, if you need something transactional, you can do it there. Google Cloud, specifically Firestore, is very fast if you have a UI-only thing, and you can read and write the data directly from the UI. You can go pretty far with that. For the mobile frameworks, I don’t think I can recommend anything because there are different things. You have Flutter, you have React Native; you need to know your users. If users are coming because you have a fancy UI, then maybe you should go with Native just because you need a smooth experience. If you don’t need a smooth experience, use Flutter.
I was sitting next to Max in the office, and I did a few interviews with people managing restaurants to know how to prioritize features in our new back office. I used the cloud as a net, generated the UI, deployed it, and asked my engineers to configure something. Then, the next day, we had a demo. But it could be instead that the product manager gathers stakeholders and talks to me. I give him what is possible and not possible, and it becomes ping pong. Then, you create a design, and the design is reviewed. Then people say, “Oh, it’s not how I like it,” and then you do iteration, and then you build it. Then you’re like, “Oh, it actually feels a bit off.” Then you do it again, the whole cycle. But now, with AI, the cost of generating a zero-shot prototype is so low that engineers who understand the business very well can go and talk to businesses and get solutions straight into the same conversation. And it enables so much speed.
I think this will be the future, and I’m looking for engineers who can ask the right questions and challenge the business. Because engineers who are like, “Oh, you tell me what to do and I’m going to do it,” they are not useful anymore.
If I know something is wrong with, like, let’s say, operations update in restaurants and that something is missing, I want you to fix the problem with the code being generated directly on the spot. But if you need another person between you and the business, we have an entropy problem because of information going back and forth.
So, we are still growing and hiring engineers who understand the business and ask the right questions, and that’s my direction because I think that in five years, we will have very few engineers who just do engineer work. Everyone will have a business layer in their head — understanding the domain knowledge and asking the right questions.
Subscribe to our newsletter
Enjoying our content? Subscribe to the TechTalents Insights newsletter and get our best articles and interviews delivered directly to your inbox. Click here to join the community!
