Services

Which of These Should You Start With?

Most enquiries arrive describing a solution rather than a problem, and the useful first conversation runs the other way. If the constraint is that an existing system is hard to change, that points at modernization. If the constraint is capacity on a team that already knows what to build, that points at staff augmentation. If nobody can yet describe the process end to end without disagreement, the honest first step is discovery.

The pages linked above each describe one route. You do not need to pick correctly before getting in touch, and arriving with a problem and no idea which category it falls into is normal.

How Engagements Are Usually Structured

Work is split into stages that each end in something you can look at and decide against. A short paid discovery produces a documented scope, an architecture and a costed plan that belongs to you and can be taken elsewhere. Build work then proceeds in slices, highest-value capability first, so something useful exists during the project rather than only at the end.

• Discovery. Current process, systems in scope, constraints, and what success would look like as evidence rather than opinion.
• Architecture and plan. What gets built, in what order, and what each stage depends on.
• Delivery in slices. Each slice usable on its own where the work allows it.
• Handover. Source in a repository you control, documented setup, and enough written context that another team can pick it up.

What We Need From You

The two things that most affect a schedule are access and decisions. Credentials, test environments and sample data are routinely the longest lead-time items, and they are entirely avoidable delays. Naming one person who can decide when two departments disagree is worth more than any tooling choice.

Where a system belongs to a third party, their change process and their availability become part of your timeline. Raising that at the start is better than discovering it at integration.

When a Smaller Answer Is the Right One

Some requirements do not need custom software. If a configurable product covers the requirement and the difference is a preference rather than a differentiator, buying is usually the better decision. If a process is painful because it is undefined rather than unautomated, define it before encoding the confusion in software.

We would rather say that during scoping than build something you did not need. Specialized requirements are routed to the practice that owns them, which the specialist practices page sets out.