Most teams that try AI software testing start in the wrong place. They point a model at the app, ask it to "find bugs," and get a list of guesses. Some are real, many are noise, and nobody can say what the agent actually checked.

At DevIT we build and run our own Shopify apps, so we test our own products every release. This October our QA team ran an AI agent against an internal analytics console we are building for our app portfolio. It was the first full test pass after development wrapped up and before release, the stage where a product is expected to have open defects. The agent did not test against a plan written for QA. It tested against the specification written while the product was being built: the product owner decided what each feature must do, and developers captured those decisions as they built it. Between October 8 and October 14, 2026, the agent produced 75 bug reports in Jira, and almost every one of them points to a numbered requirement. Here is how the chain works, what the agent is good at, and where a human still has to make the call.

Why AI software testing fails without requirements

An agent with no reference point tests what it sees. It clicks a button, sees a success message, and reports that the feature works. It has no way to know that the number on the screen should have been an average, not a sum, because nobody told it what the number means.

A human tester fills that gap with experience and with conversations with the product owner. An agent can't. It needs the expected behavior written down, one statement at a time, in a form it can check. Without that, the agent invents its own expectations, and you end up reviewing its imagination instead of your product.

We are not the only ones moving this way. The 

 by Capgemini, Sogeti and OpenText surveyed more than 2,000 senior executives in 22 countries. It found that 89% of organizations are piloting or deploying generative AI in quality engineering, but only 15% have reached enterprise-wide implementation. One third of respondents saw minimal productivity gains.

Two findings from the same report match what we saw. First, test case design and requirements refinement now lead AI adoption in QA, ahead of defect analysis and reporting. That is exactly where our chain starts: requirements first, tests second. Second, 60% of organizations name hallucination and reliability among their top challenges. In our run, that risk showed up as findings the tester had to reject.

World Quality Report 2025-26: 37% of organizations use generative AI in quality engineering in production, 52% in pilots, 11% not at all; 15% at enterprise scale

thumbnail_ai-software-testing-agent-01-industry-adoption.png

ai-software-testing-agent-01-industry-adoption.png

, based on nearly 5,000 technology professionals, adds the other half of the picture. 90% of respondents use AI at work, and 30% report little or no trust in the code it generates. DORA's conclusion is that without strong automated testing and fast feedback loops, more change volume leads to instability. AI makes teams write code faster, so testing has to keep up.

Three steps, each with a human in the loop

The setup that worked for us has three steps. AI does most of the writing in each one, and a person owns the result.

 The product owner decides what each feature must do. Developers work those decisions through with an AI assistant as they build: edge cases, limits, trade-offs. The result is a specification that lives in the product repository next to the code.

2. Requirements are generated from the spec.

 From those specs, AI drafts product requirements: short, testable statements, each with its own ID, grouped by screen. "The list shows each customer once across pages." "Average monthly revenue is the mean of member values." A person reviews them before they are published, and they are what testers write test cases from.

3. An agent tests the product against the requirements.

 This is the part our QA team built, and it is not a single prompt. The agent is a combination of skills and instructions it follows on every run. It reads a requirements page, walks the matching part of the app, and checks each statement. When something doesn't match, it drafts a bug report with steps, expected result, actual result and the requirement ID.

The requirement ID is what makes the output usable. A developer reading the ticket doesn't argue about whether it is a bug. They open the requirement and see what was agreed.

Three steps from spec to bug report, each drafted by AI and checked by a person: developers, a requirements reviewer and the tester

thumbnail_ai-software-testing-agent-02-testing-chain.png

ai-software-testing-agent-02-testing-chain.png

The first one needs the least setup: Claude Opus 5.5 with the Claude in Chrome extension. The agent loads our skills and instructions, reads the requirements, clicks through the app in a real browser and drafts tickets. It needs almost no setup. The cost is tokens: the agent "sees" each page as a screenshot, and in our runs each one took roughly 1,000–1,500 tokens.

The second setup uses MCP servers: one to read the requirements pages, 

 to drive the app, and a Jira MCP to file the results. Reading documents and filing tickets through an API is far cheaper than screenshots. Playwright MCP also works from a text snapshot of the page's accessibility tree, not from images, so each step costs less. The trade-off is setup time: you install Playwright, connect the servers and configure access before the first run.

