Implementation
Build an API
Your application receives a documented API for controlled reading and modification of one defined data area.
Implementation / Frontend development & interaction
VAT-exempt under section 19 of the German VAT Act
Build a web application interface
A web application receives up to five usable views for one defined workflow, connected to existing APIs.
US$4,499.00
Total price · one-offVAT-exempt under section 19 of the German VAT Act
- Develop one flow with up to five views from an approved design
- Connect up to five existing API endpoints
- Include loading, empty, error and permission states in the interface
Your enquiry is non-binding. An order is created only when you accept our quotation .
Image 1 of 4
Service scope
Your result
- One implemented workflow with up to five frontend views
- Connected existing endpoints and documented states
Included
- Develop one flow with up to five views from an approved design
- Connect up to five existing API endpoints
- Include loading, empty, error and permission states in the interface
- Flow testing, source-code handover and one shared correction round
Excluded
- New backend logic, database or authentication architecture
- Complete product conception and design of a new design system
- Native mobile app and offline synchronisation
Which projects does this service suit?
Suitable if …
- Backend and design exist, but the usable interface is missing
- A web app needs one connected workflow added
Not suitable if …
- The entire application, including backend, needs creating
- An open feature catalogue should be implemented without prioritisation
Possible overlaps with: Build a client portal, Build an internal tool, Build an MVP. 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 does my app design become a usable workflow?
A web-app interface connects views with data and actions. Users might select a case, edit details and then see its updated state. The package implements one such flow from existing design and connects it to available APIs.
This includes more than populated standard views. Empty lists, slow responses, invalid input and missing permissions need understandable behaviour. Actual permission checks and business logic must exist server-side. New backend functions are planned separately.
Data states determine interaction
A frontend must know whether data is loading, absent or missing because of an error. If these look identical, users cannot assess the situation. We define these states for the agreed flow and connect suitable actions.
A documented API describes server data and errors. Without this contract, assumptions arise on both sides. Before starting, we align endpoints, formats and permissions. An artificial sample-data demo is not considered a finished integration.
Does this sound familiar?
A backend is waiting for an interface
Data and endpoints exist, but the workflow is not usable yet. We implement agreed views in the existing project.
A new flow extends the application
The extension should fit navigation and components. We clarify which building blocks can be reused and which are new.
The demo covers only success
Prototypes often omit empty data and failed responses. A usable interface explicitly plans and tests these states.
How we approach it.
Align the flow and APIs
We map up to five views to available endpoints. Formats, actions and possible errors are clarified before implementation.
Develop views and data flow
The interface connects presentation with the existing API. Changes show loading feedback and are marked successful only after an appropriate server response.
Test roles and edge cases
We test the agreed flow using suitable data and roles. Handover and documentation name remaining backend dependencies.
After handover
The interface can present existing permissions clearly but does not replace server-side access control. This boundary is explicitly reviewed during API alignment.
The result is a limited flow within your application. Further views or changed data contracts count as additional work even when visually similar.
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?
- API endpoint
- An addressable server function through which the frontend reads data or triggers actions. Format and error behaviour must be agreed between both sides.
- Empty state
- A view without matching records. It explains, for example, whether nothing has been created yet or a search returned no results.
- Data contract
- The agreed request and response structure of an API. It prevents frontend and backend from expecting different things from the same data.
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 React mandatory?
No. We review the existing stack and requirements. A working application is not moved to another framework solely for this package.
Can you start with an unfinished API?
An agreed interface description may enable an early start. Finished integration and acceptance still require accessible endpoints and suitable test data.
Is the backend included?
No. The service connects an interface to existing functions. New business logic, persistence and server-side permissions are separate backend work.
Are error states designed?
Relevant states are agreed before starting and technically implemented. This does not automatically include a comprehensive new application design concept.
Is mobile use possible?
Agreed views are implemented for defined screen sizes. Complex tables or workspaces need deliberate mobile priorities beforehand.
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 views with states and a documented API Test data, test access and an agreed role model 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
Implementing a Figma design as a website: preparing the handover
A desktop design is rarely enough for implementation. Clarify content, narrow layouts and the states of interactive elements.
Read the guide ↗Related services
These may fit too.
Implementation
Build an MVP
We turn a clearly scoped product idea into a first usable web application, with one core journey, an interface and a backend.