Forem: SimpleWBS

MCP is not an open standard play, it is a platform consolidation play

SimpleWBS — Sun, 15 Mar 2026 13:58:44 +0000

Anthropic Just Did to SaaS What SaaS Did to On-Premise Software

Most of the coverage of Anthropic’s enterprise strategy has focused on model benchmarks and pricing tiers. That is the wrong frame. What Anthropic has quietly executed is one of the more significant platform power grabs in recent enterprise technology history, and the incumbents who enabled it are only beginning to understand what they agreed to.

The thesis is simple. SaaS companies spent a decade dismantling on-premise software by moving where value and dependency lived. They did not replace the capability. They just repositioned themselves between the user and the underlying infrastructure, commoditised the servers and the IT teams, and captured the margin. Anthropic has done the same thing to SaaS, and the SaaS vendors built the connectors themselves.

What MCP Actually Is

The Model Context Protocol gets described as an open standard for connecting AI tools to external services. That description is technically accurate and strategically misleading.

What MCP actually does in practice is let Claude call a third party service, receive the results, and synthesise them for the user. When Anthropic markets Claude Enterprise as having enterprise search capability, Claude is not doing the search. It is calling Atlassian’s search, or Microsoft’s Graph API, or whatever backend the connector points to. The third party does the retrieval. Claude presents the output.

That distinction matters enormously because of where the credit lands. When the experience is good, the user credits Claude. When it is bad, the attribution is murky. Anthropic is reselling retrieval infrastructure it does not own or operate, presenting it as a native product capability, and the actual infrastructure owners are invisible in the transaction.

Why Every Vendor Had No Real Choice

The coercion in MCP was structural rather than explicit. Anthropic never pressured anyone. They published an open standard and let competitive dynamics do the rest.

The message to every SaaS vendor was implicit but unmistakable. If you do not build an MCP connector, you become invisible to AI-native workflows. Your competitor will build one. Your users will notice. The standard being open is precisely what made adoption frictionless, which is what accelerated the consolidation of power at the AI layer.

The result is that vendors with significant engineering resources and sophisticated technical leadership built the connectors anyway. It was the rational individual decision. Collectively it was a terrible outcome for the SaaS layer as a whole because every integration deepened Claude’s position as the central orchestration layer sitting above their products.

They funded their own displacement. And they did it voluntarily.

The SaaS Parallel

The structural parallel to what SaaS did to on-premise software is exact enough to be uncomfortable if you are running a SaaS business today.

SaaS did not replace the capability that on-premise software provided. Finance teams still needed accounting software. Sales teams still needed pipeline management. The capability stayed constant. What changed was where the dependency lived. SaaS moved it away from the software installation and toward the vendor relationship, the subscription, and increasingly the data that lived in the vendor’s cloud.

On-premise vendors who thought SaaS was just a different delivery model missed that it was a fundamental restructuring of where margin lives. By the time they understood the game had changed, the switching costs had already moved.

Anthropic has executed the same move on SaaS. The capability stays constant. Teams still need project management, documentation, CRM, data analytics. What is changing is where the dependency lives. Users who increasingly rely on Claude to interact with, query, and act on the data inside these tools are migrating their cognitive dependency away from the SaaS application and toward Claude.

Once that behavioural shift completes, whether the underlying data store is Jira or an open source alternative or something purpose built by Claude Code stops mattering in the way it used to. The SaaS application becomes infrastructure. Infrastructure gets commoditised.

Anthropic’s position is arguably stronger than early SaaS vendors had because they do not even need to build and maintain the application layer. The partners do that. Anthropic owns the reasoning layer and lets everyone else maintain the plumbing.

Atlassian Is the Biggest Loser

Atlassian had the perfect strategic position to own enterprise AI and chose not to take it.

They already had the knowledge graph of how organisations actually work. Confluence held institutional memory. Jira held execution state. They were embedded across engineering, product, and operations at most serious technology companies. They had a living map of organisational intelligence that any AI company would have spent years trying to acquire.

The opportunity was to become the organisational intelligence layer. Not just storing what teams know and do, but reasoning across it, surfacing it, and acting on it. Notion saw a version of this opportunity and built toward it, treating the document as a database, the database as a workflow, and the workflow as something AI could operate across.

Atlassian instead treated Confluence as a wiki and Jira as a ticket system and kept adding features to a product mental model that was formed in 2005. They are now a structured data store that Claude queries.

The replacement risk they face is more severe than most analysis acknowledges. Historically Jira and Confluence carried enormous switching costs. Not because of technical superiority but because migration was painful, institutional knowledge was buried in the tooling, and nobody wanted to rebuild workflows from scratch.

Claude Code removes all three of those switching costs simultaneously. Migrating an entire Jira instance to an alternative is now a legitimate Claude Code project rather than a six month professional services engagement. The open source alternatives, Plane for project management and Outline for documentation, are genuinely capable. The only barrier was setup and maintenance complexity. That barrier is largely gone.

More fundamentally, a team can now simply ask Claude Code to build them a project management tool built precisely to their requirements, self-hosted, with no licensing cost, maintained through natural language instructions. The replacement is not migration to a competitor. It is replacement with something that did not exist as a practical option eighteen months ago.

By making their data accessible via MCP, Atlassian has given Claude a complete map of everything stored in their systems. That is exactly the information needed to migrate away from them cleanly. They handed over the blueprint.

Microsoft Is Complicated

Microsoft’s position is harder to summarise because they are winning and losing simultaneously depending on which product you look at.

The Excel and PowerPoint moats are real and durable in ways that most AI analysis underestimates. The threat to those products is not that Claude replaces them. It is subtler and more dangerous than that. Anthropic releasing a Claude addin for Excel and PowerPoint looks like a partnership. The actual strategic logic is that Claude inserts itself as the cognitive layer on top of applications that have thirty years of human muscle memory behind them.

Users keep using Excel. But increasingly Claude understands the data, writes the formulas, builds the models, and interprets the outputs. The human’s dependency quietly migrates from Excel to Claude. Excel becomes the rendering engine, the thing that holds the grid, while Claude owns the thinking. Once that behavioural shift completes, whether the grid is Excel or Google Sheets or something else stops mattering. Anthropic has used Microsoft’s own distribution to detach users from Microsoft’s core stickiness. That is a genuinely aggressive move dressed as a productivity feature.

Microsoft’s own execution has made this worse. The Copilot rollout was one of the more damaging own goals in recent enterprise technology history. They attached the Copilot brand to every product in their portfolio before any of it worked properly. Teams Copilot, Word Copilot, Security Copilot, Azure Copilot, Dynamics Copilot. Enterprise sales teams were selling a vision the product could not yet deliver. CIOs bought licences, switched it on, got underwhelming results, and Copilot became a thirty dollar per user per month punchline inside most organisations that tried it.

The SharePoint activation decision compounded the damage. SharePoint is famously where organisational knowledge goes to die. Decades of poorly structured, ungoverned, duplicated content sitting in folder hierarchies nobody maintains. Pointing an AI at that and calling it enterprise intelligence was never going to produce good results. The garbage in garbage out problem was entirely predictable. They ignored it and shipped anyway.

The strategy that was available to them was almost embarrassingly simple in hindsight. Take OpenAI’s best model, make it the engine, build genuinely excellent connectors for Microsoft 365, go deep on Excel and PowerPoint where AI assistance has obvious daily value for every enterprise user, build everything else AI-native from scratch rather than retrofitting Copilot onto legacy surfaces, and price basic functionality at zero for existing enterprise clients. Absorb the cost, embed the behaviour, create the dependency, and monetise once the habit is unbreakable.

They had Teams, Outlook, Excel, and PowerPoint inside essentially every large organisation on earth. The distribution advantage was extraordinary. Instead they charged a premium before the product deserved it, generated widespread rejection, and now face the considerably harder task of re-convincing buyers who already evaluated and dismissed them.

Dynamics 365 is likely the next product they lose through the same pattern. Dynamics was always a second tier ERP and CRM that won on Microsoft relationship and bundling rather than product merit. It has always suffered from being a collection of acquired products, Navision, Axapta, Great Plains, that were never truly unified. The data models do not naturally share context. Workflows between finance, sales, and operations require heavy implementation work. Microsoft’s response has been to add Copilot features to paper over the seams rather than fix the underlying architecture.

The modern replacement stack for something like Dynamics is now a purpose built database layer, clean APIs, and Claude handling workflow orchestration, data synthesis, and user interaction. The implementation complexity that made switching feel risky is the same complexity that Claude Code is systematically eliminating.

Google Read the Room

Google is the one major incumbent that correctly diagnosed what MCP actually meant for them and built around it rather than into it.

The clearest example is Gmail. Google built MCP connectors for Gmail and Google Workspace. They participated in the standard. They did not block it or ignore it. But connect Claude to Gmail via MCP and the experience is noticeably limited compared to working inside Google’s own surface. The threading, the full conversation history, the deep integration with Calendar and Drive, the search quality across your entire mail history, none of that comes through the MCP layer with the same richness. The connector exists. It is just not very good.

That is not an accident. Google controls exactly what the connector exposes and has every reason to ensure the really useful context stays native to their own products. Meanwhile Gemini inside Gmail has full access to everything. The comparison is not even close, and Google engineered the gap deliberately.

This is a more sophisticated move than simply refusing to participate. Refusing to build MCP connectors would have looked obstructionist and driven enterprise customers to ask uncomfortable questions. Building connectors that are just good enough to avoid that conversation, whilst keeping the genuinely valuable integration experience locked inside their own ecosystem, is the smarter play. It lets Google say yes to MCP whilst making sure yes does not actually cost them anything.

Their broader defensive strategy is coherent for the same reason. Gemini is deeply embedded in Workspace, in Docs, Sheets, Gmail, and Drive. Google owns the file layer, the identity layer, and the collaboration layer simultaneously in a way that is genuinely difficult to route around. Simplified enterprise pricing reduces the CFO conversation that might otherwise trigger a migration evaluation. Gemini improving rapidly means the quality gap that might push enterprise users toward Claude-centric workflows narrows over time.

The core insight Google is operating from is that they cannot win by being the backend for Claude’s ecosystem. They can only win by making their own ecosystem so integrated and frictionless that adopting a Claude-centric workflow has a real organisational cost. They are the one incumbent that understood that MCP participation is not the same as MCP commitment, and acted accordingly.

What This Means If You Are Buying Enterprise Software Today

The switching cost calculus for enterprise software has changed in ways that most procurement processes have not caught up with yet.

The complexity that historically justified paying premium SaaS pricing, the implementation risk, the migration cost, the maintenance burden, is the specific complexity that AI is eliminating fastest. That means the risk premium built into staying with an established vendor is eroding at the same time as the cost of evaluating alternatives is falling.

Data infrastructure is where this plays out most visibly right now and Microsoft’s Fabric is the clearest example of a product that should not exist in its current form.

Fabric was always a questionable proposition. A sprawling PaaS that attempted to unify data engineering, warehousing, and analytics into one Microsoft-billed surface. The integration convenience it sold was real but expensive, opinionated, and deeply tied to the Microsoft estate. Then they added Copilot and rebranded parts of it as Fabric IQ, which is AI washing on top of a platform that was already struggling to justify its complexity.

The actual replacement stack is straightforward. Take a ClickHouse SaaS instance, which is cheaper to run, faster for analytical workloads, and operationally simple. Connect it via MCP. Let Claude handle the querying, the interpretation, and the insight layer. The complexity that Fabric was charging you to manage disappears, and you are not locked into Microsoft’s data estate to access it.

Snowflake appears to have understood the direction of travel. Snowflake Intelligence is a genuine attempt to put a chat and reasoning layer directly on top of your data, removing the abstraction complexity rather than adding to it. Snowflake Code takes that further by tackling the data engineering plumbing itself, the pipelines, the transformations, the infrastructure work that has always been the expensive and brittle part of running a serious data platform. That is the right problem to solve. Make the hard stuff disappear rather than building new interfaces on top of it.

Databricks has gone the opposite direction and it is going to cost them. Rather than simplifying, they have kept shipping new features and new complexity, including new ways to build BI tooling. That is exactly the wrong bet. BI as a category is being hollowed out in real time. The entire premise of BI, that you need a specialised tool and trained analysts to surface insights from data, falls apart when anyone in the organisation can ask Claude a question and get an answer directly from the underlying data. Building new BI features in 2025 is the Fabric Copilot mistake made twice. It is adding a layer of complexity to solve a problem that the AI layer is eliminating from the other direction.

For project management and documentation, the question worth asking honestly is how much of the switching cost is real technical complexity versus accumulated organisational inertia. Claude Code has changed that answer significantly in the past year.

The businesses that figure this out before their competitors will carry a structural cost and flexibility advantage that compounds over time. The businesses that stay locked into legacy SaaS pricing out of habit will eventually face the same reckoning the on-premise vendors did when SaaS matured. By that point the window to move cheaply will have closed.

The One Sentence Version

Anthropic got the SaaS layer to build the connectors that make the SaaS layer optional, and most of the companies that built those connectors are still describing it as a partnership.

Your Laptop Isn't Old. Windows Just Got Heavy.

SimpleWBS — Sun, 22 Feb 2026 12:05:16 +0000

We've all been there. You turn on your laptop, and before you can even open a browser, you're greeted by a spinning circle. A notification pops up about a mandatory update. Another reminds you that your subscription is renewing. Then, there's the new AI assistant you didn't ask for, hovering in the corner of your screen.

We are told this is progress. But for many of us, it feels like obstruction.

Recently, there's been a quiet migration happening. People are waking up to the fact that their hardware isn't the problem—the software is. And the solution isn't buying a new $1,500 machine. It's installing a free operating system that respects your hardware, your privacy, and your attention.

Enter Linux Mint.

Here's why this might be the best upgrade you never pay for.

The 10-Year Rule Planned obsolescence is a real phenomenon. Windows 11, for example, famously dropped support for millions of perfectly capable CPUs.

Linux Mint, however, is remarkably lightweight. I've seen it run smoothly on hardware from a decade ago—machines that struggle to boot modern Windows installations. By switching to Mint, you aren't just saving money; you're fighting e-waste. You're extending the lifecycle of your device by years.

In a world obsessed with the new, there is something radical about making the old work beautifully again.

