Frequently asked questions

In practice it is usually one of these situations: an SME has an existing solution that nobody really looks after any more, and no IT department of its own to step in. A growing organisation realises that a website and individual tools are no longer enough, and that a platform, integrations and stable operation are needed. A municipality or administration needs a website, a portal or a specialist application that meets the requirements for data protection, accessibility and operation in the public sector. Or a project team has capabilities of its own and brings us in specifically for backend, infrastructure, integration or UX/UI – including alongside an existing agency or general contractor.

In terms of size, that ranges from a technical analysis lasting a few days to platform projects that we develop further and operate for the long term. There is no minimum budget. We are based in Switzerland and work for organisations throughout Switzerland and across Europe, particularly in Germany, Austria and Hungary; we run projects in German, English and Hungarian.

It helps if you tell us briefly in advance what it is about: the situation, existing systems, the desired timeframe and any known constraints such as a budget range, an ongoing procurement procedure or political deadlines. It is also important for us to know who makes the decision on your side. On our side, the consultation is attended by the person who will later be responsible for your project – in other words, someone who can answer your questions technically.

At the end of the conversation you receive our assessment of whether we are the suitable partner for you. If we are, either a quote follows directly (when the scope is clear) or we propose a short analysis phase (when it is not). You normally receive a quote within five working days; it is valid for 30 days.

Quotes, contracts and documentation are binding, and we only write binding documents in languages in which we can judge every wording ourselves. That is why this also applies to enquiries made through the French or Italian version of this website. In the contact form you choose the language in which we reply to you.

This restriction does not apply to the content of your website or application. We produce translations into other languages as standard. If you would rather provide us with your own translations – for example from your communications department or a translation agency – we build them in.

For this we are happy to offer you one or more workshops with your specialist staff and, where it exists, your IT team: what should be achieved, who uses the solution, which processes depend on it, which technical constraints apply? The result is a prioritised list of requirements (must / could) with an initial effort estimate.

The result belongs to you and is deliberately structured so that it remains usable without us: as a basis for internal decisions, for a funding or budget request, or as the basis for a requirements specification in a tender. For public-sector clients one caveat applies: if we help draw up the requirements specification for a procurement procedure, that may constitute prior involvement, which can restrict our later participation. We raise this openly before we begin.

A separate analysis makes particular sense when the state of an existing system is unclear, when the decision between modernisation and a rebuild is pending, when the effort can only be estimated seriously after a look at the code and infrastructure – or when you are preparing a tender and need a sound basis for it.

Depending on the case, the analysis covers code, architecture, infrastructure, security, data flows and the third-party providers in use. It ends with a written report: current state, assessment, options for action with an effort estimate, and a clear recommendation. The report is written so that another provider can work with it too.

That first step is an inventory: we secure the access credentials (hosting, domain, code repository, administration areas), gain an overview of the code, architecture, infrastructure, dependencies and data flows, and document the current state. From that comes a risk assessment: where are the security gaps, which components are outdated, which licences are affected, and so on. On that basis we can proceed, for example, as follows: stabilise and operate, modernise step by step, or replace – or differently, depending on the state of the system.

What we need from you is above all the existing access credentials and a contact person who knows the system from a user's perspective. If a change of provider is due, we accompany the handover. And if we come across critical security problems during the analysis, we inform you without delay and agree on immediate measures before we continue.

Which procedure applies depends on the contract value and on the procurement law of your canton (the intercantonal agreement on public procurement, IVöB, and the cantonal implementing acts). Contracts of this size often fall within direct award or the invitation procedure; we take part in open tenders via simap.ch. We work with the contract and terms-and-conditions templates of the public sector; we clarify any diverging points before signing. If we have already supported you in defining the requirements, we address the question of prior involvement openly before a procedure begins.

Some of the biggest cost drivers are usually the range of functions, the number and complexity of the integrations, the data migration, the design ambition, the target standard for accessibility and the security requirements. Hosting, licences and third-party services are always shown as separate items; the ongoing operating costs are stated separately from the project costs.

A quote from us contains the defined scope, the assumptions, the services included and not included, the schedule and the payment terms. For municipalities and public bodies we provide figures suitable for budget and funding requests – a cost ceiling, separated into one-off and recurring costs – and on request we divide projects into phases that can be spread across several budget years.

A fixed price requires that requirements and acceptance criteria are set down in writing. Anything beyond that is handled as a change request. The advantage is planning certainty: you know the amount before implementation begins and can budget and apply for it.

On a time-and-materials basis we work with transparent time tracking, a contractually agreed cost ceiling, regular reports on effort and remaining budget, and the option to end the project at the agreed points. You receive proof of effort in either model.

