Custom software development services

Roles on a software project

Engagement models

Your side of the work

Projects succeed when someone in your organisation has time and authority to make decisions: which features matter most, how a rule should work, whether a design fits real tasks. This product owner role is often underestimated. Without it, developers guess or wait, and the software drifts from what the business needs. Plan for a few hours each week, more at the start.

Ask any provider what they will need from you and when.

Terms to agree

A healthy communication rhythm

• Regular demos

  Working software shown every one or two weeks.

• Visible backlog

  Shared list of what is planned, in progress and done.

• Spend reporting

  Time or budget used, compared with plan.

• Risk log

  Known issues and decisions recorded openly.

A sensible selection process

1. 01

   Shortlist

   Providers with relevant experience and mainstream technologies.

   Output: Two or three candidates

2. 02

   Discovery or workshop

   A paid exercise to see how each works.

   Output: Comparable outputs

3. 03

   References

   Conversations with long-term clients.

   Output: Evidence of delivery

4. 04

   Agreement

   Model, team, terms and first phase agreed.

   Output: Signed engagement

Continuity and key-person risk

Software knowledge lives in people as well as code. If one developer understands the whole system and then leaves, progress can stall for weeks while someone else learns it. Ask how a provider spreads knowledge: code review by a second person, shared documentation, pairing on complex parts and more than one person familiar with each area. Ask too what notice you will get if team members change, and how a handover inside the provider's team would be managed.

A small provider can manage this well, provided knowledge is written down and the code is held in a repository you can access.

Warning signs when comparing providers

Be cautious of a provider who quotes a firm price before understanding your processes, cannot explain who will do the work, keeps source code on their own systems with no access for you, or avoids discussing what happens if the relationship ends. Equally, a provider who asks detailed questions about users, data and edge cases at the start is usually showing the habits that keep projects on track.

Long-term client references, rather than polished case studies alone, give the clearest picture of how a provider behaves when things get difficult.

Subcontracting and offshore work

Some providers pass parts of the work to subcontractors. That is not necessarily a problem, but you should know who is handling your code and data, where they work and under what confidentiality and data protection terms. Ask for this to be stated in the agreement.