How to Choose a Software Development Company for a Complex Business Project

By Gary Leicher, CEO of Smudge Technologies

When a business decides to invest in custom software, the first conversations often focus on features, cost and delivery dates. Those questions matter, but they are not where I would start.

The first question I would ask is: Does the development company understand how our business actually works?

The second question is: How do we Choose a Software Development Company?

I have seen projects where the proposed solution looked good in a presentation, but the difficult business rules had not been discussed. Those rules are often where the real work lies. They determine how people use the system, what happens when something goes wrong, and whether the software will still serve the business as it grows.

If you are choosing a software development partner, here is what I would look for.

Do they take time to understand your business?

A good development team should ask more than what screens you want built. They need to understand your workflows, the people using the system, the decisions it must support and the problems you are trying to solve.

They should also be willing to question an initial idea. Sometimes a client asks for a particular feature because it seems like the obvious answer. Once we work through the process with them, we may find a simpler or more effective way to achieve the same outcome.

Ask a prospective partner how they run discovery and what you will receive from it. You should expect enough clarity to make decisions about scope, priorities and the approach to development.

Can they work with the systems you already have?

Most complex projects do not begin with a blank page. There may be an accounting platform, an ERP system, an old database or a piece of software the business depends on every day.

These connections need proper attention early in the project. Ask what information the new system will need, how it will move between platforms and which third parties will need to be involved. If an existing system has limited documentation or an unreliable integration, you want to know that before a delivery date is promised.

This is especially important when you are replacing legacy software. The current system may have years of business rules built into it, including rules that nobody has written down. Understanding those rules is part of the project.

Who will be responsible for delivery?

Find out who will do the work and who will make decisions. Depending on the project, you may need a business analyst, designer, architect, developers, testers and someone responsible for keeping delivery on track.

You do not necessarily need every role full time. You do need to know that the right skills will be available when the project needs them.

Ask who will lead the project, how progress will be reported and how issues will be raised. You should know who to speak to when a decision needs to be made.

How do they handle changes?

Requirements can change during development. A new business rule comes to light, an integration works differently than expected, or users respond to an early version of the system in a way nobody anticipated.

The question is how those changes are managed.

Before work starts, agree on what is included, how work will be reviewed and what happens when you request something additional. A development partner should be able to explain the effect a change will have on cost, timing and other priorities so that you can make an informed decision.

Be cautious of a proposal that promises a fixed outcome before the team has properly investigated the difficult parts of the project.

Can they show you relevant work?

A list of technologies is useful, but it does not tell you how a company handles a complex project. Ask for examples that are relevant to yours.

What was the client’s problem? What did the team build? Were there difficult integrations, security requirements or multiple types of users? What happened after launch?

The projects do not need to be identical to yours. You are looking for evidence that the team can work through comparable business and technical challenges.

What happens after launch?

Software needs attention once people begin using it. Bugs may be found, business processes change, and new requirements emerge. Ask who will support the system, how issues will be prioritised and what documentation you will receive. Be clear about access to the code, hosting environment and third-party services. These details matter if you want the freedom to maintain and develop the platform over time.

Questions to take into your first meeting

If you are comparing development companies, I would ask each of them:

• How will you learn our business rules before development begins?
• What do you see as the biggest risks in this project?
• Who will work on it, and who will be accountable for delivery?
• How will we review and approve the work as it progresses?
• How will you assess a change to the agreed scope?
• What support will be available after launch?
• Can you show us a project with similar complexity?

The answers should help you understand how the company thinks and works. You should leave the meeting with more clarity about your own project, even if you have not yet chosen a partner.

At Smudge Technologies, we start by understanding the business problem and the systems around it. That gives us a sound basis for planning, building and improving software that people can rely on.

If you are planning a new platform or need to replace a system your business has outgrown, you can read more about our custom software development approach or speak to us about what the project involves.