In practice we often combine the two: a fixed price for analysis and concept, then a fixed price for the implementation on the basis of that concept.

Behind that stand a few fixed mechanisms: a written scope document with acceptance criteria, a prioritisation into must and could, openly declared reserves instead of hidden buffers, regular reports on effort against budget, and an early warning as soon as a deviation of more than 10 per cent becomes apparent – long before the budget is reached.

Changes during a project are normal: framework conditions shift, something happens in the market or in legislation, new requirements arrive from outside – that cannot be fully foreseen. In iteratively run projects we prefer to exchange new requirements for less important ones rather than adding them. For municipalities this is particularly relevant: a supplementary credit is politically delicate, and we give notice early enough for it to remain avoidable.

After the kick-off, in which roles, communication channels and decision-making processes are established, we work in two-week iterations. After each iteration we make the current state available to you – on a test environment if you wish – so that you can follow the progress yourself. We record decisions in writing; requirements and changes are managed in a system that both sides can see. Milestones conclude with a formal acceptance. Before go-live come the acceptance tests and, where needed, training; for the launch phase we agree increased availability on request.

How long a project takes depends mainly on the scope of functionality, the technical complexity and the integrations required. The availability of content and data, and how quickly decisions and approvals are made, also affect the schedule.

After the analysis, we draw up a project plan with the planned phases and milestones. For larger projects, we can split the implementation into several stages, so that the first functions can already be used while other parts are still being developed.

For public-sector clients, the duration of any procurement procedure must also be taken into account.

This person is your counterpart for deadlines, budget and decisions as well as for specialist and technical questions – without a detour via minutes or another party. A deputy who knows the project is arranged for periods of absence.

After go-live, contact does not move to an anonymous hotline: support requests go through our ticket system, by email or by telephone and reach people who know your system. Wherever possible, the same people look after a system from the project into operation – that is one of the reasons we offer operation at all.

Three roles matter, and they can also be held by one person: someone who decides on budget and approvals; someone who knows the specialist processes and content and tests interim states; and an IT contact for access and infrastructure – which can also be your external IT service provider.

The effort is distributed unevenly: in the analysis phase we need you intensively, during implementation only occasionally for queries and interim acceptances, and more again at acceptance. If your capacity is tight, we take on additional tasks such as content migration, coordination of the tests or even project management on your side. We are happy to run workshops on site with you as well; where it makes sense and your infrastructure allows, also remotely – which saves time and cost. The ongoing exchange usually takes place remotely.

We know HERMES and follow it: in such projects we deliver the prescribed results in the prescribed form – from the study through concept and realisation to deployment – and fill the roles your project manual provides for. An agile approach within the HERMES phases is possible and is common today. In Scrum environments we take on the corresponding roles and work in your sprints and tools.

When working with your internal IT or your existing IT service provider, we clarify responsibilities at the start – typically the service provider operates the infrastructure and we operate the application. Alongside an agency or a general contractor we take on a clearly delimited part, such as backend, infrastructure or integration. If your own development team is to take over the solution later, we plan documentation, joint work on the code and training in from the start.

The following reasons usually speak for a rebuild or relaunch: the technology in use no longer receives security updates, the architecture cannot carry the new requirements, every extension becomes disproportionately expensive, or the operating costs exceed those of a new system. If none of that applies, we proceed step by step: first secure the system (updates, backups, monitoring), then replace individual components – a frontend, an interface or the database – and, where needed, consolidate several solutions that have grown separately into one system.

The advantage of this path: operation continues, the costs are spread across several budget years, and the first improvements are felt quickly. The price for it is a transitional phase with a mixed system, which has to be properly documented. Which option suits you is your decision, based on a transparent comparison of costs, risks and benefits that results from our analysis.

Among other things, we work through the following questions with you: does this process set you apart from others, or is it interchangeable? Does a standard product cover 80 per cent of the need without contortions? How do licence costs over five to ten years compare with development plus operation? Are there requirements regarding data sovereignty and data location that standard products cannot meet? And how many existing systems have to be connected?

Typical cases for individual solutions are customer portals and self-service platforms, internal specialist applications, the automation of processes with media breaks, and integration layers between ERP, CRM and specialist systems. Often the best answer is hybrid: a standard product as the basis, extended by an individual component exactly where it pays off.

We distinguish two things: a prototype makes flows and interfaces visible early, so that they can be tested with real users – at Woop Technology it is usually created directly in code rather than in a separate design tool. An MVP is already usable in production, deliberately reduced to the essentials. Both can make sense; often one follows the other. If a surrounding system is missing – a test ERP, for instance – we simulate it on the basis of its interface description, so that development does not have to wait for it.

