How we work
Afoxlabs delivers QA as defined pieces of work with a committed timeline — measured in days, weeks or sprints. You never rent a tester, manage a headcount or pay by the hour. You agree what gets delivered and when, and we deliver it.
From task to delivery
A feature that needs testing, a regression pack to automate, a release to validate, an API to cover, a suite to stabilise. A short description is enough to start.
Within two business days: the deliverables, the acceptance criteria, the delivery date in days, weeks or sprints, and a fixed quote for the whole piece of work.
Progress is visible in your own tools — your repository, your tracker, your CI. Any risk to the date is raised the day we see it, with options.
Test cases, automation code, pipeline configuration and documentation are delivered into your repositories, with a handover and a written summary of what is covered.
Engagement models
Each one is priced by what it delivers. Start with whichever fits the work in front of you.
For: Teams that want an outside view of where quality stands before deciding what to outsource.
Includes
Outcome
A written assessment you can act on with your own team, or turn straight into a scoped piece of work with us.
For: Any defined QA task you want delivered by a specific date, without hiring or managing anyone.
Includes
Outcome
One finished piece of QA work, on the agreed date, at the agreed price.
For: Teams with a steady flow of QA work who want it planned and delivered every sprint.
Includes
Outcome
A predictable QA delivery rhythm that matches your own sprints — priced per sprint, never per person.
Typical timelines
A guide to plan with. Your exact date is confirmed in writing after we have looked at the product and the repository. One sprint is two weeks.
| QA work | Typical delivery |
|---|---|
| Test plan and test cases for one feature or module | 2–4 working days |
| Exploratory testing of a new feature, with a written defect report | 1–2 working days |
| Manual regression cycle for a release (up to ~150 test cases) | 2–5 working days |
| Wiring an existing test suite into CI with quality gates | 3–5 working days |
| API test automation for a service of 20–30 endpoints | 1–2 weeks |
| Playwright automation for your five most critical user journeys | 1–2 weeks |
| Performance baseline for key APIs with JMeter or k6 | 1–2 weeks |
| New automation framework set up from scratch, running in CI | 2–3 weeks |
| Evaluation harness for an LLM or RAG feature | 2–3 weeks |
| Stabilising a flaky automation suite | 1–2 sprints |
| Automating an existing manual regression pack (~100 cases) | 2–4 sprints |
Most requested package
Two weeks, fixed scope, fixed quote. The fastest way to put an automated safety net under the journeys your revenue depends on — and a clear picture of what working with us is like.
Working principles
Each of these appears in the statement of work, so both sides can rely on them.
You agree what gets delivered and by when. How we staff it is our responsibility, not a line item you manage.
Tests and frameworks live in your version control from the first commit, with no proprietary runner. Everything we build is yours to keep.
Each delivery has a written statement of work. New requests are welcome — they get their own scope and date, so the original commitment stays intact.
We only commit to timelines we have capacity to meet. If something threatens a date, you hear about it immediately, with options.
NDA before anything technical. Scoped credentials, production access only when the work requires it, and secrets kept in a secrets manager.
For every release we validate, you get a written recommendation with the evidence behind it, so the decision is easy to make and easy to explain.
Reporting
These four show whether your product is getting safer to release, and they are the ones we report against for every ongoing engagement.
FAQ
By the delivery. After scoping, you get a fixed quote for the agreed deliverables and date. There are no hourly rates, no day rates and no per-person billing. For ongoing work, each sprint is priced the same way: by what it delivers.
From the work itself: the number of journeys, endpoints or test cases, the state of your environments, and how much automation exists today. We look at the product and the repository before committing, so the date reflects your actual system. The typical timelines are listed here.
Yes — that is exactly what Scoped QA Delivery is for. One feature, one regression cycle, one automation build-out. There is no minimum contract and no obligation to continue afterwards.
The new work gets its own short scope, date and quote, and you decide whether to add it. The original commitment stays as agreed, so you always know what you are getting and when.
We work primarily in IST with planned overlap for European and US teams. Working hours and response windows are written into the statement of work.
Read-only first: repository access, a walk through the product, existing tests and CI configuration, and your last few incidents. Incidents are the most useful artefact you have — they show where the product actually breaks.
Yes, and it works well. Your engineers hold product knowledge that is hard to replace. We usually take on the automation build-out and regression execution, so their time goes into the work that needs their judgement.
You keep everything: the framework, the tests, the pipeline configuration and the documentation, already in your repositories. We run a handover session and write down what is covered and what we would suggest next.
Describe the work — a feature to test, a regression pack to automate, a release to validate. Within two business days you get a written scope, a delivery date in days, weeks or sprints, and a fixed quote.