Analysis
Load time analysis
We measure up to three page types under documented conditions and show your developer where to start.
Implementation / Frontend development
VAT-exempt under section 19 of the German VAT Act
Frontend optimisation
Up to three agreed changes to your existing frontend. We work in a test environment and document the results.
US$1,699.00
Total price · one-offVAT-exempt under section 19 of the German VAT Act
- One predefined improvement goal after a suitability review
- A maximum of three agreed measures within the confirmed effort limit
- Implementation in staging or a separate branch
Your enquiry is non-binding. An order is created only when you accept our quotation .
Image 1 of 4
Service scope
Your result
- The agreed changes in a branch or staging
- Before-and-after test and notes for incorporating the change into your project
Included
- One predefined improvement goal after a suitability review
- A maximum of three agreed measures within the confirmed effort limit
- Implementation in staging or a separate branch
- Documented before-and-after test, handover and one written follow-up round
Excluded
- No unrestricted complete rebuild or new shop system
- No unrequested production changes
- No unlimited bug fixing or ongoing maintenance
Which projects does this service suit?
Suitable if …
- A specific finding and a limited implementation goal are available.
- Changes can be checked in a suitable test environment.
Not suitable if …
- The scope is open or requires a complete relaunch.
- You need 24/7 operations or an immediate change without review.
Possible overlaps with: Design implementation support. If you enquire about these services for the same project, we check for duplicated work before commissioning. Your selection also shows a notice.
What this covers
Can my website be improved without rebuilding it?
The menu responds slowly or the product page jumps while loading. If the problem is already defined, we implement up to three agreed changes to the existing frontend: the part of your website visitors use in the browser.
What handing over a change includes
Before starting, we define the problem and test conditions. For a jumping product page, for example, we record when the shift occurs. Implementation takes place in a test environment, also called staging, or a separate development branch. Your team can review the change before adopting it in production.
You receive the changes with a documented before-and-after test and adoption notes. The test report states which functions were checked. If the cause is still unknown, we first clarify the analysis required.
Does this sound familiar?
The analysis exists, but implementation is missing
The report identifies a slow selector, but nobody has time to fix it. We review the finding and define the behaviour the change should achieve.
An interface does not respond as intended
After invalid input, the form jumps upwards while the error message remains below. The fault is reproducible. We clarify which component and states need work.
You want to review a change before publication
Your website should remain accessible while work proceeds. The change is created in staging or a separate branch. Before starting, we clarify how your team will review and then adopt it.
How we approach it.
Define the goal and effort
We check whether the issue can be resolved through the agreed measures within the effort limit. Required access is clarified beforehand. If the scope is insufficient, we discuss this before additional work begins.
Implement in the agreed work area
We implement changes in staging or a separate branch. For handover, we record relevant dependencies and decisions so your team can review and adopt the change.
Compare before and after
We test the agreed behaviour under defined conditions and document what changed. This does not automatically approve other functions, browsers, security aspects or production conditions.
After handover
At handover, run through the documented test yourself and compare it with the agreed goal. The follow-up round clarifies open adoption steps; your team decides on publication.
Record a process we can reproduce: which page do you open, what do you click and what happens next? For operational questions, name the tools used and describe how changes reach the server.
Passwords, repository tokens and production data must not be included in the enquiry. We agree required documents and suitable access separately.
Terms used in this service
What does that mean?
- Frontend
- The part of an application you use in the browser, such as product selection, navigation and forms. It displays data and sends input to the responsible services.
- Staging
- A test environment for changes before publication. It should resemble subsequent operation as closely as possible; known differences are considered during testing.
- Branch
- A separate development state in version control. Changes can be worked on and reviewed there before the responsible team merges them into the shared state.
Before your enquiry
Questions about the offer.
What is included, what do you need and what happens after your enquiry?
The process in detail →Do you work on my existing team's code too?
Following a suitability review, implementation can take place in the existing project. Structure, access and adoption method must be agreed. A particular framework alone does not determine whether the goal can be addressed within the package.
Do changes go live on my website immediately?
No. Implementation is first provided in staging or a separate branch. Publishing is a separate step to agree. No unrequested changes are made to the running product.
Is ongoing maintenance included in the price?
The package covers the confirmed improvement goal and agreed measures. Ongoing maintenance, additional bug fixes and new features are not automatically included. Further work is separately agreed before it starts.
Do I need to use a particular framework?
State the framework, versions and deployment method in your enquiry. The suitability review determines whether the project fits the intended scope. A search result for React, Vue or another tool is not a blanket promise for every possible configuration.
What happens if additional problems appear?
Newly discovered problems do not automatically become part of the commission. We first clarify whether they concern the agreed goal or need additional scope. This keeps included work and decisions requiring separate approval clear.
When does work begin?
Suitability, the specific effort limit and the work window are confirmed before commissioning.
Which access is needed?
An existing frontend and a clearly testable goal Technical suitability and effort limit confirmed in writing before commissioning Authorised code and test-environment access only after commissioning Credentials must not be included in the enquiry. Details are agreed only after written commissioning.
What happens after handover?
One written follow-up round is included. The service scope lists the analyses, designs or technical changes covered by the package. We agree additional work with you before it begins.
Read more on this topic
Improving loading times: how can you assess the effort?
A faster page has no fixed monetary value. Connect measurement, the affected user journey and implementation costs to make a verifiable decision.
Read the guide ↗Related services
These may fit too.
Analysis
Technology and stack review
Do you really need a rebuild? We review an application's structure and explain what to keep or change.