Quality Parameters, Quality Conditions & Quality Policy

At Uxally, quality is an integral part of how we plan, design, develop, test, deliver, and improve our services. This page explains the quality parameters we use, the conditions that apply to our deliverables, and the principles that guide our quality management approach across custom software development, UX/UI design, and cryptocurrency-related solutions.

Our practices are informed by recognized quality-management principles and software-quality models, including customer focus, process-based management, evidence-based decision-making, continuous improvement, and quality attributes such as functional suitability, reliability, security, usability, performance efficiency, maintainability, compatibility, and portability.

Important: This policy describes Uxally's internal quality commitments and operating practices. It does not represent an ISO certification or a guarantee that every project will meet every quality attribute to the same degree. Quality objectives and acceptance criteria are defined according to the scope, risk, budget, technology, and intended use of each project.

Quality Parameters

Last updated: August 2, 2026

1. Purpose

The purpose of our quality parameters is to establish clear and measurable criteria for evaluating the services and deliverables provided by Uxally.

Quality is assessed throughout the project lifecycle rather than only at final delivery. Depending on the project, this may include:

Requirements review.
Technical and UX/UI planning.
Architecture and solution design.
Design reviews.
Code review.
Automated and manual testing.
Security and dependency checks.
Performance validation.
User acceptance testing.
Deployment verification.
Post-release monitoring and improvement.

The specific activities applied to a project depend on its scope, complexity, risk level, budget, timeline, and contractual requirements.

2. Software Development Quality Parameters

For custom software, web applications, SaaS platforms, internal systems, integrations, APIs, and other digital products, we may evaluate the following parameters.

Functional Suitability

The solution should implement the agreed requirements and support the intended business or operational processes.

We may evaluate:

Completion of approved user stories, requirements, or specifications.
Correctness of core business rules.
Accuracy of calculations and data processing.
Expected behavior under defined use cases.
Traceability between requirements and delivered functionality.

Reliability and Availability

The solution should operate consistently under expected conditions and recover appropriately from foreseeable failures.

We may evaluate:

Stability during normal operation.
Error handling and controlled failure behavior.
Data consistency.
Recovery and restart procedures.
Monitoring and incident visibility.
Availability objectives when they are included in the agreed scope.

Availability depends on infrastructure, hosting providers, third-party services, network conditions, maintenance windows, and other external factors. Unless a service-level agreement expressly states otherwise, Uxally does not guarantee uninterrupted or error-free operation.

Performance Efficiency

The solution should use computing resources reasonably and provide acceptable response times for the agreed workload.

We may evaluate:

Page and application response times.
API response times.
Database-query efficiency.
Resource consumption.
Expected concurrent usage.
Scalability considerations.

Performance targets must be defined in measurable terms when they are material to the project. Results may vary according to infrastructure, network conditions, device capabilities, third-party dependencies, and real-world usage patterns.

Security

Security is considered throughout design, development, testing, and deployment according to the risk profile of the project.

Measures may include:

Secure authentication and authorization.
Role- and permission-based access controls.
Encryption in transit through HTTPS/TLS.
Secure credential and secret management.
Input validation and output handling.
Protection against common application vulnerabilities.
Dependency and package review.
Logging and auditability where appropriate.
Secure deployment practices.

Security controls are selected according to the project's risk, architecture, data sensitivity, regulatory context, and agreed scope. No software system can be guaranteed to be completely secure or immune to future vulnerabilities.

Maintainability

The software should be structured so that authorized developers can understand, test, correct, and extend it efficiently.

We may evaluate:

Code readability and consistency.
Separation of responsibilities.
Modularity and reuse.
Documentation of relevant technical decisions.
Testability.
Dependency management.
Maintainable architecture appropriate to the project.

Compatibility and Interoperability

Where integrations are included, the solution should exchange information correctly with the agreed systems, platforms, APIs, browsers, devices, or services.

We may evaluate:

API contract compliance.
Data-format compatibility.
Integration error handling.
Supported browser or device ranges.
Backward compatibility when expressly required.

