From requirements to handoverA clear process and commitments.

How We Turn Your Requirements into a Working System

01 — Understand your business

We start with the problem, your current workflow, the users, and the desired outcome. We identify questions that affect the solution before implementation begins.

02 — Define the scope and agreement

We set out the included features, pages, and integrations, handover deliverables, schedule, costs, and each party's responsibilities. Project work begins after the agreement is approved and the initial 50% payment is made.

We notify you of any expected delay that materially affects delivery and explain its impact and the proposed schedule. Any change to the agreed date is documented with you; notification alone does not constitute your agreement to an extension. Statutory termination and refund rights apply when their conditions are met, taking account of force majeure and applicable rules.

03 — Design and develop

The team implements interfaces and functionality according to the agreed requirements. Change requests are reviewed to explain their effect on cost and schedule before implementation.

04 — Deliver a fully functional version

We deliver the agreed pages with complete functionality, integrated with the system, together with the access credentials needed for actual use. The second payment of 25% becomes due at this stage.

05 — Use the system in your business

You use the system for one week to check that the delivered functionality meets the approved requirements. If defects prevent use of the agreed core functions, we address them and verify that their blocking effect has been resolved before the final 25% payment becomes due.

06 — Support continues after handover

Handover includes the source code and project repository as agreed. The software defect correction warranty continues for 10 years from the agreed handover date, subject to its terms.

WhatsApp and email support channels are available around the clock. Included services and response and resolution times are defined in the project agreement. Operations, monitoring, and restoration testing are specified separately.

Engineering, Quality, and Security Standards

Code review before approval

Developers do not approve their own code for delivery on their own. Another developer or qualified team member reviews it under the Four-Eyes Principle before it is merged into the approved branch or included in the final release.

The review checks alignment with requirements, code structure and maintainability, error and exception handling, and the change's effect on existing functionality.

Testing suited to the project

We determine the required tests according to the nature and impact of the change. Where applicable, these include:

• Unit tests: To verify the behavior of individual software components.
• Integration tests: To verify that components work together.
• Backend and API tests: To verify requests, responses, permissions, and error handling.
• Functional acceptance tests: To verify that functionality meets the agreed requirements.
• Edge-case and failure tests: To check unexpected inputs and failed operations.
• Regression tests: To verify that changes have not broken affected existing functionality.

Security within development and review

We review authentication and access control, input validation, session and token handling, and the protection of sensitive data.

We also check that passwords, access keys, and secrets are not embedded in the code or repository. Static analysis and dependency scanning tools are used when available in the project environment.

Sensitive and security-related changes receive stricter review and testing according to the risks they may introduce.

When is a change ready for delivery?

We consider a change ready only after it has passed code review, the required tests have succeeded, critical findings and risks have been addressed, and affected existing functionality has been checked.

These practices describe our working approach. They do not claim independent security certification or guarantee that any system is free of every vulnerability.

Project Ownership and Handover

What do you receive when the project is complete?

Project handover includes:

• The source code and project repository.
• A user guide explaining the main functions and how to use the system.
• Operating and deployment instructions, including the requirements for setting up and running the system.
• API documentation, where APIs are provided, explaining their use and integration.
• A walkthrough or training session introducing the system and its use.

The detail of the documentation and training is proportionate to the project scope. Components, licenses, and external subscriptions needed for continued operation are identified as part of handover.

Project accounts under your control

Project hosting, domain, and external service accounts are created in the client's name and remain under the client's control. Our team receives the access permissions needed for implementation and operations as agreed.

The written agreement identifies the economic rights and rights to use, modify and publish project-specific work granted to the client, and when the transfer or licence takes effect. Third-party components and assets remain subject to their licences; delivery of a code copy does not automatically transfer every component’s rights.

Software Defect Correction Warranty

We are confident in the quality of our work and provide a software defect correction warranty for 10 years from the agreed handover date. It covers, at no additional correction charge, defects in software we developed that cause functionality to fail to meet the agreed requirements.

The following work is assessed separately, with its cost agreed before implementation:

