The Internal Work a Custom Software Build Still Needs

Buying a custom software build does not remove the work only your organisation can do. Before committing to a delivery plan, reserve internal capacity for decisions, accurate business content, access to representative users, acceptance reviews and preparation for launch.

The development fee and the internal workload are different planning questions. This guide helps a buyer make the second one visible without inventing a standard staffing percentage or assuming every project needs the same team.

Key takeaways

• Give internal work an owner and a delivery window, not just a stakeholder name.
• Separate the time needed to prepare an input from the time needed to approve it.
• Reserve review capacity around meaningful decisions rather than promising unlimited availability.
• Agree who resolves conflicting feedback before the delivery team receives it.
• Treat launch preparation and ongoing ownership as work, not as a date on the roadmap.

Start with the work, not an attendance list

A project can have a full kickoff meeting and still lack someone able to prepare its business inputs. Attendance does not tell you who will resolve a disputed calculation, supply approved terminology or check whether a proposed screen supports the real task.

The earlier guide to who should join software discovery addresses participation at the start. The next question is availability throughout delivery: what must each person produce, decide or review, and when?

Ask the prospective partner which inputs it expects from your organisation. Then test that list against ordinary workloads, leave and competing deadlines. A person named on a plan is not automatically available to fulfil it.

Some activities can be included in the development engagement. Others depend on internal authority or knowledge. Clarify that division in the agreed scope rather than assuming either side owns everything.

Put five kinds of internal work on the plan

Use this original Essential Designs workload table as a starting point. It is a planning recommendation, not a contractual allocation or a staffing benchmark.

Internal work	A concrete output	Question to settle with the delivery partner
Business decisions	One agreed answer to a rule or priority question	Who can decide, and who can act when that person is unavailable?
Content and reference material	Reviewed terms, instructions and representative examples	Who prepares the material, and what makes it ready to use?
User participation	Access to people who perform the relevant task	Who arranges participation without assuming staff can leave their work at any time?
Acceptance review	Consolidated feedback against an agreed task	Who checks the result, resolves disagreement and communicates the decision?
Launch and ongoing ownership	Agreed operational instructions and a named owner	What must your organisation prepare before people start using the application?

Avoid turning each row into a new committee. A small organisation may assign several responsibilities to one person. A larger one may need different owners for different workflows. The useful output is a workable allocation, not a particular organisation chart.

For a custom software development discussion, bring this table alongside the proposed features. It helps expose dependencies that a feature list alone does not describe.

Preparation time is different from approval time

Consider a fictional organisation replacing an internal request form. A delivery team asks for the labels, categories and routing rules that should appear in the new application.

The buyer might say, "Our operations lead will approve those." That still leaves unanswered who gathers existing forms, identifies conflicting versions and prepares a coherent proposal. Approval cannot substitute for the missing preparation.

Record two activities when necessary: someone prepares the input; someone with the right authority decides whether it is correct. They may be the same person, but the work remains distinct.

Do not send a collection of contradictory spreadsheets and describe it as an approved specification. Mark unresolved questions, identify the decision owner and agree how the uncertainty affects the next piece of work. The software requirements checklist can help organise those inputs without pretending every detail is already settled.

Negotiate review windows you can actually honour

"We will be available whenever needed" sounds supportive but is difficult to schedule. A more useful commitment describes how a review becomes ready, who receives it and when a decision can reasonably be made.

Ask which upcoming decisions are difficult to proceed without. Reserve time for those first. A short, prepared review with the correct owner can be more useful than a recurring meeting with no material to decide.

Before accepting a proposed window, check what the reviewer needs. They may need a demonstration, realistic examples or time with a colleague who performs the work. Delivery and review time are not interchangeable.

If the required availability is impossible, discuss the plan before work depends on it. Options might include changing the sequence, reducing the next release scope or assigning an empowered delegate. None should be treated as a guaranteed way to preserve the original date.

Consolidation is a responsibility of its own

Feedback from finance, operations and customer service can each be reasonable while pointing in different directions. Passing all comments to a developer does not resolve the business choice.

Name the person responsible for producing one internal position. Their job is not to hide disagreement. It is to distinguish a correction, a preference and an unresolved decision so the delivery team knows what it can act on.

For web application projects, this can be as concrete as agreeing which task the first screen supports. A screen should not acquire every requested field simply because nobody has authority to choose.

Use a small decision record: the question, available options, chosen direction, responsible owner and any remaining limit. Keep it proportionate. The point is to make the decision usable, not to create paperwork for its own sake.

Launch preparation belongs before the finish line

A working application still needs an organisation ready to use it. Decide who prepares internal instructions, explains changed responsibilities and confirms the route for reporting problems.

Also identify who will own business changes after launch. A development partner can help maintain software, but it cannot independently decide every future operating policy or business priority.

Before approving the delivery plan, ask: what must be ready inside our organisation for this release to be useful on its first working day? Record actual outputs rather than a general instruction to "manage change."

This does not require predicting every future task. It requires acknowledging that adoption and ongoing ownership need capacity, just as design and development do.

Make the buying decision with both workloads visible

Before committing, complete one page covering the five work areas. Add an owner, preparation needs, expected review window, delegate and unresolved questions. Ask the delivery partner to challenge any dependency that appears unrealistic.

The useful result may be a clearer allocation, a smaller first release or a different sequence. It should not be a confident timetable built on people who have no time to participate.

Discuss your software project and internal capacity with Essential Designs. Bring the proposed outcome and the work your organisation can realistically own.

Sources and scope

The UK government's service-team roles guidance distinguishes product priorities, decision authority, user research and content responsibilities in government delivery. It provides useful context for separating responsibilities; it is not a requirement that a private-sector buyer copy those roles.

The workload table, fictional example and buying prompts are original Essential Designs editorial recommendations. They are not client results, a staffing formula, a quotation of project terms or legal advice. Published and reviewed October 26, 2026. Recheck source links, service destinations and the planning examples by January 26, 2027.