Via agency partner · white-label
Multi-location healthcare: delivery unblocked.
An agency drowning in backlog handed us their delivery queue. Dedicated team, their brand, their tools: velocity up 85%.
85%
Faster delivery
Cleared
Delivery backlog
QA software testing services
that check every release before it ships.
QA software testing services that run all through the project, not in a rush in the final week. You get a written test plan, automated tests where they save time, and testing on real phones and computers. Every build must pass a final check before release. We test code we wrote, or code anyone wrote.
Strategy in writing · Real devices · Runs in your CI
Brands our teams have delivered for
What we do
PixelCrayons provides QA and software testing as a service: test strategy, automated suites, manual and real-device passes, and release gates. Each project starts with a written test plan around your biggest risks. Automated tests run in your CI, which checks code at every change. We test software built by anyone, direct for brands and white-label for agencies.
- A test strategy in writingA written, risk-based plan of what's tested, how, and what 'ready to release' means.
- Automation where it pays backUnit, integration and user-journey suites in your CI, automated only where it pays back.
- Manual testing for what machines missExploratory testers who try to break things, with findings written up as reproducible reports.
Our work
See what we've built
and the results it brought.
Real projects for real clients, with results we can show.
2004
Established
500+
Agencies served
4,500+
Projects delivered
340%
Revenue growth · 7 months
eCommerce
+127%
Organic traffic · 5 months
SaaS
85%
Faster delivery · backlog cleared
via agency partner
Where the work happens
How it starts
From no testing
to checked releases.
01
Start
Brief and access
We sign an NDA and get access. Then we study the product, its bug history and its support tickets to find where problems get through.
02
Once the brief is complete
Itemised proposal
We confirm the date your proposal arrives. It sets out a plan built around your risks. It says what we automate, what we test by hand and what a release must pass. Every item is listed and priced.
03
Your decision
You sign off
You confirm the scope, the payment and the access we need. Nothing starts before this.
04
Typically 2 to 3 business days later
The work starts
A quick set of checks, called a smoke suite, covers the steps that bring in revenue. It runs in your CI. We agree the device list from your real visitor data.
05
On the date in your proposal
First deliverable
The first round of regression and manual testing, with bugs sorted and reported by severity. From here, every release goes through the check.
Inside Prism
Your engagement, week to week,
in one workspace.
Prism is the client workspace where your requests, approvals, tasks and weekly reviews live.
Some engagements include Prism, our client workspace, and your proposal says whether yours does. Where it does, your build runs in a workspace you log into: requests, approvals, the task list and the weekly review, beside the repository your team already owns.
- 01
Requests and approvals
One queue, beside the repository your team owns.
- 02
Owned tasks
Every task has one owner and a date.
- 03
Weekly review
Each decision recorded, with the expectation attached.
In every engagement
What our testing service
includes.
01
A test strategy in writing
Before we run a single test, we agree what we test, how, when and against which risks. The plan covers the steps that bring in revenue and which failures you can live with. It also says what we automate and what we test by hand. It also says what 'ready to release' means for you. Your team can read it, question it and update it. Testing without a plan is just clicking around with confidence.
First
02
Automation where it pays back
Automated tests check each small part of the code, how the parts work together and full user journeys. They run in your CI every time code changes. We keep them fast and reliable, because tests that fail at random teach teams to ignore warnings. Automation pays off when a check is repeated often. So we tell you which steps are worth automating and which are cheaper to test by hand.
Every merge
03
Manual testing for what machines miss
Our testers actively try to break things. They check how easy the product is to use, which scripts can't judge, and the odd cases nobody wrote down. Manual testing takes judgement: a step can pass every check and still confuse the person paying. We write each problem up so anyone can repeat it, not as a vague complaint.
Every release
04
Testing on real devices as well as emulators
We agree a list of browsers and devices from your real visitor data, then test on physical hardware. That includes mid-range Android phones on slow connections. That is where many real users are, and where emulators make things look better than they are.
Per matrix
05
Release checks and regression testing
Every release must pass a set check before it ships. Automated tests pass, the regression tests run, manual testing is done and bugs are sorted by severity. Regression testing means re-checking old features after each change. Every PixelCrayons build goes through this same QA check, and here you can buy it on its own. The regression tests grow with the product, so what worked last quarter keeps working.
Every release
Proof
Finding problems early
so delivery moves faster.
Around the testing
QA works with
every service that ships code.
Testing is built to fit around other people's work. Each service here stands on its own, with QA built in, or you can buy QA alone.
01All DevelopmentAll our web, online store and engineering services in one place. Every build passes a QA check before it ships.02Web DevelopmentCustom sites and web apps, tested while they are built rather than afterwards.03DevOpsRelease pipelines: the systems that run the automated tests and stop a release that fails.04PerformancePage speed measured and kept within limits. Users feel a slow site before they ever see a bug.
Need the builders, not just the testers?
QA as a service tests anyone's code. You may need a team that builds and tests together instead. We offer that too, under your brand or ours, and the same release check comes with the team.
Who is accountable
The people responsible
for your work.
Parvessh Agarwal
Founder & CEO
An entrepreneur at heart. He links business analysis, strategy, clear goals and ROI to practical technology.
LinkedIn →
Saundaraya Gupta
Technical Manager
Brings technical work, client updates and project management together, so work moves smoothly from brief to launch.
LinkedIn →Every engagement
A named coordinator and escalation contact
Know who coordinates your engagement, who owns the work and how to escalate an issue.
All engagements. Roles may be combined and vary with your engagement.
Before you sign
Our commitments
Each one says where it applies and links to its full terms.
Response and start times
We typically respond within four business hours. Eligible engagements can typically start within two to three business days after scope, payment and required access are confirmed.
Business hours are Monday to Friday, 9:00 am to 6:00 pm IST, excluding published company holidays. Typical expectations, not guaranteed service levels.
Full terms30-Day Corrective Maintenance
Applicable development work includes 30 days of corrective maintenance after production launch.
Development engagements, including partner (agency) development engagements and AI implementations; not marketing services or retainers.
Full termsClear IP & Ownership Terms
Your materials remain yours. Bespoke deliverable rights, licences and handover are agreed before work starts.
All engagements.
Full termsClear Delivery & Escalation Ownership
Know who coordinates your engagement, who owns the work and how to escalate an issue.
All engagements. Roles may be combined and vary with your engagement.
Full termsHow do we know the work will be good?
Every delivery is reviewed before release by QA, your Project or Account Manager and a senior delivery lead, and you then review it against the acceptance criteria agreed at the start. Our specialists use AI to support delivery, with people responsible for reviewing the work. Applicable development work includes 30 days of corrective maintenance after production launch.
Who owns the ad accounts, the data and the work?
Your materials, data and accounts remain yours, and we prefer to work in advertising and analytics accounts you own, with access delegated to our team. Agreed ownership rights in bespoke deliverables transfer under the engagement terms and applicable payment; third-party software and assets keep their licences. We do not withhold customer-owned data or accounts over a payment dispute.
What if we want to stop?
Cancellation, notice and any renewal terms are written into your proposal or statement of work before you accept it. If an engagement ends early, we hand over completed, paid-for work and list any unfinished work separately. For an eligible specialist trial, you can stop within the trial window and pay nothing for eligible trial hours.
How will we know what you are doing?
Before work starts we agree how often you get updates, what the reports cover and who sends them. You know who coordinates your engagement, who owns the work and how to escalate an issue. For hourly and retainer work, time is recorded in Workstatus, so you can see the time records behind your invoice.
How we handle claims, credentials and your data: group credentials, dated ratings, how case figures are signed off, client permissions and data handling.
Automate or not
Which flows we automate,
and which stay manual.
Before you commit, the written plan says which steps get which kind of test, and why. Automation pays off on checks you repeat, and manual testing covers judgement. This is how we split the work.
| The flow or check | How we test it | Why |
|---|---|---|
| The steps that bring in revenue | A quick smoke suite running in your CI, in week one | They carry the most risk, so we cover them before anything else. |
| Checks needed on every code change, such as whether systems still connect | Automated tests in your CI | Automation pays off on repeated checks. The system enforces the release check, so nobody has to remember it. |
| Features that worked last quarter | Regression tests that grow with the product | A bug fixed stays fixed. |
| A step that would cost more to keep automated than to test by hand | Manual, by design | Tests that fail at random teach teams to ignore warnings. So we tell you when automating would not pay off. |
| New features, usability, visual quality and the edge cases nobody wrote down | Testers who actively try to break things | A step can pass every check and still confuse the person paying for it. |
| How it behaves on your users' phones and browsers | Real devices, from a list agreed from your visitor data | Emulators make things look better than they are. Many real users are on mid-range Androids and slow connections. |
Every release then passes the same check: automated tests pass, regression tests run, manual testing done and bugs sorted by severity.
Questions
Frequently
asked.
No, and no honest QA company can, because complex software can't be tested completely. We commit to the process that makes missed bugs rare. That means a plan built around your risks, automated tests on every code change, and manual testing on real devices. Bugs are sorted by severity, and no release skips the final check. Regression tests keep fixed bugs fixed.
Both, in a mix the test plan works out for your product. Automation suits checks you repeat: regression tests, checks that systems still connect, and steps tested on every code change. Manual testing suits judgement: trying to break things, ease of use, how it looks and the odd cases nobody wrote down. The written plan says which steps get which kind of test, and why.
Yes. Most of our work as a QA software testing company is exactly that. The code may come from your in-house team, another supplier or a developer who has left. We study the product, its bug history and its support tickets, then build the plan around the risks we find. Each bug report shows the steps to repeat it, where it happened and the evidence.
We agree the list from your visitor data, not a standard list. That usually means current and recent versions of the main browsers on desktop and mobile. We add real iOS and Android devices, chosen to match your visitors, including mid-range Androids on patchy connections. The list is written into the plan and updated as your visitors change.
We work inside them. Automated tests run in your CI on every code change, in GitHub Actions, GitLab CI or what you already have. Bugs go into your tracker with steps to repeat them and a severity. Testers join your stand-up meetings where that helps. If your pipeline needs building first, that's our DevOps service.
The difference is how the work fits in. Our testers work as part of your team, with tests in your CI and bugs in your tracker. Every project starts with a written test plan, built around your risks, that your team can read and question. The tests are built in your repositories, with IP and ownership terms agreed before work starts.
Your materials, data and accounts remain yours, and the suites are built in your repositories. Agreed rights in bespoke deliverables transfer under the engagement terms and applicable payment. Agencies white-label QA, NDA-backed, and we don't approach the clients you introduce for direct business, through the work and for twelve months after the last assignment for that client ends.
The range
What it costs,
at the direct rate.
A fixed quote for the test plan and the automated tests, and a per-release rate for checking each release. Then a monthly retainer for testers who work as part of your team.
- ProjectTest strategy and suite build$1,875–$12.5Kfixed quote, one-time
- Per unitRelease regression pass$625–$2,500per release
- RetainerMonthly QA retainer$1,000–$5,000per month
Indicative: every figure is refined into an itemised proposal.INR figures shown excl. GST.
Put a gate
in front of your releases.
Tell us what you're shipping and what keeps breaking. Once we have a complete brief, we confirm the date you will receive your written test strategy and itemised proposal.
Reply within four business hours (typical) · NDA standard · Clear IP & Ownership Terms
Last updated