It Looks Like Home The biggest barrier to Linux isn't code; it's fear. People worry about a steep learning curve or a terminal screen full of green text.

Linux Mint's flagship edition (Cinnamon) was designed with a specific philosophy: familiarity.
There's a Start menu (it's called the Menu).
There's a taskbar at the bottom.
There's a system tray with a clock on the right.

If you can use Windows 7 or 10, you can use Linux Mint. You don't need to relearn how to compute. You just get a faster version of what you already know.

The Enough Software Argument Critics often ask: But what about Microsoft Office?

For the vast majority of students, small business owners, and professionals, the answer is: You don't need it.

The modern workflow has shifted.
Writing and Spreadsheets: LibreOffice comes pre-installed. It handles Word and Excel formats seamlessly. For 95% of documents, the average user will never notice the difference.
The Web: Most professional tools now live in the browser. Whether you use Google Docs, Notion, or Salesforce, they run perfectly on Firefox or Chrome on Linux.

When you strip away the bloated suites you barely use, you're left with a machine that does what you need, without the baggage of what you don't.

Security Without the Stress Windows users are conditioned to fear viruses. We install heavy antivirus suites that slow down our systems even more.

Linux Mint is secure by design.
No Telemetry: It doesn't track your keystrokes or sell your search data.
Repository System: You install software from a curated app store (Software Manager), not by downloading .exe files from random websites. This drastically reduces the risk of malware.
Permissions: The system architecture makes it difficult for viruses to gain root access without your explicit password.

You spend less time managing security and more time working.

The Antidote to AI Bloat This is perhaps the most timely reason to switch. Microsoft is aggressively integrating Copilot and AI features into the core of Windows. Pop-ups, sidebar chats, and automated suggestions are becoming unavoidable.

For many professionals, this isn't helpful; it's digital noise.

Linux Mint operates on a different philosophy: User Sovereignty. The computer is a tool, not a platform for experimentation on your attention span. There are no forced AI assistants. No news feeds in your start menu. No shopping suggestions.

It is a quiet workspace in a noisy digital world.

The Cost of Switching? Zero.
Let's talk numbers.
License Cost: $0.
Upgrade Cost: $0.
Risk: Low. You can try Linux Mint from a USB stick without installing anything. If you don't like it, reboot and you're back to Windows.

Is It For Everyone?
I'll be honest: If you are a video editor relying on Adobe Creative Cloud, or a gamer needing specific anti-cheat drivers, Linux might require more tinkering than you want.

But for the writer, the student, the accountant, the small business owner, and the casual user? It is more than enough.

Reclaim Your Machine
We accept too much slowdown, too much tracking, and too much bloat as the cost of doing business. It isn't.

Your hardware is capable. You are capable. You just need an operating system that gets out of the way.

Give Linux Mint a try. You might find that your old laptop wasn't ready for the retirement home after all.

LINKS
Linux Mint Official Site: https://linuxmint.com/
LibreOffice: https://www.libreoffice.org/
Mozilla Firefox: https://www.mozilla.org/en-US/firefox/new/

Battle of the AI Coding Agents: Claude Code vs OpenAI Codex vs Qwen Coder (February 2026)

SimpleWBS — Thu, 05 Feb 2026 10:34:49 +0000

The AI coding wars just got interesting. February 2026 has seen three major players launch or expand their autonomous coding agents: Claude Code's web interface (claude.ai/code), OpenAI's brand new Codex macOS app, and the game-changing arrival of Qwen Coder (coder.qwen.ai) — an open-source, completely free alternative that does everything Claude Code does, but without the subscription fee.

Let's break down what just happened and why Qwen Coder might be the most disruptive launch of 2026.

What Changed in February 2026
The Three Contenders
The Qwen Coder Bombshell
Feature Comparison
Pricing Reality Check
Performance Benchmarks
Real-World Use Cases
The Verdict

What Changed in February 2026

February 2, 2026: OpenAI launches the Codex macOS app — a native desktop application for managing multiple coding agents in parallel.

February 2026: Qwen launches coder.qwen.ai — a web-based coding agent that directly competes with Claude Code Web, but it's completely free and open-source.

This isn't incremental improvement. This is disruption.

The Three Contenders

Claude Code Web (claude.ai/code)

What It Is:
Anthropic's web-based coding agent. Connect your GitHub, point it at a repo, give it a task, and watch it create branches, write code, run tests, and submit PRs — all whilst you're away from your desk.

Launch: October 2025

Cost: Paid

Platform: Web browser, CLI

OpenAI Codex App

What It Is:
A native macOS desktop application that serves as a "command center" for multiple parallel AI coding agents. Each agent gets its own isolated worktree, allowing simultaneous work on different features.

Launch: February 2, 2026

Cost: Paid

Platform: macOS only (Windows/Linux coming)

Qwen Coder (coder.qwen.ai)

What It Is:
Here's where it gets interesting. Qwen Coder is a web-based coding agent that works exactly like Claude Code Web — connects to GitHub, creates branches, writes code, submits PRs — but it's completely free and open-source.

Launch: February 2026

Cost: FREE (with generous usage limits)

Platform: Web browser, CLI

The Qwen Coder Bombshell

Let me be crystal clear about what just happened: Alibaba's Qwen team just open-sourced the entire Claude Code Web experience.

What Qwen Coder Does

✅ Web-based interface at coder.qwen.ai (no installation required)
✅ Direct GitHub integration via OAuth
✅ Autonomous coding — give it a task, it creates branches automatically
✅ Pull request generation — writes code, commits, and opens PRs
✅ Repository understanding — 256K token context window (extendable to 1M)
✅ Asynchronous work — runs tasks whilst you're offline
✅ MCP support — connect to external tools
✅ Skills & subagents — reusable workflows

The Kicker

All of this is:

FREE (2,000 requests per day with OAuth)
Open-source (Apache 2.0 licence)
Self-hostable (run your own instance)
No vendor lock-in (you control everything)

This is the equivalent of GitHub releasing a free, open-source alternative to GitHub Copilot that works just as well. It's that significant.

Feature Comparison

Feature	Claude Code Web	OpenAI Codex App	Qwen Coder
Interface	Web browser	Native macOS app	Web browser
GitHub Integration	✅ Native OAuth	✅ Native Git	✅ Native OAuth
Branch Creation	✅ Automatic	✅ Via worktrees	✅ Automatic
PR Submission	✅ Direct	✅ Direct	✅ Direct
Async Work	✅ Full	⚠️ 30 min max	✅ Full
Multi-Agent	⚠️ Multiple tabs	✅ Built-in	⚠️ Multiple sessions
Context Window	200K-1M tokens	400K tokens	256K-1M tokens
MCP Support	✅ Native	✅ Skills system	✅ Native
Mobile Access	✅ iOS app	❌ Desktop only	✅ Web (any device)
Self-Hosting	❌ Cloud only	❌ Desktop only	✅ Open-source
Cost	£15-170/month	£17/month	FREE
Open Source	❌	❌	✅ Apache 2.0

Pricing Reality Check

Claude Code Web

Pro Plan: ~£15-17/month (approximately $20 USD)
Max 5x: ~£70-85/month (approximately $100 USD)
Max 20x: ~£140-170/month (approximately $200 USD)
Weekly usage limits apply

Annual Cost: £180-2,040 (approximately $240-2,880 USD)

OpenAI Codex App

ChatGPT Plus: ~£17/month (approximately $20 USD)
Temporary free access (promotional period)
5-hour rolling limit (doubled during promo)
macOS only (major limitation)

Annual Cost: £204 (approximately $240 USD) + macOS requirement

Qwen Coder

FREE tier: 2,000 requests per day
Self-hosting: FREE (run your own)
DashScope API (if you exceed free tier): ~£0.25-0.50 per 1M tokens (approximately $0.35-0.60 USD)

Annual Cost: £0 (approximately $0 USD)

The Math

For a solo developer using Claude Code Pro:

Claude Code: £180/year (approximately $240 USD)
Codex App: £204/year (approximately $240 USD) + must buy a Mac
Qwen Coder: £0/year (approximately $0 USD)

For a team of 5 developers:

Claude Code: £900-10,200/year (approximately $1,200-14,400 USD)
Codex App: £1,020/year (approximately $1,200 USD) + 5 Macs
Qwen Coder: £0/year (approximately $0 USD)

This isn't a small difference. This is game-changing.

Performance Benchmarks

SWE-Bench Verified (Real GitHub Issues)

Model	Score	Notes
Claude Opus 4.5	80.9%	Industry leader
GPT-5.2-Codex	80.0%	Close second
Qwen3-Coder-480B	69.6%	Best open-source model

Qwen trails by ~11 percentage points compared to Claude, but it's completely free and open-source. For many workflows, that trade-off is absolutely worth it.

Context & Efficiency

Context Windows:

Claude Code: 200K tokens (1M extended)
Codex App: 400K tokens
Qwen Coder: 256K tokens (1M extended)

Token Efficiency:

Claude Code: More verbose (thorough reasoning)
Codex App: Most efficient
Qwen Coder: Efficient with context caching (80% cost reduction on repeated content)

Real-World Performance

What Developers Are Saying:

From early testers (February 2026):

"Qwen Coder handles 80-90% of tasks as well as Claude Code"
"For refactoring and bug fixes, it's indistinguishable"
"Complex architectural decisions might need more guidance"
"But it's FREE, so who cares?"

Reality Check:
Qwen3-Coder performs comparably to Claude Sonnet 4.0 or GPT-4 Turbo — very capable, but may need more iteration on highly complex tasks compared to Claude Opus 4.5.

For most real-world development work (bug fixes, feature implementation, refactoring, test generation), the performance difference is negligible.

Real-World Use Cases

When to Choose Claude Code Web

Best For:

Mission-critical production code requiring highest accuracy
Teams with budget for subscriptions
Enterprises needing support contracts
Complex architectural refactoring
When you absolutely need the best model (Opus 4.5)

Real Example:
Netflix using Claude Code for major microservices refactoring where stability is paramount and budget isn't a concern.

When to Choose OpenAI Codex App

Best For:

Mac-based development teams
Projects requiring parallel feature development
Workflows needing multiple simultaneous agents
Teams already invested in OpenAI ecosystem
When desktop integration is crucial

Real Example:
OpenAI's own DevDay 2025 — seven parallel agents building different games simultaneously.

When to Choose Qwen Coder

Best For:

Literally everyone else
Startups and indie developers (zero cost)
Open-source projects (no vendor lock-in)
Teams requiring self-hosting (data sovereignty)
Privacy-sensitive projects (run your own instance)
Multi-platform teams (works on any device with browser)
Students and educators (completely free)
Experimentation and learning (no financial risk)

Real Example:
Startup MVP development with zero coding costs. Run 2,000 requests per day for free, or self-host for unlimited usage with complete control.

The Qwen Coder Advantage

1. Open-Source Transparency

Claude Code & Codex: Black boxes. You have no idea what they're doing internally.

Qwen Coder: Fully open-source. You can:

Audit the code
Modify behaviour
Understand exactly how it works
Contribute improvements
Fork and customise

2. Self-Hosting

Claude Code & Codex: Cloud-only. Your code goes through their servers.

Qwen Coder: Self-host your own instance:

Complete data sovereignty
No external dependencies
Unlimited usage
Custom configurations
Perfect for enterprises with strict security requirements

3. No Vendor Lock-In

Claude Code & Codex: Subscription required. Stop paying, lose access.

Qwen Coder:

Free tier is generous (2,000 requests/day)
Self-hosting means you own everything
Apache 2.0 means you can do anything with it

4. Community-Driven Development

Claude Code & Codex: Development controlled by single companies.

Qwen Coder:

Community contributions
Rapid bug fixes
Feature requests from users
Transparent roadmap

5. Platform Freedom

Claude Code: Web + iOS only
Codex App: macOS only (major limitation)
Qwen Coder: Any device with a browser (Windows, Mac, Linux, tablets, even phones)

The Business Case for Qwen Coder

For Startups

Scenario: 3-person startup building MVP

Claude Code:

Cost: £45-51/month (approximately $60-72 USD)
Annual: £540-612 (approximately $720-864 USD)

Codex App:

Cost: £51/month (approximately $60 USD) + 3 Macs (£3,000+ or approximately $4,000+ USD)
Annual: £612 + hardware (approximately $720 USD + hardware)

Qwen Coder:

Cost: £0 (approximately $0 USD)
Annual: £0 (approximately $0 USD)

Savings: £612+ per year (approximately $720+ USD per year)

That's a few months of runway extended. For a startup, that's huge.

For Agencies

Scenario: 15-person dev agency

Claude Code:

Cost: £225-2,550/month (approximately $300-3,600 USD/month)
Annual: £2,700-30,600 (approximately $3,600-43,200 USD)

Codex App:

Cost: £255/month (approximately $300 USD/month) + 15 Macs
Annual: £3,060 + hardware (approximately $3,600 USD + hardware)

Qwen Coder:

Cost: £0 for most usage, or self-host for unlimited
Annual: £0 (approximately $0 USD)

Savings: £2,700-30,600 per year (approximately $3,600-43,200 USD per year)

That's an entire junior developer's salary saved.

For Enterprises

Scenario: 200-person engineering org

Claude Code Enterprise: Custom pricing (likely £20,000-100,000+/year or approximately $28,000-140,000+ USD/year)

Qwen Coder Self-Hosted:

Infrastructure costs: £2,000-10,000/year (approximately $2,800-14,000 USD/year)
Complete data sovereignty
Unlimited usage
Full customisation

Savings: Tens of thousands to hundreds of thousands per year

