Legal
Service Delivery Policy
Last updated: September 7, 2026
Fikrova Labs LLC delivers digital services. Everything we produce is delivered electronically — there is no physical product and nothing is shipped. This policy explains what you receive, how updates and handover work, how acceptance works, and what is and is not included after delivery.
1. Delivery is digital
All deliverables are provided electronically — through a code repository, a deployment, a shared file or design workspace, or another agreed channel. We do not ship physical goods, and no shipping, freight, customs, or delivery address is involved in any engagement.
2. What you receive
Deliverables depend on the project and are listed in the accepted proposal. Depending on scope, they may include:
- Websites and marketing sites
- Web applications and SaaS platforms
- Source code
- Design files and UI/UX assets
- Design systems and component libraries
- Documentation and handover notes
- Automation systems and workflow integrations
- AI integrations and their configuration
- Deployment and environment configuration
- Credentials, access, and handover information for the systems built for you
- Other digital deliverables agreed in the proposal
The proposal for your project is the definitive list. Anything not named there is outside scope.
3. Project updates while work is under way
Fikrova Labs LLC provides custom digital services rather than physical goods. Active clients receive project and milestone updates through the agreed project communication channel, which may include email, WhatsApp, scheduled calls, or project collaboration tools.
There is no order-tracking page, because there is no order to track in the retail sense — progress is reported against the milestones in your proposal by the people doing the work. We do not currently offer a client portal; if that changes it will be announced rather than implied in advance.
4. Timelines
An estimated timeline is provided in the approved proposal for each engagement. We do not publish standard delivery times, because the time a project takes depends on its complexity, the agreed scope, the number and depth of integrations, and the review cycles built into it.
Timelines given in a proposal are estimates made in good faith on the information available at the time, not guaranteed dates, unless the proposal expressly states otherwise.
5. What timelines depend on
Delivery dates assume we receive what the project needs, when it is needed. In particular, timelines depend on your feedback and approvals, the content and brand materials you supply, access credentials and third-party account access, decisions from whoever has authority to approve work, and the availability and behaviour of third-party services the project relies on.
6. Delays caused by missing input
Where required input is outstanding, work on the affected part of the project cannot proceed. We will tell you in writing what we are waiting for. Time lost waiting for client input shifts the delivery dates in the proposal accordingly — a week’s delay in approvals moves the remaining schedule by about a week, and longer gaps may require rescheduling around other committed work.
7. Revisions
Revisions follow the scope agreed in the proposal, which states the review points and how many rounds of revision are included at each. We would rather build in proper review cycles than treat revisions as an exception.
Additional revision rounds, or changes that alter the agreed direction rather than refine it, fall outside the approved scope. Those require a change order or a new quote and may affect both cost and timeline, as described in our Payment & Engagement Policy.
8. Handover: documentation, access, and training
At handover we transfer what the engagement produced. Depending on the project, a digital handover may include:
- Production and deployment information
- The agreed source files and design files
- Credentials, or instructions for transferring access
- Basic operational and handover notes
- Any documentation specifically included in the approved proposal
The exact documentation package depends on the project scope. Formal training sessions are included only where the proposal states them. Advanced technical documentation, ongoing consulting, staff training, and continuing technical support are not assumed — each may require its own scope and quote.
Access to third-party systems is subject to those providers’ own account, licensing, and transfer rules. Where an account cannot be transferred under a provider’s terms, we hand over the instructions and information needed for you to hold it in your own name.
9. Review and acceptance
You receive deliverables, or a milestone’s deliverables, for review. The standard review period is 14 calendar days from delivery of the applicable milestone or final deliverable. Where a proposal or statement of work specifies a different review period, the proposal controls.
During that period:
- Please identify any material issues measured against the agreed scope.
- Reported issues are reviewed against the approved scope, so that both sides are comparing the work to the same agreed description.
- Valid scope-related defects are corrected according to the terms of the engagement.
- Requests for features or changes that fall outside the agreed scope are handled separately, as a change order or a new quote, rather than absorbed silently or refused without explanation.
If the review period passes without anything raised, the milestone is treated as accepted so the project can move forward. Final handover may require completion of the agreed outstanding payments for the engagement. Rights in project-specific deliverables are granted or transferred as described in section 9 of our Terms of Service and the applicable proposal, subject to the agreed payment terms.
10. After delivery: what is and is not included
The 14-day review period described above is a defect-review period, not a general support period. During it you may report material defects — places where the delivered work does not conform to the approved scope — and valid scope-related defects reported in that window are reviewed and corrected according to the terms of the engagement.
It does not cover new features, scope changes, content changes, third-party service issues, infrastructure changes, maintenance, enhancements, or additional consulting. Those are separate work, quoted separately, whether they are requested during the 14 days or after them. A proposal may specify a different review period, in which case the proposal controls.
It helps to be precise about what different kinds of post-delivery work actually are:
- Correction of defects— work that does not match the approved scope. Handled under the terms of the engagement when reported within the 14-day review period, or within a different period where your proposal states one.
- Ongoing maintenance— keeping a live system updated, patched, and monitored over time. A separate engagement.
- New features— anything not in the approved scope, including additions suggested during the build but not agreed. Quoted separately.
- Third-party service issues— outages, breaking changes, deprecations, or pricing changes at a platform, API, or hosting provider. Outside our control; we can help address them under a separate arrangement.
- Infrastructure and hosting changes— migrating providers, changing plans, or reconfiguring environments after handover. A separate scope.
- Client-requested changes after acceptance— content edits, design changes, or behaviour changes once a milestone has been accepted. Quoted separately.
To state it plainly: ongoing support and maintenance after the review period — along with enhancements, monitoring, content updates, and new development — are not included after project completion unless explicitly included in the proposal or covered by a separate maintenance agreement.
11. If something is wrong
Raise it with us directly, first, through the business contact channels below. Most disagreements come down to a difference in what each side understood to be in scope, and are resolved by going back through the proposal together. Tell us the project reference and what does not match the agreed scope, and we will review it and respond in writing.
What happens to money already paid if an engagement ends early is set out in our Cancellation & Refund Policy, and the law governing an engagement is set out in our Terms of Service.
12. Questions about delivery
For anything about the status, scope, or handover of a project, contact info@fikrovalabs.com or message us on WhatsApp at +972 59 889 9099. How an engagement runs from enquiry to completion is described on our How We Work page.