What 9 Years at BearStudio Taught Me

BearStudio is a small web and mobile development studio whose mantras are “#NoBullshit” and “From idea to production”.

• NoBullshit, because we have always said what we think openly, whether to clients, as part of our advisory role, or to developers, with the goal of improving as much as possible.
• From idea to production, because we support project owners throughout the entire lifecycle of their project. Whether they are new entrepreneurs or clients from large companies, the goal is to provide our clients with the agility, knowledge, and resources of the company.

I joined BearStudio less than a year after it was founded, when the team was made up of the CTO, the designer and front-end developer, and one or two back-end developers. Such a small team makes it possible to work directly with the different members of the team, but also to be in direct communication with clients.

It therefore becomes easier to learn from everyone and from every role: designer, front-end developer, back-end developer, infrastructure, CTO, sales, etc.

I will therefore try to summarize everything I have learned about entrepreneurship and software development during these 9 years within a team that grew from 3 to 30 people.

Test Your Idea and Validate a Market

When developing a product, we often have a very clear vision and well-defined expectations, which leads us to form an idea of what the “perfect” product should be. In my opinion, this is why too many entrepreneurs wait until they have a perfect product before launching it—which is, most of the time, a major mistake.

1. It’s expensive: the more you aim for a perfect product, the more budget it will require to develop. Considering that the daily rate of experienced developers in France is around €500 to €600, and that some features can take 5, 10, or even 30 days to build, a perfect product quickly becomes very costly.
2. It takes time: beyond the cost induced by the development time of features the application could do without, it also means that this time is not invested in other priority areas to grow the business around the application.
3. Experience has shown me that trying to predict what users will do with our product is a lost cause. Of course, I’m talking here about the big picture. I’m not saying that when building a flight ticket booking app, users should be allowed to use it to book concert tickets. I’m simply saying that an entrepreneur and their team do not represent a large enough sample of the population to understand the needs and habits of all users, as well as the opportunities within the business targeted by the application. It’s by putting the application into users’ hands that real needs emerge—and there’s nothing better than a need expressed by a user who is willing to pay for it.
4. What if there is no market in this application domain? The best market study is to offer the final product and see whether users show up. But there is no point in having a perfect application. That’s why it’s important to aim for an MVP (Minimum Valuable Product).

Organizing Your Project to Move It Forward

As I mentioned earlier, there is always a lot to do when starting a project, whether we’re talking about
entrepreneurship, intrapreneurship, or simply client work.

1. Start with mockups or wireframes: if there is one step that helps minimize misunderstandings, it’s the mockup phase. It serves both as an expression of the need and as a thinking phase to understand how the project will work in practice. It is simply inconceivable to ask developers to start building an interface without having a model to rely on. Not creating mockups—or at least wireframes—is the best way to end up with an application that lacks consistency (with the initial need, from one page to another, visually, etc.). If you are an entrepreneur, mockups also allow you, with a much smaller budget than development, to assess the quality of your provider.

2. Break tasks down: just as the task “Finish the project” is not acceptable as a single task, features like “develop the user dashboard” or “set up the payment system” are also not granular enough and must be broken down. This is the best way to properly estimate the hidden complexity of a task and avoid costly overruns.

3. Estimate tasks: whether you’re working alone or as part of a team, for yourself or for a client, it’s better to estimate tasks before starting them. The best way to miss your goals is not to set any. In other words, the best way to exceed the budget is not to estimate tasks. Note that at each stage of the project, estimates can become more and more accurate (wireframes/mockups → preliminary design → detailed design).

4. Start by delivering value: what if you could build your house by finishing your living room in two weeks so you could live in it, instead of having the walls of the entire house without windows, paint, or furniture? Sounds unrealistic? It isn’t in application development, because it’s often possible to start with the feature that brings the most value, test it, and have it tested. To give a very concrete example, when I created TraveledMap, I started with the trip presentation page, even before being able to create a trip. I used “hardcoded” trip data (JSON format). Doing things this way allowed me to:

   • present the trip I had just returned from to my family, which I wouldn’t have been able to do if I had started with trip creation, since they didn’t care at all about how a trip was created;
   • demonstrate how the app worked to friends to see whether they liked the idea, and gather their suggestions on how they thought the app should work;
   • define the data to be collected when creating a trip so it could then be displayed on the already existing page;
   • motivate myself to continue developing the project, encouraged by the feedback from my demos.

