How to start a custom system without risking everything at once
You don't have to build it all at once. The fear of a large, expensive project is well-founded, but the approach has changed. Start with the process that takes the most time from your team, get it running in weeks, and the system grows from there.
The fear you recognize
Building custom software sounds, for almost any director, like the same thing: months of project, a large upfront figure, and the risk that in the end it doesn't work or that you had to stop the operation to get there. It's an image that didn't come from nowhere. Anyone who has seen a software project up close turn into a bottomless pit has it.
And it's not an irrational fear. For years building software was exactly that, an act of faith: you defined what you needed, paid for everything before starting, waited months, and until the end you didn't know if you had gotten it right or if the money had gone into something that didn't work. The entire project was committed before you could see a single piece working.
Why that fear was well-founded
Software projects became risky because they were designed to be so. A team would sit down to plan everything upfront: every screen, every connection, every business rule. A thick requirements document was written, the entire work was budgeted, and only then construction began. If halfway through you discovered something wasn't working as you had imagined, you had already spent half the budget and had no choice but to continue.
It was done that way for so long that it became considered the only possible way to build software, and many teams still work that way. What changed is that you are no longer obligated to do it like that.
The first process, the one that hurts the most
The decision that really matters is not whether to build custom software, but which is the first process you are going to solve. And it's not the biggest or the most complex. It's the one that costs the most today: the one that consumes the most manual hours, the one that fails the most times, the one that leaves several waiting when the person who knows how to do it is missing. The one that, if you solve it, frees up time from the first week.
That first process matters more than any technology decision because that's where you check if the idea works, in real operation and not on paper. To find it, you don't need a long diagnosis. It's in the Excel that your team maintains by hand, in the tasks that repeat without any system taking them on, in the places where someone invented a solution because the tool didn't have it.
There is a second condition, and it's the deciding one. The process that hurts the most also has to be one that can work alone, without waiting for something else to be solved first. It hurts a lot and depends little. Those two traits together mark the candidate.
The system that builds itself over time
What happens next is where the concept of this series takes shape. Each piece you add builds on the previous one, and what started as solving a specific pain ends up being, without anyone drawing a master plan at the beginning, the platform on which the business operates.
It's the complete arc of these three articles. The Excel that nobody asked for showed the patches your team maintains by hand. The next one served to decide if it's worth turning them into something of your own. This one answers where to start when the answer is yes. The patches become a system one at a time, not because you got a perfect architecture right from the start, but because each new piece is decided by looking at what is already working.
The system grows with parts that have already proven their value, rather than being born from a big leap based on assumptions.
Two ways to build software
| Criterion | Traditional method | Piece-by-piece method |
|---|---|---|
| Proof point | After months, with everything complete | In weeks, with the first process |
| Initial risk | Everything invested before knowing if it works | Small investment, reversible |
| If something fails | It's corrected on a large project | It's corrected on something small and cheap |
| Team confidence | It is gained at the end if everything goes well | It is gained in weeks with the first success |
| Decision for the next step | Based on initial assumptions | Based on data from what is already working |
| System growth | A big leap from the start | Gradual increment, each piece connected |
The first process, not the biggest
Starting small isn't for everything. There are processes that only make sense if they are solved together with others. If the process that hurts the most depends entirely on three others to work, then that's not your first step. There, the first step is bigger, and that's fine. The way to know is to ask: can this process work alone for weeks, or does it need another to be solved first?
-
Your team maintains a file that nobody asked for but half the operation already depends on
Consequence That file is the symptom that an important process is not automated and consumes manual hours that could be freed up.What to do Identify that file. It's your candidate for the first step. Note what process it solves and how many monthly hours it consumes. -
There is a process that fails more times than others and when it fails, everything stops
Consequence Your team loses time investigating what went wrong, and other processes are left waiting. The cost is greater than what you see.What to do Document how many times it fails per month and who else is affected. If it's a process that works alone, that is your first step. -
When a key person is absent, that process freezes because only they know how to do it
Consequence Your operation depends on a person, not a system. That's pure operational risk and limits your ability to grow.What to do Ask: what does that person do that no one else knows? That knowledge captured in a process is where you start. -
You spent years asking the software you use to do something it doesn't do, and it never did
Consequence Your team found a workaround. That workaround is inefficient, consumes time, and is probably in a file or a manual procedure.What to do What the software doesn't do and your team does by hand is a strong candidate. Ask if it depends on other processes to work. -
You have repeated conversations about 'we should automate this' but nothing ever happens
Consequence The problem stays as it is. Your team keeps spending hours on something that could be solved. The gap widens.What to do From those conversations, choose the one that repeats the most. That is the process that hurts the most. That's where you start. -
A process depends on three others to work, and all three are on a waiting list
Consequence That is not your first step. It's a process that needs a larger, coordinated approach with the others.What to do Discard it. Look for another that can work alone for weeks. That one is your first candidate.
Where you start tomorrow
You don't have to decide to build today. Just know where you would start if you ever decide.
Choose, from everything that is done manually today, the process that meets the two conditions: it costs a lot and it doesn't depend on something else being solved first. That is the candidate, and it's most likely already pointed out in the Excel that your team maintains without anyone having asked for it. It's a small, reversible, and manageable first step that tests the idea in your real operation and not on a spreadsheet of intentions.
If it works, and you'll know in weeks, everything else is built from there.
Tres preguntas antes de aceptar un presupuesto
Tres cotizaciones para el mismo proyecto: una cuesta la mitad que las otras. Sin saber qué omitió el más barato, decides. Este artículo te da las tres preguntas que separan una inversión digital de una compra que tendrás que repetir.
The Excel Nobody Asked For
Someone on your team manually maintains a file no system generates, and half the operation now depends on it. It describes, in more detail than any requirements document, the software your company needed but never got built.
Renovaste tu imagen. En tres años, volverás a empezar
El ciclo de renovación digital en empresas turísticas de lujo sigue un patrón predecible: rebrand, lanzamiento, obsolescencia. No es un problema de diseño. Es un problema de cómo se concibe el proyecto desde el inicio.
Comments 0
Be the first to comment.