Implementation
Build a component library
We build recurring interface elements as shared code components, with defined variants, states and documentation.
Implementation / Frontend development & interaction
VAT-exempt under section 19 of the German VAT Act
Modernise an existing frontend
We restructure a defined part of your existing frontend to make it easier to maintain while preserving the agreed user behaviour.
US$2,799.00
Total price · one-offVAT-exempt under section 19 of the German VAT Act
- Examine one frontend area with up to three views and five shared components
- Implement one predefined modernisation measure in the existing project
- Protect relevant behaviour with targeted regression tests
Your enquiry is non-binding. An order is created only when you accept our quotation .
Image 1 of 4
Service scope
Your result
- One modernised, defined frontend area with verified behaviour
- Documentation of the change, dependencies and useful follow-up work
Included
- Examine one frontend area with up to three views and five shared components
- Implement one predefined modernisation measure in the existing project
- Protect relevant behaviour with targeted regression tests
- Document changes and conduct one shared correction round
Excluded
- Complete rewrite or replacement of every frontend technology
- New product functions or complete redesign
- Unlimited repair of historical bugs outside the agreed area
Which projects does this service suit?
Suitable if …
- A defined legacy area makes changes difficult or blocks a necessary update
- Duplicate components or outdated patterns need targeted replacement
Not suitable if …
- The entire application should be rewritten immediately without assessment
- The main aim is a new visual appearance
Possible overlaps with: Build a component library. 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
How can an older frontend improve without rewriting everything?
Modernisation starts with a specific problem: duplicated form logic, a hard-to-update module or tightly coupled views. We define one area and choose a suitable measure. The existing stack remains the starting point.
Before changing code, we record behaviour to preserve. The area is then revised gradually and checked against those flows. Modernisation is not automatically a visible redesign. Its result often makes affected code easier to understand, change and maintain.
Understand the problematic area before rebuilding
Old technology is not unusable merely because of age. What matters is which changes it obstructs and the risks involved. A limited restructuring may suffice where a complete rewrite would create new errors and long parallel phases.
We document dependencies and choose a testable boundary. Tests focus on behaviour to preserve. If the area cannot sensibly be isolated, we explain this before implementation and redefine scope.
Does this sound familiar?
Small changes affect many files
Scattered responsibilities can make maintenance harder. We examine a specific area and simplify its structure through one clearly defined measure.
A necessary update is blocked
One dependency or outdated pattern can block progress. The affected area is reviewed in isolation rather than replacing the whole project indiscriminately.
Duplicate implementations drift apart
Copied components develop different bugs. Targeted restructuring can consolidate shared logic while preserving agreed flows.
How we approach it.
Record the problem and reference behaviour
We reproduce the maintainability issue and document affected views. The measure and flows to preserve are defined before restructuring.
Restructure within limits and protect behaviour
The agreed area is modernised gradually. Relevant regression tests check behaviour and integration points touched by the change.
Hand over changes and remaining boundaries
You receive the revised version and an explanation of its new structure. Untouched legacy areas and possible next steps remain clear.
After handover
Compare the revised area with documented prior behaviour. Easier maintenance and faster execution are different questions. We report speed gains only with a suitable measurement comparison. Other application areas remain outside this review.
Describe what already exists: design, website or application. A specific journey with the views and states to develop or change is useful.
We then clarify which technology the site uses, where changes are tested and how they reach you. We also discuss missing content. Do not send repository tokens or production credentials through the enquiry form.
Terms used in this service
What does that mean?
- refactoring
- Changing internal code structure while aiming to preserve agreed external behaviour. It differs from a new feature or redesign.
- Regression test
- A check of already expected behaviour. It helps identify when a change unintentionally damages an existing flow elsewhere.
- Dependency
- A building block other code relies on, such as a library, shared module or interface to another area.
Before your enquiry
Questions about the offer.
What is included, what do you need and what happens after your enquiry?
The process in detail →Must the framework change?
No. A change needs a specific reason. We first check whether the problem can be solved within the existing stack.
Does the design stay the same?
Agreed user behaviour and appearance generally remain the reference. Desired visible changes are expressly identified and planned separately.
What if there are hardly any tests?
Meaningful reference cases are defined for the affected area and protected where needed. Complete coverage of the entire legacy application is excluded.
Is a version update included?
A limited update may be the agreed measure. Scope and compatibility are reviewed beforehand because major version jumps can affect several areas.
Can the whole frontend be modernised afterwards?
Yes, the revised area can provide a foundation. Further sections still need their own scoping and review; no automatic complete migration is promised.
When does work begin?
We confirm the start and delivery deadline in writing after reviewing your documents. The agreed scope and complete source data determine the schedule.
Which access is needed?
A working project version, repository access and reproducible development environment A specific maintainability problem and agreed reference flows 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
Building a component library: when is it worthwhile for the frontend?
Maintaining the same form field in several places: choose shared building blocks, integrate them into a real journey and adopt them gradually.
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.