5. Finish tasks before starting new ones: it’s important to keep in mind that as long as a feature (or bug fix) is not in production, it has no value for the application’s users. You therefore need to agree on a “definition of done” and put the right tools in place to ensure tasks don’t remain “in progress” forever, but regularly move to “done”. I recommend Kanban boards for this.

Mindset

1. See the beginning of a collaboration as a period of “seduction”:
   Seeing the start of a collaboration as a period of “seduction” means keeping in mind that, at the beginning of any collaboration (client / service provider, for example—but this also applies between developers or in a business partnership), trust still has to be built. When I talk about a “seduction period”, I’m referring to accelerating the phase during which trust is established. Here are a few tips for that:

   • Be impeccable in communication (be responsive, concise without under-communicating, don’t hesitate to share screenshots of results, make sure you’re clear, etc.).
   • Be proactive and a source of proposals.
   • Be very rigorous about commitments (task updates, etc.). Of course, this doesn’t mean you should stop doing all of this once trust is established, but it’s extremely reassuring for the other party to know they can rely on you rather than having to chase you.

2. Fight impostor syndrome:
   From the very first months of my end-of-studies internship at BearStudio, I found myself in situations where I felt like I didn’t belong. When I was entrusted with managing the main project in the CTO’s absence, for example, or when I went to provide consulting for a telecommunications company, or when I was asked to prepare conference talks. What I take away from these experiences is that we all have different backgrounds, which means we always have things to learn. There’s no need to have 15 years of experience to share your experience: first, because you’re offering a point of view, and second, because there will always be people less experienced than you who are willing to listen to what you have to pass on.

3. Adapt to your context:
   Even though this advice may seem obvious, I’ve witnessed hundreds of decisions made by “following a ready-made manual”, without adapting what was learned to the actual context of the situation. One of the most striking examples was several years ago, when a company hired us for a project because its future depended on it and it was unable to meet the imposed deadlines. While working on the project, a colleague and I realized that developers kept trying to produce perfect code (DDD, hexagonal architecture, microservices), performing reviews with hundreds of comments, while the survival of the company depended on meeting those deadlines. Adapting to your context here means understanding that there’s no point in producing easily maintainable code if there’s no longer any code to maintain—because the company is gone.

On Recruitment — and How to Get Hired

Throughout my various missions at BearStudio, I’ve conducted dozens of interviews—whether to recruit interns, full-time employees, or even to handle recruitment on behalf of clients. Here’s what I take away from that experience:

1. Logic before technology:
   Logic matters more than knowledge of a specific technology. A developer will always be required to use skills that go beyond the technology they were hired for, which is why it’s important to test a candidate’s logical reasoning. As Montaigne put it, what we should favor is “a well-made mind rather than a well-filled one.” To that end, don’t hesitate to give candidates a technical algorithmic test.

2. Never rely solely on the résumé:
   I’ve interviewed candidates more than once who had twice as many years of experience as I did, yet were unable to solve simple problems at a third- or fourth-year university level. Trust me—it’s better to find that out during the interview.

3. Also test the target technology:
   Although I strongly recommend testing logic first and foremost, it’s still important to assess the candidate’s level of knowledge in the technology they’ll be working with.

I’ll be writing an article soon about interviews to share my experience both as a recruiter and as a candidate.

Conclusion

If I had to summarize, in just a few sentences, the lessons I’ve learned over all these years, it would be as follows:

The world of software development is one where skills are highly heterogeneous. You can sometimes find recent graduates who outperform developers in their forties with 15 years of experience. You’ll also occasionally encounter “experts” who promote solutions that don’t work, or who lose sight of the reason we do this work in the first place: moving projects and businesses forward. And even though solving technical challenges is sometimes part of the job, we shouldn’t create those challenges purely for the love of complexity. In other words: adaptability matters—and for that, a well-made mind is better than a well-filled one.