Build Plan: IndexDesk
● Live prototype This tool has a working CLI/web build you can try right now →Concept IndexDesk — Search Intelligence cluster, Vertical variant.
Summary
Index a tree once, then ask which of the hits are .go files under 100 KB.
Windows Search is weak while pro search tools feel old. Make local search instant, private, semantic, and keyboard-first.
Primary persona
The Specialist — a user in lawyers, researchers, and consultants with large local document corpora, whose day-to-day workflow this variant is purpose-built around — not a generic power user.
Target customer (from research): lawyers, researchers, and consultants with large local document corpora.
Competitive inspiration
We’re combining the strongest parts of tools people already pay for:
| Source app | Modeled annual revenue | Current stack |
|---|---|---|
| dtSearch Desktop | $4.0M | C++ native indexing engine |
| FileLocator Pro | $3.4M | C++/.NET Windows |
| Listary Pro | $2.5M | C++/native + modern UI |
| Copernic Desktop Search | $3.4M | C++/.NET Windows |
Combined addressable revenue pool (modeled): $13.3M. Target capture rate: 7.8%.
Feature scope
v1 (MVP — ship this, nothing more):
- Content index
- Regex
- Metadata
- OCR index
- Quick launcher
v2 (after v1 has real usage data):
- Saved queries
- Email/doc search
Architecture sketch
- Supporting component: Rust Tantivy-like indexer
- Application shell: C#/.NET 10 WinUI 3
- Supporting component (2): local embeddings
The split matters more than the exact tech: keep the engine (file I/O, hashing, scanning, capture — whatever is CPU/IO heavy) decoupled from the UI shell, so the engine can be tested headless and reused across variants in this cluster.
Roadmap
| Phase | Focus | What happens |
|---|---|---|
| Weeks 1–2 | Core engine spike | Stand up the riskiest part of the tech stack first (the engine, not the UI) against real sample data and confirm the approach holds up. |
| Weeks 3–8 | v1 feature build-out | Build the full v1 feature scope below on top of the proven engine, wiring up the UI shell as features land. |
| Weeks 9–10 | Polish, packaging & soft launch | Crash/usage instrumentation, code signing, pricing/licensing wiring, and a soft launch to a small user group. |
- MVP timeline: 6–10 weeks
- Build simplicity: 7/10 (higher = simpler)
- Opportunity score: 7.7/10
Go-to-market
- Partnerships and sponsorships inside the specific niche community
- Integrations / import-export support for the niche’s existing tools
- Targeted content marketing built around the specific workflow, not the category
- A referral program seeded through the niche community’s existing influencers
Success metrics
- Activation: % of installs that complete the core action (the thing in “Feature scope v1”) within the first session
- Retention: 30-day active rate among installs that activated
- Monetization: trial-to-paid conversion rate, tracking toward the $1.0M/yr mid revenue scenario within 12 months of launch
- Quality: crash-free session rate ≥ 99.5% before removing the “beta” label
Risks & mitigations
| Risk | Why it matters | Mitigation |
|---|---|---|
| Naming risk | The working name has a flagged trademark/domain collision and cannot be used as the shipping brand as-is. | Run a formal name-clearance pass (trademark + domain + store-listing search) before any public landing page, build, or store listing goes live. |
| Market risk | Users already pay for the incumbent tools this concept borrows from and may see little reason to switch. | Lead marketing with the specific market gap this product closes, not a feature checklist — differentiation is the pitch, not parity. |
| Distribution risk | New, unsigned Windows apps routinely get flagged by SmartScreen or Store review, which kills first-run trust. | Budget for a code-signing certificate and Microsoft Store review lead time before any public launch date is promised. |
| Technical risk | The scope is largely straightforward app engineering; the main risk is time-to-polish, not feasibility. | Timebox the v1 feature list tightly to the MVP scope below and resist adding v2 features before launch. |
Revenue scenario (modeled, not a forecast)
| Scenario | Estimated annual revenue |
|---|---|
| Low | $469K |
| Mid | $1.0M |
| High | $2.0M |
Pricing
$49–$149/yr depending value
Naming status
Working name only — brand verdict CAUTION (Medium). Collision: IndexDesk. Possible with formal clearance; don’t depend on exact .com.
This is a working title for planning purposes. Clear the name (trademark + domain + marketplace search) before any public build, landing page, or store listing.
Build checklist
- Validate demand (forum/Reddit/community signal check for the search intelligence job-to-be-done)
- Clear the working name (trademark, domain, store listing collisions)
- Spike the core engine described in the architecture sketch above
- Ship a thin end-to-end MVP covering the v1 feature scope only
- Instrument usage + crash reporting before wider release
- Set up licensing/payment (one-time key or subscription per pricing direction)
- Soft-launch to a small user group and gather pricing/feature feedback
- Revisit the v2 feature list using real usage data, not guesses
Notes
Working product name only; validate trademarks/domains and user demand before build.