Warranty Policy

Warranty for Implemented Software Solutions

 

www.abac.software

Version [01.01.2021]

 

Disclaimer

 

This document describes the policies operated by abac.software for processing the warranty for implemented software development platforms.

abac.software is operated by RED ABACUS DEVELOPMENT SRL, a Romanian company registered under nr. J12/2788/2016 in the Registry of Commerce, with unique business ID RO36345302, headquartered at 27 Gruia Street, 400171 Cluj-Napoca, Romania. Hereinafter referred to as “abac”, “we”, or other similar terms.

 

Introduction

 

Software solutions developed by abac.software under certain constraints benefit from a 1-year limited functional warranty. Examples of where this applies include:

  • Software solutions developed using our recommended Pipeline Model (see our software development process for details)

  • Software solutions where abac.software has explicitly offered a post-implementation warranty

 

 

Terminology

 

  • Warranty Holder → The individual or organization that has collaborated with abac to build a software solution and has received a post-implementation warranty period.

  • Warranty Period → The period specified in the commercial offer during which the Warranty Holder can report bugs in the delivered software, and abac will remedy them free of charge.

  • Warranty Claim → A formal notification by the Warranty Holder to abac describing a bug that needs resolution.

  • Maintenance → Routine, non-development activities that help keep the system healthy and stable (e.g. server space cleanup, log rotation). Maintenance does not include bug fixes or new feature development.

  • Issue → Any reported problem with the software, which may be a bug (covered under warranty), a maintenance task (covered under defined maintenance scope), or an enhancement request (a new feature or change, typically outside warranty).

  • Fix → The action of correcting a bug or defect in the delivered software. Warranty covers fixes for qualifying bugs within the warranty period, but does not cover enhancements or changes outside scope.

 

 

Warranty Cover

 

This warranty covers:

  • Correction of bugs or defects that prevent users from completing agreed-upon usage scenarios

  • Fixes for data inconsistency errors under normal use

  • Correction of visual defects that harm user experience (e.g. overlapping text, unclickable buttons)

  • Performance or visual issues that violate agreed non-functional requirements

  • Functionality issues that fail the agreed acceptance criteria

  • Adjustments to text content, button labels, or element positions in the UI when these do not match the approved design or documented requirements

 

This warranty does not cover:

  • Extensions of the software solution (e.g. adding new features or expanding existing features)

  • Improvements to the software solution (e.g. interface redesigns or performance optimizations beyond agreed requirements)

  • Changes to content or application behaviour requested outside of approved specifications (e.g. changing texts, labels, or layouts purely at the client’s request without being covered by the original requirements)

  • Changes needed to fix errors in the client’s own business processes as originally specified (e.g. if the workflow itself was flawed or inefficient). abac.software cannot be responsible for redesigning processes that were defined and approved by the Warranty Holder.

 

 

How Are Warranty Claims Evaluated?

 

Warranty coverage for software solutions is different from that of physical products. In our context, warranty covers the correction of specific types of bugs and defects that can be clearly tied to the agreed requirements and acceptance criteria of the delivered software. As such, it does not cover logical errors for the processes or scenarios that are part of the warranty holder’s specification.

A warranty claim may be opened when the software exhibits one of the following:

  • Errors that prevent users from completing defined usage scenarios

  • Data inconsistency errors arising during normal interactions

  • Visual defects that harm user experience (e.g. text overlapping, unclickable buttons)

  • Performance or visual issues that violate the agreed non-functional requirements

  • Functionality issues that do not meet the agreed acceptance criteria

  • Adjustments to texts, button labels, or element positions in the UI when these do not match the approved design or documented requirements

 

How does abac evaluate warranty claims?

Warranty claims are assessed against the documented scope and requirements of the project to ensure that defects fall within the agreed coverage. The evaluation process depends on how well-defined and stable the specifications were during development:

  • For projects with exhaustive, stable acceptance criteria (that were not modified during development and leave little room for interpretation):

    • Claims are assessed strictly against the existing specifications and acceptance criteria.

    • Only issues that clearly violate these requirements are eligible for free warranty correction.

     

  • For projects with less defined or evolving acceptance criteria (that changed during development or were ambiguous):

    • Claims are assessed not only against existing specifications but also against all relevant correspondence and agreements with the Warranty Holder.

    • This ensures fairness but can introduce interpretation challenges, which abac aims to avoid through careful planning.

     