So that the MVP does not become a technical bottleneck, we pay attention from the outset to a modular architecture, clean data models, documented interfaces, established technologies and automated tests. What is to be added later we plan as phases in a roadmap – which also allows the budget to be spread across several years. After the MVP we evaluate feedback together, re-prioritise and continue development.

An integration usually starts with an interface analysis: which data flows in which direction, how up to date does it have to be, which system is the leading one? If a system offers no modern API, there are usually other ways: regular exports and imports, synchronisation at database level or – as a last resort – automation of the user interface, in which a script operates the application the way a member of staff would, for example to export data regularly. With proprietary systems we work together with the manufacturer.

For single sign-on we integrate existing identity and access management systems via the common standards OpenID Connect, OAuth 2.0 and SAML, so that your staff can use the credentials they are used to. Interfaces we develop ourselves are documented according to the common standard (OpenAPI), so that they can later be developed further independently of us. We migrate data from legacy systems including clean-up.

It starts with an inventory: content, data, URLs, integrations, domains, DNS records and email services. We migrate content and data, carry out test migrations and reconcile the results before the productive migration takes place. On request we provide a staging system – for the duration of the project or permanently – on which you can check the new state in advance; it is blocked for search engines, and everything else can be tested there. For search visibility we draw up a redirect plan (301 redirects for every previous URL), update sitemaps and monitor error pages, rankings and logs after go-live.

The switchover itself takes place in a window outside peak usage. The old system stays operational until after acceptance, so that we could switch back at any time. Where necessary, existing interfaces run against both systems during a transitional phase, until all dependent processes have been switched over.

Depending on the solution we use unit, integration and end-to-end tests, supplemented by performance tests and checks on various browsers and devices. Every change automatically runs through the tests and a review by a second person before it is released. We recommend a test environment, on which you can check interim states yourself, for the duration of the project; it is commissioned separately and can be switched off again afterwards.

Acceptance follows criteria agreed in advance: you test during a defined phase, faults found are classified by severity and remedied within set deadlines, and go-live takes place only after your approval. We record technical decisions in short architecture decision records (ADRs); at the end you receive technical documentation and an operations manual.

For municipalities and public bodies there are legal requirements on accessibility, which differ from canton to canton; the Swiss standard eCH-0059 refers to WCAG 2.1 AA for this. If accessibility is part of the assignment, we take it into account as early as the design stage (contrast, structure, focus handling), during development (semantic HTML, keyboard operability, correct markup of forms and components) and in testing: automated tests, manual tests with keyboard and screen reader and, on request, an external audit by an independent specialist body. Accessibility can be agreed as an acceptance criterion.

We assess existing websites in an audit and show what needs to be done. The components we deliver are built to be accessible; whether a page stays that way is decided afterwards in the editorial work – in the choice of components, in alternative texts, heading structure and uploaded documents. That is why we train your editorial team in creating accessible content and provide technical support for the accessibility statement. Please also note that third-party content and existing stocks of PDFs may not be able to be made accessible at the push of a button.

A maintenance agreement with us covers regular updates of the operating system, frameworks, libraries and dependencies, including the prompt closing of known security gaps; monitoring with alerting, so that we notice faults before you or your customers do; backups with tested restores; announced maintenance windows; documentation of all changes to the production system; and, on request, an operations report covering availability, updates applied and open items.

We also take systems into maintenance that do not come from us – after an assessment, so that we know what we are taking responsibility for. Taking over operation runs in three steps: analysis, securing the current state, transfer into regular operation. You can also commission operation and maintenance from us without a preceding development project.

An operating flat rate typically covers hosting and infrastructure, maintenance (security and framework updates, monitoring, backups), a support allowance and the agreed response times. Third-party licences are invoiced separately, as is further development that goes beyond operation.

For your budget planning we provide a fixed figure for the recurring costs, normally with a term of twelve months and three months' notice.

Support requests are prioritised by impact:

For each level, a response time and a target time for resolution apply, both set out in the contract. Reporting channels are the ticket system, email and telephone, and if a fault is not resolved within the expected time, an escalation process applies up to management level.

Outside support hours, monitoring continues to watch the systems and raises alerts automatically; the alerts are processed on the next working day unless on-call availability has been agreed. Critical security gaps in components in use are closed within 48 hours as standard, independently of the regular maintenance cycle. Recovery time (RTO) and maximum data loss (RPO) can be agreed contractually.

