When a company adopts artificial intelligence with a technology partner, the cost of learning how to use it usually lands inside the project: rework, scope changes, delays and decisions made on the fly. At Shifta we take that cost on up front. Every new capability is tested, measured, discarded or refined inside our own operation first, and only then can it become part of a proposal. We call that practice Customer Zero.
In practice: a cycle of several internal stages before the client sees anything. Four rules that decide what moves forward and what does not. Internal forums such as our SHIFTalks and the token clinic, where results, mistakes and real usage get shared. We measure it with delivery-capability indicators, not AI-usage metrics. What reaches the client is not a demo: it is decisions already made, tools already evaluated, technologies already ruled out and capabilities that have worked under real conditions.
Learn first, deliver better
Customer Zero is our practice for validating new capabilities, processes and ways of working internally before turning them into a recommendation.
For a CIO, a CTO or a business leader, the most expensive risk in adopting artificial intelligence is hiring a partner who is still learning how to use it.
Hundreds of companies offering AI services have appeared in the past few years. At the same time, the industry conversation organized itself around concepts like AI readiness and AI first: one measures how prepared an organization is to adopt AI, the other proposes putting it at the center of every decision. Both can be useful, but neither answers a more basic question.
Who absorbs the cost of learning how to apply that technology under real business conditions?
Often the answer turns out to be the client. The tool is presented as validated, but its limitations surface during implementation. Assumptions get corrected with the project already underway. Estimates change. Scope is redefined. The partner's team learns while it delivers.
At Shifta we took a different route. Before adding a new AI capability to a proposal or a project, we use it to change the way we work ourselves: we test it, measure it, identify its limits, discard what does not work and document what we learned. Only then can it reach a client. We call that way of working Customer Zero.
Who pays for the learning curve
Every new technology repeats the same pattern: partners promise results before accumulating real experience, and for a while that is enough. But a successful demo does not guarantee that a capability holds up inside a full process, integrates with existing systems, meets security requirements or maintains quality under delivery pressure. When the partner does not have those answers yet, the first implementations become their learning process.
That cost rarely appears as a line item in the proposal. It shows up later, as rework, scope changes, delays, architecture decisions made on the fly and uncertainty about outcomes. Every new technology has a learning curve; the problem for the client is funding it without knowing.
If a tool still has to prove how it behaves under real conditions, that learning should happen on our time, with our teams and our budget, not the client's.
That was the trigger for Customer Zero: take the learning curve on internally and turn it into a reusable working method.
The industry applies it to products; we apply it to how we work
Customer Zero was not born at Shifta. Microsoft popularized it by using its own teams as the first clients of its technologies before taking them to market. Amazon holds a related idea in its "Day 1" principle: always operate as if it were the first day, close to the problem and deciding with evidence instead of inertia. Google and Meta run their own internal platforms before opening them up, and Atlassian and Salesforce do something similar with their products.
The shared premise is simple: an organization should experience the difficulties, limits and opportunities of a technology before recommending it to others.
Customer Zero usually means running internally the same software that later reaches the market.
We build delivery capabilities, methods and ways of working that we then apply on client projects.
So for Shifta, Customer Zero validates a way of understanding a problem, running a discovery, designing a solution, building software, producing documentation, testing quality, estimating effort, automating tasks, making decisions with AI and delivering a project under real conditions.
By the time a new practice reaches a client, our own teams have already used it, it has been measured inside a real process and it has been refined based on those results. Working once is not enough: it has to prove it improves a full delivery capability.
The full cycle, in six stages
Every new capability goes through the same cycle before becoming part of a proposal or a client project. The cycle exists so that we only adopt what has already proven it creates value.
The cycle starts with a real problem: a task, a point of friction or a decision that could be handled better. We do not start from an available tool and then look for somewhere to apply it. The opening question is which part of our work needs to improve, and why.
The hypothesis gets tested inside Shifta. The first environment might be an engineering process, a sales activity, a marketing task, a people need or a finance analysis. Experimenting internally lets us get it wrong without passing that risk to the client.
A proof of concept can look compelling and still fail to improve the process. That is why we measure from the first experiment. Depending on the case, we track variables such as time recovered, quality, consistency, accuracy, adoption, reduced rework or the ability to speed up a decision.
Not every tool or hypothesis deserves to move forward. Some are discarded because they do not create enough value, others because they introduce more complexity than they resolve, and others because they do not yet meet the required levels of security, reliability or quality. Every capability we discard is one less experiment happening later inside a client's project.
A capability stops being a test when it becomes part of other teams' daily work. At this stage we confirm it does not depend solely on the person who created the experiment: real adoption surfaces difficulties an isolated demo never shows.
For that to happen, each experiment leaves reusable knowledge behind: usage criteria, known limitations, prompts, skills, agents, evaluations, templates, metrics, technical decisions and the cases where the tool should not be used. Once the capability proves it can be repeated, that learning becomes method: guides, components, workflows and governance criteria that make it possible to apply consistently. That is where an individual experience turns into an organizational capability.
Only after clearing the earlier stages can a capability be considered for a proposal or a project. The client receives a practice that has already been used, measured, documented and refined inside our own delivery process, not a promise based on a demo.
The cycle does not end when a capability reaches a client. Every project brings new conditions, constraints and lessons, and that experience returns to the system to update the playbooks, improve the standards and revisit the original assumptions. That way each future project starts from a more advanced point than the last.
Four rules we apply before taking anything to a client
Customer Zero is a set of principles we use to decide which capabilities we adopt into the way we deliver projects. Those principles are what make it a repeatable practice instead of a collection of isolated experiments.
Every new technology has a learning curve and we absorb it. Each capability is tested inside Shifta first, with real processes and real teams. That is where the first limitations, implementation errors, edge cases and the questions a demo never answers show up. By the time the capability reaches a client, most of that learning has already happened.
In artificial intelligence it is easy to mistake a good demo for a good solution. That is why every hypothesis is tested and measured inside a real process before moving forward, and it has to answer one simple question.
What concrete improvement does it create in the way we deliver value today?
If we cannot answer that with evidence, we keep experimenting or we discard it. How many tools we decide not to adopt is one of the most important indicators of Customer Zero: saying "not yet" matters as much as saying "yes".
An experiment only creates competitive advantage when it can be repeated. That is why each initiative leaves more than a result behind: documentation turns individual experience into organizational knowledge.
The goal is to improve our ability to deliver results, not to add AI to every process. In some cases that means automating, in others assisting a decision, and in many it means deliberately deciding not to use AI.
Before automating processes, we train people
If you are currently evaluating how to bring AI into your organization, the first decision looks like which tool or license to buy. In our experience that is the second one: the first is understanding what capabilities each team needs to develop in order to create value with that technology.
It was one of the first processes where we were our own Customer Zero. We mapped the skills each role needed, assessed the level of knowledge across the company and used a pilot to validate which format drove real adoption. Only then did we build an upskilling program with DataCamp as the main platform, reaching engineering, marketing, people, sales and finance: AI changes how an entire organization learns, collaborates and decides, not only how software gets built.
And based on the results, DataCamp documented Shifta's experience as one of its customer success stories.
Customer story published by DataCamp
Case: how a pilot ended up becoming part of our delivery
One of the first processes we decided to review was requirements definition. It was a stage that required at least two technical profiles and seven chained steps:
- Define the user stories
- Refine them with the client
- Refine them with architecture
- Build screens or mockups
- Validate acceptance criteria
- Generate test cases
- Load everything into the management tool
It depended heavily on each Project Manager's experience and the quality varied across projects. The hypothesis looked simple: could AI help us generate more consistent user stories without losing business context?
The first experiment was basic. We took recorded meetings and tried different tools to turn them automatically into user stories. The results were uneven: some stories were too generic, others left out important constraints, and others invented information.
Instead of dropping the idea, we kept iterating. We tried different models, adjusted prompts, added project documentation as context and defined minimum quality criteria.
Today the stage is split in three.
Loading into Azure DevOps
On that stage we measure three things: definition lead time, requirements rework and ambiguity detected.
What created the most value was what remained after the experiment: a skill available to the whole team, an agent that splits complex user stories into simpler ones, templates, review criteria, examples and documentation.
Refinement skill available to the team
New projects now start with that learning already built in. That is the point of Customer Zero: turning every experiment into a delivery capability.
How we measure Customer Zero internally
One of the most common risks in adopting artificial intelligence is confusing activity with impact. It is easy to count licenses purchased, people who completed a course, prompts written, even agents built. None of those metrics answers the question that matters most.
Did our ability to deliver projects with AI actually improve?
Customer Zero exists to answer that question with evidence. We measure before scaling in order to show that we deliver better, not that we use more AI.
In practice we track three families of indicators. Speed: how long it takes an idea to become a proof of concept and an initial backlog. Quality: rework, consistency across teams and estimate accuracy. Adoption: usage by team and reuse of internal playbooks and agents.
We also measure token usage by team and by project. It is the most direct way to see where AI is genuinely being used, what each capability costs and whether that consumption translates into something. Cross-referenced with delivery times, it shows the trend we care about: tasks that used to take weeks now take days, and the ones that took days are resolved in hours. That reduction, sustained and measured, is the evidence that the capability improved.
SHIFTalks: where we share mistakes and wins
Many conversations about artificial intelligence still cover possibilities more than results. We prefer it the other way around.
At Shifta we regularly hold SHIFTalks, sessions where the teams themselves present real implementations, lessons and experiments already happening inside the company. Every area shares what they tried, what worked, what they discarded and what they learned. Customer Zero feeds on the wins and on the mistakes alike.
In one SHIFTalk we showed how we built, in under three hours, a proof of concept for detecting vehicle damage from photographs. It was not a finished product, but it showed that a business hypothesis can be validated in hours instead of weeks.
Vehicle damage inspector - proof of concept
In another SHIFTalk we built a map that estimated the commercial potential of a new branch by combining public data on traffic, demographics and competition. The goal was to reduce uncertainty enough to make a better decision.
Location intelligence · proof of concept
Not all of those initiatives will reach production, but all of them left reusable assets behind.
The token clinic: a close look at real usage
We also launched the token clinic. It is the technical team's equivalent of the SHIFTalks: a space to share experience and practices around token usage.
We look at cases like this one: two people solve the same task with the same tool, and one consumes several times more tokens than the other, with results of similar quality.
The clinic reviews real usage: what each workflow consumes, what context is being sent unnecessarily, when a smaller model is the better fit, when a reference file replaces three retries, and when the task did not justify using AI at all.
Four things we are working through right now
Being Customer Zero means learning ahead of our clients, not having every answer. These are some of the challenges we are still working through.
As more teams generate initiatives, different solutions appear for similar problems. Our challenge is to organize that knowledge without slowing experimentation down.
Some results are easy to observe: cutting the time needed to build a proof of concept is relatively simple. Others take more work. How do we measure a better decision, the quality of a recommendation or the value of having discarded a tool in time? We are still refining those answers.
When a person makes a mistake inside a process, we know how to investigate it, correct it and learn from it. AI raises new questions: who is accountable for a bad decision? How much human review is needed? How do we keep a record of who decided what?
Artificial intelligence changes too fast to assume any decision is final. A tool we discarded six months ago may be the best alternative today. That is why Customer Zero accumulates learning rather than certainties, and that learning is reviewed continuously. The goal is to keep improving our delivery capability, not to be right.
What we do has not changed: we are still a strategic partner
We still build digital products, scale teams and help organizations make better technology decisions. What changed is how we learn: tools change, models evolve and vendors come and go, and the sustainable advantage comes from learning faster than the technology changes.
A client working with Shifta is not just buying a team or development hours. They are buying hundreds of decisions already made: tools evaluated, technologies ruled out, processes refined, playbooks written, agents built and delivery capabilities that have already worked under real conditions. That learning, hard to see from the outside, is what reduces uncertainty from day one.
Where it shows most is in the meetings: we used to explain possibilities, and now we describe how we used a tool, what problem it solved and what limitations we ran into. The client no longer has to wonder whether it works and can focus on deciding whether it creates value for their organization.
What comes next
Customer Zero keeps evolving. We are currently exploring new capabilities for discovery, estimation, architecture, development, testing, documentation, operations and knowledge management. Some will reach our projects and many will not, and that is also part of the process.