Implementation
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.
Implementation / Frontend development & interaction
VAT-exempt under section 19 of the German VAT Act
Build a component library
We build recurring interface elements as shared code components, with defined variants, states and documentation.
US$3,349.00
Total price · one-offVAT-exempt under section 19 of the German VAT Act
- Develop up to eight agreed UI components in one existing frontend stack
- Implement variants and states from an existing design system
- Create a local component overview with usage examples
Your enquiry is non-binding. An order is created only when you accept our quotation .
Image 1 of 4
Service scope
Your result
- Eight or fewer documented reusable code components
- Example integration and guidance on extension and version maintenance
Included
- Develop up to eight agreed UI components in one existing frontend stack
- Implement variants and states from an existing design system
- Create a local component overview with usage examples
- Integrate into one representative flow and provide one correction round
Excluded
- New brand design or a complete Figma library
- Migration of all existing pages or several frameworks
- Unlimited component variants or permanent library maintenance
Which projects does this service suit?
Suitable if …
- Several views use the same elements through different implementations
- An existing design system needs reliable code implementation
Not suitable if …
- Design foundations still need developing
- All interfaces should be completely rebuilt simultaneously
Possible overlaps with: Modernise an existing frontend. 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 do we avoid building every button and form differently?
A component library contains shared code blocks for recurring elements. Changing an input field's error handling, for example, can reach every view using that component.
The package is limited to up to eight components and their agreed states. Selection follows genuinely recurring tasks. An existing design system supplies visual rules. The library is documented with examples and used in one representative flow.
Reuse needs clear boundaries and states
A component is not good merely because it offers every imaginable setting. Too many options make use and maintenance harder. We define its purpose and the variants actually needed. Arbitrary special parameters do not conceal differences between components.
Interaction matters as much as appearance. A field needs a label and error association; a dialog needs a clear focus flow. Requirements are agreed for each component. Documented examples show correct composition.
Does this sound familiar?
Similar elements behave differently
Separate implementations can diverge in focus, errors or loading states. Shared components make agreed behaviour traceable.
Design rules reach code inconsistently
Colours and spacing alone do not create a reusable interface. The library connects existing design rules with specific components.
New views should use existing patterns
Documented examples support further development. They explain when a component fits and which combinations are deliberately unsupported.
How we approach it.
Select recurring building blocks
We compare existing views and define up to eight components. Variants, states and a representative integration case are explicitly described.
Develop components and examples
Components are implemented in the agreed stack. A local overview shows permitted variants, content and interaction states.
Verify use in a flow
A specific integration checks whether component APIs fit everyday use. Handover explains extension, maintenance and areas not yet migrated.
After handover
The library provides a shared foundation for agreed components. Existing pages do not automatically use them; further migration needs planning.
Reuse does not eliminate every kind of effort. Maintenance, version changes and new requirements remain tasks whose ownership the team should clarify.
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?
- Component
- A reusable code block with a clear task. It combines presentation and, where relevant, behaviour, such as a button or input field.
- Variant
- An intended form of the same component, such as primary and secondary buttons. Not every arbitrary visual deviation becomes a new variant.
- Design token
- A centrally named design value, such as colour or spacing. Components use these values so shared changes remain controlled.
Before your enquiry
Questions about the offer.
What is included, what do you need and what happens after your enquiry?
The process in detail →Is a design system included?
An existing visual system is required. The package translates selected rules and components into code; brand development and a full Figma library are excluded.
What counts as one component?
A defined building block with agreed variants and states. A complex calendar is not equivalent to a simple text field and is scoped appropriately beforehand.
Do we need Storybook?
A local overview is included. The suitable tool depends on the existing project; new infrastructure is not assumed without a concrete need.
Are existing pages migrated automatically?
One representative flow is included. Further pages are not silently migrated; scope depends on special cases and technical dependencies.
Can the library serve several frameworks?
This package covers one agreed frontend stack. Multiple frameworks require separate implementations and tests, adding scope.
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?
Approved design rules, component list and existing stack Example views and agreed keyboard and state requirements 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.
Implementation
Build a website or landing page
We turn an approved design into a responsive website or landing page that works on small and large screens.