Which option makes sense is something we recommend to you on the basis of the data being processed: for a website with no special protection needs, a location in the EU is the cost-efficient choice and unproblematic in data protection terms; transactional email is sent via AWS SES with processing in Ireland. As soon as personal data from an administration, particularly sensitive data or cantonal requirements are involved, we recommend Switzerland as the location for data and processing – we then select every service involved, from the data centre to the email dispatch, so that data and access do not leave the country. Our own infrastructure is currently located in Germany, that is within the EU; monitoring and logging run there too.

Backups are created daily and stored encrypted at a location separate from operation. As a standard policy we retain them for 30 days; depending on the system and backup method a longer retention applies, and older states are cleaned up regularly. Restores are tested; we define the interval per system. Logs are rotated and backed up encrypted; monitoring data is generally non-critical. You receive a list of the subprocessors in use on request and as part of the data processing agreement. Where individual services – for sending email or for development tools, for instance – could process data outside the chosen location, we disclose that and offer an alternative if your requirements call for one.

You can also stay with your existing hosting infrastructure or have us operate your own cloud or server environment. Hosting and development can be obtained separately. And because we rely on standard technologies, changing hosting provider later is possible without redevelopment.

A data processing agreement (DPA) is needed as soon as we process personal data on your behalf – in hosting and operation therefore practically always, in pure development with test data usually not. Which data we actually process depends on the solution and is set out in the contract. Privacy by design applies in development and operation: data minimisation, an access model following the principle of least privilege, encryption in transit, encrypted backups, separate environments and no production personal data in development and test systems. Our technical and organisational measures are documented and available for you to inspect.

After the contract ends, your data is exported and handed over, then deleted within 30 days as standard – with written confirmation. For a data protection impact assessment or a prior check under cantonal law, we provide the technical input. And if you want to know what data your existing website sends to third parties today – tracking, fonts, maps, embeds – we analyse that and show what should change.

Access to your systems is personalised, protected with multi-factor authentication wherever possible and withdrawn immediately when a staff member leaves. Administrative access is limited to a few people and is traceable. Passwords, API keys and other secrets are never held in the code but in a system intended for them. Every change goes through a code review, dependencies are checked automatically for known vulnerabilities, and we apply critical security updates within 48 hours as standard. For higher protection needs we carry out security reviews and, on request, organise external penetration tests.

If an incident does occur, a defined process applies: detection through monitoring and alerting, containment, information to you within 24 hours with a named contact person, remediation, recovery and subsequently a written report with cause and measures. Where there are reporting obligations towards the Federal Data Protection and Information Commissioner or the cantonal data protection authority, we support you with the necessary information. You receive our security measures in documented form – for a supplier assessment, for example.

The distinction matters to us because it is often blurred in supplier assessments: the certification of the data centre covers physical security and the operation of the infrastructure. For everything above that – the application, the access, the development process, the handling of your data – we are responsible, and no external certification applies to that.

What we provide instead: a documented security concept, the list of technical and organisational measures, completed security questionnaires from your organisation and a self-declaration for procurement procedures.

As standard you receive the complete source code at the end of the contract at no additional charge, together with the documentation – as a complete state without version history, with which you or another provider can continue development; for a pure development project, that means on its completion. Anyone who wants insight during the term can commission a mirror repository with read access, which we update with every release – a separate effort that is invoiced separately. Our own reused components are marked as such: for these you receive a non-exclusive, perpetual right of use within your solution – including the right to modify them and to commission third parties to do so – as well as their source code in the state deployed. We document the open-source components used together with their licences, so that you always know what is in your solution.

The documentation covers setup, architecture, interfaces and operation – written for people who have never seen the system before.

What that means in concrete terms: your data can be exported completely, in the formats provided for by the technologies in use – database dumps, structured exports, files in their original form. Interfaces are documented. The application is containerised; with the code you receive the associated container definitions, so that you can build new versions independently. An operations manual describes the system requirements and recommendations for operation. And we build in no dependencies on components that cannot be transferred.

A change of provider runs as an orderly handover with a transitional phase in which we answer the new provider's questions. For that we charge the actual effort at the normal hourly rate – there is no «exit fee». For the case that we ourselves drop out: the documentation is current, every system is known to several people at Woop Technology, and on request we agree a mirror repository or the deposit of the code with an escrow agent. At the end of the contract you receive code, data, documentation and confirmation of deletion for everything that remains with us.

After the project you can decide, among other things, whether we operate the solution completely; whether we take on maintenance while hosting stays with your current provider; whether you commission us only as needed for further development, for example through an allowance of hours; or whether your internal IT or another provider takes over – with handover, training and a transitional phase in which we remain available for questions.

In every case you receive the complete documentation when the project is concluded. We continue to support your own development team after the handover on request, and we train your staff – editorial, administrative or development – so that they can use and maintain the solution independently.