# Development & Testing — Alfaveo

> Process for raising development requests, estimates, approval, testing and acceptance with Alfaveo.

Source: https://alfaveo.com/development-and-testing

← Back to home 🇬🇧 EN

## Development request, estimation and approval process

How collaboration works for raising requests, producing estimates, approval and acceptance.

Company: Alfaveo Platform: Jetveo Document version: 1.2 (customer) Date: May 2026 Audience: customers of Alfaveo

## Contents

- 1. Introduction
- 2. Submitting requests and communication
- 3. New applications
- 4. Estimation
- 5. Estimate approval
- 6. Execution and development
- 7. Testing and acceptance
- 8. Request changes
- 9. Classifying reported issues: bug vs. new request
- 10. Warranty bugfixing, SLA bugfixing and new requests
- 11. Invoicing
- 12. Dispute and complaint resolution
- 13. SLA (Service Level Agreement)
- 14. Key definitions and principles
- 15. Process overview

## 1. Introduction

This document describes how Alfaveo and its customers work together when raising development requests, producing estimates, and going through approval and acceptance of delivered features. The aim is for both parties to be clear on what happens when, what gets approved, what gets invoiced, and how disputes are resolved.

This document complements the General Terms and Conditions of Alfaveo.cz s.r.o. ("GTC"), available at www.alfaveo.cz. In case of conflict between this document and the GTC, the GTC prevails.

### 1.1 Customer cooperation

The customer is required to provide Alfaveo with the maximum cooperation needed to deliver the request (in particular: responding to questions, supplying inputs, and granting access). If the customer fails to cooperate, all deadlines stated in this document are automatically extended by the time spent waiting on cooperation.

## 2. Submitting requests and communication

### 2.1 Channels for submitting a request

Requests are submitted to the Alfaveo helpdesk in one of three ways:

By phone the customer calls the support line. If support picks up, the request is discussed live. If no one answers, the customer leaves a voicemail; the helpdesk processes the recording and creates a ticket. If the phone number is paired with an email contact in the system, the customer receives a notification with a link to the ticket.

By email to podpora@alfaveo.cz the helpdesk mailbox is read periodically and tickets are created automatically. Subsequent emails about a ticket carry the ticket code in the subject; the helpdesk uses it to route replies to the right ticket automatically.

Via the helpdesk website the customer signs in (login + password) and creates a ticket. After login, the system already has the email and customer/application assignment from the account, so nothing has to be entered manually. The web helpdesk is always behind login; there is no public ticket-creation page.

When signed in, the customer sees an overview of all their tickets and a chat component on each one for direct communication with support.

Notification links in emails (see 2.3) lead to a specific ticket without login the link contains a one-time token. This mode lets the customer respond quickly (e.g. approve an estimate) without having to log in every time.

### 2.2 Ticket priority

When creating a ticket, the customer sets a priority:

- MID standard request. Handled in the regular order.
- CRITICAL critical request. Procedurally identical to MID the customer must state why the request is critical. Differs only in SLA response times (see 13.3).

After review, Alfaveo may reclassify the priority (CRITICAL → MID if the actual severity does not match the set priority, or MID → CRITICAL, e.g. when a regression or outage is identified). The customer is notified about the reclassification. If they disagree, this is handled via the standard escalation (see 12).

### 2.3 Notifications to the customer

The customer automatically receives an email with a link to the ticket in the following situations:

- ticket creation,
- priority change,
- work on the request started,
- estimate sent for approval,
- handover for testing / acceptance,
- ticket closure.

The link in the email allows access to the specific ticket without login.

### 2.4 Ticket closure

Whenever a ticket is closed, the reason is recorded:

- Accepted by customer the customer confirmed acceptance,
- Auto-accepted the customer did not respond within 14 days,
- Cancelled the request was cancelled by the customer or by Alfaveo,
- Duplicate the request duplicates another ticket.

A closed ticket cannot be reopened. If a new issue arises (including a bug under warranty), a new ticket is created.

### 2.5 Customer-side approver

For each Application, the customer designates an approver a specific person responsible for approving estimates and accepting deliveries. If the approver is unavailable (illness, vacation, leaving the company), the customer must appoint a replacement and inform Alfaveo. Without a valid approver, an estimate cannot be sent for approval.

