 So, we'll go to share some personal experiences, it doesn't mean that things working for us will work out for you, I hope not. But at least we show you some things during our history, since eight years now. So let's start by some personal history. I first founded a company which was quite similar to Adyx in 2000. I was 20 years old, and I failed it in nine months, so I get to pay IRS taxes for years and years, and then a friend of mine had a good idea to launch a video-based booking site for luxury apartments and hotels in Paris, which was quite a good idea by the time there was no video, and that was actually for a reason, because if you look at nice hotels' rooms with nice, big-angle photos, it's just like a dream, so you reserve it. And if you look with a small video, you actually realize that this room for 1,000 years a night is just a 10-square-meter small room, and you'd never buy it. Unfortunately, we noticed it after we launched the site and after filming 250 hotels. So four months after releasing the website, we just realized that we cannot get any money from that. So it was quite good failure. So we decided to pivot. By the time it wasn't pivot, it was just failure. But we still decided to pivot because the good thing is that actually by totally random, we selected Drupal, Drupal 4.7 at the time, to create this website, and by the time there was only about 10 companies in France doing Drupal, so we said, a good idea, let's try to sell Drupal sites. So the first time we called our company E-Drupal, which was quite good in cold call, saying, hi, we are E-Drupal doing Drupal, quite normal. Then we got a cold call from Dries saying, hey, guys, it's cool to call your company E-Drupal, but actually you cannot because it's a trademark. So we was doing like, oh, okay, we changed our name, second failure. But the thing was we was thinking about names and names and names, how to call a Drupal digital factory, factory, websites, whatever. It was spending hours and hours of brainstorming. And then we called a friend of ours who is big in Hong Kong and who is working as a marketing director for Colgate. And he found the company name in about 27 seconds. He understood that we were doing advertisements, so Jan Maxim and Yax was born. So by this time, now we do 12 million's revenue this year and we are quite happy. We have 12 offices all around the world and opening New York since a couple of months. And we have very good clients. We are very happy with them. But before getting there, from the very beginning we learned some hard-learn lessons. The first one was that actually the things you don't have to do and you don't need when you start a company, you don't need a website, we didn't have any. You certainly don't need a business plan and you don't need marketing, business cards or reporting because when I see young companies, they all care about, okay, how my business cards look, what is my logo, what my name, and all this is just bullshit. You don't need that. The only thing you need, there are three things you need. First one is sales. You need contracts and that's the only thing that is important. The second is obviously sales and the third one is sales. That's all. That's all the rest. And the thing is if you don't have any references because when you start a company, you cannot just pop into Johnson & Johnson and say hello. We are two here. We're doing Drupal websites. You want us to work with together. So actually you can, sorry, I shouldn't touch that, please make it work. Yeah, thank you. So actually, as you saw, many logos of famous, it should work now, yeah, in this. Actually, it would be quite complicated to talk about failures, to fail projects and slides, but it should have worked. Thank you. Please, assistance. Thank you. Now this is another important lesson, having backups. Up, no, not my, thank you. Thank you, Rony. It's okay. We are over. So as you don't have clients and you cannot show the things you've done, the good thing, what changed our growth, it was going to see these agencies. They have a lot of creative guys and they do very bad Drupal at by the time, very bad Drupal developers. They are not using this technology. They don't have in-house high-skill developers. So we actually called them and it was saying just we did that, please don't want to give us some business. And actually they do because they're searching for cheap, small companies to subcontract their development tasks. They don't want to do development because they have creative. So this is how you gain references, actually how we gain references and then you cut them and you go directly to this big reference saying actually we did your website. Check your NGA, you never know. But actually you go, you say that, but shit happens. And then you say that we actually did it, so do you want us to continue? And this is how it works. Obviously after that, they will never send you any businesses again. But that's life. So the second important lessons we've learned as we're doing mainly fixed budget projects is the art of estimates, which actually starts with just find out putting numbers randomly on a sheet saying, okay, looks like 20,000 projects, it's okay. And then you end up paying 45,000 to your developers to end up with 20,000 projects. So what is really important is doing as precise quotes for fixed budgets as possible. We from what I know after eight years have the longest, the largest quotes on earth. I mean, we have quotes of 200 lines. And it actually works because of several points. You can easily negotiate if somebody sells you, I do front end for 20 days, and you actually say why not 18 or 16. And it's quite complicated to argument that. But if you are selling a line for 0.5 days, nobody say, maybe 0.4, it's a better number. But so this is easier to negotiate. And another problem with fixed budget is that once you started doing, they all want more than they buy. So this is normal. This is how clients work. So then having very detailed quotes gives you a very simple way to negotiate. It wasn't in the quote, my quote is extremely precise, pay more, it's an evolution. And it looks good, it looks professional, like, oh, many numbers. So you see that some numbers are weird there because we actually apply on project management and QA work of percentages of development, which is quite standard. But we obviously adapt these numbers based on client we'll talk about later. But sometimes you cannot do that because the scope of the project is absolutely unknown. And then we actually pick up one from not one company, it was old one company. Now it's, I don't know, Wondercrowd maybe integrated, I don't know. They have a very good thing of uncertainty factors. So they actually pick up the same lines we do. But instead of putting this precise number, we put a precise number with an uncertainty factor. So if you don't know anything about the perimeter, so you put one and it gives you a range. So per line range. So at the end, you end up with a range. So client actually tend to accept that saying, look, your scope is uncertain. So you have a range. And it's quite reassuring for them saying you have a range because it's quite of shows you that you are aware of risks, aware of the reality of the projects. Then you have to remain inside the range. This is a problem. Another thing is what happens during the project because you have to keep track of change requests because this happens all the time. You have a year project, you started with a fixed bid and then your changes. So as you are not in time and material, there is no problem in time material. I mean, we don't talk about that because time and material just bill. You have to keep track of all the small changes. You can send quotes each time they want something. They change a button, 20 years, 100 years quote. That's not sustainable on a big project. So we keep track of the shared document. We have total credit, total debit. So each time they ask something, we make them validate on this document. And then we just add up numbers. So in monthly rate or each quarter, we just bill the amount and we clean up this table. So another thing we learned because we was working with agencies to just send you stuff without RFP, just I need a website, 10K, 20K, 30K, OK, let's go start then. Once you work directly with big clients, you enter the RFP process. And it's a good game. I like RFP process because so this is kind of numbers we have. If we get an incoming bids from some client calls us saying, do you want to participate? Our average winning rate is about 70%. If we call clients and we are doing cold calls or marketing efforts or we are outbound, then it drops to 30%. So how different? At the end, we all go through RFP processes. The problem is that usually, from what I understand, I don't know why it's like that, but from what I understand, when you call them, they accept to put you in the RFP process, but they already have their preferred client or the preferred set of vendors that they want to work with, which actually happens when they call you. So it's important from any possible way to create this relationship and to give trust to your potential client. So one thing we learned also is you have to, during your answer, you don't have to talk about you at all. This is eliminatory. Each time you explain how beautiful you are, what good your references are, how your methodology is, you usually fail. So instead of sending like 100 pages of description of how good you are, it's better to show you examples and details. Example, this is way better, and I have a client who actually saw this during the RFP process here. It's way better for a client to show you back office interface saying, look, we did this, this, this, this, and this, even if it's not very beautiful, but it's very detailed. Rather than showing something like this, oh, we did get one. So because the clients are not always able to project to your project inside their project, so you have to do the job for them. Take parts of your projects and show them a concrete example. And the more you go into details, the more you show your application, the importance of this RFP for you, and the understanding also, oh, I know, we did that before. Knowing the client's business is not important things. We now never go to an RFP or a presentation or a session without trying to understand exactly what is the business of the client. Even if it's only technical migration from type of free to Drupal, or from other B to Drupal, or from whatever to Drupal, we still, during the process, try to learn as much as possible who is their competition. Is it a complicated business? What are the sales channel? Why? Because during the conversation, you have to create this small link between you and the trust link within your clients. And knowing their business, it's easier. When I go to see a publishing company, and I bring in with a journalist, for example, so they talk the same languages, same small jokes or same sad stories. This is how it helps you to create this trust. So this is an example. When I come to a publishing company, I show you a look. We know how to build your workflow. Look, we did a very complicated workflow for another publishing company. So it shows you the level of your expertise. Another way is changing the game. I give you a story. We received a very large public RFPs from the Ministry of Health in France, very large, multimillion public RFPs. So we was against Accenture and Capgemini, very large companies. So the initial thing it was create a portal to aggregate all the health care information around different producers. They have hundreds of public producers of health information, like e-cancer, orbital.gov, et cetera. So we aggregate and we get one portal named Santé.fr, which is health.fr. So we know that if we were competing on portals with big companies, we are sure to lose them because we are small and we don't have all this process. So what we actually did, look, this is bullshit, don't create a portal, it will never work. Let's create a Google Now of Health, an app, totally different thing. And it actually worked because it was a specific public process buying process when you meet the client several times during the process. So they actually changed the RFP and they redo the RFP with our recommendation, creating an app, health.gov, et cetera. So now the other, the big guys were in trouble because they didn't understand why the RFP changed from one round to another. And because we actually prepared the RFP for that, we were ready to answer. They had to change everything. They was answering on the portal team and now they are answering to an app team. This is a way to change the game. We actually won the project and we are releasing it in the end of November. There are many ways to change the deal. For example, another company came to us to say, look, we want to migrate one of our website to Drupal. We said, no, you should migrate all your website to Drupal, even your boutique and your e-commerce website. So again, we changed the RFP because the other guys were not, there was all very good in creating corporate website but have no experience in e-commerce. So by changing the RFP, we changed the scale and the competition. So this works very well. Also, you have to keep in mind specifically when you have very large RFPs, you usually have to fill up hundreds of lines. Do you do the compliance metrics? And do your solution do that? Yes, yes, yes, yes, yes. Actually, there are guys spending hours and hours just feeling right in comments column. Nobody read that. It's actually just to calculate some numbers. Your still RFP process have to convince the guys. So the most important is not the exactitude of your RFP, except for public because then you have to be very careful with rules. Don't play with the rules. If you are confident, you just have to convince the guy that your solution or your enterprise is better than the rest. So for example, another RFP for Sephora, we was again competing against very big companies and there was like 300 lines to fill and we answered this RFP in 24 hours because I forgot this RFP. So in 24 hours, we obviously cannot respond to all the things. So we actually produced 60 slides of just talking about their projects and how we did it and we won again. Even if we did not feel and our compliance score was zero out of 10 rather than others get 10 out of 10 but still won because actually they feel comfortable with our team. And another big question specifically, the price. We noticed that price is absolutely never an issue. You will never lose a project because of price. I mean, important to explain to you, if you explain to your client, you all sell heroes, some of you, you all sell time. If you are in times of material, it will be your rate card. You probably hire the same developers with the same salaries and same location so your competition have almost the same rate cards so it's never an issue. You will net in the same town, you not have two companies having different rate cards on same resources because they are the same. If you are going to fix budget, here you have the big price ranges. Somebody will answer 20 case or will answer 200 case for the same project, same RFP. So here you have to be very smart in explaining how you build up your estimate and what is included and what is not. Obviously you can option the maximum things to lower the total number but also you have to explain everything you do in details. So if they compare, I have 200 lines quote here and I have 10 lines quote here. So obviously I don't buying the same. So they ask them if they start to ask you about questions about price, say them, okay, did they do that, did they include that, did they include that and then they will start to compare and the numbers will grow up on the other side. Another good approach we learned is to being expensive, very expensive from the first shot. During that, you actually, if you are twice the price of the client, if it's a very good insight because if you are just in the budget, plus minus 10% is my price okay? Yeah, yeah, more or less and then you'd get no information. If you are twice more expensive than the rest, you call them, you are mad, you are twice more expensive, okay, no problem. So you know the price, you know the price of the others. So then you can say, oh, sorry, we added some things. This is a good way. Another important way, it's Achille in the background because Achille have a problem with his. So it's easy to kill. You have to know your competition. So you're going in an RFP, the most important is not even the budget of the client. You will understand that based on their size and the quality of the RFP. It's more to understand who against who you compete. If you are competing against editor solution, you will push on open source. If you can competing with small companies, you will have to push on reassuring how big you are. If you are fighting with big companies, then you have to push on flexibility, et cetera. So you have to adapt your answers based on who in front of you you have. It's not easy to know who your competition is, but again, all tricks of calling guys, saying by who is in front, how many companies, checking what they did previously, who did their website previously, who did their intranet, because obviously they will work with a small group of persons. Or you can just check your classical competition, the references and see if they have already them in their clients. Obviously you have to be extremely careful with larger public RFPs because all these tricks will never work later. So you can answer yes everywhere, but you can say yes to very dangerous thing that you'll have to assume later, like 24 hours support in five languages, or 9.9 web content ability, or the last one, average response time of the web contents must be less than 20 milliseconds, 200 milliseconds, which will be quite difficult to obtain with Drupal, specifically with Drupal 8. So, HR. We learn a lot of things with, because we are so distributed, we have 12 offices, so we don't have all these big office places, everybody can exchange. So we learn some lessons here too. For instance, the culture is the most important thing we have, well it's obvious to say that, but you don't realize that because at the beginning we were thinking we need rock stars, so we was hunting on Drupal camps, like I want the top contributor, I want this top rock star there. This guy works for Capgeminaya, I want them. And actually this is less important, culture, because it's something that you set up at the very beginning and then it's continued to spread around your company, so if you plant a bad seed at the beginning, you will end up with a big piece of shit. So, plant the good seed at the beginning. So, if you can define your culture, then it's okay, just we have this, I just make the exercise, so we have humor and sarcasm to somebody who knows us, will know that we are very humorous and very sarcastic. We love parties and events, I don't remember what happens yesterday night, but anyway, but we still focus on results and quality, not time, results and quality. Whatever happens, we end up with a project. And finally we have autonomy respect, we don't have very high level, we are very flat company, so we let guys doing whatever they want. And cultural melting pot, that's something they find us, we have guys from India, from Ukraine, from Russia, from whatever country we have France, Syria, yes, and many others. So, reporting, something that we also noticed is that checking that the guys doing their job is, at the beginning it was very scared because guys was all working remotely, so we was obsessed with guys logging more hours than they actually do and they are doing Facebook or whatever, so it actually was a big mistake. If you give autonomy and responsibility, people do great job, you don't have to check and report, we will have some reporting and we'll show you them, but autonomy and responsibility is the most important things. You actually get way better results if you don't over control and micromanage guys. And actually the reporting and reviewing things, we failed to set up this because as you're growing, we're growing at 30% rate each year, because so the staff going, so you never have time, you're always, everybody's always on the staff, they have overtime and you don't have time to do reviews, reporting, so we cut it off, but instead we started since some years to implement some automatic tools because we need some control over, we are almost 300, so we need some control. So first thing we implemented is a project alert. Everybody can use it, they have access on old screens, they can just put click on it and say, I feel an alert, everybody in the company can say that, so we don't have specification, we have over budget for quality, whatever, and this alert is immediately treated by the top management, we have to accept that. So it's very simple, and the main problem was that people was at the beginning scared to do alerts, and we'll get fired if I have an alert saying that my boss is just a piece of bullshit not doing his specification. We said no, we fired nobody and then we fired the guy anyway, so. No, but it's a very important tool and it works. Because usually the problems, you will see them at the very low level, QA guys, developers, not on the project manager. Project manager usually say I manage everything is okay and actually it's not. So you have to get this bottom top alerts. Second thing we have implemented is a dashboard to help project managers to supervise their hours, what was sold, what was done. Well, it's quite complicated, but for those who use it is we have tasks and everything, so it's actually we have to be adapted to each of your company. But the idea is to say we offer a tool because we don't do reviewing or reporting, we offer a tool to self-control the project. Okay, where I am, what I did, how many hours I've spent. And again, I took an example from a project that somebody knows and the client can see in this room that we do way more hours than we actually sell to them. So another, this is a continuous screen of the previous tool, so we have some big information here, top important information like total hours by users, so we control who works, how many times, top time consuming tasks so we can spot bottlenecks in the projects and we have tasks with no time logged inside so that means that, or it's very important for us to track everything, so we ask to everybody track their time in the right task, not during eight hours of working, we ask to do more precise. But so we have a control here to see if there are no tasks with no time, that means that somebody work on it but probably never logged. Then bonuses, we've experienced a bonuses system, we still have this bonuses system, but actually it absolutely doesn't change the way of the project works. So it's written everywhere, there was scientific experiences confirming that but you still want to, if I give you more money from the margin, you will do better projects, no. Motivation is more important. If the guys are motivated by a project, they will do great job. If there is a shitty, boring project, regardless the money, they will do shitty, boring job. So, but obviously money is important to keep or recruit new personnel. If you don't pay you guys enough money, they will leave, that's normal. But bonuses system, it never worked. I don't know why, but we have tried all the combinations possible, no changing in project setup. And of course, we also have to bend the rockstar's assholes. I have a story of a partner or a similar company. I cannot name it obviously because we don't treat people as assholes. But they have a rockstar with them, but he was really an asshole inside the team, like really, really bad with his team members. And I've talked with the boss of this company saying, you should fire him, but he's a rockstar, he's a very good contributor, and I said no. And actually it was very bad for them because people inside the company started to leave saying why he's still here, I don't like to work with them, if his bad spirit starts to spread like a cancer. So as soon as we got spotted in an asshole, we fired them immediately, even if it's very good. And we fired a couple of guys who was extremely good, but real assholes. Get rid of them, you need to create a team. The team is way better than individuals. We still have some pain is resources planning. It's a manual, painful process. Yes, this is the image I think of when I think about resources planning. So we don't have a magic tool saying that this developer will be free in two weeks. We have some things manually, we review all the project managers, but still it's not automatic because project slips all the time, they have shifting in planning, client is late. Well, we don't have the magic formula. So if you have, please. Finally, the money, the finance. So we, until I would say three, four years ago, we was able to control everything by over viewing things. I know here the client will pay, the other project will be ending. We got 100K here, we still have to spend this service. It was okay. One time it happens in a couple of months we lost completely control of what really happens inside the company. It was too big, and this kind of spreadsheet's working, it doesn't work. So we implemented in a very short time period a lot of reporting stuff and KPIs. So we actually, this is a KPI we track inside, we have production ahead. Why it's important? Because when you do time's material, your production is actually your bills. So you invoice weekly, so what you invoice is what you produced. When you do fixed budget, imagine you sign off a one million year project over two years, what is your production? You never know. If you are sending 30% invoice at the beginning, 70% at the end. Well, it's not like that, but imagine. So your progress on this bill is not understood how much you produced. Margins is obviously the most important fixed budget because you don't know them at the beginning. And bookings are also important to see what's your next year will be. A number of active clients, this shows you if you are really growing, but it's important indication of how you are growing. Or you are growing with less clients, with bigger clients, or you is multiplying small clients. Average bid is like average cart, it's important also. And average invoice shows you how good you are on invoicing. So this is the software we have. So we have Salesforce for leads and opportunity pipes. That's all. Everything goes then. We have also Open ERP, but now it's called although they changed the name so, I don't know how, let's call it Open ERP. And we'll have invoice and quotes. And we have RedMind for locked hours and projects. And everything, all the reporting is consolidated in the Postgre database, which is then used for Tableau Software BI reporting. Very good software. And some internal individual reporting system. So this is the first example of what I call production per head. We actually asked for each project manager to list all the quotes they have and to see what are the progress on this particular quote. And that is all aggregated. So we have the production per head and the grand total. So we can see if somebody is understaffed or overstaffed or is not producing enough. So we can see what happens. But we also give a tool for each individual to track down everything what happens in their project. So if they access to this tool, they see what happens currently in their project. So they see where they are in advancement, what are the total cost of the team, months per month, and they see if they are good. And there is a left also, it's saying okay, that the margin is okay, if it is red, it's popping everywhere saying, hey guys, guys, guys, you're running out of money. Another thing is in theory, this is a theory about S curves. It shows the life of a project in terms of costs. So it's theoretical. So we tried to implement that internally to see how it really happens in the real life. So we got that. So this is an margin over time. So it starts by design phase. So you work, few guys are working on it. So it's very low consumption because a couple guys, UX designer and project manager. And then you have the development team, the build phase. Then you start to burn much more money. And at the end, you are in the wrong. So you reduce the team just for the backfixing and it's mostly lending. This is the perfect solution and this is how I would be rich. Unfortunately, there are also these kind of S curves who actually reach the zero and then goes down and then I start to pay for the client. So it happens also, unfortunately, this is life. So you have to control and you can control and you can adapt with this tool early and to avoid hitting down too hard. All this bullshit is absolutely useless if you do crappy job. That's just natural. So the most important is QA. So in 2008, I was doing the tests. It was quite okay for a couple of websites we were doing. Then we asked it to developers doing testing. Guys, why are you doing bugs? What was the stupid idea? And then in 2011, we hired QA guys doing tests. And only a couple of years ago, we started asking them to do QA and not tests because what is important to understand that the QA guys don't do testing. They do quality assurance. So they check that the requirements are met and the test plan is think and organize. So you don't have to hire small hands to click on the Internet Explorer 6, 7, 8 and 10. You have to hire smart guys who are able to create a coverage of your projects to create a test plan, how to test and organize the testing. And actually today, we have 20% of our workforce are just dedicated to QA and it's not enough. When we see, we have this also reporting tool which is a test relative effort per project. So you see the percentage of the test testing efforts compared to the development efforts. And you see the range is going from 35% for very simple or standard projects up to 50 and more for complicated projects. I think the first one is an error, but okay, anyway. So what the regular number for doing high quality job is to 50% of your time of development time is dedicated to QA, creating tests, running them, maintaining automatic tests. You have to do a lot of testing to do quality job. And again, quality teams don't have bugs. They actually check what the developers created meet the requirements. So if your requirements are bad, then they cannot save your project. So we have another metric we track in quality is what we call with cost of rework. So the amount of time, the cost of bug fixing, bug hunting, everything related to bug versus actual total cost of the project. So you have immediately, and when we just implemented that KPI we see immediately that the top projects are the complicated project we get problems. And what we also noticed with analyzing all these numbers is that if it is under 15% of the cost you have a perfect project. If you are between 15 and 20% of cost of rework you have a technical debt problem. So actually you're rushing your architecture so you're creating crappy models and you go fast to meet deadlines, but okay. And if you are over 20% that's a requirement problem. So you solve something that was not poorly described bad specification and actually you are redoing stuff again and again and again. It can be a never ending project. So you have to be very careful from the beginning. Project management efforts is also very depending of the client and depending of the complexity of the project, but the most important is it shows the client maturity. If you have less than 20% of project management then you have a mature, digital mature client. If you are over 30, if it's a large organization with tens and tons of people trying to give their ideas about your job, so you have to explain them, no it's not a good idea, no it's not a good idea and again and again. Finally, again for the team and for the client we set up a very simple KPI that I calculated as you may see in Google Docs which shows you the efficiency, the quality and the post delivery quality on the KPI. So actually we track some numbers like velocity variation and reward care for test efficiency, et cetera. In fact, you can find all these metrics that are very well known, you just tap them on Google, you will see how to calculate them. And we show to the client these small gas line things so they can see that we are quite efficient the quality is quite okay but still and the post delivery was very bad but I think because we didn't set some numbers at the end. And for the run, because we also have a support team running the project H24, we have a little bit more KPIs like equality efficiently and SLA. Do we meet the SLA or not? Because if you not meet the SLA then you pay penalties automatically so. And cost variation, so again this helps your team to really understand how they do and it helps the client because sometimes the client say I feel you are not good enough. The quality is not as it used to be and he cannot explain why and you cannot explain why you ask your guys everything is perfect, you ask me everything is bad so you have some real numbers to show them. Sales, obviously we run until 12 with only two guys doing sales. We have a sales guy who is doing cold calls and we have a very smart, intelligent, beautiful guy doing bid management, it's me. So together we reached 12 millions, how? Basically, well the first of all the case studies are the most important source of leads. You can talk everything but what we ask to our clients or potential prospects is to call our clients, existing clients, to spend time, we organize events where they can talk together. We try to just, not to talk about ourselves but talk about our projects, we show examples, right? Then what we also discovered is that cold calls work. We have marketing, content marketing, we have retargeting, we have ACO, we have, well okay, Facebook ads, LinkedIn ads, whatever ads. Cold calls work pretty well. We just last year we get like, I think a million revenue just because of cold calls. Obviously you have to find the right guy and also even if it doesn't work you don't sign exactly, it's still a marketing effort. The guys will hear of you because it's a small community, actually the big organization doing digital, the guys are switching from one organization. I heard a guy called about months ago talking about Drupal. So it's also marketing efforts. On the reverse there I see a lot of agency having account managers everywhere. They have five, 10 account managers, sorry. We don't have any and I think that account managers work for very large organization like Johnson & Johnson, LVMH, then you have to talk to go to advocate about you. But your project managers are way better account managers to do business. They can sell things and as soon as I get the bid I don't talk to the client about sales anymore. I will spend time with them but all the sales process is then in hands of project managers. They are day to day meeting the client, they know better his habits, they know better how to sell and it's way easier to learn and engineer how to sell right manner rather than to salesman ask them to do engineering or understand complicated tasks. So this is how we actually only two people reach to 12 million. Thank you. This is in Gaelic, so I don't know if it's Irish guy here, probably they understand. Hope I didn't write something bad here. And if you have any questions, so welcome. Yes. Well, actually they don't have to report a lot because the only thing they report is logging hours and we only structure our red mind task in a very specific way. But then everything else is automatically gathered because the hours are locked in specific tasks. We have a specific workflow in red mind. So we set up a very specific workflow in red mind. We have a very specific organization of tasks in red mind, epics and user stories and classification of each task. And then they log hours. And everything is automatically generated. Well, actually we don't have so much subjective information. We have this reporting form, alert form. We also have a red mind popping up time to time now. We will have this, how do you rate this project? Like, don't like, but that's all. We don't, the subjective information I gathered after we get an alert or after we check out there is a problem. But all the things I showed is automatically generated. Yes, there is one is advancement of the quotes on the fixed budget to see the production per head. This is, there is a guy going, hello? This is your list. How it takes like five minutes per guy just to see what are the percentage of advancements. That's all. Well, actually it takes a little bit more, but you know. Any other? Yes? It depends, it depends, good question. Half of the bids, I do it myself because I have, I'm doing it for eight years. I'm faster than others. So then you have, we have also metrics on past projects so we know quite precisely. And then, yes, we ask them to time to time to spend half a day to do a quote and estimates. And actually estimates are not the worst in terms of time consuming activity. Creating an answer that corresponds to the client needs this takes time. Filling up numbers, it takes, even if very large it takes a couple of hours. You know, okay, because we know what we do so it's not surprising. So, but creating the answer, this is takes time. This takes me 80%, 120% of my time. So there was another question there. Yeah. Yeah. No, well, it's okay. We, I think it's small. If you speak loud, you're a big guy so you should. It was very interesting. You have to be, it's, the first one is free. 200 lines, yes, sometimes, yeah. Yeah, we will actually, I'm technical, quite technical guys. So I know what, well, I almost, well, I used to know what I was talking about. Now it's a little bit different. But yeah, the idea is to split up to features and templates and small features and all parallel activity, like set-uping platform integrations. You actually extract from the bid everything. If you see one word is SSO. So you automatically know that you have to integrate a DFS, LDAP, and SSO protocol. So you have to set up maybe some CAS server and you write up lines each time. So one single word in the RFP can end up with five lines on your quote. And then second, and then you can go back to the third question because we have one, yes. It was about when we go from five to seven million, five to seven million of revenue, at this point, I don't remember 180, I think. But you know, our structure is a little bit different because we have a lot of QA, for example, so it maybe doesn't correspond to your teams. But as you don't oversee the projects, and I would say, when you are reaching more than 40 concurrent projects in the same time, you're probably losing control. Second question. Okay, about? Yeah. No, we gave 5% of margins to, at the end, we sum up all the margins. So it's more like a bonus at the end of the year. And it's not related to performance or activity. We abandoned that because as soon as you start to do that, people start to working for the KPI and not for the job. So we don't do that. We raise salaries, we get bonuses because they rushed on the project, but we decide when and why. But no automatic things with KPI's because, well, it just didn't work. Yeah, it's quite, yes, we decide at the manager's levels, well, there's margins, but that's all. At the end, you sum up everything. If you lose, if on all your projects, we lose money, so, well, you don't get bonus, but we don't take money from the guys. But if they are overperforming on their projects, so they get some bonuses. But it's not automatic. We don't have this automatic. I know that, for example, in Buffer, the Buffer company, they are very transparent, so they have a very smart formulas of giving bonuses and performance and location. Well, I don't have that. I don't know. It didn't work for us. Maybe it works elsewhere. So, yes. Oh, it was the first time we were starting to hire quite immediately because we need developers. So, but then we actually, as soon as we realize that we will fail, we call this, I remember it was TBWA and publicists, saying, hello, we do Drupal, and we are in Drupal. It was easy. And then they receive it because Drupal is cool. And then we spent two hours and they gave a test project, both of them, small projects, 7K or 8K, I don't remember. And we started like that. And then, as we performed well on the first iteration, they give more project and they have hundreds of small projects they don't want to do themselves. So, they just give it to the cheaper bidder. So, we were, at the time, were cheaper. So, we gathered all this money from them. So, well, small money, but at the time it was okay. Oh, yes. I compete against everybody. No, I mean, no, actually changed. We started as a Drupal shop, competing against other Drupal shops and actually taking some businesses from agency. Now, obviously, there is two steps. We have two levels of competition, Sidecore and Adobe. Oh, sorry, I have a meeting. No, I don't know why, but okay. So, yes, now we have two level of competition. The first, Adobe and Sidecore, all the time. They are, we won against them, C4, we fail against them on other sides. So, it's a constant and very hard competition. They are very performant, editor, all integrated. Aqued tries to help, but, well, not so easy to help with marketing cloud, for example, for Adobe. So, Adobe is on one level, it's a big competition. But, on the other side, we also have to compete with agencies, big agencies, because we have now creative guys inside and we change our logo for those who know us since several years. So, we're now also moving from Drupal development team, but also to a consulting, UX and design things. And the path is where we took is to going not to doing websites anymore, because, well, we do websites, obviously, but it's not our core business. Our core business now is doing enterprise application, because it's something where, on the left, we have Capgemini integrators, but they do shitty job in design and UX and ideas. And on the right, we have very nice designs from agency, but they don't know how to do critical enterprise application integrated with SAP, CRM, reporting, et cetera. So, this is our expertise now, so going to enterprise application, complex stuff inside critical businesses. So, now we're competing against everybody. So, but, well, it's a game. There was, yeah. Yeah. And how do you manage, how do you manage, and, well, their organization is way more structured. We have a CEO manager, then we have five to six HR managers, office managers, recruiters, recruiting companies. So, the organization on production is extremely organized, because, well, we have 12 offices across several counties, so we have to be very careful to spot the right guy and to try to hire him. So, yeah, it's a very structured organization. Yeah? Yeah. What about the rest components? The thing is, yes. Well, there was some white powder, we sell it. No, actually, as again, when you, I take the new, so let's cold call and I sign up a good client in London doing some publishing business. Very nice, okay? Beautiful, perfect client. Then, once I've started, I give it to my wonderful project manager. Very beautiful, et cetera. And then, all the relationship is managed by these guys. So, if there are new projects, new demands, it's all goes to them. I don't touch it anyway. So, he manages the rest. So, the rest comes from project managers who are actually sales and Swiss knifes. Yeah. We try to sell everything we can, but we're not always all the way, but the good thing, we spend about from 35 to 50% of development time on QA. This is a standard metric. When we sell, well, we try to sell 30, 35%. It's, you know, always you have a purchase manager saying, oh, you are too expensive. You're right, 50% of QA is way too much. We are used to 20, I say, okay, but it's actually how you get quality and well. So, it's complicated to sell QA, but well, at the end they, on fixed budget, they see the final number. They don't actually check the percentage. So, 50%. Yeah. Sorry, I, yeah. Yeah, we have only one cold call, cold color. It's a maximum. He's a small maximum, the big maximum. So, it's a maximum team to maximize revenue. And the cold call guys, yeah, he's alone. He qualifies, he's just a gem. You know, it's complicated to find. Don't say to him, he's a gem. He will ask for raise and salary. But yeah, he qualifies and he selects the client. He calls, he calls, he calls again until they get the first meeting and then I come in and then we try to understand what their needs, et cetera. Finish? No, well, I don't see how you can outsource your cold calling. I mean, some bullshitter will call you, hey, hi, you want some Drupal shop? No, no, you cannot. You have to understand before calling, the guy spends about an hour before calling a company an hour to just qualify who they are, what they do, what are the existing technology? Who are their competition references? And its qualification asks to somebody who knows your business. You cannot outsource just calling. It's not just calling. Understand, and calling the right person saying, I'm calling from your boss. Who is your boss? Ah, you know, it's a quite complicated process. So, then it is more about quality time? Yes, yes. You don't need to call everybody. You have to just call total, actual, I don't know, general electric and big companies. Then the rest you, well, you spend your efforts on the big ones. Yes, one big clients is better than small, yes. Okay, yeah. It's four questions, you know. The percentage is a high level. KPI at what? This is cold calling. You call and you cannot end up with everything. You can go to dinner with them or, I don't know, but you can sell them, try to sell a project. Well, it's cold calling. It's a random process. You have to adapt each second to what your guy's saying. So, it's very different. You cannot formalize, like, you do this and this and this, there's no script. You can say, it's personal to bypass a secretary. You can say, checking his boss, saying I'm calling from his boss and how he's scared. So, it's all different. So, yeah, that was the fourth question. He's a good at sales. Actually, we were able to hire you to upsell things. It is absolutely. Look at my eyes. It's absolutely bottleneck. So, I'm finishing the bid now because you don't see my second screen. So, I'm just filling up because I have to send it in five minutes. No, yes, it's absolutely bottleneck. We'll try to resolve that. And escalation, well, we have several levels of escalation. We have project director. We have CEO and we have me and my partner. So, but we don't have escalation because every project happens so good. Okay, thank you guys. I think we're running the time.