Development or ongoing development?
That question comes up often: do you build further on what is already there, or is it smarter to develop something new? The answer does not depend on buzzwords, but on the state of your software, the room to change, and what you will need in the coming years.
Comparison
Software as building a house
At 10KB we like to compare software development with building a house. The place works fine for you, but you want an extension. Would you first check whether the foundation, layout, and construction can handle that? Of course. If that checks out, ongoing development is the obvious route: you build further on something that has already proven its value.
Sometimes the situation is different. If a house no longer fits structurally, if the foundation is too weak, or if every renovation costs more than it returns, building something new may be wiser. The same holds for software. What you want to add matters, and so does whether the current foundation can still carry it.
So the real question is not whether something is old or new, but whether continuing to build on this software is still rational.
Choosing a route
Sometimes building new is more logical
An important part of our work is preventing organizations from jumping into a large rebuild too quickly. If certain parts are still healthy, we simply use them. And if focused modernization is enough, we say so too.
So we put the options side by side: improve in a focused way, develop further in a controlled way, replace parts in phases, or rebuild where the foundation is truly finished. In every trade-off, cost, risk, planning, data, integrations, continuity, and changeability count.
We do not aim to build for the sake of building. It is about the smallest intervention that actually solves the problem.
Decision helper
When do you choose what?
The right question
Do not ask yourself "is our software old?" Ask: can we still responsibly keep working on this, or does the situation force a fresh foundation?
A solid foundation does not have to be perfect. What matters is that the software keeps delivering value, changes stay practically feasible, and you can solve problems in a focused way without everything grinding to a halt.
Working method
Honest advice, no standard answer
What we hear again and again during introductions is that other parties lock in one route early, before the real work has started. Sometimes that conclusion is right, but you should always expect a clear rationale with it.
Sometimes continuing to develop what is already there is fine. Sometimes you are better off putting a new foundation in place. And it can also make sense to combine both. To say something useful about that we need context: how is the software put together, where does it hurt, and what do you want to achieve next.
Our working method
Frequently asked questions
No. Replacing everything in one go is not necessarily the only option. Usually smarter is a phased approach, where we develop further where we can and build new parts where that is really needed.
Not by definition. At first glance continuing often looks cheaper, but if the technical foundation structurally works against you, continuing to build can become more expensive over time through delay, regressions, and rework. Therefore we compare scenarios on cost, risk, and planning.
Look at code quality, architecture, infrastructure, knowledge retention, and operational maturity. If changes are still feasible and focused improvement still makes sense, ongoing development usually fits better. If almost everything becomes slower, riskier, and more expensive, a new foundation is worth investigating.
Ongoing development builds on the foundation that is already there: adding features, fixing bugs, improving UX, and stabilizing. Modernization updates outdated parts in a focused way without replacing everything. Development is about creating new custom software, or rebuilding an existing application when the current foundation no longer makes sense. More about ongoing development and software development.
Yes. With an analysis, inventory, or a small first improvement step you quickly get clarity on what is sensible. So you do not first have to choose between development and ongoing development to start a conversation with us.
Yes, often exactly that. Reality is rarely black and white. We build new where that is needed and develop further where the existing foundation is still healthy enough.
Those belong in the trade-off. With ongoing development the existing application usually keeps running. With a new foundation we plan explicitly how data, integrations, and users move over in phases.
Then we say so. If during ongoing development it becomes clear that rebuilding is more rational, or the other way around, we map that out in time and discuss the alternatives.
Is your question not listed here?
Get in touch