## 3. New applications

Requests for an entirely new application are handled individually. Even in that case, the resulting scope is broken down into individual features, each going through the standard estimation and approval process described in this document.

## 4. Estimation

### 4.1 What an estimate contains

Each estimate contains:

- Request description a clear specification of what is to be delivered, optionally what is explicitly out of scope.
- Test and acceptance criteria concrete, verifiable conditions that the output must meet to be accepted.
- Time estimate broken down into items (see 4.2).

### 4.2 Structure of the time estimate

The estimate consists of a development estimate plus derived items covering analysis, testing, communication, and a buffer for bugfixing:

Item | % of dev | Description

Analysis | 15% | Understanding the request, designing the solution, preparing the spec

Development | 100% (base) | Implementing the solution on the Jetveo platform

Testing | 20% | Internal testing before handover to the customer

Communication | 10% | Time for consultations, questions and clarifications with the customer

Bugfixing | 15% | Buffer for fixing bugs found during acceptance

Total | 160% |

Example: development estimated at 10 hours → total estimate = 16 hours (1.5 h analysis + 10 h dev + 2 h testing + 1 h communication + 1.5 h bugfixing).

### 4.3 Estimate delivery time

Alfaveo delivers an estimate within 48 hours of receiving the request. If the request is so complex that this deadline is insufficient, Alfaveo informs the customer and provides an expected estimate delivery date.

### 4.4 Maximum estimate size

Requests with an estimate exceeding 20 hours must be split into smaller, individually estimated and approved parts. This rule reduces the risk of inaccurate estimates and lets the customer manage priorities better.

### 4.5 Scope definition

The scope of the request is critical. The description and acceptance criteria define exactly what is and is not part of the estimate. Anything not explicitly stated in the description and acceptance criteria is out of scope and requires a new estimate.

This protects both sides the customer knows exactly what they will get, and Alfaveo has a clearly defined scope of work it commits to deliver within the estimate.

## 5. Estimate approval

### 5.1 Sending for approval

Once the estimate is finished, it is sent to the approver (see 2.5). The approver sees:

- the request description and what is not part of it,
- acceptance criteria,
- the time estimate and its breakdown.

### 5.2 Approval by the customer

The customer reviews the whole project in the application not just the estimate, but also the scope and delivery conditions. Specifically, they approve:

- Request description (scope) whether the spec matches what the customer needs and what is out-of-scope,
- Test and acceptance criteria whether the conditions for successful handover are correct and complete,
- Time estimate whether they agree to the price for the defined scope.

Before approval, the customer can amend or refine the request and the test criteria. If the customer proposes changes, Alfaveo reviews them and adjusts the estimate if needed. Approval is repeated against the updated project.

Estimate revision limit: a single estimate can go through at most 3 revision rounds (i.e. estimate → comments → estimate → comments → estimate → final decision). If no agreement is reached after the third round, the situation is escalated to the Alfaveo manager (see 12). This rule prevents an endless loop of small estimate tweaks with no real progress.

Only by clicking "Approve" does the customer consent to delivery at the given scope, against the given acceptance criteria, and at the stated price. After approval, Alfaveo can begin work.

Important: by approving, the customer confirms that the scope and acceptance criteria are complete and correct. After approval, any change is handled as a new request (see 8).

### 5.3 Estimate rejection

If the customer rejects the estimate, no fee is charged for preparing the estimate or analysis. Time spent on a rejected estimate is borne by Alfaveo.

### 5.4 No response to the estimate

If the customer does not respond to the estimate within 10 working days, the estimate is automatically closed (rejected). The customer is notified before closure.

## 6. Execution and development

### 6.1 How development runs

After approval, Alfaveo delivers the request in line with the description and acceptance criteria.

### 6.2 Communication during development

Alfaveo contacts the customer only when:

- something in the request is unclear and clarification is needed,
- the feature is ready for testing.

Periodic status reports during development are not provided by default. The customer can track the request status in the helpdesk.

### 6.3 Scope protection during development

Scope changes are not allowed during development. Any new or modified request including ones raised during communication or testing requires a new estimate (see 8).