Third-party services may change their APIs, policies, limits, pricing, or availability. Changes outside Uxally's control may require additional work and are handled according to the applicable change-management process.

Portability and Deployment

The solution should be deployable in the agreed environment and supported by appropriate configuration or deployment documentation.

We may evaluate:

Reproducible build procedures.
Environment configuration.
Deployment validation.
Backup and rollback considerations when included.
Compatibility with agreed hosting or infrastructure.

3. UX/UI Quality Parameters

For user experience and user interface services, quality includes both visual consistency and the effectiveness of the experience.

User-Centered Design

We seek to align the interface with the needs, goals, context, and expectations of the intended users.

Depending on the project, activities may include:

User and stakeholder interviews.
User-flow definition.
Information architecture.
Wireframes and prototypes.
Usability review.
Design validation with stakeholders or users.

The depth of research and validation depends on the scope and budget approved for the project.

Usability

Interfaces should be understandable, efficient, predictable, and appropriate for their intended audience.

We may evaluate:

Clarity of navigation.
Consistency of interactions.
Visibility of system status.
Error prevention and recovery.
Readability and content hierarchy.
Efficiency in completing key tasks.
Responsive behavior.

Accessibility

We aim to apply practical accessibility considerations appropriate to the project, including:

Sufficient visual contrast where feasible.
Readable typography.
Keyboard-accessible interactions where applicable.
Meaningful labels and form feedback.
Clear focus states.
Semantic structure.
Alternative text guidance for relevant visual content.

Unless expressly agreed, accessibility conformance to a specific standard or level is not guaranteed. Formal accessibility audits, remediation, and certification require a defined scope and may be provided as separate services.

Visual Consistency

We seek to maintain a coherent visual language across screens and components.

We may evaluate:

Consistent typography.
Color and spacing systems.
Reusable components.
Interaction-state consistency.
Brand alignment.
Design-system documentation when included.

Responsive and Cross-Platform Experience

Where applicable, designs are prepared for the agreed device categories, screen sizes, operating systems, and browsers.

Support for legacy devices, uncommon screen sizes, or unsupported browsers must be expressly defined.

4. Cryptocurrency and Blockchain Solution Quality Parameters

Cryptocurrency, blockchain, wallet, token, smart-contract, exchange-integration, and related solutions may involve elevated technical, financial, security, regulatory, and operational risks.

Depending on the agreed service, we may evaluate:

Correctness of blockchain or API integrations.
Transaction-state handling.
Address and network validation.
Wallet and key-management architecture.
Smart-contract testing and review.
Testnet or staging validation.
Confirmation and reorganization handling.
Error and failure scenarios.
Dependency and protocol compatibility.
Security controls appropriate to the solution.

Where smart contracts are included, testing may involve unit tests, integration tests, scenario testing, and code review. A formal independent security audit is not included unless expressly stated in the proposal or agreement.

Uxally does not guarantee:

The future value, liquidity, profitability, or market performance of any cryptocurrency or token.
The uninterrupted availability of blockchain networks, exchanges, wallets, nodes, bridges, or third-party providers.
Immunity from protocol vulnerabilities, network congestion, forks, exploits, governance changes, or regulatory actions.
Recovery of lost private keys, irreversible transactions, or assets transferred to incorrect addresses.

Cryptocurrency-related projects may require specialized legal, regulatory, tax, compliance, custody, or financial advice. Unless expressly agreed, Uxally does not provide those services.

5. Quality Metrics and Evidence

When appropriate, quality objectives may be documented through measurable indicators, such as:

Percentage of agreed requirements completed.
Number and severity of identified defects.
Defect-resolution time.
Test execution and pass rates.
Automated test coverage where applicable.
Performance results against agreed targets.
Accessibility findings.
User acceptance results.
Deployment success and rollback results.
Client feedback and satisfaction indicators.

Metrics are interpreted in the context of the project. A single metric does not, by itself, determine overall quality.

6. Quality Records

Depending on the project, quality evidence may include:

