Quality and acceptance
What is not tested is not delivered.
Written acceptance plan, testing on real browsers and devices, accessibility and performance checks before going live.
A written acceptance plan, shared before delivery
The plan lists the scenarios to verify, in plain language: place an order paying on delivery, correct an address, cancel. You read it beforehand, you complete it, and it becomes the shared reference.
Without that document, acceptance turns into a list of mood-driven remarks and the project never really ends.
Test on what your visitors actually use
We test on an entry-level Android and on a throttled connection, not only on a development machine. That is where heavy pages and thumb-hostile forms show up.
Basic accessibility checks come with it: contrast, keyboard navigation, field labels, alternative text on images. They take little time and prevent expensive rework.
A heavy page also costs rankings, and that is the first thing flagged by an audit of search engine optimisation .
Pricing is handled subject by subject, with a short form and a written answer: Request a quote for your web project. And to judge on evidence, we show what we run ourselves: our four in-house products.
DX-21
Common questions about quality
Is acceptance billed separately?
It is included in our own projects. We bill it separately when it covers a build done by somebody else.
How much time should we plan?
One to two weeks on a mid-sized project, fixes and a second pass included. The limiting factor remains the availability of your testers.
What if a defect appears after launch?
Blocking defects are fixed without argument during the warranty period set in the contract. We separate defect from change request, and that separation is written before delivery, not improvised after.
Reference DX-21
Put a price on it
A short scoping round, a fixed price, a schedule. Tell us the outcome you want, not the solution you picture.