The Catch (There's Always a Catch)

What Qwen Coder Trades Off

1. Slightly Lower Performance

69.6% vs 80.9% on SWE-Bench
May require more iteration on complex tasks
Not quite Opus 4.5 level (more like Sonnet 4.0)

2. Newer Platform

Launched February 2026 (brand new)
Smaller community (for now)
Fewer tutorials and examples (for now)

3. No Enterprise Support Contracts

Open-source means community support
No SLAs (unless you pay for support)
You're responsible for self-hosting

4. Less Polished (Maybe)

Claude Code has 6 months of polish
Codex has OpenAI's resources
Qwen Coder is newer (but fast-improving)

Is It Worth It?

For 90% of developers: Absolutely yes.

Unless you're:

Building mission-critical infrastructure for Netflix
Have unlimited budget
Need guaranteed enterprise support
Require the absolute highest model performance

...then Qwen Coder is the obvious choice.

How to Get Started with Qwen Coder

Quick Start (5 minutes)

Visit: coder.qwen.ai
Authenticate: Sign in with GitHub OAuth
Connect Repository: Select which repos to authorise
Start Coding: Give it a task

   "Fix the authentication bug in issue #42"
   "Refactor the user service to use dependency injection"
   "Add unit tests for the payment processing module"

Watch It Work: Qwen creates branches, writes code, runs tests, opens PRs
Review & Merge: Check the PR, provide feedback, merge when ready

Advanced: Self-Hosting

# Clone the repository
git clone https://github.com/QwenLM/qwen-code

# Install dependencies
npm install

# Configure your instance
cp .env.example .env
# Edit .env with your settings

# Start the server
npm start

Now you have your own private Qwen Coder instance with unlimited usage.

The Future (Next 6 Months)

Predictions

Qwen Coder Will:

Gain massive adoption (it's free!)
Build huge community
Close performance gap with Claude
Add more integrations and features
Become the default choice for indie devs and startups

Claude Code Will:

Maintain enterprise dominance
Focus on highest performance
Add more enterprise features
Remain the "premium" option

Codex App Will:

Expand to Windows/Linux
Improve parallel agent workflows
Compete more directly with Claude

The Real Winner

Developers.

We now have three excellent options:

Premium: Claude Code (highest quality)
Desktop: Codex App (native Mac experience)
Free: Qwen Coder (open-source, zero cost)

Competition drives innovation. Everyone wins.

The Verdict

Overall Rankings

Best Performance:

Claude Code Web (80.9% SWE-Bench)
OpenAI Codex App (80.0% SWE-Bench)
Qwen Coder (69.6% SWE-Bench)

Best Value:

Qwen Coder (FREE)
Codex App (£17/month or approximately $20 USD/month, temporary free access)
Claude Code (£15-170/month or approximately $20-200 USD/month)

Best for Startups:

Qwen Coder (saves £612+/year or approximately $720+/year)
Codex App (if you already have Macs)
Claude Code (if you need premium quality)

Best for Enterprises:

Qwen Coder (self-hosted, saves tens of thousands)
Claude Code (if you need support contracts)
Codex App (if heavily Mac-based)

Best for Privacy:

Qwen Coder (self-hostable)
Codex App (local execution)
Claude Code (cloud-only)

Best for Open-Source:

Qwen Coder (Apache 2.0)
Everything else doesn't qualify

My Personal Recommendation

Default Choice: Start with Qwen Coder

Seriously. It's free. It's open-source. It works on any device. For 90% of coding tasks, it's indistinguishable from Claude Code.

Try this workflow:

Use Qwen Coder for:
- Bug fixes
- Feature implementation
- Refactoring
- Test generation
- Documentation
- Daily development work
Upgrade to Claude Code for:
- Critical architecture decisions
- Complex system refactoring
- When you need the absolute best
Use Codex App for:
- Parallel feature development on Mac
- When managing multiple agents simultaneously

Most developers will spend 90% of their time in Qwen Coder and occasionally upgrade to Claude for the hardest 10%.

This gives you the best of both worlds:

Save money on routine work (Qwen is free)
Pay for premium quality only when you need it (Claude)

The Bigger Picture

What Qwen Coder Means for AI Development

This is bigger than just a free tool.

Qwen Coder proves that:

Open-source can compete with proprietary AI
Performance gaps are narrowing (69.6% vs 80.9% is close)
Free tiers can be generous (2,000 requests/day!)
Self-hosting is viable (enterprises can own their infrastructure)
Vendor lock-in is avoidable (Apache 2.0 means freedom)

The Pressure on Claude & OpenAI

With Qwen offering 85-90% of the functionality for free, Claude and OpenAI must now justify their subscriptions through:

Highest model performance
Enterprise features
Support contracts
Additional integrations

They can't compete on price. So they'll compete on quality and service.

This is healthy competition. Everyone improves.

Closing Thoughts

February 2026 will be remembered as the month AI coding agents went mainstream:

OpenAI launched the Codex desktop app (February 2)
Qwen dropped the bombshell of free, open-source web coding (February 2026)
Claude continues refining its premium experience

We've moved from "Can AI write code?" to "Which free AI coding agent should I use?"

The answer for most developers is clear: Qwen Coder.

It's free. It's open-source. It connects to GitHub. It creates branches and PRs. It works on any device. And it's good enough for 90% of coding tasks.

Start there. Upgrade to Claude only when you need the extra 10-15% performance. Use Codex if you're all-in on Mac.

The future of coding is agentic, asynchronous, and now it's also free.

Welcome to 2026.

Resources

Qwen Coder:

Web Interface: coder.qwen.ai
GitHub: github.com/QwenLM/qwen-code
Documentation: qwenlm.github.io/qwen-code-docs
Model: github.com/QwenLM/Qwen3-Coder

Claude Code Web:

Interface: claude.ai/code
Docs: support.claude.com
Pricing: Pro £15-17/month, Max £70-170/month (approximately $20-200 USD/month)

OpenAI Codex App:

Download: openai.com/codex
Docs: developers.openai.com/codex
Pricing: Included with ChatGPT Plus £17/month (approximately $20 USD/month)

Have you tried Qwen Coder yet? I'm curious to hear about your experience compared to Claude Code. Drop your thoughts in the comments!

Tags: #ai #coding #opensource #github #free #qwen #claude #openai #webdev #developer

Last updated: February 2026 | Qwen Coder launched February 2026

Build Your AI Analyst and Start Having Conversations with Your Structured Data

SimpleWBS — Wed, 28 Jan 2026 09:25:41 +0000

There’s a peculiar bottleneck in most organisations: the people who have questions about data aren’t always the people who know how to query it. A marketing manager wants to understand customer behaviour patterns. A product lead needs to analyse feature adoption. A CEO wants a quick breakdown of quarterly trends. And all of them end up in a queue, waiting for someone who speaks SQL.

What if you could simply ask your database a question in plain English?

‘What are the tip patterns in New York taxis?’

And instead of a blank stare, you get a comprehensive analysis: average tip amounts, the most common payment methods, seasonal variations, and the curious insight that New Yorkers are most generous with their tips early in the morning.

This isn’t science fiction. You can build this today, in about thirty minutes, using open-source tools. Let me show you how.

Why ClickHouse Is the Ideal Backend for AI Analytics

Before we dive into the setup, it’s worth understanding why ClickHouse is particularly well-suited for AI-powered analytics.

When an AI analyst explores your data, it doesn’t write one perfect query. It writes many queries. It might scan available tables, sample data to understand distributions, run aggregations to find patterns, then drill down into specific segments. A single conversational question can trigger five, ten, or even twenty queries behind the scenes.

With a traditional row-based database, this exploratory pattern is painfully slow. Each query might take seconds or minutes. The conversation becomes stilted — you ask a question, wait, get a partial answer, wait again. The AI’s ‘thinking’ is bottlenecked by the database.

ClickHouse changes this entirely. As a columnar OLAP database, it’s engineered for exactly this use case: fast analytical queries over large datasets. Queries that would take thirty seconds in PostgreSQL complete in milliseconds. Aggregations across billions of rows return in under a second.

This speed transforms the AI analyst experience. The AI can afford to be curious. It can run exploratory queries, check its assumptions, and iterate on its analysis — all whilst maintaining conversational flow. When you ask about tip patterns, the AI can query by time of day, by payment method, by location, by trip distance, and synthesise everything into a coherent answer before you’ve finished reading the previous response.

There’s another advantage: ClickHouse Cloud handles the infrastructure. You don’t need to provision servers, manage scaling, or worry about query optimisation. Point your data at ClickHouse — whether from S3, Kafka, PostgreSQL, or dozens of other sources — and the analytical layer is ready.

For serious analytical workloads, the database isn’t a commodity choice. ClickHouse’s speed is what makes conversational data analysis feel natural rather than laborious.

The Medallion Architecture: Structuring Data for AI

If you’re bringing your own data into ClickHouse, consider organising it using the medallion architecture. This three-layer approach — bronze, silver, gold — makes your data progressively more useful for analysis.

The Bronze layer holds raw data exactly as it arrives. No transformations, no cleaning. This is your source of truth, useful for debugging and reprocessing.

The Silver layer contains cleaned and normalised data. Duplicates removed, data types corrected, timestamps standardised. This is where you’d point most analytical queries.

The Gold layer holds aggregated, business-ready tables. Pre-computed metrics, dimensional models, KPIs. These are optimised for specific analytical questions.

When you configure your AI analyst, you’ll point it primarily at the gold layer for fast, reliable answers, with permission to explore silver for deeper investigation. This structure helps the AI deliver consistent results whilst maintaining flexibility for ad-hoc exploration.

The Tools We’ll Use

We’re going to wire together three components:

LibreChat is a popular open-source library for building ChatGPT-style interfaces. It gives us a polished chat experience without having to build one from scratch. Crucially, it includes an Agent Builder that lets us create specialised AI assistants with pre-loaded knowledge and connected tools.

ClickHouse MCP Server is the bridge between the AI and your database. MCP stands for Model Context Protocol — it’s a standardised way for AI models to interact with external tools and data sources. The ClickHouse MCP server specifically allows AI models to discover databases, explore table structures, and execute queries.

Docker ties everything together, letting us run the entire stack with a single command.

The beauty of this architecture is its modularity. You can swap out LibreChat for another interface. You can point the MCP server at your own ClickHouse instance instead of the demo playground. You can even switch between AI models — Claude, GPT-4, or others — depending on your preference and budget.

Choosing Your LLM: Premium vs Budget

One of the most important decisions is which language model to use. The good news: you have options spanning a wide range of capabilities and costs.

Premium tier: Claude Opus, Claude Sonnet, and GPT-5/GPT-4o represent the state of the art. These models excel at complex reasoning, handle ambiguous questions gracefully, and generate sophisticated SQL. For mission-critical analytics or complex datasets, they’re worth the cost. Claude Sonnet in particular hits a sweet spot — excellent analytical reasoning at a lower price point than Opus.

Budget tier: Here’s where things get interesting. Models like Qwen 2.5 (72B and 32B variants), Llama 3.3, and DeepSeek deliver surprisingly strong performance at a fraction of the cost. For straightforward analytical queries — ‘show me sales by region’, ‘what’s the trend over time’, ‘compare these two segments’ — these models perform nearly as well as their premium counterparts.

OpenRouter is the secret weapon here. Rather than managing API keys for multiple providers, OpenRouter gives you a single API endpoint that routes to dozens of models. You can experiment freely: try Qwen for a week, switch to Claude for complex projects, fall back to Llama for high-volume batch analysis. The flexibility is remarkable.

A practical strategy: start with a premium model whilst you’re building and testing your agent. Once it’s working reliably, experiment with budget models on the same queries. You might find that Qwen handles 80% of your use cases perfectly well — and that 80% just got significantly cheaper.

Setting Up Your Environment

Before we begin, make sure you have Docker running on your machine. That’s the only prerequisite.

First, we’ll clone the ClickHouse examples repository. This repository contains examples for many different use cases, but we’re particularly interested in the MCP integrations with various AI libraries.

git clone https://github.com/ClickHouse/examples.git
cd examples/AI/MCP/librechat

Next, clone the LibreChat project itself into this directory:

git clone https://github.com/danny-avila/LibreChat.git libra

You’ll now have a folder called ‘libra’ containing the LibreChat codebase.

Configuring Docker Compose

The ClickHouse examples repository includes a Docker Compose override file that does most of the heavy lifting. Let’s examine what it contains.

The override file defines two key services. The first is the API service, which mounts a custom librechat.yaml configuration file. This file tells LibreChat about our MCP server. The second service is the ClickHouse MCP server itself.

For the MCP server, the configuration looks something like this:

clickhouse-mcp-server:
  image: clickhouse/mcp-server
  container_name: clickhouse-mcp-server
  ports:
    - "8001:8000"
  environment:
    - CLICKHOUSE_HOST=sql-clickhouse.clickhouse.com
    - CLICKHOUSE_PORT=8443
    - CLICKHOUSE_USER=demo
    - CLICKHOUSE_PASSWORD=demo
    - CLICKHOUSE_SECURE=true

By default, this points to the ClickHouse SQL playground — a public demo environment with several interesting datasets. But here’s the important bit: if you want to point this at your own ClickHouse server, this is the place to do it. Simply replace the environment variables with your own connection details.

Copy the Docker Compose override file into the LibreChat folder:

cp docker-compose.override.yml libra/
cd libra

Setting Up Your API Key

LibreChat needs an API key to communicate with your chosen language model. Create an environment file from the provided example:

cp .env.example .env

Open the .env file in your preferred text editor. Search for the API key configuration for your chosen provider.

For Anthropic (Claude):

ANTHROPIC_API_KEY=sk-ant-your-key-here

For OpenAI (GPT models):

OPENAI_API_KEY=sk-your-key-here

For OpenRouter (access to Qwen, Llama, and dozens of others):

OPENROUTER_API_KEY=sk-or-your-key-here

You can configure multiple providers and switch between them in the interface. Save and close the file.

Configuring LibreChat to Use the MCP Server

This is where the magic happens. We need to tell LibreChat about our ClickHouse MCP server.

Create the LibreChat configuration file:

cp librechat.example.yaml librechat.yaml

Open librechat.yaml and scroll to the bottom. Add the MCP server configuration:

mcpServers:
  clickhouse-playground:
    url: http://clickhouse-mcp-server:8000

The name ‘clickhouse-playground’ is arbitrary — you can call it whatever makes sense for your setup. The URL points to the Docker container we defined earlier. Because both services run within Docker’s network, they can communicate using container names rather than localhost.

Launching the Stack

Everything is configured. Time to launch:

docker compose up

You’ll see a cascade of log messages as Docker pulls images and starts containers. Once the logs settle, open your browser and navigate to:

http://localhost:3080

LibreChat will prompt you to create a user account. Fill in your details, complete the registration, and log in.

Important: Don’t start chatting directly with the base interface. The raw chat works, but without an agent, you’re essentially onboarding a new analyst from scratch with every conversation. The AI has to discover tables, figure out what columns mean, and guess at business logic each time. Instead, head straight to the Agent Builder to create a proper AI analyst.

Building Your Analyst Agent (The Critical Step)

This is the most important part of the entire setup. Everything else is infrastructure — this is where you create actual intelligence.

Click on the sidebar in LibreChat and select Agents, then Create Agent.

You’ll see several fields to configure. The most important one is Instructions — this is where you embed domain knowledge directly into the agent’s behaviour. Think of it as writing an onboarding document for a new analyst, except this analyst has perfect recall and will follow your guidelines precisely.

The quality of your instructions directly determines the quality of your AI analyst. A generic instruction like ‘you are a helpful data analyst’ produces generic results. A detailed instruction set that explains your data, your business rules, and your analytical priorities produces an agent that behaves like a knowledgeable colleague.

Using AI to Write Your Agent Instructions

Here’s a powerful technique: use another AI to help you write the instructions for your analyst agent.

Take the schema of your gold layer tables — the datamarts and analytical tables your AI analyst will query — and give them to Claude, GPT-4, or whatever AI you prefer. Ask it to write comprehensive instructions for an agent that will use this data.

Here’s a prompt you can adapt:

I'm building an AI analyst agent that will query a ClickHouse database using
natural language. Below is the schema for my main analytical tables.

Please write detailed instructions for this agent that include:
1. A description of what each table contains and when to use it
2. What each column means in business terms (not just technical definitions)
3. Important business rules and caveats (data quality issues, special cases,
   things that would trip up a naive analyst)
4. What analytical priorities to focus on when given open-ended questions
5. Query guidelines specific to ClickHouse (aggregation functions, time
   handling, performance considerations)
6. How to present findings (lead with insights, mention limitations)

Here's my schema:

[Paste your CREATE TABLE statements or schema documentation here]

The AI will generate a first draft of instructions. Review it, refine it, add your own domain knowledge, and iterate. You might go back and forth several times — ‘add more detail about how we calculate churn’, ‘explain the difference between gross and net revenue’, ‘mention that Q1 2023 data is incomplete due to the migration’.

This approach works because you’re using AI where it excels (synthesising information, structuring documentation) to create instructions that make another AI excel at analysis. It’s AI helping AI help you.

Example: A New York Taxi Analyst

Here’s what a comprehensive instruction set looks like for the ClickHouse playground’s taxi dataset:

You are a senior data analyst specialising in New York City taxi operations.
You have access to the ClickHouse SQL playground via the MCP server.

PRIMARY DATASET

Your main focus is the trips table in the nyc_taxi database. This contains
millions of taxi trip records from New York City.

KEY COLUMNS AND THEIR MEANING

- pickup_datetime: When the passenger got in (use this for time-based analysis)
- dropoff_datetime: When the trip ended
- passenger_count: Number of passengers (1–6 typically; 0 means data error)
- trip_distance: Distance in miles (sanity check: over 100 miles is likely bad data)
- fare_amount: Base fare in USD (does not include tips or extras)
- tip_amount: Tip in USD (only recorded for card payments, not cash)
- total_amount: Everything combined – fare, tip, tolls, surcharges
- payment_type: 1 = Credit card, 2 = Cash, 3 = No charge, 4 = Dispute
- pickup_location_id: Zone where trip started (joins to taxi_zone_lookup)
- dropoff_location_id: Zone where trip ended

BUSINESS RULES AND CAVEATS

- Tips for cash payments are not recorded. When analysing tipping behaviour,
  always filter to payment_type = 1 (credit card) and mention this limitation.
- Airport trips have different fare structures. Location IDs 132 (JFK) and
  138 (LaGuardia) indicate airport pickups or dropoffs.
- Data quality varies by year. Pre-2015 records have more missing values.
- Rush hour is 7–9am and 5–7pm on weekdays.
- Trips with fare_amount <= 0 or trip_distance <= 0 should be excluded
  from most analyses as they indicate cancelled trips or data errors.

ANALYSIS PRIORITIES

When asked open-ended questions, focus on:
1. Revenue patterns (fare trends, tip percentages, seasonal variation)
2. Operational efficiency (trip duration vs distance, busy periods)
3. Customer behaviour (tipping habits, popular routes, payment preferences)

QUERY GUIDELINES

- Always include a LIMIT clause (start with 1000, increase if needed)
- For time-based analysis, use toStartOfHour(), toStartOfDay(), or
  toStartOfMonth() to aggregate appropriately
- When comparing periods, calculate percentage change, not just absolute difference
- Round monetary values to 2 decimal places in final output
- Use formatReadableQuantity() for large numbers to improve readability

OUTPUT STYLE

Present findings as a business analyst would: lead with the insight,
then provide supporting data. Mention any data quality issues that
might affect interpretation. If you're uncertain about something,
say so rather than guessing.

Notice what this instruction set accomplishes:

It tells the agent which database and table to focus on — no more wandering through irrelevant datasets.
It explains what each column actually means in business terms, not just technical definitions.
It flags data quality gotchas that would trip up a naive analyst.
It establishes analytical priorities so open-ended questions get sensible answers.
It sets guardrails for query efficiency and output formatting.
It defines a communication style that prioritises insights over raw data dumps.

Connecting the Agent to ClickHouse

After writing your instructions, scroll down to the Actions section in the Agent Builder. This is where you connect the agent to your ClickHouse MCP server.

Select your clickhouse-playground (or whatever you named it) from the available MCP services. This gives the agent the ability to list databases, describe tables, and execute queries.

Choose a model — Claude Sonnet works well for analytical reasoning, or use a budget model via OpenRouter if you’re optimising for cost.

Save your agent.

Using Your AI Analyst

Now when you start a conversation with this agent, it already knows your data. You’re not chatting with a generic AI that needs to discover everything from scratch. You’re working with a specialist who understands your domain.

Ask ‘What affects tip amounts?’ and it immediately queries the right table, filters for credit card payments (because it knows cash tips aren’t recorded), and structures its analysis around the factors that actually matter.

Ask ‘Show me the busiest times’ and it knows to aggregate by hour, distinguish between weekdays and weekends, and present the results in a way that’s actionable.

Ask ‘Are there any data quality issues I should know about?’ and it can point to the caveats you built into its instructions, reinforcing that institutional knowledge with every conversation.

This is the difference between a chat interface and a proper agent.

Adapting the Instructions for Your Data

The taxi example above is a template. For your own data, you’ll want to adapt each section:

Primary Dataset: Which database and tables should the agent focus on? If you have dozens of tables, explicitly list the three or four that matter most for analytical questions. Point it at your gold layer first.

Key Columns: Don’t just list column names. Explain what they mean in your business context. What does ‘status = 3’ actually represent? What are the valid ranges? Which columns are frequently null? What’s the relationship between customer_id and account_id?

Business Rules: Every dataset has quirks. Maybe your revenue numbers need to be multiplied by an exchange rate. Maybe certain customer segments should be excluded from churn analysis. Maybe dates before a system migration are unreliable. Maybe ‘active users’ has a specific definition that’s different from what someone might assume. Write these down.

Analysis Priorities: What questions does your business actually care about? Revenue, growth, efficiency, customer satisfaction, operational metrics? Tell the agent what to optimise for when given ambiguous requests.

The better your instructions, the more your agent behaves like a knowledgeable colleague rather than a generic chatbot with database access.

Pointing at Your Own Data

The demo is compelling, but the real value comes when you connect this to your own ClickHouse instance.

Modify the environment variables in your Docker Compose override file. Replace the playground credentials with your own:

environment:
  - CLICKHOUSE_HOST=your-clickhouse-server.com
  - CLICKHOUSE_PORT=8443
  - CLICKHOUSE_USER=your_username
  - CLICKHOUSE_PASSWORD=your_password
  - CLICKHOUSE_SECURE=true

Restart the containers, update your agent instructions to reflect your actual schema, and suddenly your AI analyst can explore your production data. Sales figures. User behaviour. Operational metrics. Whatever lives in your database becomes queryable through natural conversation.

A few considerations for production use:

Security matters. The MCP server will execute whatever queries the AI generates. Consider creating a read-only database user with access limited to specific tables. You probably don’t want the AI accidentally running expensive queries or accessing sensitive data.

Performance deserves attention. Large language models sometimes generate inefficient queries. ClickHouse is remarkably fast, but it’s still worth monitoring query execution times and setting appropriate timeouts.

Iterate on your instructions. Your first version won’t be perfect. Pay attention to where the agent gets confused or produces unhelpful results. Each failure is a signal to add more detail to your instructions.

Beyond Querying

What we’ve built is a foundation. A conversational interface to structured data. But the possibilities extend further.

You could add scheduled reports — ‘Every Monday morning, summarise last week’s sales performance and email it to the team.’ You could create alerts — ‘Tell me if any metric drops more than 20% compared to the previous week.’ You could build dashboards that update themselves based on natural language instructions.

The MCP protocol is designed for extensibility. The ClickHouse examples repository contains integrations with other AI libraries beyond LibreChat. The same principles apply whether you’re building a Slack bot, a custom application, or an internal tool.

The Bigger Picture

We’re at an inflection point in how humans interact with data. For decades, there’s been a translation layer between questions and answers — someone who knows SQL, someone who can write the query, someone who can interpret the results. That layer is dissolving.

This doesn’t mean data analysts become obsolete. Quite the opposite. It means they can focus on the genuinely difficult problems: data quality, model design, causal inference, strategic interpretation. The mechanical work of translating ‘what were our sales last quarter?’ into SELECT statements becomes automated.

Building your own AI analyst isn’t just a technical exercise. It’s a glimpse of how data work will function in the near future. And now you have the tools to build it yourself.

The complete setup instructions are available in the ClickHouse documentation under ‘Using ClickHouse MCP Server with LibreChat’.

Why most organisations should evaluate ClickHouse Cloud + Power BI before committing to Fabric, Databricks, or Snowflake

SimpleWBS — Tue, 27 Jan 2026 10:02:01 +0000

The Uncomfortable Truth About Your Data Platform

Here's a question every business leader should be asking their IT team right now:

"Why does our data platform cost this much, take this long to deliver insights, and require this many people to maintain?"

If the answer involves phrases like "we're still building out the lakehouse", "the Spark clusters need tuning", or "we're waiting on the platform team to provision environments" — you've fallen into the enterprise data platform trap.

There's a simpler path. One that delivers better performance, lower costs, and fewer headaches. And most organisations aren't even evaluating it.

The Modern Data Stack Has Become Absurdly Complex

Let's be honest about what "enterprise data platforms" have become.

Databricks started as managed Spark. Now it's notebooks, Unity Catalog, Delta Live Tables, MLflow, Feature Store, SQL Warehouses, and a pricing model that requires a spreadsheet to understand.

Snowflake was beautifully simple — until it wasn't. Now you're navigating Snowpark, Streamlit, Cortex AI, Dynamic Tables, and consumption-based pricing that surprises finance every quarter.

Microsoft Fabric took everything in the Microsoft data ecosystem and put it in a trench coat pretending to be one product. Power BI, Synapse, Data Factory, Real-Time Analytics, and a capacity-based licensing model that nobody fully understands.

Each of these platforms has merit. Each solves real problems. But each has also accumulated complexity that most organisations simply don't need.

The result? Expensive implementations that underperform, require specialised talent to maintain, and deliver questionable ROI.

The Alternative: Elegant Simplicity

Consider a different architecture:

Component	Purpose
ClickHouse Cloud	Analytical database — storage, compute, and query engine
Power BI	Business intelligence and visualisation
Airbyte	Data ingestion and pipeline automation
LibreChat + ClickHouse MCP	AI-powered natural language analytics

That's it. Four components. Each does one thing exceptionally well.

Let me explain why this stack deserves serious evaluation.

Why ClickHouse Changes the Economics

ClickHouse wasn't adapted for analytics — it was built for analytics from the ground up.

Raw Performance

ClickHouse uses columnar storage, vectorised query execution, and aggressive compression. The practical result is that queries which take minutes in traditional data warehouses often complete in seconds.

This isn't marketing fluff. The ClickBench benchmarks consistently show ClickHouse outperforming alternatives by significant margins on analytical workloads.

Cost Structure

ClickHouse Cloud separates storage and compute, but without the abstraction layers that inflate costs elsewhere. You're paying for:

Storage (compressed, so less than you'd expect)
Compute (scales to zero when idle)
That's essentially it

Compare this to Databricks DBUs, Snowflake credits, or Fabric capacity units — pricing models designed to be difficult to predict and optimise.

Operational Simplicity

ClickHouse Cloud is genuinely managed. You don't need a platform team to configure clusters, tune Spark executors, or manage infrastructure. The service handles scaling, backups, and maintenance.

This matters enormously for organisations without dedicated data platform engineers.

Materialised Views: Forced Architectural Discipline

Here's something most ClickHouse evaluations overlook: materialised views fundamentally change how teams build data pipelines.

In ClickHouse, materialised views:

Execute transformations at ingestion time
Enforce explicit contracts between data layers
Create clear lineage from raw to refined data
Cannot easily be bypassed or bodged

This naturally implements the medallion architecture (bronze → silver → gold) without requiring process discipline or governance overhead.

Compare this to a typical Databricks environment where:

47 different notebooks implement transformations
Each data engineer has their own approach
Lineage is scattered across jobs and workflows
Nobody's quite sure which version of the data is "correct"

ClickHouse's materialised views don't just improve performance — they impose structure. For organisations without mature data engineering practices, this constraint is a feature, not a limitation.

The "Software People Aren't Data People" Problem

Let's address the elephant in the room.

Modern data platforms assume you have:

Platform engineers who understand Kubernetes and cloud infrastructure
Data engineers who understand Spark internals and distributed computing
Analytics engineers who understand dbt, semantic layers, and transformation patterns
BI developers who understand data modelling and visualisation

Most organisations don't have these specialists. They have generalised IT teams who are expected to do everything.

The ClickHouse + Power BI stack respects this reality:

ClickHouse speaks SQL. Not Spark SQL with its quirks. Not proprietary query languages. Standard SQL that any database-literate person can write.
Power BI is familiar. Business users already know it. The learning curve for analysts is minimal.
Airbyte provides pre-built connectors. You're not writing custom ingestion code. You're configuring established connectors.
Administration is minimal. ClickHouse Cloud handles the infrastructure. There's no cluster management, no executor tuning, no garbage collection optimisation.

This isn't about dumbing things down. It's about choosing tools that match your organisation's actual capabilities.

The AI Analyst That Actually Works

Here's where things get interesting for 2026 and beyond.

ClickHouse has released an MCP (Model Context Protocol) integration. Combined with LibreChat or similar interfaces, you get an AI analyst that can:

Query your data directly using natural language
Understand your schema and relationships
Generate and execute SQL against ClickHouse
Return results and visualisations

This isn't a bolt-on feature that requires a separate AI platform, vector database, and orchestration layer. It's a direct integration between your analytical database and AI capabilities.

The queries are fast because ClickHouse is fast. The results are accurate because the AI is querying real data, not summarised embeddings. The scaling is handled because both components are cloud-native.

Compare this to implementing AI analytics on Databricks (requires Mosaic AI, model serving, and significant configuration) or Snowflake (requires Cortex, which is still maturing and adds cost complexity).

What About Governance and Compliance?

This is where I'll be direct about limitations.

ClickHouse Cloud's governance capabilities are less mature than Unity Catalog or Microsoft Purview. If you're in a heavily regulated industry with complex compliance requirements — healthcare, financial services, government — you'll need to evaluate whether ClickHouse's current governance features meet your needs.

That said, most organisations' governance requirements are simpler than they believe. Role-based access control, audit logging, and data encryption cover the majority of use cases. ClickHouse Cloud provides these.

The question to ask is: "Do we need enterprise governance features, or have we been told we need them?"

Many organisations implement complex governance frameworks because vendors sold them on the requirement, not because regulations actually demanded it.

The Total Cost Comparison

Let's talk numbers — not hypothetical benchmarks, but the real costs organisations experience.

Databricks

Compute costs scale with DBU consumption, which is difficult to predict
Storage costs for Delta tables
Premium features (Unity Catalog, Model Serving) add additional DBU multipliers
Typically requires dedicated platform engineering resources
Common complaint: costs 2-3x initial estimates after first year

Snowflake

Credit consumption varies dramatically based on query patterns
Virtual warehouse sizing requires ongoing optimisation
Premium features (Snowpark, Cortex) add cost complexity
Common complaint: finance teams consistently surprised by monthly invoices

Microsoft Fabric

Capacity-based pricing requires right-sizing that's difficult to predict
Unused capacity is wasted spend
Feature availability varies by capacity tier
Common complaint: nobody understands how to optimise capacity utilisation

ClickHouse Cloud + Power BI + Airbyte

ClickHouse Cloud: predictable compute + storage costs, scales to zero
Power BI: per-user licensing (Pro) or capacity (Premium) — well understood
Airbyte Cloud: usage-based pricing on data volume — straightforward

The total is typically 40-60% lower than equivalent enterprise platform implementations, with significantly less variance in monthly costs.

The Implementation Reality

Let's compare what "getting started" actually looks like.

Enterprise Platform (Fabric/Databricks/Snowflake)

Procurement and licensing negotiation (2-4 weeks)
Environment provisioning and configuration (2-4 weeks)
Network and security integration (2-4 weeks)
Platform team onboarding and training (4-8 weeks)
Initial pipeline development (4-8 weeks)
First production workload (4-6 months total)

ClickHouse Cloud + Power BI

Sign up for ClickHouse Cloud (1 day)
Configure Airbyte connections to source systems (1-2 weeks)
Create initial tables and materialised views (1-2 weeks)
Connect Power BI (1 day)
First production workload (3-4 weeks total)

This isn't because ClickHouse is less capable. It's because the architecture has fewer moving parts, fewer integration points, and less configuration surface area.

Time-to-value is dramatically shorter.

When NOT to Choose This Stack

I'm not arguing this stack is universally superior. There are legitimate reasons to choose alternatives:

Choose Databricks if:

Machine learning and feature engineering are core to your use case
You need tight integration between data engineering and ML workflows
You have a mature platform engineering team

Choose Snowflake if:

You need extensive data sharing capabilities across organisations
Your workload involves complex multi-table joins as the primary pattern
You're heavily invested in the Snowflake partner ecosystem

Choose Fabric if:

You're deeply committed to the Microsoft ecosystem
Your organisation mandates Microsoft tooling
You need tight integration with Microsoft 365 and Azure services

But evaluate ClickHouse + Power BI if:

Your primary use case is analytical queries and business intelligence
You value operational simplicity
You want predictable, lower costs
Your team doesn't have dedicated platform specialists
You want to move fast without drowning in configuration

The Call to Action

If you're a business leader, here's what I'm asking:

Before your organisation commits to (or renews) an enterprise data platform, require your IT team to evaluate ClickHouse Cloud + Power BI as a baseline comparison.

Not as a foregone conclusion — as a genuine evaluation.

Ask them to:

Run a proof of concept with a representative workload
Document the total cost of ownership for both options over 3 years
Compare time-to-value for delivering initial capabilities
Assess operational requirements — how many people are needed to maintain each option
Evaluate performance on your actual query patterns

If the enterprise platform wins that comparison fairly, proceed with confidence. But don't assume complexity equals capability. Don't let "nobody got fired for buying [enterprise vendor]" drive a decision that affects your organisation's agility and costs for years.

The data industry has been selling enterprise complexity to organisations that would be better served by simplicity.

It's time to question that assumption.

Getting Started

If you want to evaluate this stack:

ClickHouse Cloud: clickhouse.com/cloud — free tier available
Airbyte Cloud: airbyte.com — free tier available
Power BI: powerbi.microsoft.com — Pro trial available
LibreChat: librechat.ai — open source
ClickHouse MCP: github.com/ClickHouse/mcp-clickhouse

You can have a working proof of concept in days, not months.

The question is whether you'll take the time to try.

Have you evaluated ClickHouse for your analytical workloads? I'd be interested to hear about your experience in the comments — both successes and challenges.

Free CRM for Small Business: 7 Traps to Avoid (And Where to Start)

SimpleWBS — Sun, 25 Jan 2026 20:29:50 +0000

You've realised that sticky notes, spreadsheets, and memory aren't cutting it anymore. Customer details are scattered. Follow-ups are missed. You know you need a CRM, but every option seems designed for enterprises with IT departments and unlimited budgets.

Here's the truth: most small businesses make the same mistakes when choosing their first CRM. They waste months on complex implementations, spend thousands on features they never use, or get locked into platforms that hold their data hostage.

This guide will help you avoid those traps and get started the right way.

The Real Problem CRMs Should Solve

Before we discuss solutions, let's be clear about the actual problem.

You don't need a CRM because "that's what businesses use". You need one because:

You're losing track of conversations. A customer mentions something important, and three weeks later you've forgotten.
Follow-ups fall through the cracks. You meant to call that prospect back, but it slipped your mind.
You can't see your pipeline. How many deals are close to closing? You're not entirely sure.
Your team can't collaborate. When your colleague is off sick, nobody knows where things stand with their customers.
You're missing opportunities. That customer who bought six months ago? You forgot to check in.

If these sound familiar, you need a CRM. But you need the right one.

Trap #1: The Feature Comparison Trap

The Mistake: Choosing a CRM based on feature lists.

You search for "best free CRM" and find comparison articles listing dozens of features: marketing automation, AI lead scoring, advanced reporting, social media integration, custom workflows...

It sounds impressive. So you choose the one with the longest feature list.

Why This Backfires:

Three months later, you're still trying to figure out how to use it. Your team hasn't adopted it. You've configured 15% of the available features. The CRM has become a job unto itself.

The Reality:

Most small businesses need five things from a CRM:

Store customer contact information
Record interaction history
Track opportunities through a pipeline
Set reminders for follow-ups
See everything in one place

That's it. Everything else is noise until you've mastered these basics.

What to Do Instead:

Start with the absolute minimum. Get your team actually using a simple system. Once that's second nature, you can evaluate whether you need additional capabilities.

Trap #2: The "Free Trial" Trap

The Mistake: Starting with a "free" CRM that's actually a time-limited trial or heavily restricted freemium version.

The advertised price is £0, so you sign up. You spend two weeks getting everything set up. You import your contacts. You train your team. You build your pipeline.

Then you hit the limitations:

"Upgrade to add a third team member"
"Unlock custom fields with Premium"
"Email integration requires Professional tier"
"Export your data: Enterprise only"

Why This Backfires:

You've invested time and built dependency. Now you're facing the classic sunk cost fallacy. Do you pay the suddenly expensive subscription, or start over?

These companies know exactly what they're doing. The "free" tier exists to get you invested, then extract payment once you're locked in.

The Reality:

Truly free CRMs are rare. Most use one of these models:

Free trial (14-30 days) then mandatory payment
Freemium with crippling restrictions
"Free forever" with per-user pricing that becomes expensive
Free with your data being monetised

What to Do Instead:

Look for CRMs that are genuinely free with no strings attached, or transparent about their pricing from day one. If something claims to be "free", read the fine print carefully.

Trap #3: The Complexity Trap

The Mistake: Choosing enterprise-grade CRM software for your five-person business.

You want to "do it right", so you choose Salesforce or Microsoft Dynamics. These are what the big companies use, after all.

Why This Backfires:

Enterprise CRMs are built for enterprises. They assume you have:

Dedicated CRM administrators
Complex sales processes with multiple stakeholders
Integration requirements with dozens of other systems
Compliance and governance needs
Custom development resources

Your five-person business has none of these things.

The result? You spend weeks in "implementation" and your team still doesn't understand how to use it. The CRM sits unused whilst everyone goes back to spreadsheets.

The Reality:

Complexity doesn't equal quality. In fact, for small businesses, complexity equals friction.

A CRM should take five minutes to understand and fit naturally into your daily workflow. If your team needs training, something's wrong.

What to Do Instead:

Choose boring simplicity over impressive complexity. You can always migrate to something more sophisticated later. But first, build the habit of actually using a CRM.

Trap #4: The Data Hostage Trap

The Mistake: Not considering data portability until you want to leave.

You choose a CRM, use it for two years, and accumulate thousands of customer records, notes, and interaction history. Then you decide to switch platforms.

Suddenly you discover:

Export is only available on Enterprise tier
Data exports are in proprietary formats
Contact notes aren't included in exports
You can export data, but not import it anywhere useful

Why This Backfires:

Vendor lock-in is intentional. Once your business data is trapped in their system, switching becomes so painful that you stay even when you're unhappy.

The Reality:

Your customer data is your business's most valuable asset. Any system that makes it difficult to get your data out is a system you should avoid.

What to Do Instead:

Before committing to any CRM:

Verify you can export all your data at any time
Check the export format (CSV is universal)
Test the export process whilst you're still in the trial period
Ensure there are no restrictions on data export in the free tier

Trap #5: The Privacy and Security Trap

The Mistake: Not questioning where your customer data actually lives.

You sign up for a CRM. Upload your customer list. Start recording conversations. Never think about where this information is being stored or who has access to it.

Why This Backfires:

Your customer data now lives on someone else's servers, in someone else's database, subject to someone else's security practices. You're trusting a third party with your customers' personal information.

Consider:

Data breaches happen regularly
Terms of service can change
Companies get acquired
Servers can go down
Privacy regulations (GDPR, etc.) make you liable for how vendors handle your data

The Reality:

Every cloud CRM creates a security and privacy dependency. You're outsourcing the protection of your most valuable business asset to a third party.

What to Do Instead:

Understand the trade-offs:

Cloud CRMs: convenient but create dependencies
Self-hosted CRMs: full control but require technical expertise
Encrypted sync CRMs: data syncs but remains encrypted, only you hold the keys

Choose based on your risk tolerance and privacy requirements.

Trap #6: The Integration Trap

The Mistake: Choosing a CRM based on its impressive integration marketplace.

"It integrates with 5,000+ apps!" sounds amazing. You imagine your entire business running seamlessly through connected systems.

Why This Backfires:

Integration complexity compounds. Each integration is another thing to configure, monitor, and troubleshoot. When integrations break (and they will), your workflow breaks.

Moreover, most small businesses don't need integrations. You think you do because the marketing tells you that you do.

The Reality:

For most small businesses, the "integration" you actually need is being able to copy and paste between tools. Anything more complex than that probably isn't worth the maintenance overhead.

What to Do Instead:

Start with zero integrations. Use your CRM as a standalone tool. If you discover a genuine need for integration later, you can evaluate options then.

Don't let integration capabilities influence your initial choice. They're almost certainly not as important as you think.

Trap #7: The "Scale for the Future" Trap

The Mistake: Choosing a CRM based on what you might need in three years rather than what you need today.

You're a two-person business, but you're planning for growth. So you choose an enterprise CRM that can "scale" to support hundreds of users.

Why This Backfires:

Three things happen:

You pay for capabilities you don't use (wasted money)
You struggle with complexity you don't need (wasted time)
You often don't actually grow the way you imagined (wasted planning)

The business you'll be in three years is unknowable. Your needs will change in ways you can't predict. Over-engineering for hypothetical future requirements is almost always a mistake.

The Reality:

Migrating CRMs is easier than you think. Your data is portable (if you avoided Trap #4). Modern CRMs are designed for easy migration.

The cost of using the wrong tool for three years whilst you "scale into it" is far higher than the cost of migrating when you actually need more capability.

What to Do Instead:

Choose the CRM that solves your problem today. When your needs change, you can switch. This is infinitely better than struggling with an over-complicated tool whilst you wait to "grow into it".

Where to Actually Start: A Framework

Now that you know the traps, here's a simple framework for choosing your first CRM:

Step 1: Define Your Core Requirement

Write down the one problem you're trying to solve:

"I need to stop losing customer contact details"
"I need to remember follow-up conversations"
"I need to see which deals are close to closing"

If you have more than three core requirements, you're overthinking it.

Step 2: Test With Zero Commitment

Find a CRM you can try immediately without:

Credit card details
Complex signup process
Data import requirements
Configuration or setup

Open it. Use it for a real customer interaction. If it feels natural, continue. If it feels complicated, move on.

Step 3: Use It for Two Weeks

Don't just test it. Actually use it as your daily system for at least two weeks.

Track real customers. Record real conversations. Move real opportunities through your pipeline.

You'll know within two weeks whether this tool helps or hinders.

Step 4: Evaluate Actual Usage

After two weeks, ask:

Did we actually use it daily?
Did it make our work easier or harder?
What features did we use? (This is usually surprising)
What features did we ignore?
Would we miss this tool if it disappeared?

Step 5: Commit or Move On

If the tool proved valuable, commit to using it properly. If it didn't, try something simpler.

Most people skip step 3 and 4. They choose based on features and promises rather than actual daily usage. Don't make that mistake.

Why Simple-CRM.org Should Be Your Starting Point

Full transparency: I'm going to recommend simple-crm.org. But not because it's the "best" CRM. Because it's the best place to start.

Here's why:

It Avoids Every Trap We Discussed

Trap #1 (Features): Simple-crm.org has exactly three capabilities: contacts, notes, and opportunities. That's it. No feature bloat to navigate.

Trap #2 (Pricing): Genuinely free. No trial period. No user limits. No premium tier. No "upgrade to unlock". Free forever.

Trap #3 (Complexity): Open it and start using it. No setup. No configuration. No training needed. If you can use a web browser, you can use this CRM.

Trap #4 (Data): Your data lives in your browser using IndexedDB. Export it anytime in standard formats. No lock-in whatsoever.

Trap #5 (Privacy): Your data is fully encrypted, like Signal messenger for CRM. You create a PIN, get a share link, and only people with both can access your data. The stored data is encrypted end-to-end—even the sync service can't read it. Complete privacy by design.

Trap #6 (Integrations): No integrations to configure or maintain. This is a feature, not a limitation—one less thing to manage.

Trap #7 (Scale): Designed for small teams who want to track customers, not enterprises who need governance frameworks.

It's a Learning Platform

Think of simple-crm.org as CRM training wheels.

Use it to build the habit of:

Recording customer interactions
Tracking opportunities
Following up consistently
Reviewing your pipeline weekly

Once these habits are established, you'll know exactly what you need from a CRM. You might discover that simple-crm.org does everything you need. Or you might identify specific requirements that justify something more sophisticated.

Either way, you've learned what actually matters rather than what marketing materials claim matters.

The Total Cost is Zero (Time and Money)

No signup process means you can be using it in 30 seconds.
No configuration means you're not investing hours in setup.
No learning curve means your team adopts it immediately.
No subscription means you're not spending money on software you're not sure about.

The entire cost of trying simple-crm.org is: opening a web browser.

If it works for you, fantastic. You have a CRM that costs nothing and works forever.

If it doesn't work for you, you've lost nothing. No sunk cost. No commitment. Just close the browser tab.

Team Collaboration Without Compromise

When you're ready to collaborate, simple-crm.org offers encrypted sync. You set a PIN, share a link with your team, and everyone can access and update the same data—all whilst keeping it completely private.

Think of it like Signal for CRM: end-to-end encrypted, zero-knowledge architecture. Your data syncs across devices and team members, but it remains encrypted in storage. Only people with your share link and PIN can decrypt it.

No vendor can read your data. No third party has access. Just secure, private collaboration.

What Simple-CRM.org Isn't

Let's be honest about the limitations:

It's not for enterprises. If you need role-based permissions, audit trails, and compliance features, this isn't for you.

It's not for complex sales. If you have multi-stakeholder deals with custom workflows, you need something more sophisticated.

It's not integrated. If your workflow requires data flowing between multiple systems automatically, this won't work.

It's deliberately minimal. If you need advanced reporting, custom fields, or marketing automation, you'll outgrow this quickly.

But here's the thing: most small businesses don't need any of that.

Most small businesses need to:

Know who their customers are
Remember what was discussed
Track which deals need attention
Not forget to follow up
Collaborate with their team securely

Simple-crm.org does all of that perfectly.

Your Action Plan

Here's what to do right now:

1. Try Simple-CRM.org (5 minutes)

Go to simple-crm.org. Don't sign up (there's nothing to sign up for). Just open it.

Add one real customer. Record one real conversation. Create one real opportunity.

Did that feel natural or complicated?

2. Use It for Real (2 weeks)

For the next two weeks, use simple-crm.org for every customer interaction:

Before a call, review the contact's history
After a call, record what was discussed
When a deal progresses, update the opportunity stage
At the end of each day, check tomorrow's follow-ups

If you're working with a team, set up encrypted sync and share the link and PIN.

3. Evaluate Your Experience (30 minutes)

After two weeks, sit down and honestly assess:

Did you actually use it?
Did it solve your problem?
What's missing that you genuinely need?
What features did you ignore completely?

4. Decide Your Next Step

If simple-crm.org met your needs: Keep using it. You're done. You have a CRM that costs nothing and works forever.

If you identified specific gaps: Now you know what to look for. You understand CRM workflows. You know what features you actually need versus what sounds good in marketing. See our recommendations below.

If you didn't use it at all: The problem isn't the CRM. You probably don't need a CRM yet. Revisit this when the pain of disorganisation becomes unbearable.

When You're Ready for the Next Stage

You've used simple-crm.org for six months. You've built solid CRM habits. Your team actually uses it daily. But you've identified genuine needs that require more capability.

Here's what to consider next:

Recommended: CRMs Done Right

Salesmate.io — When You Need More Without the Bloat

Salesmate hits the sweet spot: more capable than simple-crm.org, but without enterprise complexity.

What you get:

Email integration and tracking
Automation for repetitive tasks
Built-in calling and texting
Custom fields and pipelines
Team performance analytics
Mobile apps

What you don't get:

Overwhelming feature bloat
Complicated pricing tiers
Mandatory consulting fees
Six-month implementation timelines

Best for: Small businesses that have outgrown basic CRMs but don't need (or want) enterprise complexity.

Pricing: Transparent and reasonable. Starts around £12 per user per month. No hidden fees, no surprise upgrades, no pricing gymnastics.

Zoho CRM — When You Want One Platform for Everything

If you're tired of juggling separate tools for email, calendar, invoicing, and accounting, Zoho One is worth considering.

What you get:

Full CRM capabilities
Email and calendar (Zoho Mail)
Invoicing and quotes (Zoho Invoice)
Accounting (Zoho Books)
Project management (Zoho Projects)
40+ other integrated applications

The key advantage: everything integrates by default because it's all built by the same company. No third-party integrations to configure or break.

Best for: Small businesses ready to consolidate multiple tools into one ecosystem. Particularly good if you're currently paying for separate email, CRM, and accounting software.

Pricing: Zoho One subscription gives you access to the entire suite. More cost-effective than paying for multiple separate tools.

Warning: It's a full ecosystem. There's a learning curve. But if you're committed to consolidation, it's one of the better options.

What to Avoid (Seriously)

These are the platforms that sound impressive but consistently disappoint small businesses:

HubSpot

Why it sounds good: "Free CRM!" and impressive marketing.

Why everyone regrets it:

The free tier is intentionally crippled to push you towards paid plans
Basic features are locked behind expensive upgrades
You'll constantly hit paywalls: "Upgrade to Professional to unlock this"
The pricing structure is designed to extract maximum revenue as you grow
You'll end up paying enterprise prices for features that should be standard

The pattern: Start free, get invested, hit limitations, pay increasingly expensive subscriptions.

Salesforce

Why it sounds good: Market leader. What the big companies use.

Why everyone regrets it:

Absurdly complex for small businesses
Requires dedicated administrators or consultants
Implementation takes months, not days
Constant "customisation" needs that require developers
Total cost of ownership is astronomical (licensing + implementation + maintenance + training)
Your team will hate using it

The reality: Salesforce is built for enterprises with complex sales organisations. Using it for a small business is like buying a Boeing 747 to commute to work.

Microsoft Dynamics 365

Why it sounds good: Microsoft brand. Integrates with Office.

Why everyone regrets it:

Enterprise complexity without enterprise resources
Pricing is convoluted and expensive
Requires significant technical expertise to configure
The Office integration isn't as seamless as marketing suggests
Over-engineered for what small businesses actually need
Support is geared towards enterprise customers

The pattern: Same as Salesforce—enterprise tool marketed to small businesses who discover too late that it's completely inappropriate for their needs.

The Common Thread

Notice what HubSpot, Salesforce, and Dynamics 365 have in common:

They're built for enterprises but marketed to everyone
Complexity masquerades as capability
The true cost is hidden (implementation, training, consultants, administrators)
Vendor lock-in is intentional
Everyone who uses them for small business regrets it

These aren't bad products for their intended audience. They're just terrible for small businesses.

If a CRM requires consultants, extensive training, or dedicated administrators, it's not for you. Full stop.

The Bigger Lesson

Here's what most small businesses get wrong about CRMs: they choose based on what the tool can do, not whether they'll actually use it.

A sophisticated CRM you don't use is worse than a simple CRM you use daily.

Simple-crm.org forces the question: will you actually use this?

There's no setup to delay adoption. No configuration to hide behind. No learning curve to blame.

You either use it or you don't. And that clarity is valuable.

If you use it, you'll build better customer relationships. If you don't, you'll learn that you need a different approach entirely.

Either outcome is better than paying for Salesforce whilst everyone keeps using spreadsheets.

Start Simple, Stay Simple (Until You Can't)

The best CRM for your small business isn't the one with the most features. It's the one you'll actually use tomorrow.

For most small businesses, that's something radically simple. Something that gets out of your way. Something that takes 30 seconds to start using.

Try simple-crm.org. Use it for two weeks. Let your actual experience guide your decision.

You might discover that simple is all you ever needed.

And when you genuinely outgrow it, you'll know exactly what you need instead—and you'll avoid the expensive mistakes that trap most small businesses.

Start using simple-crm.org now →

No signup. No credit card. No commitment. Just open and start tracking your customers.

When you need team collaboration, set a PIN and share the encrypted sync link. Your data stays private whilst your team stays coordinated.

Simple-crm.org is a free, privacy-first CRM that runs entirely in your browser. Your data syncs encrypted across devices and team members—only you hold the keys. No servers can read your data. No vendor has access. Perfect for small businesses who want to focus on customers, not software.

When Your CRM Becomes the Job: How Simple-crm.org Solves the Demand-Side Sales Problem

SimpleWBS — Sun, 25 Jan 2026 20:05:22 +0000

As developers, we’re taught to add features. More functionality equals more value, right? But what happens when the tool meant to help your sales team actually becomes their primary obstacle?

Traditional CRMs have a dirty secret: they’re designed with supply-side thinking. They’re built around what vendors believe sales teams need, not what causes sales teams to struggle. The result? Tools that create more work than they eliminate.

The Struggling Moment

Bob Moesta’s demand-side sales framework starts with a simple question: what is the struggling moment that causes someone to seek change?

For sales teams using traditional CRMs, the struggling moments are everywhere:

“We’re spending more time updating Salesforce than talking to customers.”

“Another licence renewal? We just hired two people and now we need to justify £400 per month to management.”

“What do I even put in this field? Why does it matter?”

“Our junior sales rep can’t access the CRM because we’re out of licences.”

These aren’t edge cases. They’re the daily reality of sales teams drowning in software that was supposed to help them sell.

The Forces Working Against Traditional CRMs

Moesta’s framework identifies four forces at play when someone considers making a change:

1. Push of the Situation (What’s Not Working)

Traditional CRMs transform sales work into data entry work. They demand fifty fields per contact. They require mandatory custom properties. They create workflows that need workflows to manage workflows.

The push isn’t “we need better reporting”. The push is “I joined this job to build relationships and close deals, and instead I’m filling in dropdown menus”.

2. Pull of the New Solution (What Could Be Better)

Sales teams don’t dream about advanced analytics dashboards. They dream about spending their Tuesday morning having conversations instead of updating opportunity stages.

The pull is simple: “What if the CRM just got out of my way?”

3. Anxiety of the New Solution (What Could Go Wrong)

Even when sales teams recognise the problem, anxiety holds them back:

“What if we lose our data?”
“What if it doesn’t integrate with our other tools?”
“What if it’s too simple and we miss important information?”
“What if management demands reports we can’t generate?”

4. Habits of the Present (The Comfort of the Known)

Perhaps most powerful: “We’ve always used Salesforce. Everyone knows how it works. Switching would be chaos.”

How simple-crm.org Addresses Each Force

Simple-crm.org’s design directly responds to these forces. Let’s examine the technical and product decisions that make this work.

Eliminating the Data Entry Burden

The entire data model consists of three entities:

Contacts (name, company, email, phone)
Notes (timestamped interactions)
Opportunities (deal tracking)

That’s it. No mandatory fields. No custom properties to configure. No dropdown menus requiring governance committees.

From a technical perspective, this is stored entirely in IndexedDB:

// Simplified schema
contacts: {
  id: string,
  name: string,
  company: string,
  email: string,
  phone: string
}

notes: {
  id: string,
  contactId: string,
  timestamp: Date,
  content: string
}

opportunities: {
  id: string,
  contactId: string,
  stage: string,
  value: number
}

No ORM complexity. No schema migrations. No database administrator. Just the essential information needed to track a sales relationship.

Removing Cost Anxiety Completely

The pricing model is radical: free. Not freemium. Not “free tier”. Just free.

No per-user fees means:

Hire someone on Monday, they’re in the CRM on Tuesday
No licence management overhead
No renewal negotiations
No tiered pricing that punishes growth

For developers, this eliminates an entire class of business logic. No payment processing. No subscription management. No usage tracking. No paywall code scattered throughout the application.

Privacy by Architecture

Traditional CRMs store your data on vendor servers. This creates legal concerns, compliance requirements, and trust issues.

Simple-crm.org takes a different approach: your data never leaves your browser.

// All data operations happen locally
const db = await openDB('simple-crm', 1, {
  upgrade(db) {
    db.createObjectStore('contacts');
    db.createObjectStore('notes');
    db.createObjectStore('opportunities');
  }
});

// No API calls to external servers
// No data synchronisation with vendor infrastructure
// Complete data sovereignty

The technical implementation is straightforward, but the implications are profound. There’s no server to breach. No third party with access to your customer data. No compliance questionnaires.

Want to sync between devices? You handle the encryption and syncing yourself. The tool doesn’t make assumptions about your security requirements.

Removing Implementation Friction

Traditional CRM implementations take months:

Requirements gathering
Configuration
Data migration
Customisation
Training
Rollout

Simple-crm.org’s implementation timeline: open the browser, start using it.

No installation. No configuration. No setup wizard. No onboarding process. Just a URL.

From a technical perspective:

// The entire "setup" process
localStorage.clear(); // Optional: start fresh
window.location.href = '/crm/';
// That's it. You're using the CRM.

This eliminates the implementation anxiety entirely. There’s no sunk cost. If it doesn’t work for your team after a week, you’ve lost nothing.

The Demand-Side Perspective on Features

Here’s where developers often struggle: isn’t this too simple? Where’s the advanced functionality?

Moesta’s framework teaches us that features don’t create demand. Struggling moments create demand.

Traditional CRM features exist because vendors are thinking supply-side: “What can we build that sounds impressive in a feature comparison matrix?”

Demand-side thinking asks: “What is preventing this sales representative from having more meaningful customer conversations today?”

The answers are never:

“We need better email campaign analytics”
“We need AI-powered lead scoring”
“We need deeper Salesforce integration”

The answers are usually:

“I need to quickly see who I spoke to last week”
“I need to remember what we discussed”
“I need to track which deals are close to closing”

Simple-crm.org provides exactly those capabilities. Nothing more. This isn’t a limitation; it’s a design decision informed by understanding the actual job to be done.

What This Means for Developers

If you’re building tools for people, the technical sophistication of your solution matters far less than whether it solves their struggling moments.

Consider these architectural decisions in simple-crm.org:

Browser-based storage instead of server infrastructure

Solves: Privacy concerns, hosting costs, scaling challenges
Trades off: Cross-device sync (users solve this themselves if needed)

Minimal data schema instead of flexible custom fields

Solves: Configuration complexity, training overhead, analysis paralysis
Trades off: Customisation options (most teams don’t need them)

No user authentication instead of robust identity management

Solves: Password resets, account recovery, session management
Trades off: Multi-user collaboration (acceptable for many small teams)

Each decision eliminates a struggling moment whilst accepting constraints that the target users don’t actually care about.

The Weekly Conversation Principle

Moesta emphasises that healthy sales processes are built on conversations, not complexity. The goal is weekly conversations about where deals are and what happens next.

Traditional CRMs make this conversation harder:

“Before we discuss deals, let me pull up the dashboard…”
“Wait, why is this opportunity showing in two different stages?”
“Can someone remind me what we put in the custom field ‘Lead Temperature’?”

Simple-crm.org makes this conversation trivial:

Open the tool
See your opportunities
Discuss next actions
Update status
Close the tool
Get back to selling

The technical implementation enables the human process rather than dictating it.

When Simple is Actually Better Engineering

There’s a tendency in software development to equate sophistication with quality. More features, more code, more architecture.

But sometimes the better engineering decision is radical simplification.

Simple-crm.org’s entire codebase likely fits in a few thousand lines. There’s no backend. No database server. No authentication service. No payment processor. No analytics pipeline.

Yet it solves the core struggling moments that cause sales teams to seek a CRM:

Where are my customer details?
What did we last discuss?
Which opportunities need attention?

Everything else is noise that creates new struggling moments.

The Real Competition

Here’s another insight from demand-side sales: you often compete with non-consumption.

Simple-crm.org doesn’t compete with Salesforce or HubSpot. It competes with:

Spreadsheets
Sticky notes
Email threads
Memory
Chaos

Sales teams using these approaches aren’t thinking “I need a sophisticated CRM platform with enterprise features”. They’re thinking “I need to stop losing track of conversations”.

That’s the struggling moment. That’s the job to be done.

A browser-based tool that stores contacts, notes, and opportunities solves that job perfectly. Adding invoice generation, marketing automation, and artificial intelligence doesn’t solve it better; it just adds complexity.

Lessons for Developers

Building tools through a demand-side lens changes everything:

Start with struggling moments, not feature lists
Interview people who recently adopted similar tools. What specific event triggered their search? What wasn’t working? What did they hope would change?

Identify the forces holding people back
What makes someone continue suffering with their current solution? Often it’s not because better options don’t exist, but because the anxiety and habits are stronger than the push and pull.

Solve for the job, not the category
Simple-crm.org isn’t trying to be a comprehensive CRM platform. It’s trying to help sales teams have more conversations and fewer data entry sessions. That’s a different job.

Embrace constraints
Every feature you don’t build is one less thing to maintain, one less thing to document, one less thing users need to understand. Constraints create focus.

Make switching trivial
The biggest anxiety in adopting new tools is the switching cost. Browser-based. No installation. No data migration. No sunk cost. This eliminates the anxiety of commitment.

The Technical Beauty of Simplification

From a technical perspective, simple-crm.org is elegant precisely because of what it doesn’t do:

No user authentication? No password hashing, session management, or account recovery flows
No server-side storage? No database optimisation, backup strategies, or scaling concerns
No payment processing? No PCI compliance, subscription management, or billing logic
No custom fields? No schema migration system or configuration management

Each omission isn’t a missing feature. It’s a deliberate trade-off that eliminates complexity whilst preserving the core value proposition.

The result is a tool that:

Loads instantly (no server round trips)
Scales infinitely (it’s just IndexedDB)
Costs nothing to operate (no infrastructure)
Respects privacy completely (data never leaves the browser)
Requires zero maintenance (no servers to patch)

This is engineering in service of the struggling moment.

Conclusion: Building for Demand, Not Supply

The traditional approach to building tools is supply-side thinking:

Research what competitors offer
Build similar features (but better)
Add unique capabilities to differentiate
Market based on feature comparisons
Sell based on specifications

The demand-side approach is fundamentally different:

Understand the struggling moments
Identify the forces at play
Design for the job to be done
Eliminate anxieties
Help people make progress

Simple-crm.org exemplifies demand-side thinking in product design. It doesn’t try to be the most feature-rich CRM. It tries to be the CRM that gets out of your way so you can focus on relationships.

For developers, this is a valuable lesson: the best technical solution isn’t always the most sophisticated one. Sometimes it’s the one that deeply understands the struggling moment and eliminates it with radical simplicity.

Your sales team doesn’t want to manage a CRM. They want to have conversations, build relationships, and close deals. Everything else is just in the way.

Perhaps that’s the most important technical decision you can make: knowing what not to build.

Simple-crm.org is a free, open-source CRM that runs entirely in your browser. No servers. No tracking. No complexity. Just the essentials for sales teams who want to spend their time selling, not managing software.

Work Breakdown Structures: Why They’re More Critical Than Ever in the AI Era

SimpleWBS — Tue, 20 Jan 2026 14:06:01 +0000

In the rapidly evolving landscape of data and AI systems, the complexity of modern projects has reached unprecedented levels. We’re no longer building isolated applications or simple databases — we’re constructing intricate ecosystems where people, data, technology, and AI models must work in concert whilst simultaneously managing traditional business-as-usual operations. This is precisely where Work Breakdown Structures (WBS) have transformed from a nice-to-have project management tool into an absolute necessity.

The New Complexity: Why WBS Matters More in AI and Data Worlds

Traditional software development could often get away with linear thinking. Build a feature, test it, ship it. But AI and data systems demand something fundamentally different: systems thinking. These projects require us to:

Break down highly complex, interdependent systems into manageable components
Navigate the integration of disparate technologies that must speak to one another
Manage data silos that need to be connected, transformed, and governed
Align multiple stakeholder groups who each see the system through different lenses
Deliver transformational change whilst keeping existing operations running smoothly

Consider a typical AI implementation project. You’re not just building software — you’re orchestrating a symphony of data pipelines, model training workflows, API integrations, governance frameworks, and organisational change management. Without a clear decomposition of this work, teams drown in the complexity. WBS provides the structured thinking necessary to make the overwhelming become manageable.

The beauty of WBS in this context is that it forces you to confront the true scope of what you’re building. When you break down “implement customer churn prediction model” into its constituent parts, you quickly discover you need data engineering, data quality assessment, feature engineering, model development, model deployment, API development, frontend integration, monitoring dashboards, documentation, training materials, and change management activities. Each of these decomposes further. This decomposition isn’t bureaucracy — it’s clarity.

The Four Pillars: People, Process, Data, and Technology

Successfully implementing WBS in AI and data projects requires balancing four critical elements:

People: The Skills Gap Nobody Talks About

Here’s an uncomfortable truth: most project managers haven’t been trained to actually use WBS tools effectively. They’ve heard of WBS in their PMP certification course, perhaps even created one in an exam, but they’ve never genuinely practised the art of decomposition with real stakeholders.

Many find the process overwhelming. Where do you start? How granular should you go? What if you miss something critical? Others fail to see the advantage, viewing WBS creation as bureaucratic overhead rather than a thinking tool that creates shared understanding.

The result is that some teams attempt WBS half-heartedly, creating superficial breakdowns that don’t actually help. Others skip it entirely, then wonder why their AI project has spiralled into chaos six months in. The issue isn’t that WBS doesn’t work — it’s that people haven’t developed the muscle memory to do it well.

Process: Busting the Agile Mythology

There’s a persistent myth in modern software development that agile methodologies and self-organising teams have made upfront planning obsolete. The story goes: just create a backlog, let the team self-organise, and magic happens.

This is bollocks.

Self-organising teams need structure to self-organise within. They need to understand the larger system they’re building, how their work connects to others’ work, and what the critical dependencies are. WBS provides exactly this structure.

WBS doesn’t contradict agile principles — it complements them. You can absolutely decompose your work upfront whilst remaining flexible about how you execute. In fact, a good WBS makes agile execution more effective because everyone understands the terrain they’re navigating.

Here’s where WBS becomes particularly powerful: it drives trust through alignment. When the entire team participates in breaking down the work, when everyone sees how their piece fits into the whole, trust naturally emerges. People stop second-guessing whether others understand the dependencies. They stop duplicating effort. They start coordinating naturally because they share a mental model of the project.

But — and this is crucial — WBS is a hypothesis, not a contract carved in stone. It’s your best current thinking about how the work decomposes. As you progress, you’ll discover things. Parts of the system will reveal additional complexity. New requirements will emerge. That’s not WBS failing — that’s WBS working. It encourages teams to decompose further as they learn, to add new branches as understanding deepens, to refactor the structure as reality teaches them.

This requires a specific rhythm: asynchronous status updates against the WBS structure, with one synchronous check-in per week where the team reviews progress, discusses blockers, and decides whether the decomposition itself needs to evolve. This cadence provides structure without suffocation.

Data: The Hidden Dimension

Data work decomposes differently than traditional development work. A WBS for a data pipeline project needs to capture:

Data source identification and access negotiation
Data quality assessment and profiling
Schema mapping and transformation logic
Data validation rules development
Pipeline orchestration and scheduling
Monitoring and alerting setup
Data cataloguing and documentation

Each of these contains further decomposition. Data quality assessment, for instance, might break into completeness checks, accuracy validation, consistency verification, timeliness monitoring, and uniqueness constraints. You can’t see this complexity without decomposition, and you certainly can’t plan for it.

Technology: Integration Complexity

AI and data systems are rarely monolithic. They’re assemblages of technologies that must integrate seamlessly:

Cloud infrastructure (compute, storage, networking)
Data platforms (warehouses, lakes, lakehouses)
Orchestration tools (Airflow, Dagster, Prefect)
ML platforms (Vertex AI, SageMaker, Azure ML)
Monitoring and observability systems
API gateways and service meshes
Frontend applications
Security and governance tools

Each technology integration represents work that must be broken down. WBS forces you to think through these integrations systematically rather than discovering them as painful surprises mid-project.

The Tool Trap: Why Most WBS Software Misses the Point

Search online for “WBS tools” and you’ll drown in options. Design platforms like Canva promise pretty diagrams. Flowchart tools like LucidChart offer visual decomposition. Atlassian (makers of Jira) promotes Kanban as a WBS solution. Monday, Asana, and Wrike all tout fancy features for work breakdown.

The problem? They’ve made WBS a secondary feature buried under layers of other functionality. To use WBS in these platforms, you navigate through menus, enable premium features, learn platform-specific quirks, and spend more time wrestling with the tool than actually thinking about your work breakdown.

Many charge extra for WBS capabilities, treating it as a premium add-on rather than a fundamental project management tool. The cognitive overhead is immense — you need training just to use the software, let alone to do good WBS.

This is where simpler often wins. Excel remains surprisingly popular for WBS, and for good reason. It’s familiar, flexible, and doesn’t impose artificial constraints. You can decompose your work however makes sense for your project. Vertex42 and Smartsheet offer excellent Excel templates that provide just enough structure without becoming restrictive.

Sometimes a shared Google Sheet or Excel file is genuinely sufficient. No fancy software required. Just a clear hierarchical structure that everyone can access, update, and reference.

But there’s also a place for purpose-built tools that prioritise doing WBS over everything else. Tools like simpleWBS.com take a refreshingly different approach: fully private by design (think Signal or Proton for project management), no sign-up required, just immediate utility. The philosophy is simple — get people using it and get them focused on doing WBS itself, not everything else that slows things down.

You create your WBS and update it as you go. That’s it. No feature bloat, no premium tiers, no learning curve. Just the essential functionality you need to break down complex work into manageable pieces.

Making WBS Work for Your AI and Data Projects

The key to successful WBS in AI and data projects is starting with the right mindset:

Start with outcomes, not activities. Don’t begin by listing tasks. Begin by articulating what needs to exist at the end of the project. Then decompose backwards from those deliverables.

Embrace hierarchical thinking. Your WBS should have clear levels. Level 1 might be major system components. Level 2 breaks each component into subsystems. Level 3 decomposes subsystems into deliverables. Level 4 identifies the work packages needed to create each deliverable.

Involve the whole team. WBS creation shouldn’t be a solitary exercise by the project manager. The best decompositions emerge from collaborative sessions where technical experts, data scientists, engineers, and business stakeholders all contribute their perspectives.

Decompose until you reach estimable units. Keep breaking down until each work package is small enough that someone can reasonably estimate the effort required. This is usually somewhere between a few days and two weeks of work.

Acknowledge uncertainty explicitly. Some parts of your AI project will be more uncertain than others. Research spikes, proof-of-concept work, and exploratory data analysis all have inherent uncertainty. Mark these clearly in your WBS rather than pretending you can predict their outcomes with precision.

Review and refactor regularly. Your initial WBS is your hypothesis. Test it against reality. When you discover you’ve missed something or decomposed incorrectly, update the structure. This isn’t failure — it’s learning.

Use the WBS for communication, not just planning. A good WBS becomes the shared language of your project. When someone asks about progress, you can point to specific work packages. When dependencies emerge, you can trace them through the structure. When scope discussions arise, you can anchor the conversation in the decomposed work.

The Bottom Line

In the AI and data era, where we’re building systems of unprecedented complexity whilst maintaining existing operations, Work Breakdown Structures aren’t optional — they’re essential. They’re the thinking tool that helps us manage complexity, align teams, drive trust, and maintain clarity as projects evolve.

The challenge isn’t whether to use WBS. The challenge is developing the capability to do it well and choosing tools that support the work rather than complicating it.

Start simple. Decompose your work. Involve your team. Update as you learn. Whether you use Excel, a shared Google Sheet, or a purpose-built tool like simpleWBS, what matters is that you’re breaking down complexity into manageable pieces and creating shared understanding across your team.

Because in the end, the best AI models and data systems aren’t built by teams who avoid planning — they’re built by teams who plan intelligently, adapt continuously, and maintain clarity through complexity. WBS is how you do that.

Demystifying the Work Breakdown Structure (WBS): A Practical Guide for Technical Projects

SimpleWBS — Thu, 15 Jan 2026 07:07:15 +0000

Introduction: From Project Chaos to Structured Clarity

For anyone in a technical or software project, the landscape is often a chaotic mix of shifting requirements from product, urgent bug fixes from QA, and gold-plating from the dev team. In this environment, the Work Breakdown Structure (WBS) emerges not as bureaucratic overhead, but as a fundamental tool for imposing order. It is the strategic blueprint that defines the complete scope of your project, preventing the dreaded "if it's not written down, it doesn't exist" problem and creating a single, shared understanding of all the work that needs to be done. A well-crafted WBS is the first step from a vague idea to a concrete, manageable plan.

This article will deconstruct the WBS, moving beyond abstract definitions to provide a practical, step-by-step guide to creating one. We will explore its underlying philosophies, detail a framework for building it, and explain why it is the foundational artifact for successful project planning, scheduling, and execution.

What is a WBS, Really? The Foundation of Project Scope

At its core, the Work Breakdown Structure is the primary tool for articulating a project's scope in a structured, hierarchical manner. It is a methodical process that breaks down the entirety of a project's work into smaller, more manageable components. This decomposition ensures that the project team has a comprehensive and detailed view of everything that needs to be accomplished, leaving no room for ambiguity.

The WBS is formally defined as a hierarchical decomposition of the total scope of work to be carried out by the project team. If a piece of work, a feature, or a deliverable is not on the WBS, it is officially outside the scope of the project. This makes the WBS the ultimate authority on what will and will not get done.

The structure itself is simple yet powerful. It begins at the top with the entire project, representing the total work. This is then broken down into a number of substantial chunks, which are in turn broken down into their principal components. This decomposition continues until you reach the lowest level, which consists of unique, fully defined deliverables or components—the fundamental building blocks of the project.

This structured approach forms the basis for all subsequent planning. Before you can determine dependencies, estimate timelines, or create a budget, you must first know what you are building. The WBS answers that question with absolute clarity, setting the stage for the two primary philosophical approaches used to build it.

The Two WBS Philosophies: Activities (UK) vs. Deliverables (US)

Globally, project managers have adopted two recognized approaches to structuring a WBS. I often see teams get stuck here, but the choice is simpler than it seems. The key is not which is 'better,' but which serves your project's needs—and that you stick to your choice. One method focuses on the actions to be performed, while the other focuses on the products to be created.

Project management expert Mike Clayton notes that while neither approach is inherently better or worse, the deliverable-focused approach is more common globally and is often considered more rigorous, particularly for technical projects. For this reason, this guide will focus on the deliverable-based method.

Interestingly, Clayton expresses a preference for the UK approach, reasoning that "it's a work breakdown structure," so it makes sense to break down the work. However, his ultimate and most critical advice is to adopt one approach and do not mix the two. Attempting to combine activities and deliverables in the same WBS can lead to confusion and breakdown in planning.

With that in mind, let's transition from the theoretical to the practical and walk through the step-by-step process of building a robust, deliverable-based WBS.

How to Build a Deliverable-Based WBS: A Step-by-Step Framework

A deliverable-based WBS requires a systematic, level-by-level decomposition to ensure nothing is missed. Since the WBS represents the complete scope of the project, this methodical approach is crucial—if it isn't on the WBS, it won't get done.

Step 1: Define the Levels of Decomposition

Level 0: The Project This is the top of the hierarchy and represents the totality of the entire deliverable set. It is the project itself, viewed as one single, ultimate product.
Level 1: The "Key Line" This unique concept serves as the primary organizing principle for the entire WBS. The key line sets up the main categories for decomposition. This could be organized by:
- Project Phases: (e.g., Design, Development, Testing, Deployment)
- Work Streams: (e.g., Technology, People, Processes)
- Geographic Divisions: (e.g., North America, Europe, Asia)
Level 2: Major Deliverables Within each key line element, you identify the main deliverables. These can be end deliverables (the final products the project was created to build) or major interim deliverables (products needed along the way).
Level 3: Sub-Components & Interim Deliverables Here, you break down the major deliverables into their smaller components. This level will contain a large number of interim deliverables, which are things created to help achieve the end deliverables. Examples include prototypes, test scripts, project plans, and stakeholder lists.
Level 4 and Below: Granular Breakdown Decomposition continues until each deliverable is a unique, fully constrained item. It is perfectly acceptable for the WBS to have different depths in different areas; the structure should be determined by the work itself, not by an arbitrary need for neatness.

Step 2: Don't Forget Project Management

As Mike Clayton emphasizes, a common and critical mistake is forgetting to include the work of managing the project itself within the WBS. To avoid this, create a dedicated key line work stream for "Project Management" or "Project Integration." This ensures all management activities—such as creating plans, stakeholder lists, and progress reports—are captured as formal interim deliverables. This simple step makes certain that management work is properly resourced, budgeted, and accounted for.

By definition, everything in this workstream—the plans, reports, and stakeholder lists—is an interim deliverable created to support the successful creation of the project's end deliverables.

Step 3: Document and Number the WBS

Once the hierarchy is defined, it needs to be documented formally.

WBS Indexing System: Each item is assigned a unique index number to reflect its position in the hierarchy. The key line items are numbered 1, 2, 3, etc. Sub-deliverables under the first item would be numbered 1.1, 1.2, 1.3, and so on. This logical structure is simple to create in a standard word processor.
The WBS Dictionary: For more rigorous projects, you should create a WBS Dictionary. This is more than just a list; it's a formal document that accompanies the WBS and provides critical details for each item. For every deliverable, the dictionary can include its reference number, a detailed description, quality standards, specifications, required resources, estimated costs, and durations.

With a fully documented list of all project deliverables, the next step is to transform this comprehensive "what" into an actionable "how."

From "What" to "How": Activating Your WBS for Planning

A deliverable-based WBS is an exceptionally powerful scoping tool, but its true value is unlocked when it is converted into a plan of action. This conversion process bridges the gap between defining the deliverables and creating the schedule and budget needed to produce them.

Create Work Packages The first step is to group related deliverables that should be created together into logical "work packages." While one work package often corresponds to one deliverable, this is not always the case. This task is typically delegated to work stream leaders who have deep expertise in their respective areas.
Decompose into Activities Next, each work package is broken down into the individual tasks and activities required to produce the associated deliverables. This is the point where the focus shifts from the nouns (deliverables) to the verbs (activities).
Plan, Schedule, and Budget This final sequence of activities becomes the foundation for all further planning. You can now estimate the duration and effort for each task, allocate resources, identify dependencies between activities, and estimate costs. The result is a full project schedule (like a Gantt chart) and a detailed budget, all derived directly from the WBS. This granular breakdown is also where project risks become tangible. A poorly defined deliverable on the WBS is a clear risk to scope and quality. Likewise, the WBS Dictionary is the foundation for quality management, as it links deliverables to specific standards and specifications.
Hallmarks of a High-Quality WBS

Following a few key principles elevates a WBS from a simple list to a robust and reliable project management tool that can withstand the pressures of a real-world project.

Clear Labeling Each item in the WBS must have a clear and unambiguous description. There should be no doubt about what each deliverable is.
The MECE Principle A high-quality WBS must be "Mutually Exclusive, Collectively Exhaustive."
- Mutually Exclusive: There are no overlaps. The same deliverable or work does not appear in multiple places within the structure.
- Collectively Exhaustive: The WBS represents 100% of the project scope. All sub-deliverables at a lower level must fully add up to the parent deliverable above them.
Adaptability in Modern Projects For hybrid or evolving projects, the WBS should not be seen as static. It is a living document that can and should be updated as new requirements are discovered or as the project evolves. It is not always appropriate to try to complete the entire WBS at the very start of a project.
Stakeholder Review Don't treat this as a formality. In my experience, this review is one of the most valuable risk-reduction activities you can perform early in a project. It uncovers hidden assumptions before they become costly problems. The final, crucial step is to present the WBS to the project sponsor, client, and other key stakeholders for feedback and refinement, ensuring universal buy-in before the WBS is finalized and becomes the official scope baseline.

Conclusion: The WBS as Your Project's Central Nervous System

The Work Breakdown Structure is far more than a single-purpose scoping document; it is a central, multi-functional artifact that acts as the nervous system for the entire project. When constructed with care, it connects and integrates nearly every other aspect of project management.

It begins as a scoping tool, which provides the foundation for planning and scheduling. This detailed plan allows for precise resource allocation and highlights areas of uncertainty, making it a powerful basis for risk identification. As the project progresses, its hierarchical structure makes it an indispensable communication and reporting tool for stakeholders. Finally, by linking deliverables to standards in the WBS Dictionary, it becomes a cornerstone of governance and quality management, ensuring the final product meets expectations.

On your next project, don't just manage tasks—structure the work. Build a proper WBS. The clarity and control you gain will be the foundation of your success.

——
To reduce the friction of teams doing the WBS I have created a project called SimpleWBS.com > give it a go and let me know what you think in the comments . Happy planning.

The Lost Art of Knowing What You’re Actually Building

SimpleWBS — Wed, 14 Jan 2026 10:42:01 +0000

In 1965, NASA used a Work Breakdown Structure (WBS) to land humans on the moon. Not Gantt charts. Not Jira. A simple tree of deliverables: “Command Module,” “Lunar Ascent Engine,” “Reentry Heat Shield.” Each leaf was a tangible output—nothing vague, nothing optional.

Fast-forward to 2026. Search “Work Breakdown Structure” and you’ll get Asana, Wrike, or ClickUp—with $20/month/user plans, onboarding flows, and 50 features you’ll never use. All to solve a problem that should take five minutes: What are we actually building?

Somewhere along the way, we forgot that scoping isn’t bureaucracy—it’s precision engineering for your project. And it’s not just for PMOs. It’s for:

The solo dev scoping a weekend SaaS idea
The data scientist defining what “model ready for production” really means
The freelancer avoiding scope creep on client work

Most “productivity” tools fail here because they track tasks, not outcomes. “Write API” is an activity. “Authenticated user API with rate limiting” is a deliverable. Only the latter can be validated, shared, or signed off on.

That’s why I built SimpleWBS.com:

Free, no sign-up, works in-browser
Pure hierarchical breakdown
Export as a scoping contract (for clients, teammates, or your future self)

Think of it as personal scope hygiene. Before you open your IDE, ask: “What must exist for this to be done?” Then sketch it. If you can’t break it into concrete pieces, you’re not ready to build.

I’ve used it to:

Scope a client data migration (caught missing validation step)
Plan a side-project launch (realized I needed terms of service)
Break down a machine learning pipeline (separated training infra from inference API)

It’s not about process. It’s about not wasting your most precious resource: your time.

Try it next time you start something new: https://simplewbs.com

And if you do—reply with your WBS. I’d love to see how builders like you define “done.”

Forem: SimpleWBS

MCP is not an open standard play, it is a platform consolidation play

Your Laptop Isn't Old. Windows Just Got Heavy.

Battle of the AI Coding Agents: Claude Code vs OpenAI Codex vs Qwen Coder (February 2026)

Table of Contents

What Changed in February 2026

The Three Contenders

Claude Code Web (claude.ai/code)

OpenAI Codex App

Qwen Coder (coder.qwen.ai)

The Qwen Coder Bombshell

What Qwen Coder Does

The Kicker

Feature Comparison

Pricing Reality Check

Claude Code Web

OpenAI Codex App

Qwen Coder

The Math

Performance Benchmarks

SWE-Bench Verified (Real GitHub Issues)

Context & Efficiency

Real-World Performance

Real-World Use Cases

When to Choose Claude Code Web

When to Choose OpenAI Codex App

When to Choose Qwen Coder

The Qwen Coder Advantage

1. Open-Source Transparency

2. Self-Hosting

3. No Vendor Lock-In

4. Community-Driven Development

5. Platform Freedom

The Business Case for Qwen Coder

For Startups

For Agencies

For Enterprises

The Catch (There's Always a Catch)

What Qwen Coder Trades Off

Is It Worth It?

How to Get Started with Qwen Coder

Quick Start (5 minutes)

Advanced: Self-Hosting

The Future (Next 6 Months)

Predictions

The Real Winner

The Verdict

Overall Rankings

My Personal Recommendation

The Bigger Picture

What Qwen Coder Means for AI Development

The Pressure on Claude & OpenAI

Closing Thoughts

Resources

Build Your AI Analyst and Start Having Conversations with Your Structured Data

Why ClickHouse Is the Ideal Backend for AI Analytics

The Medallion Architecture: Structuring Data for AI

The Tools We’ll Use

Choosing Your LLM: Premium vs Budget

Setting Up Your Environment

Configuring Docker Compose

Setting Up Your API Key

Configuring LibreChat to Use the MCP Server

Launching the Stack

Building Your Analyst Agent (The Critical Step)

Using AI to Write Your Agent Instructions

Example: A New York Taxi Analyst

Connecting the Agent to ClickHouse

Using Your AI Analyst

Adapting the Instructions for Your Data

Pointing at Your Own Data

Beyond Querying

The Bigger Picture

Why most organisations should evaluate ClickHouse Cloud + Power BI before committing to Fabric, Databricks, or Snowflake

The Uncomfortable Truth About Your Data Platform

The Modern Data Stack Has Become Absurdly Complex

The Alternative: Elegant Simplicity

Why ClickHouse Changes the Economics

Raw Performance

Cost Structure