Your custom software, usable within a month, on a fixed monthly budget. Here is who carries this promise.

From 2012 to 2014, I studied for a two-year technical diploma (a French BTS) in home automation, as an apprentice automatic door technician. I only just passed. The plan was to go on to a bachelor’s and design IoT applications. My results discouraged me, and I gave up on it. After that, I worked in electronic security systems.

In 2016, I decided to revive my plan to become a developer. I’d never let go of the idea, and for personal reasons I had to make it happen. Little by little, I took it up alongside my job, and a developer helped me get started. In 2017, a training provider approached me and sold me a nine-month course. I should have been wary: a good school doesn’t need to go out hunting for students. But I wanted to become a developer at all costs, and my situation was fragile. I was naive. From morning to evening, 8 a.m. to 6 p.m., we were made to watch videos and then write reports on them. Then we tested each other with multiple-choice quizzes to check we had understood. That was how they supposedly taught us programming. Most of the students in my class were in a precarious situation. Many were foreigners, and the course was sold to them as their hope of staying in France and finally getting an interesting job. After three months, a sales rep from an IT services firm linked to the training provider came to pick out students to put forward to its clients. She chose me. To be put forward, my CV had to show five years’ experience and a master’s degree. I refused. With that CV, I would have been given a project I wasn’t capable of delivering, and the team and the client would have paid the price. The answer was: “Sébastien, you’re not complying with the school’s terms of sale.” I was thrown off the course and asked, “as a matter of professional ethics”, after everything the school had “done for me”, not to talk about these practices to anyone outside. That school operated like a cult, and its terms of sale came down to lies and manipulation. Very quickly, in my first months in this industry, I saw what I was getting into: a world of charlatans. I never got a first developer job. From my very first steps towards this profession, I wasn’t willing to compromise on my principles. In the meantime, I chose to turn to another job, IT support, rather than pass myself off as someone I wasn’t. And I kept teaching myself on the side. People I knew in the industry shared stories of projects that had gone wrong. I told myself I’d be fine. I was already interested in agile, a way of building software in small steps and adjusting it as feedback comes in. Some of what I read resonated with me, though I didn’t fully grasp why. I hadn’t run into those problems myself yet.

From October to December 2018, I did a web development bootcamp. It gave me the foundations and taught me how to learn on my own. I finished with a certification in web and front-end development. In January 2019, I registered as self-employed and found my first clients. I started out subcontracting for a Netherlands-based developer with fifteen years’ experience. On his project, deployments and tests were already automated, a level of hygiene very few web applications had at the time.

In August 2019, I went back to university for a bachelor’s degree. Students on the programme were largely left to their own devices. Whenever I asked a question, the lecturers said: “Figure it out yourself, do your own research.” I wondered what I was doing there. So I did figure it out: I paid for courses and built my own projects. The few students who made it did the same.

At my final assessment, I asked the examining panel whether I should go on to a master’s. Given my projects, they told me to go straight into the job market; I could always go back to studying later. They added: “We don’t normally say this, but you can leave with an easy mind: you have your degree. We wouldn’t give this advice to your classmates.” When I told the head of the programme I wasn’t continuing, she said: “We train our bachelor’s students so well that they don’t need a master’s.” I said nothing, so as not to knock her confidence. In fact, I’d had to learn on my own, digging into topics that, even then, people at my level often didn’t bother with.

That comes from my background and the way I think, which changed in 2017, when I attended a religious seminar that trained people to teach. You can’t teach what you don’t understand, or what you aren’t convinced of: you would do it without enthusiasm, without zeal. So we learned to do our own research, to go back to the sources to understand, and to rely on evidence rather than mere belief. During my BTS, I hadn’t yet learned to study this way. I was missing some foundations, in maths for example, and I had neither the time nor the support to go back over them. By my bachelor’s, I had. When I don’t understand something, I don’t just accept it: I keep asking questions until I know it inside out. If need be, I go back to the most basic concepts. Otherwise, you build a house of cards and end up working on autopilot. And when I’m given responsibility, I want to own it completely. My mistakes shouldn’t fall on other people.

In 2021, the project I was working on kept falling behind. My first instinct was to catch up with overtime, weekends and too little sleep. I stopped going out. Nothing worked: the gap didn’t close, and my health suffered for it. I realised I was playing a game nobody can win. Something had to change, for the sake of the client’s budget and our health. The whole team, not just me, wanted to keep working on a project we found interesting, make a living from it and be proud of what we delivered. So I stepped up and got involved in managing the project too, even though that wasn’t my job. Nobody had anything to gain from the project failing: not the client, and not the team, whose work depended on it.

To stay on budget and on schedule, we made a choice as a team. We stopped building features just because the specification listed them. To keep the promise made to users, there was no need to ship everything in the first release. We postponed the ones still to be built, strengthened the essential ones already built, and dropped the ones we had started that weren’t essential at this stage. Above all, we focused on what really mattered. We met the third deadline, the first one where I had been able to take on the project management myself, and delivered a usable application. I could see that, had we started from the essentials, the application could have been usable within a month, with the rest following later and no loss of quality. I didn’t yet know what agile really meant. But I saw the value of project management that adapts.

I wanted to get better at automated testing: knowing where to put tests, and how to test an application properly. Looking for people who really knew the subject, I came across a talk by Dave Farley, the inventor of the deployment pipeline, often called the CI/CD pipeline. With Jez Humble, he defined continuous delivery, and automated tests are only one part of it. What he explains is simple and practical.

That left the question of budget. I knew estimates couldn’t set a budget or keep a schedule on track, but I didn’t know the alternative. I had known the Agile Manifesto since I first started out, and I shared one of its values: start from what users need to be able to do, and build only what serves that.

