Anyone looking for a partner for custom software soon ends up comparing portfolios, technology and price. How an agency builds, tests and ships its work usually stays out of view. That’s a shame, because it’s exactly that way of working that determines how quickly you get changes, how often something breaks, and how long an outage lasts.
That way of working is called DevOps: development and operations treated as one discipline, with as much automated as possible. As a client, you don’t need to be able to work with it yourself. You do want to be able to judge whether a partner has it in order, because you’ll feel the consequences for years.
Small releases instead of big leaps
At the core is continuous integration and continuous delivery, CI/CD for short. Every change a developer submits is merged with the existing codebase, tested automatically and prepared for release. The result is many small releases rather than a handful of big ones each year.
For you, that means less risk. A small change that goes wrong is found quickly and rolled back quickly. A release carrying six months of work that goes wrong can bring a department to a standstill for days. So ask a partner not only what they deliver, but how often.
Automated tests as a safety net
In a mature team, every change triggers a series of automated tests: does the new feature do what it should, and does everything that was already there still work? Code that fails the tests doesn’t go live. For custom software, that safety net is essential: your application doesn’t run anywhere else, so a fault isn’t caught first by a thousand other users of an off-the-shelf package.
Monitoring that spots problems before you do
A partner with monitoring in order knows about an outage before you call. Response times, error rates and server load are measured continuously, and the moment something drifts off course, the team gets an alert automatically. That way, slow screens and rising error rates become a trend you see coming, rather than a complaint from your own staff.
Environments you can rebuild from scratch
Less visible but just as fundamental: with mature DevOps, the server setup is also described in code. If a server fails or an extra environment is needed, it’s built by machine, not from a system administrator’s memory. A fallback plan is part of that: every release must be reversible within minutes, and that’s rehearsed, not just promised.
How to test a partner across the table
You don’t need to be able to read a pipeline to gauge how mature a team is. A few questions tell you enough:
- How often do you release changes, and how much manual work does that involve?
- What happens automatically the moment a developer submits code?
- How do you notice an outage, and how quickly can you restore a previous version?
- Can you rebuild the production environment from scratch?
A partner who answers these concretely, with examples from live projects, has their working method in order. If the answer stays vague, or everything hinges on a single administrator, that tells you enough too. For more on this, see the questions to ask before you commission custom software.
For us, these practices are the standard setup for every project, not an option on the quote. Is your application currently with a partner where every release feels risky? We bring existing software up to this level too; you can read how that works under ongoing development and maintenance.