Let the intake deadline decide this release
A useful application can still be the wrong choice for the current intake. If an essential approval cannot occur before enquiries close, a custom portal cannot responsibly be presented as the route people should use now. That does not make the longer-term idea worthless; it changes the immediate decision.
This fictional example concerns a one-off employer workshop. The dates illustrate an agreed project sequence, not a delivery promise by Faith Forge Labs or a standard turnaround offered by any provider.
Put the dependency beside the real deadline
The workshop owner plans to close enquiries on 18 November. The proposed custom portal depends on a provider reviewing the organisation's requested account capability. In the inspected correspondence, the earliest confirmed review appointment is 24 November. Approval is not guaranteed at that appointment.
The owner already has an authorised enquiry channel that can receive workshop references, contact details and proposed group sizes. It supports staff replies and an export for the office's reconciliation. That capability is verified rather than inferred from the presence of a form.
The decisive comparison is straightforward:
| Milestone | Confirmed fact in the example | Consequence |
|---|---|---|
| Enquiries close | 18 November | Current customers need a working route before then |
| Earliest provider review | 24 November | The custom dependency cannot be resolved before closure |
| Existing authorised channel | Available for this workshop | Can be assessed for the current task |
A provisional design or a mock provider response cannot move the review appointment. The project should not turn that uncertainty into a public promise.
Verify the alternative as a complete task
The team rehearses the existing channel with two synthetic enquiries. E-21 asks about one attendee; E-22 proposes a group of six and includes a question about the published schedule. Each retains the correct workshop reference and contact. Staff can distinguish the individual and group requests in both the review screen and the permitted export.
An authorised staff member prepares the appropriate reply for each. The individual receives the office's next-step instructions. The group request remains subject to the office's assessment; the channel does not automatically promise six places. Replies and exports are checked in the provider's permitted test arrangement without contacting real participants.
The owner also reviews the closure behaviour. In the fixture, the existing channel supports a scheduled close with an approved explanation and an alternative contact for questions about an existing request. After closure, a new test enquiry is not accepted as part of the closed intake. E-21 and E-22 remain available to authorised staff for follow-up.
Make the bounded choice explicit
The owner selects the existing channel for this intake. The public workshop page links directly to it and explains what an enquiry means. Staff receive a short operating note covering review, reply, export, closure and unresolved requests. The proposed custom portal is removed from this release's critical path.
The choice has a cost: staff will perform the assessed reply and reconciliation work supported by the current arrangement. It also has a limit: the organisation accepts the inspected interface and export rather than the tailored experience originally imagined. Those trade-offs are preferable to opening a route whose essential dependency cannot be resolved in time.
No speculative portal is placed in front of the provider merely to make the existing channel look custom. An extra layer would introduce another receipt, support and failure boundary without changing the approval date that governs the decision.
Preserve what can inform a later project
The team retains the actual questions that the two fixtures exposed: individual versus group enquiries, schedule clarification, staff assessment and closure handling. It also records what the current channel cannot do. These observations can inform a future scope without committing the organisation to a build now.
The owner would reconsider a portal if several recurring intakes require shared account history or another demonstrated task that the existing channel cannot support, and if the necessary provider capability can be established before the next opening. Repetition alone is not approval; the later proposal still needs confirmed access, a complete operating model and a worthwhile outcome.
If the provider ultimately declines the requested capability, the design must be reassessed. The calendar does not turn an unresolved dependency into permission.
Bring the sequencing question into the first discussion
For your project, distinguish the date customers need a service from the dates on which content, access, approval and testing can actually occur. Name who controls each dependency. Then inspect whether a current, authorised route can satisfy the immediate task with acceptable limits.
The project planning page helps organise those facts. Sometimes the most useful technical decision is to keep a complete current journey working, document its limitations and reserve a larger build for a release that can genuinely support it.