Examples of situations that are out of scope and require a new estimate:

- "It would also be good to add this field…"
- "Could it work a bit differently than we agreed…"
- "It occurred to me it would be better if…"
- Requests raised during testing that are not covered by the acceptance criteria.

Alfaveo is responsible for identifying these situations and explaining to the customer that they constitute a new request.

## 7. Testing and acceptance

### 7.1 Handover for testing

Once development and internal testing are complete, the feature is handed over to the customer for acceptance testing. The customer receives a notification with a link to the application.

### 7.2 Acceptance by the customer

The customer tests the delivered feature against the acceptance criteria and has two options:

- Accept confirm that the delivery meets the requirements,
- Return for fixes describe the specific mismatch with the acceptance criteria.

### 7.3 Iterative testing

Testing is iterative the request can be passed back and forth between customer and Alfaveo. The maximum number of iterations is 3 rounds. If no agreement is reached after the third round, the situation is escalated to the Alfaveo manager who decides on the next steps (see 12).

### 7.4 Automatic acceptance

If the customer does not respond within 14 calendar days of handover for testing, the delivery is automatically considered tested and accepted.

### 7.5 What is not a reason for return

Returning for fixes is only justified when the delivery does not meet the defined acceptance criteria. New requirements or scope changes cannot be handled as fixes they require a new estimate.

## 8. Request changes

### 8.1 Change before development starts

If the customer wants to change the request before work begins, the original estimate is cancelled and a new estimate is created with the updated specification.

### 8.2 Change during development

If a change happens mid-development, the procedure is:

- The original estimate is closed and invoiced in full at the approved amount, regardless of how much work was actually done. For the customer, that is the commitment they already approved; for Alfaveo, it protects already-performed work from being retroactively devalued by a later change.
- A new estimate is created covering the entire new scope (the remaining original work after the change + the new requirements).
- The new estimate may be reduced by the part of the original work that can be reused typically analysis, parts of the implementation that are not changing, environment setup. In the new estimate, Alfaveo transparently lists what part of the original work is being credited and to what extent, so the customer can see they are not paying twice for the same thing.
- The new estimate must be approved the customer approves it via the standard process.

This approach ensures transparency and a fair distribution of risk: the customer pays for the original commitment (analysis and development did happen), but does not pay again for the reusable part. Alfaveo does not lose the time it actually invested.

## 9. Classifying reported issues: bug vs. new request

This chapter is critical to the cooperation working well. It clearly defines what counts as a bug fix vs. a new request (feature), how the call is made, and who pays for what.

### 9.1 Core rule

The single criterion for distinguishing a bug from a new request is the approved specification and acceptance criteria. What is written down decides not what someone had in mind.

### 9.2 Decision tree

For every reported issue, Alfaveo answers these questions:

- Is the behavior contrary to the acceptance criteria? → YES = Bug. The feature does not do what was approved.
- Did it work correctly before and now it does not (regression)? → YES = Bug. Even if not directly related to the latest request a regression is always Alfaveo's fault.
- Does it work per the criteria, but the customer wants different behavior? → NO = New request. The customer wants a change or extension a new estimate is created.
- Customer says "that's not how I meant it" or "it's only logical"? → The text of the acceptance criteria decides. If the desired behavior is not defined there, it is a new request.

### 9.3 Practical examples

Situation | Classification | Reason

The "Save" button does not write to the database | Bug | Contrary to acceptance criteria

After deploying a new feature, export stopped working | Bug (regression) | Previously working functionality is broken

"I'd like the form to close automatically after saving" | New request | Behavior after save is not defined in the criteria

"Export works, but I'd also like it to PDF" | New request | Extension beyond the original scope

"The filter works but is slow" | Depends on context | If performance is defined in the criteria → bug. If not → new request

"Surely every system has to do this" | New request | Implicit expectations are not part of the delivery

### 9.4 Gray zone ambiguous specification

If the acceptance criteria are ambiguous and both sides have a defensible reading:

- Alfaveo and the customer try to reach an agreement.
- If they fail, the issue is escalated to the Alfaveo manager.
- The manager decides. If they conclude the spec was insufficient, the fix is delivered under warranty.
- Acceptance criteria are tightened for next time so the situation does not recur.

