Who This Is For
If you are a Head of AI or an AI Architect evaluating automation tools for a non-technical business team, this is written for you.
Not as a polished PR piece.
As a raw account of what actually happened, what broke, why we made the decisions we made, and what a team of 5 to 10 non-technical people at a well-known FMCG brand learned about automation by the end of it.
Client
Hector Beverages is an Indian food and beverages company best known for Paper Boat, their range of traditional Indian drinks.
The brand is built on nostalgia and authenticity, which made it interesting that their internal sales operations were still deeply manual.
The project ran November to December 2025.
Problem
Their sales team was processing incoming vendor and distributor emails manually.
Every day, emails arrived in Outlook with attached PDFs. Purchase orders, delivery confirmations, sales summaries.
Someone had to open each email, extract the PDF, convert it into Excel format, and then either file it in SharePoint or forward it on.
That process was being done by hand. Every. Single. Day.
Roughly 50 emails a day.
Multiply that by working days in a month, factor in human error, context switching, and the cognitive load of doing something repetitive but still requiring accuracy, and you have a meaningful productivity drain buried inside the operations of a growing brand.
The goal: bring that number to zero.
Automate the full pipeline end to end.
How to Calculate the Real Value of Automating a Manual Process
Before a leader approves any automation project, they need a number. Not a vague claim about "productivity gains."
An actual calculation they can defend to a CFO.
Here is the formula we use. It is simple on purpose.
Automation ROI Formula
ANNUAL TIME SAVED (hours) = Daily tasks automated x Minutes per task x Working days per year
-------------------------------------------------------------------------
60
ANNUAL COST SAVED ($) = Annual time saved (hours) x Average hourly cost of the person doing it
TOTAL AUTOMATION COST ($) = One-time build cost + (Monthly infra cost x 12) + Annual maintenance hours x dev rate
ROI (%) = (Annual Cost Saved - Total Automation Cost) / Total Automation Cost x 100
PAYBACK PERIOD (months) = Total Automation Cost / (Annual Cost Saved / 12)
Applied to the Hector Beverages Scenario
Let us put real numbers in. These are estimates based on the scope.
| Variable | Estimate |
|---|---|
| Emails processed per day (manually) | ~50 |
| Average time per email (open, extract, convert, file) | ~5 minutes |
| Working days per year | 250 |
| Average hourly cost of operations staff | $8 to $12 (India, mid-level ops role) |
Annual time saved:
50 emails x 5 minutes x 250 days = 62,500 minutes per year
62,500 / 60 = 1,042 hours per year
Annual cost saved:
1,042 hours x $10/hour = $10,420 per year
Total automation cost:
Build cost (approx 10 to 15 hours at $50/hr): $750
AWS EC2 monthly ($15 x 12): $180
n8n self-hosted: $0 (vs. $50/month on cloud)
Maintenance (est. 2 hours/month x 12 x $50): $1,200
Total: ~$2,130
ROI:
($10,420 - $2,130) / $2,130 x 100 = 389% ROI in year one
Payback period:
$2,130 / ($10,420 / 12) = 2.5 months
The project paid for itself within three months. Every month after that is pure return.
Hidden Costs Leaders Forget to Count
Most ROI calculations only count the obvious time saved. Here is what they miss:
Error correction cost. Manual data entry from PDFs has error rates of 1 to 5%. In sales data, one wrong number in an order quantity or price field can cascade into chargebacks, disputes, and reconciliation work. That cost is invisible until it happens.
Cognitive load cost. Repetitive data work is mentally taxing. People doing it burn out faster, make more errors toward the end of a shift, and switch focus poorly. This is hard to quantify but real.
Opportunity cost. A person spending 4 hours a day on PDF extraction is not doing account management, customer follow-up, or analysis. The automation does not just save time. It frees capacity for higher-value work.
TCO Sanity Check (Total Cost of Ownership)
Run this before signing off on any automation tool decision.
TCO over 3 years =
One-time setup cost
+ (Monthly infra/license cost x 36)
+ (Estimated developer maintenance hours per month x 36 x dev rate)
+ (Training hours x team size x hourly cost)
+ (Estimated downtime cost: estimated hours/year x 3 x business cost per hour)
For Hector, the 3-year TCO on n8n self-hosted came out significantly lower than the equivalent on n8n cloud or a custom Python solution.
The training investment was the largest variable because they needed internal capability, not just a running system.
Quick decision test: If the payback period is under 6 months and the operator can own the system without a developer, approve it. If the payback period is over 18 months or requires permanent developer involvement, reconsider the scope.
Scope of Work
The final agreed scope covered five things:
- Connect to an Outlook mail account and monitor for incoming emails
- Extract PDF attachments from those emails automatically
- Convert the extracted PDFs to Excel format
- Store the consolidated output in SharePoint or send it via email
- Send a summary email after each processing run
Simple on paper. The real complexity was everything around it.
Why We Chose n8n and Not LangChain, CrewAI, or Any Python Framework
This is probably the question any technical person reading this will have.
So let us answer it directly.
The Hector team had five to ten people who would need to own and operate this system after handover.
They were not developers.
They were not data engineers.
Some had exposure to Power Automate and Power Apps through their company's Microsoft stack, but writing Python code or debugging a LangChain pipeline was never on the table.
When you are building for a non-technical team, the tooling decision is not a technical decision.
It is a people decision.
LangChain is a powerful framework.
But it is a framework.
It assumes you know Python, you understand how agents reason, you can read stack traces, and you are comfortable managing environment dependencies.
If something breaks in a LangChain workflow on a Friday evening, a sales operations manager cannot fix it.
They will have to wait for a developer.
CrewAI is the same story.
Excellent for orchestrating multi-agent systems, but the mental model of "agents with roles collaborating toward a goal" is abstraction-heavy.
The value it brings is in complexity.
And complexity is not what this project needed.
n8n gave us something different. A visual workflow canvas where every step is a node, every connection is visible, and every error points to exactly where the problem is.
You can see your entire automation on one screen.
You can click into a failing node, read what went wrong, and fix it without opening a terminal.
For a team that needed to eventually manage this themselves, that visibility was non-negotiable.
There is also the cost argument. At the time, the n8n cloud offering ran around $50/month.
That is manageable for a company like Hector. But the team had a clear preference: they did not want ongoing SaaS costs if they could avoid them.
They wanted control. Which led to the infrastructure decisions we will get into next.
One last thing on the framework choice. Libraries like LangChain and CrewAI are best suited for problems where the intelligence is the hard part.
Where you need an agent to reason, plan, and take adaptive actions based on unpredictable input.
The Hector problem was not that kind of problem.
The logic was deterministic: get email, find PDF, convert, store, notify.
That is a pipeline, not an agent. n8n was designed for exactly this.
[Tool Selection Framework] How to Decide What Your Team Actually Needs
This is the decision most leaders get wrong.
They pick tools based on what is trending, not based on who will be operating the system six months after go-live.
Here is a simple framework. Use it before choosing any automation tool.
[2x2] Complexity vs. Operator Profile
OPERATOR PROFILE
Non-Technical Technical
| | |
HIGH | Danger Zone | LangChain / |
PROBLEM | (Needs heavy | CrewAI / |
COMPLEXITY | abstraction | Custom Code |
| layer first) | |
|------------------|------------------|
LOW | n8n / Make / | Overkill. |
PROBLEM | Zapier | Use n8n anyway, |
COMPLEXITY | | save time. |
| | |
Where Hector Beverages sat: Low-to-medium problem complexity. Non-technical operators. n8n was the right quadrant.
Three Questions to Ask Before Choosing a Tool
Question 1: Who breaks it?
If the answer is "the same person who built it, who has a pager," you can use any tool. If the answer is "the sales ops manager in Gurgaon," your tool must be self-diagnosable. No stack traces. No terminal access needed.
Question 2: Is the logic adaptive or deterministic?
Deterministic means: given the same input, the output is always the same. Get email, extract PDF, convert, store. That is deterministic. You do not need an LLM for this. You need a reliable pipeline.
Adaptive means: the system needs to reason, change its approach based on context, handle unpredictable inputs. That is when LangChain, CrewAI, or a custom agent framework earns its complexity cost.
Question 3: What does maintenance cost in human hours, not just dollars?
SaaS tools have subscription costs. Open-source self-hosted tools have maintenance costs. Both are real. But the hidden cost most leaders ignore is the ongoing human attention required when something breaks. A well-configured n8n workflow on EC2 costs around $50/month or less. A LangChain pipeline requiring a developer for every change can cost 10x that in engineering time alone.
Real Cost Breakdown: n8n vs. Custom Code in 2026
| Factor | n8n (Self-Hosted) | Python / LangChain |
|---|---|---|
| Setup time for non-technical team | 1 to 2 days | 2 to 4 weeks |
| Debugging without a developer | Possible (visual UI) | Very difficult |
| Credential management UI | Built-in | Manual / .env files |
| Error visibility | Node-level, readable | Stack traces |
| Scaling to more workflows | Add nodes in UI | Write more code |
| Monthly infra cost | $10 to $20 (EC2 t3.micro) | Same or more |
| Developer dependency for changes | Low | High |
When You Should Use a Python Framework Instead
Be honest about this. If any of the following are true, n8n is probably the wrong tool:
- The workflow requires reasoning. Not routing. Actual reasoning. "If this PDF mentions disputed quantity, flag it, cross-reference the last 3 orders, and draft a follow-up email with context." That needs an LLM with memory and tool use.
- You need more than 10 custom integrations that do not have pre-built connectors.
- The team operating it will always include a developer anyway.
- You expect to run hundreds of parallel executions per minute at scale.
In those cases, yes. LangChain, LangGraph, or CrewAI may be worth the complexity overhead. But you should make that choice deliberately, not by default.
Handy rule of thumb for 2026: If the person who will own it in 12 months cannot describe what it does without opening a code editor, you have chosen the wrong abstraction level.
Infrastructure | Why We Landed on AWS EC2 (And Why It Was Messier Than Expected)
The team initially explored running n8n locally on-premises.
Self-hosting was always the intention, both to avoid ongoing cloud costs and to keep the data within their control.
The conversation moved to AWS after it became clear that a local machine running 24/7, exposed to the internet to receive webhooks, created more operational headache than it solved.
AWS had already been part of their consideration set.
They were familiar with it through prior vendor relationships.
We chose EC2 as the hosting environment and walked them through the setup:
- Ubuntu Server 22.04 LTS on a t3.micro instance
- SSH key pair for secure access
- Ports 80, 443, and 5678 (n8n's default) opened appropriately
- n8n running as a persistent service on the instance
The setup was documented step by step and shared with the team. Clean on paper.
The reality was less clean.
Challenges | What Actually Went Wrong
1. The Instance Was Running But Not Reachable
The screenshot we kept seeing looked like this: browser pointed at 65.1.120.19/signin?redirect=%252F, returning ERR_CONNECTION_TIMED_OUT after 33 seconds.
The n8n instance was running.
The EC2 instance was up.
But the connection was timing out before it ever reached the application.
This is one of the most disorienting errors in cloud infrastructure.
Everything is "on" but nothing works.
The root causes were layered.
Security group rules that were set correctly in theory but not applied properly.
Firewall settings at the OS level (UFW on Ubuntu) blocking port 5678 even though AWS was allowing it.
And a reverse proxy configuration that was partially done but not finalized.
Every one of these issues looks different from inside versus outside the server.
And the Hector team had no way to debug this themselves.
Which meant every blocker became our problem to diagnose remotely.
2. Credential Management Across Restricted Environments
This was the subtler challenge but arguably the more important one.
n8n integrates with Outlook and SharePoint via Microsoft OAuth.
The credentials flow involves registering an app in Azure Active Directory, generating a client ID and secret, and then authorizing n8n to act on behalf of the mail account.
For companies running managed Microsoft environments, IT policy often blocks third-party OAuth registrations by default.
Hector was operating within these restrictions.
Their internal IT setup meant we could not simply register an app and generate credentials without going through an approval process.
There were also moments where credentials were changed mid-session (intentionally, for testing), causing authenticated nodes in n8n to break without obvious error messages.
The workflow would fail silently at the Outlook connection step, and tracing it back to a recently rotated credential required manual inspection of each node's authentication state.
The lesson: in enterprise environments, credential management is not a one-time setup task.
It is an ongoing operational concern.
Build rotation procedures into the handover documentation from day one.
3. Webhook Configuration and Network Trust
n8n triggers workflows via webhooks.
An email arrives in Outlook, triggers a notification to n8n's webhook URL, and the workflow starts.
This sounds simple.
But it requires the webhook URL to be publicly accessible, which means the EC2 instance needs a stable, publicly addressable endpoint.
We used the public IPv4 address directly during testing.
That works, but it breaks if the instance restarts and gets a new IP from AWS. The proper fix is an Elastic IP (a static public IP in AWS) or a domain with DNS pointing to the instance.
During the build phase, the team was not yet at the stage of setting up domain names, which meant every time we needed to share the webhook URL for testing, we had to verify the current IP first.
This created friction in the testing cycle and burned hours that should have gone into building.
4. PDF-to-Excel Conversion Was Not a Solved Problem
The actual PDF extraction and conversion was handled via n8n's built-in capabilities combined with an external conversion service.
The challenge here was that not all PDFs are created equal.
A vendor sending a structured table in a PDF is very different from one sending a scanned image.
OCR on scanned documents has meaningful error rates, and when you are processing financial data (quantities, prices, order IDs), those errors matter.
We set up the pipeline to flag exceptions rather than process silently, so the team would know when a document needed manual review.
But this was not obvious upfront.
The first iteration processed everything and only surfaced errors when someone noticed the output was wrong.
Build exception handling early, not as an afterthought.
Self-Hosted vs. Cloud SaaS [Decision Tree]
START: Where should you run your automation tool?
|
v
Do you have data sovereignty or compliance
requirements (GDPR, internal IT policy, etc.)?
|
+---------+---------+
YES NO
| |
v v
Self-hosted is Does the team have
likely required. anyone who can manage
Continue below. a Linux server?
|
+---------+---------+
YES NO
| |
v v
Self-hosted is Use SaaS (n8n cloud,
viable. Budget Make, Zapier).
for maintenance. Pay the monthly fee.
Continue below. It is worth it.
|
v
Do you expect high volume
(1000+ executions/day)?
|
+---------+---------+
YES NO
| |
v v
t3.medium or t3.micro is fine.
larger. Consider $10 to $15/month.
auto-scaling. Good for up to
~500 executions/day.
Dual Delivery | Build and Train at the Same Time
One aspect of this project that made it different from a standard implementation engagement was that we were doing two things simultaneously.
We were building the automation.
And we were training the team to understand it.
The initial request included training on n8n, API integrations, and automation concepts.
The training actually happened, covering n8n specifically, since the Power Automate and Power Apps training was already part of Hector's existing internal program through Microsoft.
Running build and training in parallel created an interesting dynamic.
The team learned by watching the system get built, then built their own version alongside ours. By the end, both versions existed.
Ours as the production reference.
Theirs as the learning artifact.
This is worth thinking about if you are planning a similar rollout.
The best way to train non-technical people on automation tools is not a lecture. It is supervised parallel construction.
They build what you build, they make the same mistakes you make, and they learn what breaks and why.
When the system eventually needs debugging in production, they have muscle memory, not just documentation.
Technical Architecture (For Those Who Want It)
Here is how the final pipeline worked:
Outlook (monitored mailbox)
|
| [Webhook trigger on new email]
v
n8n Workflow on EC2 (Ubuntu 22.04 / t3.micro)
|
|-- Filter node: Check for PDF attachment
|
|-- If PDF found:
| |
| |-- Extract attachment binary
| |-- Send to PDF conversion service (external API)
| |-- Parse returned Excel data
| |-- Write to SharePoint folder (via Microsoft Graph API)
| |-- Compose summary email
| |-- Send via Outlook SMTP node
|
|-- If no PDF:
|
|-- Log and skip (no notification)
Authentication stack:
- Outlook: Microsoft OAuth2 via Azure AD app registration
- SharePoint: Microsoft Graph API with delegated permissions
- EC2 access: SSH key pair, IAM role with minimal permissions
- n8n: Running on port 5678, reverse proxy via Nginx on port 443
LLM usage:
None in the core pipeline.
The PDF-to-Excel conversion used a structured parsing approach.
If the project had extended to intelligent summarization of PDF contents, we would have introduced an LLM API call (OpenAI or similar) at that stage, with token costs billed per usage.
Agentic Design Patterns
(And Which One This Project Actually Used)
Most leaders hear "AI agent" and picture something complex.
A reasoning system.
An autonomous decision-maker.
Something expensive and unpredictable.
Sometimes that is true.
But most enterprise automation problems map to just a few well-defined patterns.
Understanding these patterns helps you make faster, better decisions about what to build and how much it should cost.
Here are the four patterns most relevant to real-world enterprise automation in 2026, explained simply.
[Pattern 1] Prompt Chaining (What This Project Used)
You break a task into steps. Step 1 produces output. Step 2 takes that output as input. And so on. Each step is simple. The chain is what gets things done.
Think of it like an assembly line.
Each station does one job.
The part moves to the next station only when the previous job is done.
Hector workflow was pure prompt chaining:
STEP 1 STEP 2 STEP 3 STEP 4 STEP 5
+-----------+ +------------+ +----------+ +-----------+ +----------+
| New email |-->| Extract |-->| Convert |-->| Store in |-->| Send |
| arrives | | PDF from | | PDF to | | SharePoint| | summary |
| in Outlook| | attachment | | Excel | | or email | | email |
+-----------+ +------------+ +----------+ +-----------+ +----------+
No LLM needed here.
No reasoning.
Each step is deterministic.
The "intelligence" is in the routing logic that connects them.
When to use it
Any process that has a clear start, a clear end, and steps that always happen in the same order.
Document processing, data transformation, notification workflows, report generation.
[Pattern 2] Routing (The Next Level Up)
A step in your workflow looks at the input and decides which path to take. Instead of always going straight, the pipeline branches based on conditions.
Like a post office sorting system. A package comes in, a scanner reads it, and it goes to the right bin. Not every package goes to the same place.
What this would look like for Hector if they extended the workflow:
+------------------+
| Email arrives |
+--------+---------+
|
+--------v---------+
| What type of PDF?|
+--------+---------+
|
+---------------------+---------------------+
| | |
+----------v------+ +----------v------+ +----------v------+
| Purchase Order | | Delivery Note | | Unknown / Flag |
| --> Extract PO# | | --> Match to PO | | for manual |
| --> Update CRM | | --> Close order | | review |
+-----------------+ +-----------------+ +-----------------+
When to use it: When different inputs need different treatments. Multiple document types, different customer tiers, exception handling.
[Pattern 3] ReAct (Reason and Act) When the Problem Gets Complex
The system reasons through a problem before acting. It thinks, takes an action, observes the result, thinks again, then acts again. This loop continues until the task is done.
Think of a detective. They do not just grab the first suspect. They gather a clue, reason about it, decide what to investigate next, gather another clue, and so on. Each observation changes the next action.
The loop looks like this:
+----------+
| THOUGHT | "I need to check if this PO number already exists before creating a new record"
+----+-----+
|
+----v-----+
| ACTION | [Query CRM for PO number: "PO-2025-4421"]
+----+-----+
|
+----v----------+
| OBSERVATION | "No existing record found"
+----+----------+
|
+----v-----+
| THOUGHT | "Safe to create new record. What fields are required?"
+----+-----+
|
+----v-----+
| ACTION | [Create new CRM entry with extracted data]
+----+-----+
|
+----v----------+
| OBSERVATION | "Record created. ID: CRM-00891"
+----+----------+
|
+----v---------+
| FINAL ANSWER | "Processed. Confirmation email sent."
+--------------+
When to use it: When decisions depend on information that is not available upfront. Cross-referencing databases, validating data against external systems, handling ambiguous inputs. This is where you start needing an LLM.
[Pattern 4] Human-in-the-Loop (HITL)
The automation handles everything it can confidently handle. When it hits something it is not sure about, it pauses and asks a human to decide before continuing.
Like a junior analyst who processes routine work independently but escalates edge cases to their manager instead of guessing.
What this looks like in practice:
+------------------+
| PDF arrives |
+--------+---------+
|
+--------v---------+
| Confidence check |
| on extracted data|
+--------+---------+
|
+----+----+
| |
+---v---+ +--v-----------+
| HIGH | | LOW |
| conf. | | conf. / error |
| | | |
| Auto- | | Send to human |
| process | review queue |
| and file | |
+-------+ +--+------------+
| |
| +--v-----------+
| | Human reviews|
| | and approves |
| +--+-----------+
| |
+--------v-----v---+
| Continue pipeline |
+-------------------+
When to use it: Whenever the cost of an automated error is high. Financial data, legal documents, anything that triggers a downstream action that is hard to reverse.
Which Pattern Should You Start With?
Is the process always the same steps in the same order?
YES --> Prompt Chaining. Start here. Ship fast.
Does it need to handle different types of inputs differently?
YES --> Add Routing on top of Chaining.
Does it need to look things up, verify data, or make decisions based on context?
YES --> ReAct with Tool Use. You will need an LLM now.
Is the cost of an error high enough to require human sign-off on uncertain cases?
YES --> Add HITL checkpoints.
Most enterprise automation problems in 2026 are solved by patterns 1 and 2. Pattern 3 and 4 are for the problems where the data is messy, the logic is conditional, or the stakes are high.
What This Means for Your Next Project
When a vendor pitches you an "AI agent," ask them which pattern it uses.
If they cannot answer clearly, the architecture is probably more complex than the problem requires.
The Hector project was pattern 1 plus a routing check for PDF detection.
That is it.
No LLM.
No agent reasoning loop.
Just a reliable, well-monitored pipeline that runs the same way every time.
That restraint is what made it maintainable by a non-technical team.
What We Would Do Differently
Set up the Elastic IP before writing a single workflow. The dynamic IP situation cost us multiple hours and should have been resolved on day one.
Write a credential rotation runbook before go-live. Microsoft OAuth tokens expire. Secrets get rotated. The team needed a step-by-step guide for what to do when authentication breaks, not a verbal explanation during a call.
Add structured logging from the start. n8n has execution logs, but they disappear after a retention period on self-hosted instances. We should have piped logs to CloudWatch or a simple S3 bucket from the beginning.
Set expectations around PDF quality earlier. Not all vendor PDFs are machine-readable. Setting up an exception triage process in week one would have saved scope discussions in week three.
What the Team at Hector Got Out of It
At the end of the project, a 5 to 10 person operations team that had never built an automated workflow could:
- Open their n8n canvas and read a running workflow
- Identify a failing node and understand the error message
- Re-authenticate a broken Outlook or SharePoint connection
- Build a simple new workflow from scratch using existing nodes as reference
That last point matters.
The goal was never just to hand over a working system. It was to hand over capability.
The difference between "we have an automation" and "we can automate" is the difference between a service dependency and an internal skill.
What changed operationally:
the 50-emails-a-day manual processing problem went to zero.
Every incoming PDF is now processed, converted, stored, and summarized automatically.
The team's time moved from data entry to exception review.
Key Decisions at a Glance
| Decision | What We Chose | Why |
|---|---|---|
| Automation tool | n8n | Visual, self-hostable, no-code operable |
| Hosting | AWS EC2 (Ubuntu 22.04) | Stable, familiar to their team, avoids local machine risks |
| LLM framework | None (not needed) | Deterministic pipeline, not adaptive reasoning |
| Credential management | Microsoft OAuth via Azure AD | Required by Microsoft for Outlook/SharePoint access |
| Training model | Parallel build | Fastest path from "observer" to "operator" |
| PDF conversion | External API with exception flagging | Better reliability than local OCR for financial data |
Bigger Picture
If you are a Head of AI evaluating this for your own organization, here is the honest takeaway.
Most enterprise automation problems do not need LLMs.
They need reliable pipelines with good error handling.
The decision to reach for LangChain or CrewAI should come from the nature of the problem, not from a desire to use cutting-edge technology.
When the people who will maintain the system are non-technical, the intelligence in your tooling needs to be in the interface, not the codebase.
A workflow someone can read and fix on a Monday morning without calling a developer is worth more than an architecturally elegant agent that only your team can debug.
And when you run build and training simultaneously, you create something more durable than a delivered project.
You create internal capability.
That is what this was actually about.
Decision-Making Checklist for Leaders
Stick this to your wall.
Before approving any automation project, answer these:
- Can the person who will own this in 12 months describe it without code?
- Is the payback period under 6 months?
- Do we have a static IP / stable endpoint for webhooks?
- Are credentials documented with rotation dates?
- Is there a human-in-the-loop for high-risk steps?
- Do we have a monthly health check process?
- Are error alerts going somewhere a human will see them?
- Does the team have at least one Level 3 AI Champion?
All 8 checked? Approve it.
4 to 7 checked? Fix the gaps before go-live.
Under 4? The project is not ready. Do not deploy to production yet.
The difference between "we have an automation" and "we can automate" is the difference between a service dependency and an internal skill. That is what changed.
"The team learned by building the actual thing they needed. That is the difference." HectorBeverages, Team