• Adding new features or changing approved requirements.
• Correcting errors caused by modifications made by the client or another party.
• Addressing failures in third-party services.
• Compatibility updates required by changes to third-party services, interfaces, or platforms.

These situations do not cancel the warranty for original defects in our work that are unaffected by them. Warranty details and reporting and correction procedures are set out in the project agreement.

This is a contractual warranty for covered defect correction and does not reduce statutory rights or warranties. Website updates do not retroactively change commitments for an existing project.

Support and Operations

Support channels

Support requests can be sent at any time, seven days a week, through:

• WhatsApp: 0558889690
• Email: contact@almousa.dev

Included services and response and resolution times are defined in the project agreement. Issues are prioritized according to their impact.

To help us handle your report, include the project name, a description of the issue, when it occurred, and steps to reproduce it where possible. Avoid sending passwords, access keys, or sensitive client data.

Operations and operational maintenance

System operations, monitoring, and restoration testing services are defined according to the project's size and requirements. Their duration and cost are stated in the project proposal.

A proposal may include these services for one year, or they may be provided for a separate fee, as agreed. They are not automatically included in every project.

Backups and restoration tests

The client is responsible for configuring and performing regular backups, retaining and protecting them, and providing the necessary subscriptions and storage.

When restoration testing is included in the service, we perform it using the backups supplied by the client, in coordination with the client and with the necessary access permissions. A successful test confirms that the tested backup was restorable at the time of testing; it does not replace the ongoing creation of current backups.

Relationship to the software warranty

The warranty for covered software defects continues for 10 years under its terms, independently of the duration of operations, monitoring, and restoration testing services.

The end of an operational service does not cancel the software defect warranty, and the warranty does not include free system administration and operation.

The ability to send a request at any time does not mean an immediate human response or continuous human monitoring; the project agreement defines coverage hours and response and resolution targets.

How Is Your Project Priced?

Every project has different needs. We determine cost after understanding the problem, target users, and required functionality, then provide a proposal setting out the scope, deliverables, and costs.

What affects the cost?

• Features and workflows: The number and complexity of the required processes.
• Platforms: A website, mobile applications, or a system spanning multiple platforms.
• Users and permissions: Roles, branches, and organizations the system will serve.
• Design and content: User experience, languages, content, and 3D design when needed.
• Integrations and data: Connections to external services and migration from an existing system.
• Security and operations: Protection, testing, hosting, and performance requirements.
• Artificial intelligence: The use case, data sources, and operating costs, if included in the project.

What does the proposal explain?

We specify included functionality, deliverables, implementation and handover milestones, schedule, cost, payment arrangements, each party's responsibilities, and any requirements or exclusions that affect implementation.

Third-party costs

The client pays for hosting, domains, licenses, and external services and subscriptions required for the project. We explain known costs before approval, distinguishing recurring fees from usage-based charges.

Change requests

We review each request to determine whether it falls within the agreed scope. For additions or changes outside that scope, we explain their effect on cost and schedule and obtain your approval before implementation.

Software defects covered by our warranty are addressed under the warranty policy without an additional correction charge.

Payment schedule

The usage period begins when the system is made available to the client and the necessary access credentials are provided. If blocking defects arise during this period, they are corrected and their blocking effect is verified as resolved before the final payment becomes due.

Non-blocking observations do not delay the final payment and continue to be addressed under the project scope and warranty. New features and changes outside the scope are assessed separately.

The software defect correction warranty continues for 10 years from the agreed handover date, subject to its terms, and does not end when the final payment is made.

The proposal includes the total price and any applicable fees or taxes, separately identifying external and recurring subscriptions. Invoices are issued under requirements applicable to the business and transaction.

For cancellation, refund requests or contractual complaints, email contact@almousa.dev with the agreement reference. Requests are reviewed against delivery progress, the agreement and statutory rights, with an explanation of amounts due or refundable. Paying an instalment or completing the one-week use period does not waive statutory rights.

Before contracting, we explain the applicable cancellation and refund conditions, costs and any exception relevant to the project.