How to choose a software partner that actually fits
Friday afternoon, the campaign has been running for two days, and the webshop starts to crawl. Somewhere in the chain the stock integration is lagging behind, so customers are ordering items that sold out this morning. Moments like that tell you what your software partner is really worth. The slide deck from the sales process no longer counts for anything. What counts is whether somebody picks up, works out where it is going wrong and tells you where you stand.
If your business leans on software, platforms and integrations every day, choosing a partner deserves more care than an ordinary purchasing decision. The wrong one costs you revenue, and eventually the patience of your own team as well. Below are the questions that, in practice, give away the most about how a collaboration is going to go.
Start with the problem, not the technology
A list of programming languages and frameworks tells you very little at this stage. That conversation comes later, once it is clear what your organisation actually needs. A good partner wants to understand the business problem sitting behind your technical question first.
Are you trying to take manual work out of a process? Does a customer portal need to get faster? Are people stuck because systems are not properly connected? Or is the platform growing faster than your current hosting can keep up with? Anyone who puts a solution and an hourly estimate on the table before asking those questions is taking a risk on your behalf.
So ask how a supplier starts a project. Do they map out processes, users and dependencies? Is there attention for what is already in place, including external systems and decisions made years ago for perfectly good reasons? And will someone tell you what you do not need to build? Custom software earns its keep when it removes a specific bottleneck. The moment it swaps old mess for new mess, all you have done is move house.
Look for an understanding of your daily operation
Software rarely stands on its own. A change in a webshop touches stock, payments, customer service and marketing. An internal system touches departments, roles and working agreements that were never written down anywhere. A partner who only looks at the screen is missing half the picture.
Put a scenario from your own operation on the table. A supplier delivers late. An API stops responding for twenty seconds. Someone enters the same order twice. Ask how they would absorb that technically, and how your people are supposed to carry on in the meantime. The answer quickly shows whether you are talking to builders or to someone who thinks about continuity.
Ownership matters more than development capacity
Plenty of agencies can build software. Fewer stay involved once the system is in production, users start asking questions and an external system changes without warning. That is where the difference sits between a supplier for a project and a partner for the years after it.
Ownership does not mean someone decides things behind your back. It means a problem does not get passed along. When an application, a server, an integration and an external service all affect each other, everyone should know who is leading the analysis and who is watching the fix until things are genuinely stable again.
That weighs even heavier if you have no development or DevOps team of your own. You do not want to end up mediating between a developer, a host, a domain provider and an API vendor who are all pointing at each other. Every handover costs you a day and adds fresh ambiguity.
When development and hosting belong under one roof
The question is not whether you put everything with a single supplier. The question is who can see the whole chain. A development team with no view of the production environment struggles to reproduce a fault. A host who does not know the application sees a spike in CPU and not the query causing it. As long as someone ties those two sides together, the work can perfectly well stay split across suppliers.
If you have an internal platform team that takes on that role, or a specialised cloud environment with its own operations crew, a separate development partner fits very well. Without that layer, the split gets expensive at the worst possible moment. Development and infrastructure under one roof is then usually the quieter option, simply because nobody is left to point at.
Either way, look closely at the arrangements around hosting, monitoring and backups, updates, security and incidents. Ask who you call during an outage, what happens at ten in the evening and how quickly a report gets picked up. A service level agreement puts all of that in writing. In practice it often matters more that you can reach someone who knows your environment by heart.
Look at the process before you look at the price
A tidy proposal with a sharp number on it says little about how the collaboration will run. Start by checking how carefully someone listened to your question. Are the assumptions written down where you can see them? Are risks named rather than left out? Will both the decision maker and the employee who ends up using the system understand what is about to happen?
A dependable project has clear moments for research, design, build, testing, delivery and aftercare. That does not call for a stack of project documents. It only has to stop an essential integration or a forgotten user role from surfacing two days before go-live.
Pay attention to how changes get handled too, because something always changes. New insights, shifted priorities, an external system that turns out to behave differently from what its documentation claimed. A good partner works through the consequences and lays them side by side: schedule, budget, technical impact and what it means for maintenance later on. Then you make a decision based on facts instead of getting a nasty surprise afterwards.
Judging technical quality without reading the code yourself
You do not have to be a developer to ask good questions here. A professional supplier can explain in plain language how quality is safeguarded, with concrete choices instead of jargon.
Ask how things are tested before they go live. Ask how errors are logged and who actually sees them. Ask how you get back to a working state if a release causes unexpected problems, and how long that takes. Ask how access rights are set up and what happens to privacy sensitive data. With integrations, the most interesting question is what happens when the other system is briefly unavailable. Does data disappear, do you end up with duplicate orders, or is the processing safely retried later?
Documentation belongs in this list as well, and not as a manual nobody opens. A workable overview of integrations, maintenance tasks, accounts, dependencies and the way a release is rolled out is plenty. If all the knowledge lives in the heads of two people, you are exposed the moment one of them goes on holiday.
Compare costs on equal terms
The lowest hourly rate is rarely the lowest total cost. A low starting price can turn expensive once the scope proves vague, technical debt piles up or support after delivery is missing. A higher rate, for that matter, is no proof of quality either. You are rightly paying more when there is demonstrably less risk, a faster response or a shorter lead time in return.
So put quotes next to each other on the same points. What falls under analysis, design, testing and project management? Are hosting and maintenance included or billed separately? Which costs are one off and which come back every month? What is the agreement for extra work? And who owns the source code, the configurations and the access to the infrastructure? That last question tends to get forgotten, right up until somebody wants to switch suppliers.
Be honest about the size of your question as well. For a small, clearly bounded project a specialist freelancer can do excellent work, often faster and cheaper than an agency. As soon as you are dealing with a platform that has several integrations, a growing user base and the expectation that somebody is always reachable, team continuity weighs more heavily than one person's rate. That person gets ill too.
Start small and test the collaboration
The best predictor of a good working relationship is a first, manageable assignment. A technical audit, for instance, or a stubborn performance problem that has been dragging on for months, a well bounded integration or a proof of concept. You get to see how fast they move, how clear the communication is and whether agreements hold up when things get awkward.
Use that first assignment and the conversations around it to test five things:
- Do they understand your business goal, and not just the technical question?
- Do you get answers from people who can think the problem through with you?
- Are risks and limitations put on the table honestly?
- Is it clear who is responsible for maintenance and incidents?
- Does the communication feel practical and predictable?
That last point sounds soft, but operationally it may be the most important one. Every software project throws up choices and situations nobody planned for. At those moments you do not want an account manager sitting between you and the people doing the work. You want someone on the line within fifteen minutes who knows your environment and can change something straight away.
A good partner will not promise you that nothing ever breaks. They make sure you hear about it quickly, understand what is going on and can see that someone is already working on it. So pick the supplier that leaves you thinking, after the first proper conversation, that if this stutters tomorrow morning they will pick up the phone and get on with it.