Can you deliver well if you have not worked in our industry before?
A team without prior experience in a particular industry may still deliver strong general software, but unfamiliarity is a real project risk. We should prove our understanding through structured discovery, domain-expert confirmation, and representative cases before committing to full development—not promise that industry knowledge makes no difference.
Authentication, permissions, workflows, notifications, reporting, and integrations recur across sectors. Terminology is the easy part. The difficult omissions are regulatory accountability, pricing rules, exception paths, offline handoffs, data standards, and expert judgement that experienced staff consider too obvious to document. The supplier contributes software engineering; the client and qualified specialists own domain truth. Requirements are a joint responsibility.
When turning a business goal into an executable scope, also compare Why launch the core product first and iterate from real feedback?; the linked guidance adds context that should be considered in the same decision.
| Project type | Can an unfamiliar team enter? | Minimum evidence | Decision |
|---|---|---|---|
| General internal tool | Usually | Current workflow, roles, sample records, user test | Prototype narrowly, then build |
| Core industry operations | Assessable, with higher risk | Full lifecycle, exceptions, master data, interface proof | Paid discovery or pilot first |
| Regulated or safety-critical system | Not on general experience alone | Requirements matrix, qualified experts, verification and audit plan | Decline critical scope if expertise is missing |
| Replacement of a standard product | Deep custom expertise may be unnecessary | Product coverage, configuration gaps, migration sample | Validate procurement first |
A training provider's registration form is not the same risk as regulated enrolment and fee handling. Displaying equipment status is not equivalent to remotely controlling safety-critical machinery. The project must identify which judgements software may make and which require confirmation by the client's accountable owner or licensed professional. Wavesteam should not use a case from another sector to imply undisclosed domain credentials.
Discovery follows complete real cases before discussing screens. Walk a normal case through trigger, capture, review, delivery, settlement, and support, then add common, easily missed, and high-loss exceptions. Interview frontline operators, supervisors, finance or compliance staff, and end users. Collect redacted forms, decision rules, interfaces, and historical errors. Map who acts under which conditions, what evidence they need, and how failure is handled; then replay the process using examples the client recognizes. The client's ability to find errors in our model matters more than our ability to repeat vocabulary.
Test understanding with counterexamples. A prototype should cover cancellation, duplicate submissions, retrospective changes, departed staff, missing data, and external-interface failure. Let real users complete tasks without coaching and record completion, hesitation, errors, and divergence from the present workflow. Benchmark recognition, algorithms, or calculations blindly on client samples. For regulated scope, have the client's designated legal, quality, or industry expert confirm applicable requirements in writing.
Only price full construction when both sides can name the core journey and three highest-loss exception classes, system-of-record ownership, the sources of regulatory or contractual rules, remaining assumptions, and first-release acceptance. Pause if critical experts cannot participate, representative cases are unavailable, legal scope is unclear, or the prototype still reveals material disagreement.
Wavesteam's case studies can indicate experience with adjacent systems, but they are provider claims, not a substitute for interviews, expert qualifications, or pilot evidence. In an unfamiliar sector, discovery artefacts, unresolved questions, and exit conditions should belong to the client and remain usable even if another team performs the implementation.