The bottleneck wasn't code. It was never code.
I Built an Enterprise M365 Migration Tool Over a Few Evenings. That Should Excite You — and Worry You
Last night I set out to build something that normally arrives as an invoice.
If your organisation has ever moved mailboxes from one Microsoft 365 tenant to another — the unglamorous, high-stakes plumbing of every merger, acquisition or rebrand — you’ll know the drill. You buy a commercial migration tool, and you pay per user. The premium ones can run up to around £30 a head. For a mid-sized company mid-merger, that’s tens of thousands of pounds before a single email has moved.
So I built my own. It’s called Dolop, it’s open source, and I wrote it by describing what I wanted, in plain English, to Anthropic’s new Claude Fable 5 model sitting inside my editor.
Dolop migrates the full Microsoft 365 stack between tenants — mail with full folder hierarchy and read state, calendars, contacts, tasks, OneDrive, inbox rules, mailbox settings — with incremental delta passes, item-level error reporting that never stops a whole mailbox over one bad item, and a live progress dashboard. It runs entirely on Cloudflare’s developer platform — no servers, no virtual machines, no agents — which means you self-host it on your own account for pennies rather than a per-user licence.
I want to be honest about what that means, because it means two very different things at once.
The new world is real, and it’s bigger than coders
For most of computing history, the bottleneck between having an idea and having working software was the ability to write code. That bottleneck is dissolving in front of us.
“Vibecoding” — building software by conversing with an AI rather than hand-writing every line — has gone from novelty to genuinely capable in an astonishingly short time. The latest models don’t just autocomplete a function; they hold an entire architecture in their head, reason about trade-offs, write the tests, and explain their decisions back to you.
The implication is profound and it isn’t really about programmers. It’s about the domain expert who has always known exactly what their industry needs but could never get a developer to build it. The operations lead who understands a migration better than any vendor. The small business owner quietly paying a £30-per-user tax on a problem they could now solve themselves.
That is a genuine redistribution of capability. The person closest to the problem can now build the solution. I think we badly underestimate how many good, specific, unglamorous tools simply never got built because the people who needed them couldn’t write the code — and how many of those are about to exist.
But here’s what doesn’t show up in the demo videos
Now the part I can’t, in good conscience, leave out — because I’ve spent twenty years in cybersecurity and I can already see the wave coming.
Vibecoding removes the barrier to producing code. It does not remove the barrier to producing safe, maintainable, trustworthy software. Those are different things, and the gap between them is exactly where the next few years of security incidents are going to live.
An AI will cheerfully generate something that works perfectly in the demo and quietly hardcodes a secret, ships with no access control, trusts user input it should never trust, and has no way to be rolled back when it breaks. It works on your screen. That is not the same as it being right.
The people most exposed are, through no fault of their own, the ones who’ve never had to learn the invisible disciplines that experienced engineers treat as oxygen:
Version control. Not “I saved a copy called final_v3,” but real history — the ability to see what changed, when, and why, to branch safely, and to roll back the moment something goes wrong. Without it, every change is a gamble you can’t undo.
The software delivery lifecycle. Testing before you ship. A pipeline that catches mistakes automatically. A staging environment that isn’t your customers. Code review, even if the reviewer is also an AI. The boring scaffolding that turns “it ran once” into “it runs reliably.”
Secure-by-design. Treating secrets as secrets. Granting the least access necessary, never the most convenient. Encrypting sensitive data at rest. Assuming someone hostile will eventually poke at your app — because they will — and building for that on day one, not after the breach.
A migration tool is the perfect illustration of the stakes. Dolop handles real people’s mailboxes and the keys to two corporate tenants. Get the security wrong and you haven’t built a clever app — you’ve built a single point of catastrophic failure for an entire organisation’s email.
The discipline is what turns a demo into something you can trust
This is the part I’d ask people to sit with, because it’s the whole point.
The reason I’m comfortable putting Dolop into the world isn’t that an AI wrote it quickly. It’s that I made the AI build it the way a security engineer would insist. Tenant secrets are encrypted with AES-256-GCM and the key lives nowhere but a protected runtime secret. Access to Microsoft Graph is app-only — it never collects a user’s credentials. Operator passwords are properly hashed, sessions are hardened, logins are rate-limited. There’s a CI/CD pipeline, a test suite, a documented security policy and a place to report vulnerabilities.
And — this matters — the project is honestly labelled as beta, with a published “here’s what it can’t do yet” document, because telling people the truth about maturity is part of secure-by-design.
None of that came from the speed. It came from knowing to ask for it. The AI was an extraordinary force multiplier on top of judgement I already had. It was not a substitute for the judgement.
That’s the real headline, and it’s good news for almost everyone: the future doesn’t belong to the people who can prompt fastest. It belongs to the people who can prompt fast and know what “good” looks like. The opportunity isn’t “developers are obsolete.” It’s “domain expertise plus AI plus a bit of engineering discipline is now a superpower — and that discipline is learnable.”
If you’re building with these tools, you don’t need a computer science degree. You do need to learn the handful of principles above — version control, a delivery process, secure-by-design — before you put anything that touches real data in front of real people. That small investment is the difference between joining the wave and becoming a cautionary tale in someone else’s security newsletter.
I’ll be writing more about exactly how I built Dolop — the architecture decisions, the security model, and how to vibecode responsibly — over on Medium, alongside my wider work on AI, security and building things that last.
And if you want to see the tool itself, it’s open source and live:
Try it:
https://dolop.samuel-1e5.workers.dev
The code: https://github.com/LordPixma/dolop
If you’ve started building with AI — or you’re nervous about your team doing it without guardrails — I’d genuinely like to hear where you’ve landed. That conversation is the one worth having right now.