Lesson: the more precise the acceptance criteria, the fewer gray zones. That is why investing time in a high-quality specification is critical (see 4).

## 10. Warranty bugfixing, SLA bugfixing and new requests

Alfaveo provides three different modes for handling issues and requests. It is important to understand how they differ and when each applies.

Is bugfixing conditional on having an SLA? Not in the short term. Warranty bugfixing for 1 month after acceptance is always included in the price of the delivered estimate, regardless of whether the customer has an SLA. After the warranty expires, long-term application servicing (bug fixes, regressions, maintenance) is either covered by an active SLA, or each fix is handled as a paid new request per the price list. Without an SLA the customer still gets fixes they just pay for them individually after a year or two of active use, rather than as a flat fee.

### 10.1 Mode overview

| Warranty bugfixing | SLA bugfixing | New request

When it applies | 1 month after acceptance of the specific request | Continuously for the duration of the SLA contract | Anytime

What it covers | Bugs within the just-delivered request | Any bugs in the application (including older features, regressions) | New features, behavior changes, extensions

Capacity | Unlimited (within request scope) | Within SLA, no hourly limit | Per the approved estimate

Price | Included in the estimate | Included in the SLA flat fee | Per the new estimate

Response time | Not guaranteed | Guaranteed per SLA tier | Not guaranteed (estimate within 48 h)

Condition | Bug found within 1 month of acceptance | Active SLA contract | Approved estimate

### 10.2 Classification and approval

Alfaveo classifies the issue based on the decision tree from 9.2 and acts immediately bugs are taken to fix, features are estimated. If the customer disagrees with the classification, it is escalated per 12 (Dispute resolution).

Customer approval is always required even for bugs. Why: the customer must have visibility into what is happening in their application, what classification was chosen, what the fix description is, and (for SLA) how many hours are being consumed. However, approval does not block the start of work for bugs, fixing starts immediately to honor response times, and approval happens in parallel.

#### What gets approved by mode:

Situation | What the customer approves | Does approval block fix start? | Invoicing

Bug under warranty (within 1 month of acceptance) | Classification as a bug + fix description | No (fix starts immediately) | Not invoiced

Bug via SLA | Classification, fix description | No (fix starts immediately) | Not invoiced (in the SLA flat fee)

Bug outside warranty, no SLA | Standard estimate as for a new request | Yes work does not start without approval | Invoiced per the estimate

New request (feature) | Standard estimate | Yes work does not start without approval | Invoiced per the estimate

Key distinction: for bugs under warranty and within SLA, approval is informational the customer confirms they understand the classification and description, but is not approving a price (there is none). For bugs outside warranty/SLA and for new requests, approval is binding on price without it work does not begin.

If the customer does not approve the classification of a warranty/SLA bug within 5 working days, the fix is either already done (if it was quick) or in progress, and after this period the classification is considered confirmed. Any dispute is still resolved per 12.

### 10.3 Warranty bugfixing detail

After acceptance, a 1-month warranty period runs. During it, bug fixes are included in the price of the estimate.

The warranty period starts on the date the customer clicked "Accept" or the date of automatic acceptance (after 14 days without response).

The warranty covers only bugs within the delivered request i.e. mismatches with the approved spec and acceptance criteria. It does not cover new requests, behavior changes, or extensions.

After one month, any fix is handled either via SLA (if active) or as a new request.

### 10.4 SLA bugfixing detail

SLA covers bugs across the whole application including older features no longer under warranty. Bugfixing is included in the SLA flat fee, independently of the SP1 tier, with no monthly hourly limit.

Key difference vs. warranty: SLA provides guaranteed response times (see 13.3). Warranty bugfixing has no guaranteed response times.

If a bug falls under both warranty and SLA at the same time (within warranty and the customer has an SLA), SLA response times apply.

### 10.5 New request detail

Anything that is not a bug is a new request no exceptions. A new request always requires a new estimate and customer approval. Typical examples: new features, changes to existing behavior, scope extensions, work after the warranty period, "improvements" to existing features.

### 10.6 Communication with the customer

When classifying a reported issue, Alfaveo always tells the customer:

