The best software starts as an internal tool
AWS started as Amazon's own infrastructure. Gmail started as a Google engineer's side project. Slack started as a gaming company's internal chat. The best products often emerge from solving your own problem — and the AI workflow you build for your team might be the same shape.
6 May 2026
Look at the software you use every day. AWS. Gmail. Slack. All started as something built to solve someone's own internal problem before becoming products.
That isn't an accident. It's a pattern.
AWS
Amazon was scaling fast in the early 2000s. Engineering teams kept hitting the same wall: every new product needed its own infrastructure, and every team was building it slightly differently. Provisioning servers. Managing databases. Handling storage. The cost was huge — not in money, in coordination.
The fix was a shared infrastructure layer all internal teams could use. Self-service. API-driven. Pay-per-use even internally, so teams thought twice about over-provisioning.
It worked so well that Amazon noticed two things. First, most other companies had the same problem. Second, running it as a product line was now technically straightforward — the platform already existed.
S3 launched in March 2006. EC2 in August. By 2024, AWS was over US$100B in annual revenue and the most profitable part of Amazon. It started because Amazon engineers were tired of waiting for servers.
Gmail
Paul Buchheit was a Google engineer in 2001. The 20% time policy let him work on personal projects. He built a fast email client for Google staff because Google's existing internal email was slow and search-poor.
Code-named Caribou. Just for engineers at first. Then the rest of Google. Then, on April 1, 2004 — initially mistaken for an April Fools joke — Google launched it publicly with 1GB of free storage. Other email providers offered 4MB. Gmail was 250 times bigger than the competition on day one.
Now over 1.5 billion users. It started because one engineer wanted better email for himself.
Slack
Slack wasn't a product at first. It was the internal chat tool at Tiny Speck, a small gaming company building a game called Glitch. The game failed in 2012. The chat tool didn't.
Stewart Butterfield and the team realised the chat was the actually useful thing. They productised it. By 2019, Slack was trading at a US$20B+ valuation. Salesforce bought it in 2020 for US$27.7B.
The pattern
Three things in common across all three.
Real problem. The team had the problem themselves. They weren't speculating about what other people might want. They were scratching their own itch — and that's why the product, when it eventually shipped, was sharp.
Structural reusability. The internal tool wasn't bespoke for one project. It was a layer that could serve many uses. AWS could host any application. Gmail could be any inbox. Slack could be any team's chat.
Productisation moment. At some point, someone realised the tool was too useful to keep internal. The technical work was already done. The cost of opening it up was lower than starting fresh.
What this means for SMEs building AI
Most SME owners ask the wrong question about AI. They ask "what AI tools should we buy" instead of "what specific AI capability does our business need that our competitors will never have."
The first question gets you generic ChatGPT subscriptions for the team. The second question, answered well, gets you a competitive moat. Or occasionally, a productisable asset.
You probably will not be the next AWS. But the AI workflow you build to handle your specific edge cases — the lookup pipeline, the document parser, the customer-triage agent, the brief generator — has two outcomes worth considering.
As a moat. Your competitors do not have it. They use generic tools. You have something specific to your business that they would have to commission to replicate. That is worth more over time than any productivity bump from a subscription.
As a productisable asset. If your industry has the same pain you do (and it usually does), the thing you built for yourself might become a product line. We have seen this happen at the kit level — a workflow built for one architecture practice became the basis for SiteLogic, productised across the AU planning and architecture market.
Most SMEs will land in the first category. The internal tool stays internal, and that is fine — it is doing the work it was built for. The few that land in the second category get a second business they did not expect.
How Scoper fits in
Scoper sells the kit that gets you to the first version of the internal tool. Not the bespoke build (that is much bigger). Not the generic subscription (that is not yours). Just the structured starting point — prompts, scaffolding, your first task — for the workflow you would most want to internalise.
The kit costs US$99. The internal tool you build with it might be worth a lot more.
---
[Get your kit →](/p/scoping)