Implementation
Build a web application interface
A web application receives up to five usable views for one defined workflow, connected to existing APIs.
Implementation / Backend development & data architecture
VAT-exempt under section 19 of the German VAT Act
Build a backend feature
We implement one clearly described business process on the server, with rules, storage and documented failure cases.
US$3,349.00
Total price · one-offVAT-exempt under section 19 of the German VAT Act
- Develop one function with up to five business rules and three status transitions
- Extend up to two existing data objects and one existing API
- Consider validation, permissions and retry behaviour in the existing system
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 backend function in the existing project
- Documented rules and tests for normal and rejected flows
Included
- Develop one function with up to five business rules and three status transitions
- Extend up to two existing data objects and one existing API
- Consider validation, permissions and retry behaviour in the existing system
- Targeted tests, documentation and one shared correction round
Excluded
- Complete backend, new user management or new external integrations
- Unlimited special cases or business rules left open afterwards
- New user interface and extensive data migration
Which projects does this service suit?
Suitable if …
- An existing application needs one clearly limited new function
- A manual status or approval process should be represented in the system
Not suitable if …
- The entire product should be developed without a defined core function
- Business decisions have not yet been made
Possible overlaps with: Build a booking application, 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 do we represent a business process reliably in the system?
Backend logic determines what an application may actually do. It checks input, saves changes and enforces business rules. The package adds one clearly described function to an existing backend, such as case approval or a controlled status change.
Before starting, we describe allowed actions and problematic cases. Who may trigger a change? What happens if the same case starts twice? Which data must be saved together? These questions shape the function more than visible button counts.
A status change is more than a new data field
Moving a case from open to approved may require several conditions: required fields, an authorised role or completion of an earlier action. These rules belong in the backend, not only the interface.
Related changes need appropriate processing. A partly saved state can contradict business rules. We test agreed transitions and failures in the existing system. External subsequent steps or new data areas are scoped separately.
Does this sound familiar?
A manual rule should become authoritative
A process currently depends on verbal instructions or spreadsheets. We transfer a clearly limited rule set into the existing application.
The interface allows contradictory states
Buttons alone do not enforce business rules. The new function checks allowed actions in the backend, including direct requests.
Retries create duplicate cases
The same trigger can occur repeatedly. For the specific function, we define handling of repeated and already completed actions.
How we approach it.
Describe rules and statuses
We record allowed transitions, roles and required data. Specific examples show when the function succeeds and when it must reject.
Integrate into the existing system
Rules connect to storage and the existing API. Related changes and possible errors are handled deliberately.
Test flows and boundaries
Tests cover agreed success and rejection cases. Handover explains rules, integration points and excluded follow-on functions.
After handover
Scope follows business rules and integrations. A short description such as ‘add approval button’ can hide several dependencies that must be made visible first.
Implementation takes place in the agreed existing context. Fundamental changes to authentication, data model or architecture are not automatically included side tasks.
Describe the intended function and an example of a successful process. Name existing systems and the roles involved without sharing real customer data or credentials.
After your enquiry, we clarify which data the function processes, which rules it must follow and which systems it must contact. Required documents and test access are agreed separately.
Terms used in this service
What does that mean?
- Business rule
- A business condition for an action. It defines, for example, when a case may be approved and which details are needed.
- Status transition
- An allowed change between a case's states. Transitions describe the flow and prevent contradictory business changes.
- Transaction
- A related data change completed or rolled back together within the capabilities of the system used.
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 suitable interface included?
No. The backend function supplies agreed behaviour. New views and interactions can be added through a suitable frontend offer.
Can emails be triggered?
An existing delivery method can be considered if part of the agreed function. New mail infrastructure or complex delivery flows add scope.
What happens with new special cases?
New business rules change scope. Before extension, we clarify effects on data, statuses and agreed tests.
Do you test with real customer data?
Testing uses suitable isolated data. Production data or running customer processes are not changed without an expressly agreed procedure.
Can the package also fix existing faults?
Yes, where the task concerns a new or changed defined function. General maintenance and an open bug list fit backend further development better.
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 backend and clearly described flow with examples Existing access model and approved status and data rules 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
Connecting an API: what to settle before integration
Can the existing API create the order you need? Clarify data fields, access rights and handling of missing responses before integration.
Read the guide ↗Related services
These may fit too.
Ongoing support
Develop an existing backend
We extend an existing backend within a limited work package, with prioritised tasks and documented changes.