- whether it is a bug or a new request, and why,
- if a bug which mode it falls under (warranty / SLA / paid fix),
- if over-limit or a new request that an estimate will be created for approval.

All classifications and fixes are sent to the customer for approval per 10.2.

## 11. Invoicing

### 11.1 Billing period

Invoicing happens at the end of the calendar month.

### 11.2 What gets invoiced

The invoice covers requests that, in the given month:

- were completed and accepted by the customer, or
- were automatically accepted (after 14 days without response), or
- were completed and approved for invoicing in justified cases, after prior agreement with the customer, requests that are approved and completed but have not yet passed acceptance testing may also be invoiced.

### 11.3 Invoiced amount

The approved estimate is always invoiced, not the actual time spent. If the actual work exceeds the estimate, the difference is borne by Alfaveo. That is why strict scope discipline is critical (see 6.3 and 7.5).

## 12. Dispute and complaint resolution

### 12.1 Dispute over classification (bug vs. new request)

If the customer disagrees with the classification per 9.2:

- Alfaveo provides written justification for why the request does not fall under the acceptance criteria.
- If the customer maintains their position, the issue is escalated to the Alfaveo manager.
- The manager decides based on comparing the request with the original description and acceptance criteria.
- The manager's decision is final. If it turns out the acceptance criteria were ambiguous, the fix is performed under warranty and the criteria are tightened for next time.

### 12.2 Estimate complaint

If the customer disputes the validity of the invoiced amount:

- Alfaveo provides a detailed estimate breakdown and a description of the work performed.
- If Alfaveo demonstrably failed to deliver what was stated in the estimate, a correction or credit note is issued.

### 12.3 Delays on Alfaveo's and the customer's side

Delays can occur on either side. The procedure differs depending on who caused the delay.

#### Delays on Alfaveo's side

Typical cases: exceeding the estimated hours, missing the completion deadline, delivering the estimate after the 48-hour window, exceeding SLA response times.

- Alfaveo informs the customer immediately upon discovery not only after the deadline has passed.
- The communication includes the reason for the delay and a new expected deadline.
- Exceeding the estimated hours is borne by Alfaveo the approved estimate is invoiced, not the actual time (see 11.3).
- Breaches of SLA response times are handled per the SLA contract (typically a discount on the monthly fee).
- Repeated or serious delays are escalated by the Alfaveo manager, who decides on compensation beyond the above.

#### Delays on the customer's side

Typical cases: the customer does not respond to estimates, to questions from Alfaveo, or to handover for testing; fails to provide cooperation, inputs or access.

- All deadlines in this document are automatically extended by the time spent waiting for cooperation (see 1.1).
- The system sends automatic reminders failure to respond to an estimate within 10 working days closes the estimate automatically (see 5.4); failure to respond to testing within 14 days triggers automatic acceptance (see 7.4).
- SLA response times for a specific ticket are paused while Alfaveo is demonstrably waiting on customer cooperation.
- If a delay on the customer's side causes Alfaveo measurable costs (e.g. a planned developer is blocked and cannot work on another project), this is grounds for negotiating compensation handled by the manager.
- If the customer systematically fails to cooperate, Alfaveo has the right to suspend work on further requests until the situation is resolved.

#### Documenting delays

Every delay on either side is recorded in the project history. The history is the basis for any potential billing adjustment, complaint, or evaluation of the cooperation.

## 13. SLA (Service Level Agreement)

### 13.1 Service description

SLA is an optional paid technical support service. It guarantees response times for issue resolution and ongoing application maintenance. Bugfixing is included in the SLA flat fee with no hourly limit.

### 13.2 Defect classification

For SLA purposes, defects are split into three categories:

- Critical defect the system is unusable in its core functions. Standard ways of working cannot continue and there is no available workaround.
- Major defect the system is degraded such that this state limits normal operation. The situation can however be mitigated or worked around.
- Minor defect the defect does not significantly affect normal operation. Some user functions are limited but available by other means.

### 13.3 Response times

Guaranteed start-of-work times for issue resolution:

Defect type | Response time

Critical defect | within 4 hours

Major defect | within 12 hours

Minor defect | within 3 working days

The response time starts running upon confirmation of the request. If the request is reported outside the agreed support hours, the clock starts at the beginning of the next agreed window.

