business

Verdict

Submitted 5/18/2026, 12:10:33 PM · Completed 5/18/2026, 12:12:11 PM

6.5
pivot
The idea

Built a free OneDrive/SharePoint drive-letter sync client with thumbnails, real cloud quota in Explorer, local-first, and no telemetry

Pain point
Current OneDrive sync clients lack true drive-letter mapping, centralized configuration, accurate cloud quota display, and local-first file handling.
Who has this problem
Schools, small businesses, and charities with 20-500 users managing M365 estates
Contradiction (TRIZ)
Need for accurate cloud quota display conflicts with real-time data synchronization requirements
Ideal final result
A cloud storage system that provides real-time quota information without requiring constant synchronization
Suggested solution
Develop a cloud storage synchronization tool that uses asynchronous data fetching for quota information while maintaining real-time file access through drive-letter mapping
Show original source text →
Disclosure first because the mods will catch it: I wrote this, MIT licence, link at the bottom, no upsell. School IT background, but the use case generalises to any small-to-mid-size M365 estate (schools, small businesses, charities, roughly 20-500 users) wanting proper drive-letter mapping for OneDrive and SharePoint where the OneDrive sync client isn't the right shape. Wanted a drive-letter sync setup with a few specific things: image thumbnails that actually render in Explorer for cloud-mounted files (most existing tools don't), accurate cloud-quota numbers in the drive-properties dialog (refreshed from Graph), a local-first design where files always exist as real NTFS first and sync to the cloud in the background (rather than presenting the cloud as a virtual filesystem), one config.json that deploys to the whole estate, and zero telemetry. Didn't find one off the shelf with all of those, and was also curious whether I could build it myself. Side project that turned into a real thing. It's called OneSync. .NET 8, Dokan for the FS bridge, MSAL + Graph SDK for auth and sync. Self-contained exe, Intune-deployable. Highlights: \- True drive letters via Dokan (not subst, not "OneDrive sidebar entry under TenantName - LibraryName") \- One config.json deploys to the whole estate. OneSync probes Graph at startup and silently skips drives the signed-in user can't access, so different roles (staff/students, sales/finance/ops, whatever your split is) share one config \- Accurate cloud quota shown in Explorer drive properties (refreshed from Graph) \- Image thumbnails (JPG/PNG/HEIC) render like a local disk \- LRU eviction below a free-space threshold so shared/hot-desk laptops don't fill up over time \- Office desktop AutoSave + co-auth on docx/xlsx/pptx (via file-association redirect to ms-word:ofe with the direct SharePoint URL, slightly cursed but works) \- Zero telemetry. No analytics, no licence-server pings, no anonymous usage stats. Only outbound calls are to graph.microsoft.com and login.microsoftonline.com. One war story while I'm here: Dokan's FindFiles callback enters synchronously from the kernel, so anything that blocks in there hangs Explorer. The first version called Graph synchronously to enumerate folders via .GetAwaiter().GetResult() (I know, I know). Worked fine until Graph went into 429 cooldown, at which point opening a folder hung Explorer for ten minutes while the cooldown lifted. I learned a lot in those ten minutes about how Explorer's UI thread feels under those conditions. Current behaviour: if Graph is in cooldown, folder browse returns immediately with on-disk placeholders and file hydration kicks off via Task.Run. Obvious in hindsight. Repo: https://github.com/madeyouclickstudio/OneSync (DEPLOYMENT.md covers silent install switches and Intune detection rules) Honest caveat: I'm running it with a handful of pilot users, not a full estate. The fleet-scale stuff is engineered for it but not battle-tested. Anyone deploying this to thousands of users is a pioneer at their own risk. Bug reports very welcome. Yes I know about the OneDrive sync client. We tried it. The reasons it didn't fit (no real drive letters, every library is its own sidebar entry, no way to cap disk usage on shared laptops, no central deployment for which libraries each user sees) are exactly the reasons this exists. If those don't bother your fleet, OneDrive sync client is fine and you should ignore me. Tell me what's wrong with it.
TRIZ inventive level: 3/5· Principles: asymmetry, parameter changes
Synthesis verdict
**Pivot**: OneSync has a strong technical foundation and solves a real problem for small-to-mid-size M365 estates. However, its monetization strategy and scalability are concerns that need to be addressed. The product's unique features, such as true drive letters and accurate quota reporting, differentiate it from existing solutions. Nevertheless, the reliance on Dokan and Graph API, as well as the lack of a clear pricing path, pose significant risks. To move forward, the product needs to be repositioned to capture value from organizations and mitigate the risks associated with scalability and external dependencies.

Strengths

  • Unique features that solve a real problem for small-to-mid-size M365 estates
  • Strong technical foundation using .NET 8, Dokan, and MSAL/Graph
  • Local-first design that ensures files exist as real NTFS files before syncing
  • Zero telemetry, which is a principled stance that may appeal to certain customers
  • Intune-friendly deployment that reduces friction

Weaknesses

  • Unclear monetization strategy, with a current MIT license that leaves money on the table
  • Unproven scalability, with a lack of testing at larger estates
  • Dependency on external APIs (Graph API and Dokan) that pose platform risk
  • Lack of built-in compliance tools for data protection and user consent management
  • Potential for high churn due to untested nature at scale

Best angle

OneSync should be repositioned as a paid solution with a clear pricing path, targeting organizations that value its unique features and are willing to pay for a vendor-backed solution, while also addressing scalability and external dependency concerns.

Panel verdicts

Viability

meta/llama-4-maverick-17b-128e-instruct

