Every week a new company appears promising to deliver your application in half the time and for half the price. The small print is almost always the same: a good part of that software was not written by a person, it was generated by an artificial intelligence.
We have decided not to do that. Not out of distrust towards the technology — we use it daily for other things — but because of what happens to a project when nobody on the team fully understands what was delivered.
The problem is not the first version
An automatically generated application usually works fine on day one. The problem arrives three months later, when something has to change.
That is when the questions that decide whether a project moves forward or turns into a money pit show up: why is it built this way? what happens if I touch this? can this be removed? If whoever delivered the software cannot answer, every change becomes a gamble.
We come from systems where a failure is not an inconvenience. Álvaro has maintained air traffic management software; Adrián, monitoring services for gas infrastructure. In those environments you learn one very concrete thing: code is read many more times than it is written. Optimising for writing speed and forgetting about reading is a bad trade.
What actually matters to us
When we say we write code by hand, we are not talking about romantic craftsmanship. We are talking about three very practical things:
- Someone answers. If something breaks, there is a person who knows why it is written that way and can fix it in hours, not weeks.
- The application does not grow fat on its own. Generated code tends to repeat itself. Repeated code means every change has to be made in five places, and sooner or later someone forgets one.
- Decisions about your data are made with judgement. Where a personal data point is stored, for how long and who can see it is not a technical decision: it is a legal one. In our case it is reviewed by Jhonathan, who is a lawyer.
Does this make us slower?
At the start, sometimes yes. Across the whole project, almost never.
What you save by generating code you end up spending on fixing odd behaviour, on explaining for the tenth time how something works, or on rebuilding an entire section because nobody dares to touch it any more. We would rather spread that effort out from the beginning and reach the end without surprises.
It also helps that we do not accept everything that comes our way. If a project does not fit the deadline or the budget on the table, we say so before starting rather than discovering it halfway through.
How to check this when comparing suppliers
You do not need to be technical to tell one approach from the other. Three questions in the first meeting are enough:
- Who exactly is going to write my application, and will they still be around in a year?
- If I need to change something in six months, how long would it take you to tell me the impact?
- Who reviews how my employees’ or customers’ personal data is handled?
The answers to those three questions say more about the quality of what you will receive than any sales deck.
If you are curious how we apply this in practice, take a look at OnTempo, our time tracking and people management application, or simply write to us and we will talk it through.
Was this useful?
If you would like to share your thoughts or have a question about your own case, write to us.