Skip to content
Sunbeam
Open menu

Choosing a partner

How do you choose a software agency?

Direct answer

Choose the agency that can describe your workflow, including what they would refuse to build, before they describe their technology. The practical tests are ownership of the code and accounts, a written list of what the first version will not do, and a credible answer to how a different developer would run the system in a year. A low number with none of those is not a saving.

Make them repeat the work, not the brief

A competent partner can say, in their own words, what arrives, who touches it, where it gets stuck, and what a better week looks like. If the proposal could be sent to a different company by changing the logo, it is a template. Templates are a reasonable way to start a document. They are a poor way to decide a partner.

Ask what they would not build, and why. A studio that agrees to every feature on a first call is selling effort. You are buying a judgment about what is worth the effort.

Ask where the system will live

The repository, the hosting account, the domain, the data and the analytics should be able to sit in the client's name. A year of smooth delivery followed by a discovery that the code lives in the agency's private account is not a partnership. It is a lock-in with a friendly tone.

Ask who can deploy, who holds the keys, and what a new engineer would read on day one. The answer should be boring. Boring, in this case, means the system was built to be handed over.

Look at how they treat the tools you already pay for

An agency that wants to replace Zoho, a POS, a practice system or a tax tool before understanding it is optimising for a larger build. The better question is which job the current tool does well, and which job has fallen into chat threads and spreadsheets around it. Much of the valuable work is that surrounding gap.

Ask for one example of a time they told a client to keep an existing product. You are listening for whether that sentence can be said at all.

Read the work as a problem, not as a logo

Past work is useful when you can see the constraint and the decision, not when you can see a brand. Ask what was deliberately left out of that project. Sunbeam publishes selected work on the case studies page when we have a real engagement we can describe. We do not keep a wall of unnamed claims.

Price comes after this, not before. A written scope with exclusions is what makes two agencies comparable. Without it, the cheaper quote is often the one that has not noticed the data.

Where this shows up

More short answers are on the FAQ. Side-by-side choices are in the decision guides. Ownership after launch is described in the engineering standard.

Bring the workflow, not a finished specification.

Tell us what is being retyped, who is waiting, and which list is no longer trusted. We will recommend the smallest next step.