Plan custom software with clear results
An unusual workflow does not by itself justify a new application. First examine existing products or extensions. Where custom development is appropriate, the project needs understandable goals and testable results.
Define the goal and first version
Describe the main workflow from input to expected result. Who uses the application, and which task is inadequately supported today? A feature list becomes useful once those relationships are understood.
Separate the first usable version from later ideas. A study or prototype can answer questions without being a fully operational application.
| Project stage | Useful result |
|---|---|
| Idea | Checked workflow and open questions |
| Prototype | Tested use and feasibility within agreed scope |
| First version | Usable core functions, tests and operation |
| Further development | Bounded changes and checked existing behaviour |
Understand users and usage
Internal staff, customers and partners need different permissions and interfaces. Browsers, mobile devices, desktops and services without their own interface have different requirements. Technology should follow actual use.
Give a plausible scale and known peaks. A few concurrent internal users differ from publicly accessible use. Languages, accessibility and working without connectivity can also matter.
Account for existing systems and data
Clarify which application will remain, change or be replaced. Known versions, documentation and data sources help assessment. Migration and future access to old data should be defined.
For interfaces, clarify direction, responsibilities and errors. Initially describe data categories and required connections without real customer records, code archives or credentials.
Agree quality and acceptance
Connect each important function to an observable result. Define testers, examples and defect handling before approval. Reliability, access permissions and data protection belong in early requirements.
Agree demonstrations and tests for workflows, limits and errors. Security verification complements functional testing; neither an attractive interface nor a general security promise replaces it.
Plan operation and handover
Define who manages environments, backups, updates and incidents. Where personal data is involved, examine operating locations, access and responsibilities together. Completing development does not automatically settle these tasks.
Explicitly agree usage rights, project access, documentation and handover services. Account for component conditions and how another professional could take over later.
Compare development and future costs
Analysis, design, implementation, connections and tests may be separate services. Comparable quotes state assumptions, exclusions and change handling. A fixed price only makes sense with its defined scope.
Also compare operation, maintenance, third-party services and future development. Agree understandable stages and decisions about additional work. A price for another project is not a general Swiss cost rule.
| Cost area | Distinguish services |
|---|---|
| Preparation | Analysis, design and technical clarification |
| Development | Functions, connections, migration and tests |
| Operation | Environments, third-party services, backups and support |
| Continuing work | Maintenance, changes, documentation and handover |
Prepare the enquiry and collaboration
Workflow, audiences, channels, scale, systems and intended operation support an initial assessment. Describe priorities and project stage in one common brief without confidential documents or passwords.
Then clarify open points in a bounded analysis. Define first delivery and acceptance cases, test a prototype with future users and deliberately decide further stages.
Frequently asked questions
Must we immediately build our own application?
No. Assess standard products, configuration and extensions against the required workflows.
Does the first enquiry need a complete specification?
No. Goal, users and main workflows support initial assessment. Detailed specification can be part of an agreed analysis.
Must we choose a programming language?
Only where an existing environment or requirement demands it. Otherwise use, integration and support should guide the choice.
Is a prototype production-ready?
Not automatically. Agree whether data storage, security verification, operation and error cases are included.
Do we automatically receive every right and access?
Explicitly agree these, including component terms, project access, documentation and future takeover.
Which costs follow development?
Depending on scope: operation, third-party services, support, updates and new features. Have these described separately.
