Discover the workflow before defining features
Start discovery with the people doing the work, including those handling exceptions after the standard process breaks. Ask them to demonstrate recent tasks using their current spreadsheets, inboxes, and systems. Record the trigger, required information, decision, handoff, and completion evidence for each task. In the hypothetical service portal, submitting a request is only the beginning; triage, scheduling, access arrangements, cancellation, and disputed completion all affect scope and operational responsibility.
Turn those observations into a workflow map with explicit states and transition rules. A request might move from submitted to assessed, scheduled, in progress, and completed, with separate paths for rejection or reopening. Identify who can authorize each transition and what evidence must accompany it. This exposes hidden requirements, such as whether a coordinator may reschedule a technician without customer approval or whether completed work remains editable after invoicing.
Agree on the operational problem before approving a feature backlog. Define a baseline you can actually measure, such as time spent locating attachments or the number of requests returned for missing information. Do not promise improvement percentages without evidence. Separate essential workflow changes from convenience features, and document excluded processes. A signed boundary around dispatch, billing, and customer communication is more useful than an expansive list of vaguely described screens.
Decide what to build, buy, and integrate
Evaluate existing products against the workflow map rather than a long feature checklist. A packaged service platform may handle routine scheduling adequately while failing a distinctive approval sequence. That does not automatically justify rebuilding everything. Consider configuring an existing product, adding a focused custom interface, or building only the differentiating workflow. Include operational effort in the comparison: configuration maintenance, duplicate entry, supplier coordination, and staff training can outweigh an attractive initial implementation proposal.
Ask bidders to show the consequences of each option across an agreed planning horizon. Compare licensing assumptions, implementation boundaries, integration work, support responsibilities, export capabilities, and expected change effort. Avoid treating custom software as free of recurring costs; hosting, monitoring, dependency updates, and maintenance still require ownership. Equally, do not dismiss purchased software because customization is limited when changing an internal process could solve the actual problem more simply.
For the hypothetical portal, a sensible boundary might retain an existing billing system while creating a tailored request and approval experience. Test that boundary against failure conditions. If billing is unavailable, can a coordinator still schedule work, and where does the pending invoice wait? Require a short decision record explaining why each capability belongs in the custom application, a purchased tool, or an integration, including assumptions that would trigger reconsideration.
Specify roles and permissions as business rules
Role names alone do not define access. A technician may view assigned jobs but not every customer record; a customer administrator may manage colleagues without seeing another company’s requests. Build a permission matrix across actions, record categories, ownership boundaries, and workflow states. Include viewing, creating, editing, approving, exporting, and deleting. Where multiple customer organizations share a portal, separation between their records must be an explicit requirement, not an assumed platform property.
Describe sensitive permissions with concrete examples. Can a coordinator change a completed job, download all attachments, or impersonate a customer for support? Who grants those powers, and how are they withdrawn? Separate ordinary operational access from emergency administration. Define account invitation, departure, suspension, and periodic review processes. Without these lifecycle rules, even a carefully designed permission matrix can become inaccurate as staff change duties or contractors finish their assignments.
Require permission enforcement on the server, not merely hidden buttons in the interface. Acceptance tests should attempt prohibited actions through direct requests and altered record identifiers. Specify which events need an audit trail, including approvals, access changes, and significant edits. Decide who can inspect that history and how long it remains useful. Logging every detail indiscriminately can create unnecessary exposure, so capture accountable actions without routinely storing credentials or sensitive content.
Design the data model and rehearse migration
Map the business entities before agreeing screen designs. In the hypothetical portal, customers, sites, assets, requests, appointments, work records, and attachments are related but distinct. Combining them into one flexible record may look efficient initially while making reporting and permissions fragile. Establish stable identifiers and clarify whether a request can involve several assets or visits. Those relationships determine how the application handles repeat work, shared locations, historical reporting, and future integrations.
Create a data dictionary covering meaning, format, mandatory status, ownership, and retention decisions for important fields. Distinguish facts from calculated values and free text from controlled categories. Decide which system owns customer addresses and how changes propagate. For existing information, profile duplicates, missing identifiers, inconsistent dates, and inaccessible attachments before estimating migration. Assign business owners to resolve ambiguous records rather than expecting developers to infer which conflicting spreadsheet is authoritative.
Treat migration as a repeatable process with reconciliation evidence. Run a trial import, compare record counts and relationships, and have users inspect representative histories. Plan the final change freeze or incremental transfer, including how newly entered records will be captured. Keep a controlled source snapshot and define what would trigger rollback. Buyers should approve the reconciliation method before launch, not discover afterward that successful import meant only that no technical error appeared.
Match the delivery approach to the workflow
| Approach | Best fit | Buyer check |
|---|---|---|
| Configure purchased software | Mostly standard workflows | Test exceptions and export limits. |
| Extend purchased software | A few distinctive interactions | Confirm extension and upgrade boundaries. |
| Integrate existing systems | Capabilities already exist separately | Verify ownership and failure handling. |
| Build a custom core | Distinctive rules dominate operations | Fund ongoing maintenance and recovery. |
Establish API ownership and failure behavior
An integration needs a business owner and a technical contract, not just an arrow between systems. For each connection, document the exchanged fields, direction, frequency, authentication method, usage limits, and expected response behavior. Identify who can authorize changes on both sides. If a supplier describes an integration as straightforward, request evidence that the required endpoint, access permission, and test environment exist before treating its delivery date as dependable within the project plan.
Define what happens when messages arrive late, twice, or out of order. Creating the same invoice twice is a business failure even if both API calls technically succeed. Agree how duplicate requests are recognized, which failures are retried, and when a person receives an exception to resolve. In the portal example, customers should see a truthful processing status rather than a false confirmation while an external system remains unavailable.
Keep integration accounts, credentials, and administrative access under business control wherever practical. Document API versions, transformation rules, test examples, and the support route for each dependency. Ask how changes will be detected before they break production, and who pays for necessary adaptations under the support agreement. A useful handover includes enough information for another qualified team to diagnose a failed exchange without reverse engineering undocumented assumptions from application code.
Validate a prototype with realistic tasks
Prototype the risky decisions before polishing every screen. Choose tasks involving unfamiliar users, complex approvals, or information that is difficult to correct later. For the hypothetical portal, test whether a customer can distinguish an urgent maintenance request from an ordinary booking and whether a coordinator can resolve incomplete information. Use realistic but fabricated records. Empty dashboards and perfectly formatted sample data conceal the scanning, interpretation, and prioritization problems users encounter in practice.
Give participants a goal rather than instructions that reveal the intended path. Ask them to book a visit with restricted access hours, explain a rejection, or find evidence from an earlier job. Watch where they hesitate and what they believe will happen next. Capture the severity of each problem and its consequence for the workflow. A preference for a different button color should not outrank an approval action users misunderstand.
Separate usability validation from technical feasibility. A clickable prototype can demonstrate understandable navigation but cannot prove integration reliability, permission enforcement, or acceptable performance. Commission small technical experiments for uncertainties that could change cost or architecture. Close the prototype stage with decisions: revised terminology, required information, confirmed workflow boundaries, and unresolved risks. This creates a defensible basis for scope rather than allowing attractive visuals to become an accidental promise of finished functionality.
Make security and accessibility reviewable
Ask suppliers to explain their secure development practices in terms you can inspect. NIST’s Secure Software Development Framework provides a set of practices that can be integrated into software development lifecycles. Use it to structure questions about protecting code, reviewing changes, addressing vulnerabilities, and maintaining releases. It is not a shortcut to a compliance promise. Request specific deliverables and accountable owners rather than accepting a broad statement that development follows best practices.
OWASP’s Application Security Verification Standard provides requirements for verifying application security controls. Ask the delivery team to identify the version and relevant requirements they propose to use, with a rationale suited to the application’s risks. Address authentication, authorization, input handling, session behavior, and file uploads explicitly. Agree how findings will be prioritized, corrected, and retested, and which unresolved issues would prevent launch. Automated scans alone should not constitute the entire security review.
Define accessibility expectations early enough to shape components and interaction patterns. Include keyboard navigation, visible focus, useful form labels, understandable errors, and status messages that assistive technologies can perceive. Test important workflows manually as well as with automated tools, including scheduling and attachment submission. If procurement specifies an accessibility standard, document its version, target, and evaluation scope. Describe evidence and remaining limitations accurately rather than promising universal accessibility or legal compliance.
Tie acceptance criteria to observable outcomes
Replace phrases such as user friendly, fast, and fully integrated with testable statements. An acceptance criterion should describe a starting condition, an action, and an observable outcome. For example, when an authorized coordinator assigns an available technician, the appointment appears in both permitted views and records the assigning user. Specify the alternative outcome when the technician is unavailable. This makes disagreement visible before implementation instead of leaving interpretation until the final demonstration.
Set performance expectations against stated conditions: representative data volume, concurrent activity, network assumptions, and the journeys being measured. Identify which response times concern the application itself and which depend on outside systems. Establish supported browsers and devices without implying a separate native application. Include operational acceptance too, such as usable audit records, successful exports, documented deployment steps, and support access. A working interface is only one part of a deliverable business system.
Create an acceptance process with named reviewers, realistic test data, defect categories, retesting rules, and a decision deadline. Connect payment milestones to agreed evidence and deliverables rather than subjective percentages of completion. Keep new requests separate from defects against approved criteria. When scope changes, record the impact on schedule, cost, dependencies, and testing. Business buyers should retain a traceable record of what they approved and what remains unresolved at release.
Plan deployment, observability, and launch support
Define how a reviewed change reaches production and who can authorize it. Separate development, testing, and production environments, with appropriate controls around credentials and business data. Require repeatable deployment instructions and a release record identifying what changed. Consider whether database changes remain compatible with the previous application version. A rollback button offers limited protection if the new release has already changed information in a way the old version cannot interpret safely.
Observability should answer operational questions, not merely show that a server is running. Track failed submissions, stalled background jobs, integration errors, and unusual authorization failures alongside infrastructure health. Use request identifiers to connect related events without exposing unnecessary personal information. Agree alert thresholds, recipients, escalation paths, and coverage hours. An alert without an owner creates noise; a business process that silently stops while all servers appear healthy creates false confidence.
Choose a launch approach that matches operational risk. A limited pilot can reveal support needs before all customers depend on the portal, but parallel operation requires clear rules about which records are authoritative. Publish escalation contacts and prepare staff for common problems. Agree early support arrangements and review actual incidents after release. Expansion should follow evidence that users can complete tasks and the team can resolve failures, not merely the arrival of a calendar date.
Prove restoration and protect your exit options
Specify recovery objectives in business terms. How much recently entered information could be lost, and how long could scheduling remain unavailable? Translate those tolerances into backup frequency, retention, storage separation, and restoration procedures. Cover databases, attachments, configuration, and the dependencies needed to restart service. A database backup alone may not restore a usable portal if uploaded evidence, encryption keys, or essential account access are missing when the team needs them.
Require a restoration exercise into a controlled environment and inspect the recovered application, not just the backup job status. Verify representative records, attachments, permissions, and key workflows. Record elapsed recovery time and any manual steps that could delay a real incident. Assign responsibility for repeating the exercise after significant changes. Recovery claims should reflect observed tests and their limitations, including whether an external provider outage was actually part of the scenario.
Agree the exit plan before supplier dependence grows. Clarify contractual rights to code and documentation, third party license restrictions, repository access, infrastructure accounts, export formats, and transition assistance. Ask another qualified person to follow the setup instructions and inspect whether exported relationships remain understandable. Keep an up to date inventory of services and renewal owners. The goal is not to anticipate conflict; it is to preserve continuity when people, suppliers, or business priorities change.