In both setups the agent does not file anything on its own. It returns a list of findings, and the tester decides which ones become tickets.

Keep the stage in mind: this was the first full QA pass over the product, right after development and before release. Very few of the 75 reports are crashes. Most are quiet defects that a manual pass skips: a number calculated differently from what its label promises, the same values counted in two totals, one metric under several names, empty states with no message, destructive actions with no confirmation. Nothing on the screen looks broken. You only see these when you check each screen against what was agreed, and that is exactly what the agent does.

These figures are our QA team's estimates from this round, not a benchmark.

The bottleneck moved. Finding bugs got faster, and the hard part became triage and fixing.

One week of AI-assisted testing: 75 bug reports filed, about 2 hours for a product section against more than a day manually, about 20% of findings rejected by the tester

thumbnail_ai-software-testing-agent-03-our-run.png

ai-software-testing-agent-03-our-run.png

Before testing the app, we ran an agent over the requirements themselves. It found real gaps. One requirement mentioned a "stated maximum length" for segment names without stating it. Another said the list "stays usable" with many segments, which is a wish, not a requirement. A third allowed two different behaviors when a role is deleted, so a tester couldn't know which one to expect. It also flagged a design risk: if a segment's owner leaves the workspace, nobody can edit or delete their segments, but the nightly job keeps processing them.

We didn't treat that review as its own stage, and we paid for it later. When you tell an agent to test the app against requirements, it tests the app. Where a requirement is vague, it quietly fills in its own answer. Reviewing requirements is a separate step in the testing life cycle for a reason, and with AI in the loop it matters more, not less. Requirements review is now a separate stage in our process, before any test run starts.

Our QA team is direct about the limits. The agent is weak at:

It can also report "checked, works" after a shallow check. It sees a success toast without confirming the data was saved, or takes a loading state for the final result. As our testers put it, the agent does exactly what it is told, while an experienced tester senses where bugs are likely to be.

So the agent doesn't replace the tester. It takes over the slow, systematic part, checking each requirement one by one, and leaves the tester the judgment.

What this means if you build software with us

For our clients, AI software testing changes what "QA" includes: the spec written while building becomes the test plan. We can check every written requirement on every release, not a sample. Reports come with a requirement ID, so arguments about expected behavior end quickly. And requirement gaps surface before code is written, when they are cheapest to fix.

It only works when requirements exist and are specific. That is why we treat specs and requirements as part of the deliverable, not paperwork. We wrote about a similar split between AI and people in 

. For Shopify specifically, see how we work on 

The Spec We Wrote While Building Became the Test Plan. An AI Agent Found 75 Bugs

AI / ML

Software Development

Black Friday 2026 falls on November 27, and Cyber Monday on November 30. For many Shopify merchants, those four days are the busiest of the year, and every weak spot in the store shows up at once: a slow theme, a broken discount, a tracking pixel that stopped firing in August. If you want to prepare your Shopify store for Black Friday, the work starts now, not the week before.

We have built on Shopify since 2016. As of October 2026, our 

 counts 25 stores, 64 Shopify projects and 48 apps. Five of those apps are our own and live on the App Store, so we see the platform from both sides, as the team that builds stores and as the studio that ships code into thousands of them. This checklist is what we would review in any store before the peak.