Our goal is to minimise ambiguity by working with you to define detailed, stable acceptance criteria before delivery. This ensures that what qualifies as a warranty-covered bug is clear to both parties.

 

 

Warranty Voiding

 

Warranty coverage depends on the delivered software remaining consistent with the approved, validated environment and configuration. Certain changes or uses outside of the agreed scope will void your warranty.

The following actions will result in the loss of warranty coverage:

  • Using the software solution in environments other than those set up or explicitly approved by abac

  • Using the software in ways not documented or intended in the approved specifications

  • Changing configurations in the binaries of the application

  • Changing settings in third-party software that the application integrates with or depends on (e.g. altering hosting environment settings, modifying third-party service configurations)

  • Adding or modifying code on top of the delivered and warranted code base without abac’s review and approval

 

Important:

abac.software cannot offer warranty for software solutions that are continuously edited or modified post-delivery by other software development companies or third parties. Once such modifications are made without abac’s involvement, warranty obligations no longer apply.

If you’re unsure whether a planned change or update could affect your warranty coverage, please contact us first at contact@abac.software. We’re happy to advise you on how to maintain warranty eligibility.

 

Warranty Claims

 

If you encounter an issue that you believe is covered under warranty, you can submit a warranty claim to let us know about the problem so we can evaluate and fix it.

To submit a warranty claim, please email contact@abac.software with a clear description of the issue.

We strongly encourage using the DESERT format when describing the issue. Providing these details helps us understand the problem quickly and accurately, leading to faster resolution. 

DESERT Acronym for Reporting Issues

  • (D)escription → What is happening? (describe the actual issue)

  • (E)nvironment → Where did it occur? (e.g. Production, Staging)

  • (S)everity → How critical is it? (Blocker, High, Medium, Low)

  • (E)xpected Outcome → What should happen instead?

  • (R)eal Outcome → What is actually happening?

  • (T)echnical Details → Screenshots, logs, device info, error messages

 

Example of a Well-Formatted Claim (Generic)

Context: The app is used for managing customer orders.

  • (D) → When I try to save a new order with more than 5 items, the app displays an error message.

  • (E) → Production environment

  • (S) → High

  • (E) → The app should save orders with any number of items up to the limit specified in requirements (20 items).

  • (R) → It shows an error: “Invalid request” after 5 items.

  • (T) → Screenshot of the error message attached; tested on Chrome and Firefox.

 

We will process warranty claims as quickly as possible.

For each DESERT-formatted claim, we will provide an estimated resolution time based on its complexity and severity.

 

Post-Warranty Interventions

 

After the warranty period ends, abac.software continues to support our clients with paid maintenance and intervention services.

We understand that issues and change requests may arise even after delivery. To ensure smooth, predictable collaboration, we encourage clients to agree on a formal intervention scheme (Service Level Agreement, SLA) that defines priority levels and maximum timeframes for intervention.

Our typical intervention scheme includes three levels of issue priority:

  • Critical Issues

    • Problems that block essential functionality or severely impact business operations

    • Examples: Application outage, payment processing failure, security vulnerabilities

    • Intervention Target: Maximum 3 business days to begin intervention

     

  • Moderate Issues

    • Significant but non-blocking problems that affect usability or important workflows

    • Examples: Broken reporting features, layout issues impacting conversion, integration errors with workarounds

    • Intervention Target: Maximum 14 business days to begin intervention

     

  • Trivial Issues

    • Minor, cosmetic, or low-priority improvements

    • Examples: Typos in UI, color adjustments, small layout refinements

    • Intervention Target: Best-effort approach, scheduled based on availability

     

How It Works

  • Together with the client, we establish a clear SLA that defines:

    • Which types of issues fall under each priority level

    • Agreed maximum timeframes for intervention

    • The process for submitting and tracking requests

This SLA ensures that expectations are clear for both parties, allowing for predictable, reliable collaboration post-warranty.

If you would like to set up a post-warranty intervention plan or discuss a custom SLA for your project, please contact us at contact@abac.software.