Approved requirements.
Project plans and technical specifications.
UX/UI prototypes and design files.
Architecture and technical-decision records.
Source-code repositories.
Code-review records.
Test plans and test results.
Security-review findings.
Performance reports.
Acceptance records.
Deployment documentation.
Incident and improvement records.

The level of documentation is defined by the agreed scope and project needs.

Quality Conditions

Last updated: August 2, 2026

1. Scope Defines Quality

Quality is evaluated against the requirements, deliverables, acceptance criteria, technical constraints, and assumptions agreed for each project.

A deliverable is not considered defective merely because it does not include functionality, integrations, performance levels, accessibility conformance, security controls, or documentation that were not included in the agreed scope.

2. Requirements and Acceptance Criteria

The Client is responsible for providing accurate, complete, and timely information regarding:

Business objectives.
Functional requirements.
User expectations.
Technical constraints.
Required integrations.
Content and brand assets.
Regulatory or compliance requirements.
Acceptance criteria.

Where requirements are incomplete or ambiguous, Uxally may make reasonable implementation assumptions. Material assumptions should be documented and may require Client approval.

Acceptance criteria may be defined through specifications, user stories, prototypes, technical documents, test cases, or written approval.

3. Client Collaboration

Quality outcomes depend on effective collaboration between Uxally and the Client.

The Client is expected to:

Provide required access, credentials, content, and information.
Review deliverables within agreed timeframes.
Provide consolidated and actionable feedback.
Identify authorized decision-makers.
Participate in validation and acceptance activities.
Report reproducible defects with sufficient detail.

Delays or incomplete information may affect timelines, testing, quality validation, and delivery.

4. Change Management

Any request that modifies the approved scope may require an assessment of its impact on:

Price.
Timeline.
Architecture.
UX/UI design.
Testing.
Security.
Performance.
Documentation.
Maintenance.

Changes may be implemented only after the parties agree on the applicable conditions. Urgent or unplanned changes may increase project risk and may require revised quality objectives.

5. Testing Conditions

Testing is performed according to the agreed scope and available project environment.

Unless expressly included, testing may not cover every possible:

Device.
Browser.
Operating system.
Network condition.
User behavior.
Data volume.
Third-party failure.
Security threat.
Blockchain-network condition.

Testing reduces risk but cannot prove the absence of all defects.

6. Defect Classification

For quality management purposes, issues may be classified according to their impact.

Critical

A failure that causes severe service interruption, significant data loss or corruption, a major security exposure, or the inability to use a core agreed function.

High

A failure that substantially affects an important function and has no reasonable workaround.

Medium

A failure that affects a non-critical function or has a practical workaround.

Low

A minor issue with limited impact, including cosmetic or documentation-related defects.

Priority and resolution timing may also consider business impact, risk, dependencies, and available resources.

7. Acceptance and Approval

A deliverable may be submitted for review through a staging environment, prototype, repository, document, demonstration, or other agreed method.

The Client should report material deviations from the agreed acceptance criteria within the review period established in the proposal or agreement.

Approval may be documented through written confirmation, acceptance records, project-management tools, email, or other agreed communication channels.

8. Warranty and Defect Correction

Unless a separate agreement establishes different terms, Uxally provides the warranty period defined in the applicable Terms of Service or project agreement.

During the applicable warranty period, Uxally may correct reproducible defects that:

Are directly attributable to the delivered implementation.
Cause the solution to operate outside the agreed specifications.
Are reported with sufficient information to reproduce and investigate the issue.

The warranty does not generally include:

New functionality.
Scope changes.
New integrations.
Changes in business requirements.
Changes requested after approval.
Third-party service failures or changes.
Infrastructure, hosting, or network failures outside Uxally's control.
Defects caused by unauthorized modifications.
Issues caused by unsupported environments or incorrect use.
New vulnerabilities discovered after delivery that require architectural or dependency changes beyond the agreed support scope.

9. Third-Party Services and Dependencies

Many digital products depend on external providers, including cloud platforms, hosting services, APIs, payment processors, blockchain networks, exchanges, analytics tools, libraries, frameworks, and open-source packages.