Last year's weekend set a record. Shopify reported $14.6 billion in merchant sales over Black Friday–Cyber Monday 2025, up 27% year over year, with a peak of $5.1 million per minute (

). Shopify notes the figures are estimates and unaudited. The wider market moved the same way: Adobe counted $11.8 billion in US online spending on Black Friday alone, up 9.1%, and $44.2 billion across Cyber Week (

). Globally, Salesforce estimated Cyber Week sales at $336.6 billion, up 7% (

What makes 2026 different is not the size of the weekend. It is that two parts of the platform changed under existing stores:

Neither change throws an error. Orders keep coming in, and the store looks fine. That is why this is the first thing to check.

Two Shopify platform changes in 2026: Scripts switched off on June 30 and Thank you and Order status pages upgraded on August 26

thumbnail_prepare-shopify-store-black-friday-01-platform-changes.png

prepare-shopify-store-black-friday-01-platform-changes.png

Start with checkout and the thank-you page

Place a real test order on desktop and on a phone, then walk through what happened:

Checkout is also where most sales are lost. Baymard Institute puts the average documented cart abandonment rate at 70.22% across 50 studies, and estimates that a large e-commerce site can raise its conversion rate by 35.26% through better checkout design alone (

If you find a gap, fix it now. The week before Black Friday is the worst time to discover that a discount silently stopped applying.

Peak traffic punishes slow pages, and most of that traffic is on phones: on Cyber Monday 2025, 57.5% of US online sales came from mobile devices (

). Speed shows up in revenue. In a study of 37 brands commissioned by Google, Deloitte found that a 0.1-second improvement in mobile site speed was associated with 8.4% more conversions for retail sites (

Research figures: 57.5% of US Cyber Monday 2025 online sales on mobile, 70.22% average cart abandonment, 8.4% more retail conversions with a 0.1-second faster mobile site

thumbnail_prepare-shopify-store-black-friday-02-research-numbers.png

prepare-shopify-store-black-friday-02-research-numbers.png

Run your home page, a collection page and a product page through PageSpeed Insights on mobile, and look at what loads:

A freeze sounds bureaucratic until a "small" theme edit breaks the cart on Friday morning.

Raise order value without giving away the margin

A deeper discount is the obvious lever and the most expensive one. Shoppers arrive ready to buy, so the cheaper win is making each order bigger:

Whatever you use, set it up and test it in October. Merchants who install an upsell app on Thanksgiving rarely have time to tune it.

Black Friday is no longer a US-only event, and international visitors leave fast when prices show in the wrong currency. Check that Shopify Markets is configured for the countries you actually ship to, that prices and duties are clear, and that visitors from abroad land on the right market or store. 

 adds country, currency and language selectors and geolocation redirects on top of Markets, including redirects between separate expansion stores.

Plan for the order surge, not just the traffic

The weekend ends; the fulfillment backlog does not. Decide in advance who handles what when orders spike:

Shopify Flow handles many of these rules. When you need more, such as external integrations, schedules or custom logic, we wrote about the approach in 

 covers tagging, stock alerts and risky-order handling out of the box (

Black Friday 2026 preparation timeline: audit in October, set up and test in early November, theme freeze on November 13, on call November 27 to 30

thumbnail_prepare-shopify-store-black-friday-03-timeline.png

prepare-shopify-store-black-friday-03-timeline.png

What this year's platform changes did to our own apps

We are not immune to the same changes. In October, while testing the ReSell 2.5.0 release, our QA engineer found that offers with a "Customer tag" condition did not show at checkout, on the thank-you page or on the order status page. The cause was the move to a newer API version: the field our code read the customer from no longer existed there, and the buyer now comes from a different object. Nothing crashed. The offers simply did not appear.

The fix was a single commit, and it shipped with 2.5.0. What caught the bug was not monitoring but a tester checking the offer conditions by hand. That is the lesson for any store owner: platform updates fail quietly, and the only defense is to test the flows that make you money, on purpose, before the traffic arrives.

Get a second pair of eyes before the peak

A checklist tells you what to look at. It does not tell you what broke in your particular store, and that is where most of the time goes. Custom theme code, discount logic that used to live in Scripts, several markets or expansion stores, integrations with an ERP or a warehouse: these are the places where this year's platform changes fail quietly.

Our team has worked with online stores on Shopify since 2016. Before Black Friday, we can audit your store against this list, rebuild what stopped working, test the flows that bring in revenue and stay on call through the weekend. 

Your Shopify Store Changed This Year. Is It Ready for Black Friday?

Insights

Tech

Every support team is being told that AI will take over its inbox, and vendor demos answer every question perfectly. It is hard to tell what that means for a real product with real customers. We wanted a real number for AI customer support for Shopify apps, measured on our own conversations, before we changed anything in how we work. So we took 90 days of support for the Shopify apps we build and run at DevIT Software and asked one question of every conversation: what did it actually take to resolve this?

The answer is that AI could resolve 37% of real customer requests without an operator, and help with the first reply in about two thirds of them. For a team handling around 370 requests a month, that is roughly 135 tickets nobody would need to touch. For us, that is a strong result, and this article explains how we got it and what we are doing with it.

We took every support conversation active across our apps between June 30 and September 28, 2026, mainly ReSell, Selecty, Lably, React Flow, and ShopCart: 3,904 in total. After filtering out automated notifications, newsletters, and outbound messages nobody replied to, 1,967 were left. We read a stratified sample of 957 of them, every conversation in the busiest queues and a share of the rest, going through every message including internal notes. The sample held 661 real customer requests, and we weighted the results back to all of the roughly 1,100 real requests in the period.

Bar chart: 3,904 conversations, 1,967 after the noise filter, 957 read in full, 661 real customer requests in the sample

thumbnail_ai-customer-support-shopify-apps-01-sample-funnel.png

ai-customer-support-shopify-apps-01-sample-funnel.png

Each request got one verdict based on what it would have taken to close it:

An AI model read the conversations through our support platform's API, under a written rubric that forbade any changes, and nothing in the conversations was modified. We publish only aggregate figures: no customer names, stores, or messages appear in this article.

The clearest win is "how does it work" questions: AI can answer almost all of them, and for most the help article already exists. Rule-based billing questions and plan limits fall into the same group.

The picture also differs by app. AI could resolve 47% of Selecty requests and 44% of ReSell requests on its own, compared with 29% for Lably and 26% for React Flow. The last two have more questions that depend on the merchant's own theme or workflow.

Bar chart: AI could resolve 47% of Selecty requests, 44% of ReSell, 29% of Lably and 26% of React Flow on its own

thumbnail_ai-customer-support-shopify-apps-02-ai-share-by-app.png

ai-customer-support-shopify-apps-02-ai-share-by-app.png

The 37% is only part of the value. In another 30% of conversations, AI could give a correct first reply from the documentation, some of it still to be written, and a person would then finish the job. The merchant gets an answer in seconds instead of waiting for the queue, and the operator starts with context instead of a blank reply box. Taken together, AI is useful in about two thirds of all requests.

Stacked bar: AI could resolve 37% of real requests on its own, in 30% it could give the first reply and a person finishes, and 33% need a person from the start

thumbnail_ai-customer-support-shopify-apps-03-who-resolves.png

ai-customer-support-shopify-apps-03-who-resolves.png

Published figures range from a measured 14% to a predicted 80%, mostly because they measure different things:

Bar chart of resolution without a person: Gartner self-service 14%, DevIT Software apps 26% with today's articles and 37% with all articles written, Intercom Fin vendor-reported 76%, Gartner 2029 prediction 80% of common issues

thumbnail_ai-customer-support-shopify-apps-04-published-benchmarks.png

ai-customer-support-shopify-apps-04-published-benchmarks.png

Our 37% is an estimate of what AI could close, measured one conversation at a time. It sits well above what self-service delivers and well below the vendor average, and our data shows why. About half of what our merchants ask is setup inside their own store, work that AI can't do from a chat window. A queue made mostly of questions with one documented answer will score higher. Gartner's 43% and our 11% point to the same lever: missing content is the cheapest problem to fix.

Finding the bottlenecks in our help guides

The most practical outcome was one we didn't plan for. An analysis like this shows exactly where an app's help guides fall short: which questions customers keep asking that the documentation doesn't answer. For 11% of requests, the only thing missing was an article.

That list is now our documentation roadmap. Every new article moves requests from "needs a person" to "AI can answer" and helps merchants who never open a chat.

Almost half of all requests, 48%, need someone inside the merchant's store. Setup questions make up about half of everything customers ask, and nearly nine in ten of those need hands in the store: finding the right CSS selector for a theme nobody on our side has seen before, checking markets and redirects as a shopper in another country would see them, building a workflow together with the merchant, or tracing why an upsell funnel isn't showing.

That is expert work, and it is what our support team does best. They know our apps from the inside, they read an unfamiliar theme in minutes, and they stay with a problem until it works for the merchant. Merchants notice. "Their support team is perhaps the best you will find on any Shopify app" wrote a 

This is why AI in our support is a tool in our team's hands. It takes the routine questions and drafts first replies, and it works only because a strong team stands behind it.

Our merchants are business owners and operations managers who value their time. They want the problem solved quickly, by someone who knows the product, and research says the same of customers in general:

The research and our data point the same way. AI works in front of a strong team, answering simple questions fast and handing the rest to a person who knows the product. Without that team, it becomes a wall between the customer and a solution.

The verdicts were assigned by an AI model following a written rubric, with no separate human audit. "An article exists" says nothing about how good that article is. Where part of a conversation happened by phone, we only saw the written part. We treat the numbers as a careful estimate, and we will measure again once the new help articles are live.

AI customer support for Shopify apps: what it means for yours

If you run a Shopify app or a store with its own support team, the number worth knowing is your own. Generic deflection rates hide which of your requests need a person and which only need a better help article.

We can run the same analysis on your support inbox and turn it into a documentation plan and an AI setup that fits your team. 

AI Could Resolve 37% of Our Support Tickets on Its Own. Here's How We Measured It

Data

Every Shopify store runs on small, repetitive jobs. Someone checks whether an order looks fraudulent, tags it for the warehouse, chases it when it sits unfulfilled, copies it into the accounting system, and emails the customer when something goes wrong. Each job takes a few minutes. At a few hundred orders a week, together they become a part-time position nobody hired for, and the person doing them is usually the one who should be growing the business. Shopify business process automation is how we hand those jobs to software that doesn't get tired or forget a step.

At DevIT we have been building software since 2013 and have worked with 700+ clients worldwide. We also run our own workflow automation app, React Flow, which executed over a billion workflow runs for merchants between March 2024 and August 2026. A workflow run is one execution of a workflow: an order checked, a product processed in a bulk update, a row written to a report. Not every run ends in an action. This article covers how we approach automation for a Shopify business, where we start, and what we deliberately leave to people.

When we audit a store's operations, the time rarely disappears into one big task. It leaks through a dozen small ones:

None of these needs a person's judgment every time. All of them need a person's judgment once, when the rule is written.

React Flow's own usage gives a grounded answer, but first a word on how we count the time.

 A workflow run that does its job can save anywhere from about a minute to an hour of manual work, depending on how many steps and actions it replaces. Tagging a single order by hand takes under a minute. Checking an order, creating an invoice in Xero, emailing the customer and updating the team can take close to an hour. For our estimate we take a simple flow, the kind a store usually sets up first, where one run replaces about five minutes of real manual work. It is the same figure the React Flow dashboard shows merchants.

We applied that to every store that ran workflows in the 30 days to September 24, 2026. To stay conservative, we left out the per-item runs of bulk Fetch steps.

Horizontal bar chart: 52% of React Flow stores saved at least a working day of manual work in 30 days, 33% at least a working week, and 18% a full-time month or more

thumbnail_shopify-business-process-automation-01-time-saved.png

shopify-business-process-automation-01-time-saved.png

Share of stores by manual work React Flow replaced in 30 days, at five minutes per workflow run, per-item runs of bulk Fetch steps excluded. A working day is 8 hours, a working week 40, a full-time month 168. The hours are an estimate, not a measurement. Source: React Flow usage data, 30 days to September 24, 2026.

More than half of the stores saved at least a working day a month. One in three saved a working week or more, and about one in six saved more than the monthly hours of a full-time employee. A single alert saves minutes; a whole order process can save weeks. That is why we start client work with processes, not single workflows.

Hours are only part of the gain. A workflow doesn't drink coffee, doesn't call in sick, and doesn't ask for a day off in the middle of Black Friday week. It handles an order at 3 a.m. on a Sunday exactly the way it handles one on Monday morning, and it has never once tagged an order "urgnet".

We follow the same five steps on every project, whether the result is a handful of workflows or a custom app.

Orders are the densest source of repetitive work, so to automate Shopify order management is almost always the first win. These are the workflows we build most often:

Some decisions should stay with a person: refunds above a threshold, anything involving a chargeback, and canceling orders on a rule that hasn't been watched in production. We automate the alert and leave the decision to a human. A workflow that quietly cancels the wrong orders costs more than all the time it ever saved, and a client loses trust in automation after the first one.

React Flow's telemetry gave us a long view of how Shopify stores actually automate. Three patterns from our telemetry, March 2025 to August 2026, shape how we plan client work:

Bar chart of React Flow workflow runs per month from March 2025 to July 2026, rising from 34.5 million to 75.3 million, with a holiday-season high of 74.0 million in December 2025

thumbnail_shopify-business-process-automation-02-workflow-runs.png

shopify-business-process-automation-02-workflow-runs.png

React Flow workflow runs per month, in millions. Source: React Flow product telemetry, March 2025 to July 2026; earlier months used a different tracking scheme and are not comparable.

Running an automation product at this volume taught us things a one-off project never would. At its peak in spring 2026, React Flow was processing more than two million workflow runs a day, and at that load every rare edge case shows up daily. We treated errors as an engineering problem rather than a support one and drove them down over the following months. The lesson carried into client work: automation needs monitoring from day one, not after the first incident.

We also learned that most merchants never get past an empty workflow editor. Installing an automation tool doesn't automate anything. That is why our engineers regularly build a merchant's first workflow for them, and why it is one of the things React Flow's reviews mention most. One merchant summed it up: "they even built the flow I needed for me."

Why merchants trust us with their operations

Doing it yourself: from Shopify Flow to React Flow

If you'd rather build the automation in-house, you don't have to start from scratch.

 is a good app, built by Shopify's own team, and it has taught a lot of merchants to think in triggers, conditions, and actions. We took that idea further. Every day our support team talks to merchants, and almost every conversation shows us another job a store still does by hand. React Flow grew out of those conversations: more building blocks, more connections to the tools a business already uses, and ready-made automations you switch on instead of assembling. It works on every Shopify plan, for a single-founder shop that wants its evenings back and for a Plus operation with a full operations team.

If your team spends its week on work a rule could do, we can start with an audit and a process map, and you'll see where the hours go before any code is written. 

, including the one we shut down, or see 

Shopify Business Process Automation: How We Give Store Teams Their Hours Back

DevIT is a Shopify development company and eCommerce development services provider that began its journey in software development and custom web development in 2013. Since then, we’ve grown a lot - expanding our expertise across different areas and gaining valuable experience along the way. 

One of the things we’re most proud of is the strong community we’ve built: this year, we reached 

 across eCommerce development projects and Shopify app development. We’re truly grateful to every company and individual who trusted us with their ideas and projects.

Communication has always been at the heart of what we do. Working closely with our clients on a wide range of projects has taught us a great deal - not just about development, but about building meaningful, long-term partnerships. In this article, we’d like to share some of the key lessons we’ve learned along the way.

Who Our Clients Are: Types of Projects We Work With

Before diving in, we’d like to take a moment to describe our clients and highlight just how diverse they are. They come from different industries, have varying levels of technical expertise, and approach development with different expectations.

Back in 2013, we were a young startup eager to take on new challenges. Our first clients were individuals looking to build simple online stores or create modern designs for their projects. We were excited to help bring their ideas to life and achieve their goals together.

thumbnail_eleven jewelry

eleven jewelry

Today, we continue working with small projects alongside larger ones. These projects typically take less time and deliver results within 1–3 months. They allow us to move faster, see results quickly, and stay flexible throughout the process. Such projects often encourage creativity, as we can experiment with new ideas and approaches without long timelines.

Over time, we began partnering with clients who were looking for long-term collaboration. These projects typically fall into two main categories:

1.	Ongoing improvement and support of an existing product

2.	Development and launch of custom solutions and web applications

 - is unique because the product has already been developed before we join the process. This means we dedicate a significant amount of time to analyzing the existing solution, conducting an expert assessment, and identifying areas for improvement. Based on this, we create a structured action plan that aligns with the client’s goals and expectations.

The second type of long-term project involves 

developing and launching a product from scratch

. Over the years, we’ve built a strong team of experts across various fields, which allows us to handle even complex projects. From the initial idea to design and technical implementation, we have the resources and expertise to bring products to life.

thumbnail_Real America`s Voice

Real America`s Voice

One thing we’ve learned early on is simple: there’s no one universal solution. Each client requires a tailored approach, and understanding their background and readiness is the first step toward building a successful collaboration.

Over the years, we’ve gained extensive experience across a wide range of industries. Since 2013, we’ve successfully delivered eCommerce development services and custom software development projects in areas such as e-commerce, media, social networks, healthcare, fintech, real estate, construction, entertainment, travel & hospitality, and education.

Working with such diverse areas has allowed us to better understand different business models, user needs, and technical challenges. This variety not only strengthens our expertise but also helps us bring fresh ideas and best practices from one industry to another.

thumbnail_Industries We Work With

Industries We Work With

Every client comes to us with a unique level of knowledge and experience, and we always take this into account when building our collaboration.

We truly enjoy working with clients who have great ideas but may not be technically experienced. In these cases, we’re happy to guide them through the process - explaining each stage, clarifying details, and sharing our knowledge along the way.

At the same time, not all clients need this level of involvement. Some prefer to trust us with the process and stay less engaged in day-to-day development, focusing on their own priorities. We fully respect this approach as well. It reflects their confidence in our expertise and a clear understanding of the agreed plan.

Average Cooperation Time: What the Numbers Say

In the previous section, we explored the different types of projects and clients we’ve worked with. We also mentioned short-term and long-term collaborations. Based on this, we can estimate the 

thumbnail_Average Cooperation Time

Average Cooperation Time

It is also important to highlight that a significant portion of our clients choose to return to us. Currently, 

 of our clients come back for additional services. This level of trust is influenced by several factors, which we will explore in the next section.

At the same time, we want to mention that there are situations where we have had to close projects before completion. Currently, around 

 of projects have been discontinued due to various reasons.

One of the key reasons why clients continue working with us is 

 for Shopify apps and eCommerce solutions. Often, clients come to us for development, complete their project, and move on. However, after some time, many return for updates, audits, and further improvements.

They trust us as a reliable development company with deep product knowledge. This allows us to make enhancements efficiently and safely, ensuring that improvements are implemented without disrupting existing functionality.

But, in addition to this, we have feedback from our clients, so we can highlight the following reasons why customers stay or return to us:

We define goals and timelines from the very beginning. This ensures a smooth process and eliminates surprises along the way. This also helps build trust and ensures realistic expectations for every project.

Transparent processes & meeting deadlines

Our workflows are clear and structured. We keep our clients informed throughout the project. We also respect deadlines and consistently deliver our services on time. If a particular stage requires more attention than initially expected, we always inform the client in advance and clearly explain why additional time is needed for proper implementation.

We don’t just follow instructions - we offer ideas and suggest improvements. Our team looks for creative solutions that add extra value to every project. Because the final result matters to us. And if we see an opportunity to make something even better, we always share our ideas and suggestions.

We adapt to changing requirements and client needs as projects evolve. Every project is unique and situations can evolve. That’s why we remain flexible - ready to adjust our approach and adapt the process when needed. This allows us to stay effective in dynamic environments.

Challenges & Project Failures: What Didn’t Work

DevIT continuously invests in our team’s growth and strives to expand our knowledge and capabilities. However, it’s impossible to know everything, and failures also happen in our work.

Here we can share an example of our own failure, which happened recently with one of our own products.

Our Blog

The Spec We Wrote While Building Became the Test Plan. An AI Agent Found 75 Bugs

Your Shopify Store Changed This Year. Is It Ready for Black Friday?

AI Could Resolve 37% of Our Support Tickets on Its Own. Here's How We Measured It

Shopify Business Process Automation: How We Give Store Teams Their Hours Back

700+ Clients Later: Lessons That Shaped Our Approach

Mantle Shutdown: What Happened, How to Migrate Your Data, and the Best Alternatives

How We Use AI in DevIT: AI Tools That Help Our Team Work 40% Faster

DevIT Event Digest – May 2026

Stop Losing Money on Your "Basic" Cart: The Engineering Behind ShopCart’s 24-Hour Launch

Business Boosters: DevIT at the Event in Toronto to Explore New Tech Funding Insights