Questions that help define the work

These answers explain how we approach a possible engagement. Your proposal will identify the actual deliverables, responsibilities and review arrangements for the system involved.

Can you improve a site that already works in most places?

Yes. A Dutch enquiry route, a slow document view or an unreliable connection can be assessed as a limited task. We examine what depends on the affected component and what the business needs to preserve. A broader replacement becomes a proposal to evaluate, not an automatic consequence of finding one defect.

Do you need access to everything before we can talk?

No. A current public URL, a description of the task and an anonymised example may be enough to identify an initial investigation. Do not send credentials or customer records through the enquiry form. If protected access becomes necessary, its owner, purpose and appropriate method are agreed separately.

Can the website support both Dutch and English?

We can implement language editions, corresponding page routes and a publishing process that helps editors maintain them. The organisation identifies a suitable reviewer for Dutch wording and market-specific claims. Technical work and project conversations are in English unless other arrangements are agreed; a Dutch page does not imply Dutch-language customer support or certified translation.

Must every English page have a Dutch equivalent?

That depends on the audience and task. Important customer journeys may need both languages, while a specialist document may have only one approved edition. The interface should identify what is available and preserve the intended subject when switching. Linking every untranslated page to a different-language homepage can conceal the absence of an equivalent.

Can you connect our payment provider?

We first inspect the merchant's actual account, supported interface and permitted test arrangements. The scope defines how provider results relate to the order and how uncertain outcomes are investigated. We do not promise a method based only on a logo, or change commercial terms that the merchant has not approved. Webshop and payment work explains the relevant decisions.

How do you approach customer permissions?

We identify the organisation, participants, records and actions involved. Viewing a specification, adding a colleague and approving a proposal may require different permissions. The implementation needs server-enforced checks and tests for inappropriate access, including direct document addresses. A hidden menu item alone does not establish that a record is protected.

What if an integration produces no clear answer?

The project should define an unresolved state and an investigation route. We examine what the sending system knows, what the receiver can confirm and whether repeating the action is appropriate. A timeout message is evidence of an incomplete exchange, not automatic proof that no business record was created. The correct recovery depends on the supported interface.

Can you guarantee accessibility or legal compliance?

We can implement agreed improvements and document the checks performed. A task-level accessibility review, a specialist assessment and a legal conclusion are different forms of work. The organisation and its qualified advisers determine the requirements applicable to the service; the proposal identifies what development includes and where additional review is needed.

Can we use existing tools instead of commissioning a new application?

Often the useful first step is a content correction, a configuration change or a modest connection between tools already in use. We assess whether those tools support the required behaviour and whether their limitations are acceptable. Custom development is justified by the task and constraints, rather than by a preference for another dashboard.

How are cost and timing established?

The estimate depends on scope, access, source material, provider dependencies and the review required. An uncertain data relationship or inaccessible account may need investigation first. Bring a relevant deadline and explain what creates it; submitting an enquiry does not reserve capacity or confirm a delivery date.

What should we expect at handover?

For the components delivered, the handover should explain source and account ownership, configuration, ordinary changes, release steps and known limitations. It should distinguish tested behaviour from remaining provider or environment checks. Content editing, operational monitoring and continued support need named arrangements rather than assumptions about what follows launch.

Will the work guarantee more customers?

We can agree technical and workflow outcomes, such as a correctly recorded enquiry or a maintainable publishing process, and review the evidence for them. Revenue, demand and search performance depend on factors beyond the implementation. A proposal should state the result it can deliver without turning it into an unsupported commercial forecast.

Ask about your own situation, or read how a project is reviewed.