Uxally may take reasonable measures to select, integrate, and monitor appropriate dependencies. However, we do not control third-party availability, pricing, policies, security, updates, rate limits, or service changes.

Work required because of a third-party change may be treated as additional scope unless covered by an active maintenance or support agreement.

10. Security Conditions

Security requirements must be proportionate to the project's risk and explicitly considered during planning.

The Client must promptly communicate:

Applicable legal or regulatory requirements.
Data-classification requirements.
Security policies.
Required certifications.
Penetration-testing requirements.
Incident-response expectations.
Industry-specific controls.

Unless expressly agreed, Uxally does not guarantee certification, regulatory compliance, or protection against every present or future cyber threat.

11. Cryptocurrency and Financial-Risk Conditions

For cryptocurrency-related solutions:

The Client is responsible for obtaining appropriate legal, tax, regulatory, compliance, and financial advice.
The Client is responsible for defining the intended use, jurisdictions, compliance obligations, custody model, and risk controls.
Production deployment involving real assets should be preceded by appropriate testing, review, and risk assessment.
Private keys, seed phrases, signing credentials, and privileged access must be handled according to an agreed security model.
Transactions on many blockchain networks may be irreversible.
Market losses, token-price changes, liquidity events, network fees, protocol events, or third-party failures are outside Uxally's control.

12. Continuous Improvement

Quality feedback may be collected through:

Client reviews.
Project retrospectives.
Defect analysis.
Incident reviews.
Performance observations.
Support requests.
Technical-debt assessments.
Security findings.
Changes in industry practices and technology.

Relevant lessons may be incorporated into future processes, templates, standards, and project practices.

Quality Policy

Last updated: August 2, 2026

1. Our Commitment

Uxally is committed to delivering professional technology services that are aligned with agreed requirements, appropriate to their intended use, technically maintainable, and supported by transparent communication.

We pursue quality through disciplined planning, user-centered design, sound engineering practices, risk-aware decision-making, verification, validation, and continuous improvement.

Our quality policy applies to:

Custom software development.
Web and mobile applications.
SaaS platforms.
Internal business systems.
UX/UI research and design.
Digital-product strategy.
API and third-party integrations.
Blockchain and cryptocurrency-related solutions.
Technical consulting and software architecture.
Maintenance, support, and continuous improvement services.

Deliver agreed functionality according to approved requirements.
Establish clear acceptance criteria for material deliverables.
Reduce avoidable defects through review and testing.
Maintain transparent communication throughout the project.
Design interfaces that support effective and understandable user experiences.
Apply security practices appropriate to the solution's risk.
Maintain code and architecture that can be reasonably supported and extended.
Manage changes in a controlled and documented manner.
Improve delivery practices using feedback and project evidence.
Build long-term client relationships based on reliability, clarity, and professional responsibility.

Project-specific objectives may be documented in proposals, statements of work, service agreements, technical specifications, or quality plans.

4. Roles and Responsibilities

Quality is a shared responsibility.

Uxally

Uxally is responsible for:

Planning and executing the agreed work.
Applying appropriate design, development, testing, and review practices.
Communicating material risks and limitations.
Maintaining relevant project records.
Correcting qualifying defects under the applicable warranty or support terms.
Improving internal practices based on evidence and feedback.

Client

The Client is responsible for:

Providing accurate requirements and timely feedback.
Reviewing and approving deliverables.
Supplying required access, content, data, and decisions.
Identifying applicable legal, regulatory, compliance, and business requirements.
Using delivered systems according to the agreed documentation and operating conditions.
Maintaining its own responsibilities for infrastructure, data, credentials, operations, and third-party accounts unless those responsibilities are expressly assigned to Uxally.

5. Review of This Policy

This Quality Policy may be reviewed and updated when necessary to reflect:

Changes in our services.
New technologies and development practices.
Lessons learned from completed projects.
Client feedback.
Changes in recognized quality or security practices.
Changes in applicable contractual or regulatory requirements.

The latest version will be published on this page.

6. Quality Contact

For questions about our quality parameters, quality conditions, or quality policy, contact us:

Email: [email protected]
Location: Azul, Buenos Aires, Argentina