For the buyer who knows the outcome, not yet the practice
Software Development Services
Most buyers arrive unsure whether they need a new build, a modernisation, more engineers, or steady operation of what already runs. That uncertainty is normal, not a gap to be embarrassed about. Four shapes are named honestly here, each handing off to the specific practice built for the one that actually fits, before any commercial conversation starts.
How this practice names the right starting point
Four shapes, one honest routing conversation, before any commercial number gets discussed.
90 secSample frame · video pending01Before naming a practice
The decision this category exists to settle
Four paths look similar from a distance and diverge fast once work starts. Picking the wrong one here is the expensive mistake, not picking slowly. Four tests separate building new, modernising what exists, extending your team and operating as-is before a proposal gets written.
Does the system in question exist yet?
If nothing is running today, the question is build versus buy, not modernise versus extend. An existing system changes every other answer that follows.
Is the current pain a capacity problem?
Teams that already know exactly what to build but lack hands need people, not a commissioned project. Confusing the two adds a delivery layer nobody asked for.
Would a rebuild cost more than a repair?
A live system with real users usually survives modernisation cheaper than a rewrite survives its own risk. Age alone is never a sufficient reason to replace it.
Is there budget pressure to decide fast?
Pressure to move quickly is a reason to scope narrowly first, not a reason to skip the practice decision entirely. A wrong first practice costs more time than a short scoping conversation.
| Build | Modernise | Extend team | Operate | |
|---|---|---|---|---|
| Best when | Nothing exists yet | A live system needs real change | Direction is set, hands are short | The system just needs steady running |
| Time to first move | Weeks, after framing | Weeks, after an assessment | Days, once a match is found | Immediate |
| You direct | Product and roadmap | Sequencing and risk tolerance | Architecture and standards | Priorities and incidents |
| Right practice | Custom software development | Legacy modernisation | Team extension | Product engineering |
02Agreed before a practice is chosen
The ledger that keeps early orientation honest
Early conversations drift when everyone nods along and nobody names which practice actually owns the work next. This ledger fixes what you bring, what gets identified, what comes back, and what stays yours regardless of which practice you end up in.
- Your side
You bring
- The business problem and who feels it today
- Any budget range or timeline pressure already set
- Constraints from systems, compliance or existing vendors
- Our side
We route
- A plain read of what kind of work the problem actually needs
- A comparison of build, modernise, extend-team and operate-as-is paths
- An introduction to the one practice that fits, not a pitch for all of them
- Your side
You receive
- A named practice and the reason it was chosen
- A short list of what that practice needs from you next
- A path to a scoped conversation in the right place
Never leaves you
- The final decision on which practice to engage
- Every existing vendor or team relationship
- The budget and timeline until you commit to one path
Where the line sitsThis entry point earns its keep by pointing you at the right practice quickly, not by holding you inside a generic pitch.
03From an open question to a named practice
Four stages, each closing before commercial talk starts
Orientation fails quietly when a generic conversation just becomes a pitch for whichever practice is easiest to sell that week. This system closes each stage with something you can check before a single commercial number is discussed.
Name the actual problem
The business need gets written down plainly, separated from any assumption about which kind of engineering solves it.
A problem stated in your wordsMatch the need to a practice
Build, modernise, extend-team and operate are weighed against your real constraints, not against which one is easiest to propose.
A practice chosen on evidenceRoute to the specific practice
The recommendation and its reasoning move with you into the practice page built for that exact kind of work.
A handoff with reasoning attachedBegin the real scoping conversation
The specific practice team picks up from a framed problem, not a cold introduction, so the first real conversation moves faster.
A conversation that starts already informed
04What actually drives the number
Four drivers, before any practice quotes a price
A number quoted before the practice is named is a guess wearing a decimal point. These four drivers move cost by multiples once the right practice is chosen, so they are named honestly first.
Which of the four paths applies
Building new, modernising, extending a team and operating what exists carry entirely different cost structures and payment rhythms.
How settled the requirement already is
A requirement still changing weekly costs more to scope than one already validated against real users or operators.
Integration with what you already run
Every existing system a new or modernised build must respect adds real engineering, distinct from a standalone build.
How urgently the gap needs closing
Genuine urgency can justify a faster, costlier path. Manufactured urgency rarely survives a second, calmer conversation.
05Evidence and proof
Buyers routed to the practice that actually fit.
Orientation proof is a buyer routed correctly, not a sale closed quickly. Every record shown here is pending written approval from the client before production.
Explore case studiesA buyer nearly bought a rebuild they did not need.
Aster North arrived certain their ageing checkout needed a full rewrite. An honest assessment routed them to a modernisation instead, at a fraction of the rebuild's cost.
- Rebuild avoided
- Full rewrite scoped down
- Time to a named practice
- One week
A staffing request turned out to be a scoping problem.
Pillar Learning asked for three more engineers before anyone had agreed what those engineers would build. Naming the actual practice first saved a wasted hiring cycle.
- Hiring cycle avoided
- One full quarter
- Practice identified
- Scoped build, not staffing
We came in convinced we needed a full custom build. The honest answer was that our team needed two more engineers, not a project.
Sample · pending client approval
06Read this first
When a generic orientation is the wrong starting point
Sending every buyer through the same orientation wastes time for buyers who already know their practice. Three honest exits route straight past another conversation when the shape is already obvious. When a fuller scoping conversation is the right start instead, it can span web and mobile engineering, cloud, data and modernisation, depending on which practice actually fits.
- Custom software development
The build is already scoped and ready
When the outcome, budget and constraints are already named, a custom build practice fits better than another orientation conversation.
- Legacy modernisation
A live system needs care, not a rebuild
Modernising what already carries real load is a different discipline from building new, with its own risk profile and pace.
- Hire Developers
The gap is people, not a project
If direction is already set and the stack is already chosen, hiring into it moves faster than commissioning new work.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | The outcome and constraints are already clear | Acceptance and priorities | Delivery inside the chosen practice |
| Assessment first | The practice itself is still the open question | Which constraints matter most | A named recommendation and next step |
| Team extension | Your leads already run delivery well | Architecture and standards | Named engineers and continuity |
07Straight answers
Asked before a practice gets chosen.
01How is this different from a custom software build?
Custom software development commits to building something specific. This category sits one step earlier, helping decide whether building is even the right answer before that commitment is made.
02Do you charge for the initial scoping conversation?
The first conversation about which practice fits is free and typically runs under an hour. Formal scoping with a written recommendation may carry a cost once a specific practice is chosen.
03What if two practices seem to fit equally well?
That happens more than buyers expect, especially between modernisation and extension. When it does, both practices meet the buyer together rather than competing for the same conversation.
04Can this route toward hiring instead of a project?
Yes, when the actual gap is capacity rather than direction. Team extension and dedicated development centres both sit inside this category for exactly that situation.
05How long before we get a recommendation?
Most buyers get a named practice within the same conversation, sometimes within a single call. A written recommendation with reasoning typically follows within a few working days.
06Is the recommendation influenced by which practice is easiest to sell?
No. The same team is available across every practice named here, so there is no incentive to push one path over the honest answer to your actual situation.
07What happens if our situation changes after we start?
Practices are not one-way doors. A build that reveals a staffing gap, or a hiring plan that reveals a scoping problem, can move to the practice that fits without starting over.