I knew the pattern I kept seeing wasn’t just my impression. What I wanted to know was whether it was documented, backed by numbers. I did some research and came across studies showing that 0.5% of large-scale projects, across all sectors, meet budget, schedule, and expected benefits (Bent Flyvbjerg, How Big Things Get Done, 2023, 16,000 projects). Hitting all three at once is a matter of luck: in the trade, this is called the iron triangle, and one side always gives. The rest go over budget, or stay within it by cutting part of what was planned, as we had done. Another study also struck me: it showed that only 1/3 of ideas tested at Microsoft improve the target metric (Ronny Kohavi and co-authors, Online Experimentation at Microsoft, 2009). The cause was the way projects are run, and that can change. Since then, I want to be in direct contact with users to understand their goals, without anyone in between reshaping what they say. An intermediary can make gathering requirements easier, so developers don’t spend all their time in back-and-forth, but must not stop users and developers from talking to each other. Once a feature is live, I check that its goal is actually achieved. Otherwise you risk shipping features nobody uses.

In 2023, at a large company, I joined the team on a project that ran for two years, with two million euros invested. Several teams worked on the same software, each on its own copy of the code. Nobody asked for the work to be integrated as it went. After roughly four months, everyone’s work had to be brought together: every bug surfaced at once, along with the conflicts between copies and the calls on which code to keep. After months of waiting, each team on its own, we went through two weeks of overtime and stress. Integrating the work continuously, bit by bit, would have been enough. The integration was barely finished when a manager we never saw came to tell us the project was cancelled: the market wasn’t interested in what we were building. Yet nothing had ever gone into production: the software had never been put in front of its users. Colleagues then told me happily: “We’re getting better: it used to take us six years to reach this conclusion, now it only takes two.” A developer on my team also confided in me: “I’ve been here five years, and nothing I’ve worked on has ever made it to production.” That’s when I told myself: no, I’m not staying.

Later, on another contract, the team met every week for a retrospective, as Scrum prescribes, to look for ways to improve the organisation’s processes. I was asked for my proposals, and the answer was: “We’ve been working like this for five years, and we won’t change.” That’s when it hits me: there’s something hypocritical about this. I don’t understand what I’m doing here. My remarks are brushed aside, and in the end I’m sidelined, after being made to understand that I don’t fit the team’s internal processes. Today, when you work as a freelancer inside a client’s team on a day rate, you’re treated like an employee, and you end up in bogus self-employment. It was after this episode that I decided to take the bull by the horns and build the skills I still lacked to understand how agile applies to building custom software, so that I could finally take on my projects end to end.

And it was about time: I had already got results by working this way. In 2024, on one project, the application had 600 users after three months of development. I had helped the founder see that what matters isn’t the features he has in his head, but going to interview his users, building only what they ask for, and shipping new features as they’re ready, in a continuous flow. The same year, on another project, because we all shared the same approach, we put the application in front of 30 beta testers after six months of development.

Since 2019, I had been watching Frédéric Leguédois’s talks on agility on YouTube. He is a reference on the subject, in France at least. In 2026, I was lucky enough to be trained by him directly in adaptive project management: fix cost and quality, and let the client steer the scope. That finally answered my budget question: the budget is what a company is prepared to invest in building and evolving its software, weighed against what the unsolved problem is costing it. I was already applying some of these methods; the course gave me the full framework. That is the foundation I built the DEVEDANOS offer on.

So instead of estimates and fixed plans, I chose a different standard: an adaptive approach built on continuous delivery. I want more companies to benefit from it: projects that succeed, money well spent, teams that aren’t always firefighting, developers who no longer sacrifice their health, and all of us taking satisfaction and pride in a job well done.

That means software quality, security included. Since estimates are never met, this model forces you to renegotiate the budget or deliver less, often both. When an estimate does seem to hold, it’s luck. Even with a buffer, deadlines are only met by sacrificing quality and security where nobody can see it. And a feature delivered that way can no longer be changed: it stays as it is, and once too many features are in that state, the software has to be rebuilt. That is expensive. Quality takes the first hit: how easy the software stays to change, and how secure it is. There is then neither the budget to bring in experts nor the time for developers, who are not security researchers, to deal with security within their remit. The standard DEVEDANOS applies to every project makes no compromise on quality or security: it is part of our delivery pipeline, for every change to your software.

Picture a building site run like a software project. The plumber lays his pipes, then the bricklayer closes up the wall. In comes the electrician: “Oh no, I need to run my cables through there too.” The bricklayer knocks the wall open again, and the plumber may have to come back. In software, that’s often how it goes. It has become normal, and nobody opens their eyes to how absurd it is. In this profession, many people are caught in a trap where you keep your head down and don’t rock the boat, so as not to lose your job. Out of a survival instinct, since their whole income depends on it, they keep quiet. Being different and asking questions isn’t welcome. I decided never again to set foot in organisations like these, for my mental health and so as not to pick up bad engineering habits.

It’s out of a love of good work that I now only take on projects end to end. Because I want every euro, every effort, every hour put into my work to produce a result as early as possible, one that lasts, and that my clients and I are proud of.

A feature goes live once it has been accepted and approved.

A fixed budget to build your application and keep adapting it as your business evolves, for as long as you want, invoiced monthly for that month’s work. You decide the scope as things change.

It rests on two things. Real agility, the adaptive kind: shaping the product around what its users need and keeping them at the centre. And continuous delivery (Dave Farley, Jez Humble): high-quality code that is easy to change. You can’t have one without the other. The best ideas are worthless if the code is hard to change: it’s a racing driver behind the wheel of a tuk-tuk. And excellent code is worthless if you don’t understand your users: it’s a Ferrari handed to someone who has only ever driven a tuk-tuk. Our Approach page details the mechanics.