### 13.4 SLA packages overview

SLA is composed of three independent packages: SP1 (basic support and response times), SP2 (prepaid consulting hours) and SP3 (monitoring and prophylaxis). The customer can order any combination.

### 13.5 SP1 Reactive support tiers

SP1 defines the support hours (during which response times per 13.3 run) and is available in four tiers:

Tier | Support hours

BASIC | 9:00–16:00, working days

SILVER | 6:00–20:00, working days

GOLD | anytime except public holidays

PLATINUM | anytime (24/7)

Bugfixing within SLA is included in the flat fee for all SP1 tiers, with no monthly hourly limit. The tiers differ in support hours, response times, and the corresponding flat-fee price.

### 13.6 SP2 Prepaid consulting hours

Flat 10 consulting hours per quarter. The customer uses the hours for consulting, training, analyses and small queries outside of bugfixing. Unused hours do not roll over to the next quarter they expire.

### 13.7 SP3 Product monitoring and prophylaxis

Includes:

- ongoing monitoring of performance and error rate,
- proactive maintenance (log inspection, data cleanup, oversight of scheduled jobs),
- verifying compatibility with infrastructure updates (Jetveo platform upgrades, DB, runtime),
- regular reporting of application status to the customer's manager.

### 13.8 Security bugs (vulnerabilities)

Security bugs are handled with priority over other bugs of the same severity.

#### Two layers of responsibility:

- Platform level (Jetveo) vulnerabilities in the Jetveo platform (runtime, framework, standard components, authentication, authorization, CSRF/XSS/SQLi in the basic building blocks, TLS, dependency updates) are primarily handled by the platform vendor. Alfaveo applies platform upgrades to customer applications under SP3 (or as a security hotfix outside SLA if SP3 is not contracted).
- Application level (Alfaveo) vulnerabilities in custom code written by Alfaveo (business logic, custom integrations, custom input handling outside standard Jetveo components) are handled by Alfaveo.

#### Severity classification uses standard scoring (e.g. CVSS):

Severity | Alfaveo response

Critical / High | Equivalent to Critical defect per 13.2 response time per SP1 tier. Fix as a hotfix without waiting for the next release.

Medium | Equivalent to Major defect scheduled fix in the next release window.

Low | Equivalent to Minor defect placed into the regular bugfixing backlog.

Without SLA: security bugs in Alfaveo's custom code are handled under warranty (if within the warranty period of the delivered request). Security bugs outside warranty without an SLA are handled as a paid fix, but with the highest priority.

Platform security patch: if a Jetveo platform upgrade is required (a critical vulnerability disclosed by the platform vendor), Alfaveo is required to inform the customer and roll out the upgrade within a timeframe proportionate to severity. The deployment cost is borne by customers with active SP3; for customers without SP3 the upgrade is billed as bugfixing per price list.

Vulnerability reporting: external vulnerability reports (bug bounty, pentest findings, third-party reports) are filed as a standard ticket with CRITICAL priority and "security" classification.

## 14. Key definitions and principles

To prevent disputes, the following principles apply:

- Bug (product defect) = product behavior that is contrary to the approved specification and acceptance criteria and is demonstrably caused by the delivered solution. A product defect does not include problems caused by misuse, unauthorized customer modification, or failures of software or infrastructure not delivered by Alfaveo.
- Customer responsibility: the customer is responsible for the correctness and completeness of the brief. Alfaveo works from what is written in the approved estimate.
- Implicit expectations: behavior that is not explicitly defined in the request description and acceptance criteria is not part of the delivery and cannot be grounds for a complaint.

## 15. Process overview

Request (customer)
│
▼
Project creation
(description, acceptance criteria, estimate)
│
▼
Sent for approval
│
├── Approved → Development starts
│ │
│ ▼
│ Development per scope
│ │
│ ▼
│ Handover for testing
│ │
│ ┌──────────┴──────────┐
│ ▼ ▼
│ Accepted No response 14 days
│ │ │
│ ▼ ▼
│ Invoicing Auto-acceptance
│ │
│ ▼
│ Invoicing
│
├── Rejected / change → New estimate
│
└── No response → Reminder → Closure