Why so many software development projects go over their original budget
More than half of all projects go over their original budget. The cause: a price set by adding up estimates. And how to work differently.
Bespoke legacy software modernisation
Are your tools adapted to the way you work, or do you have to adapt to them? Web or mobile app, back office, internal tool: we take over applications whose development stopped part-way, and those that are in service but have become hard to change. On a fixed monthly budget, we keep what works, and we replace a part when it blocks the changes you need.
Taking over or rebuilding: starting from the existing code
An application in service contains business rules: calculations, special cases. Often, they are written down nowhere but in the code.
Rewriting the application in one go means finding each of these rules again, one by one. Meanwhile, the application in service stops evolving. The new version brings nothing to its users until it is finished.
So we start from what exists. We read the code, we deploy it to an acceptance environment, then we decide with you what to keep and what to replace. A part is replaced when it blocks the changes you need, not because it is old.
If the application to take over also has to exchange data with other software, we can connect the software you already use.
An application that meets your need and evolves without difficulty does not need to be taken over.
What we do on an existing application
We take over projects that are running late
We go back over the planned feature list with you and rank it by its value to the users of your application. The features that matter most are designed, developed and released first, one by one, each after its acceptance.
We migrate applications to up-to-date versions
Migrating an application means moving its code to a more recent version of its framework, to another technology or to another language, without changing what it does for its users.
Tests before the first change
We start by writing tests that describe the application’s current behaviour. Only then do we change it.
We keep what works and replace what blocks
We replace a part when it blocks the changes you need, and we keep what works. The decision is made with you, after reading the code.
One change at a time
We release one change at a time, once the pipeline has checked it. If something goes wrong, we go back to the previous version.
How a takeover works
The approach is the same for a project to continue and for a project to rebuild.
- We first gather the access in your name: source code, hosting, domain name, third-party service accounts.
- The application then runs on an acceptance environment that we administer and that reproduces production.
- Before any change, automated tests describe what the application does today, on the journeys its users depend on.
- Each day, you decide your priorities: the next feature to specify, to develop, to deploy.
What we have built
Week and Go, a leisure-vehicle marketplace
For Groupe Rapido, a leisure-vehicle manufacturer, we worked on the development of its marketplace. The project had fallen behind with another provider. Together with the client and that provider, we refocused development on the essential features, the ones that brought the most value.
The new deadline was met with a minimal application; the other features were then added continuously.
Migrating a CRM that had been in service for six years
For a Dutch manufacturer of safety footwear, we worked on this migration: Ember.js 2 to 3 in Octane syntax, Symfony 2 to 4.
A fixed monthly budget, and what stays yours
The budget is built with you, from your numbers and your objectives: together we set the amount and the problem your application has to solve. Your application is usable within a month of development. From then on, the budget covers its maintenance and evolution for as long as you want, so that it keeps adapting to your business. Invoicing is monthly and fixed, with no surcharge for licences or number of users. You know your exact spend before you start.
The source code, infrastructure, deployment pipeline and documentation are your intellectual property once the first monthly invoice is paid.
You can terminate the contract in writing at any time, without justification. During the reversibility month, we support your team until they can build, test and deploy without us.
The users of your application work with it from the first month of development, and how they use it determines the next feature or features.
Can you take over an application built by another provider?
Yes. We start by gathering the access and deploying the application to an acceptance environment. We then write tests for the journeys its users depend on, before making any change. If there is documentation, we read it.
Do I need to rebuild my application from scratch?
Not necessarily in one go. We replace a part when it blocks the changes you need, and we keep what works. The decision is made with you, after reading the code.
Does my application stay in service during the takeover?
Each change goes into production separately, after its acceptance. If something goes wrong, we go back to the previous version. The hosting, the third-party services and the state of the code taken over do not depend on us alone: so we do not promise zero downtime.
Which technologies do you take over?
We take over applications in JavaScript and TypeScript (React, React Native, Next.js, Node.js, Ember.js) and in PHP (Symfony, API Platform), technologies we have already upgraded. For another technology, we discuss it with you from the first call. We do not rule it out in advance.
How long does a takeover last?
We do not set an end date. An application in service keeps evolving as long as your business changes. We plan the monthly budget and the development days per month. From the first month of development, what has been tested and signed off goes into production.
How is the budget for my application decided?
The budget is built with you, from your numbers and your objectives: together we set the amount and the problem your application has to solve. Your application is usable within a month of development. From then on, the budget covers its maintenance and evolution for as long as you want, so that it keeps adapting to your business. Invoicing is monthly and fixed, with no surcharge for licences or number of users. You know your exact spend before you start.
Do you offer ongoing application maintenance?
Yes, in the same model. Corrective maintenance (bug fixes), adaptive maintenance (dependency updates, security patches, browser compatibility), preventive maintenance (refactoring, performance optimisation) and enhancement maintenance (new features) are all included. At DEVEDANOS, the same team develops, tests, deploys and maintains your software continuously, in the same pipeline.
Is there a trial period?
In the first month, the first 15 working days are a trial period. Delivered features are accepted as they come in, by you or by us if you delegate acceptance to us. If you do not want the deliverables and do not wish to continue, no invoice is issued and you owe nothing. If you want your application in production before the trial period ends, you can ask us in writing: we issue the invoice for the days worked, and we release to production once it is paid.
An application to take over or modernise?
Thirty minutes to understand your situation. If we can help, a second meeting takes place within 48 hours to build the quote together.