8.0

The technical feasibility of OneSync is high, but the risks associated with large-scale deployment need to be carefully managed.

The idea of OneSync is technically feasible and has been partially implemented by the creator. The use of .NET 8, Dokan for the FS bridge, and MSAL + Graph SDK for auth and sync is a solid technical foundation. The creator has also demonstrated an understanding of the complexities involved in building a file system bridge, such as handling the Dokan FindFiles callback and avoiding blocking Explorer. However, there are potential risks and challenges associated with deploying this solution to a large estate, as acknowledged by the creator. The fact that it is being used by a handful of pilot users but not a full estate yet is a limitation. Additionally, the reliance on Dokan, a third-party library, may introduce stability or compatibility issues. Nevertheless, the creator's experience and willingness to learn from mistakes, as evident from the 'war story' about handling Graph cooldown, suggest that they are capable of addressing these challenges. Overall, a solo or 2-person team can likely build v1 in 4-12 weeks, but it would require careful planning, prioritization, and testing.

Competition

nvidia/nemotron-3-nano-omni-30b-a3b-reasoning

8.0

OneSync uniquely delivers true drive letters with accurate quota and thumbnail support while keeping files local first and telemetry‑free, filling a gap unaddressed by OneDrive sync client and existing alternatives.

The market already offers generic OneDrive sync clients and some niche tools that provide drive‑letter mapping, but none combine true NTFS‑first local files, accurate Graph‑based quota reporting, image thumbnail rendering, LRU eviction, a single deployable config.json, and zero telemetry. Existing solutions either rely on virtual file systems (e.g., Resilio Sync, CloudMe) that lack real drive letters, or they require per‑user configuration and send usage data. OneSync's use of Dokan for genuine NTFS drive letters, its single config.json that can be pushed via Intune, and its strict avoidance of any analytics JSON makes the differentiation both novel and durable, provided the open‑source stack remains stable and Graph API quotas are managed. Additionally, the local‑first design ensures files exist as real NTFS files before syncing, which improves reliability and offline access compared to virtual‑filesystem approaches. The architecture addresses Explorer UI thread blocking by deferring Graph calls to background tasks, mitigating the cooldown‑induced hangs that previously hung Explorer for minutes. This architectural foresight enhances durability, though the reliance on Dokan's synchronous FindFiles callback remains a potential fragility point. Overall, the idea solves a concrete, underserved need in M365 estates and offers a defensible, differentiated product.

Risk

nvidia/llama-3.3-nemotron-super-49b-v1

4.0

Unproven scalability and dependency on external APIs threaten long-term viability.

OneSync faces significant risks despite its technical merits. **Regulation** (GDPR, CCPA) may hinder its growth due to the lack of built-in compliance tools for data protection and user consent management, potentially leading to fines. **Platform Risk** is high because OneSync heavily relies on Microsoft's Graph API and Dokan; any changes to these could break the service. **Churn** might increase if the solution doesn't scale perfectly with larger estates, given its untested nature at scale. **No-budget customers** might be attracted by the MIT license but won't contribute revenue, straining support resources.

Monetization

mistralai/mistral-medium-3.5-128b

8.0

Monetization is the weak link - this solves a painful problem but currently leaves money on the table.

OneSync addresses a clear, underserved niche in M365 estates (20-500 users) where the OneDrive sync client falls short: true drive-letter mapping, centralized config, accurate cloud quotas, local-first NTFS sync, and zero telemetry. The technical execution is strong (.NET 8, Dokan, MSAL/Graph) with thoughtful optimizations (async Graph calls, LRU eviction, Office AutoSave integration). The pricing path is unclear - this is a high-value tool for sysadmins, but the MIT license and lack of monetization (no upsell, no telemetry) suggest it's positioned as a free utility. For a business venture, this is a missed opportunity: a per-seat or per-estate license (e.g., $5/user/year or $500/estate/year) could capture value from organizations avoiding OneDrive's limitations. Deployment is Intune-friendly, reducing friction. The biggest risk is scale: Dokan and Graph cooldowns could cause edge-case failures in larger estates, but the pilot feedback loop mitigates this. The war story (sync hangs) proves robustness is a priority.

Market

moonshotai/kimi-k2.6(fallback #1)

7.0

The product solves real friction for a defined niche, but the buyer profile and free-license positioning create a classic open-source trap where value created exceeds value captured.

The addressable market is real but constrained: ~1.2 million UK school staff, millions of small M365 estates globally, plus charities and niche businesses. The unmet need is genuine - drive-letter mapping with thumbnail support, quota accuracy, and central config are pain points the official client ignores. The 'local-first, sync to cloud' model specifically suits regulated sectors, shared-device environments, and organizations with compliance concerns. However, willingness to pay is questionable. The ideal buyer (school IT admin, small business ops person) often lacks budget authority, is risk-averse, and has 'good enough' alternatives. The free MIT license signals no immediate monetization path, and the 'zero telemetry' positioning, while principled, limits freemium or usage-based models. The Dokan dependency and kernel-mode complexity create support liability that scares enterprise buyers. The pilot-scale caveat is honest but damning for trust-sensitive buyers. Strength: this solves problems Microsoft's roadmap won't touch. Weakness: the people who most need this often can't pay, and those who can pay prefer vendor-backed solutions. Best path: open-source credibility building consulting/integration revenue, or targeted licensing to specific verticals (defense-adjacent, legal compliance) where 'zero telemetry' is a budget-justifiable feature.

Synthesized by meta/llama-3.3-70b-instruct · 34.6s