Ixana · Internal platform
Ixana-Wiki
One place to find every document, meeting, task and patent record — instead of five tools and a colleague who might remember.
Shipped internally- Live demo — search a synthetic workspace yourself
- Five sources under one index; a citation opens the exact passage
- Security shipped in v1: Azure AD, JWT, signed media URLs
Fixing search in OneDrive alone would have moved almost nothing.
Problem. Company knowledge lived in five disconnected systems. People spent a median of nine minutes hunting for a document before giving up and asking someone — or rewriting it from scratch.
What I did. I owned delivery of a single internal knowledge platform: one searchable repository across OneDrive, ClickUp, Teams, efficiency trackers and patent records, with hybrid search, cited AI answers and role-based access.
Result. 84 of about 100 employees used it within a quarter — 100 being the current roster, up from about 50 a year earlier. Median time-to-find fell from nine minutes to under one, and duplicate document creation stopped being a weekly occurrence.
01Why this, and why now
Three internal problems were on the table for the coming half-year: knowledge search, an onboarding documentation rebuild, and automated meeting notes. All three had vocal advocates. I sized each by the same measure — engineering and operations hours lost per month — using calendar sampling and a two-week diary study with nine people.
The knowledge problem was also the only one getting worse on its own: every failed search produced another duplicate document, which made the next search harder. The other two were stable. That compounding effect is what turned a large problem into an urgent one, and it's the argument I used to get the half committed.
02The problem as people experienced it
I interviewed 14 people across engineering, operations and legal, and shadowed four of them while they searched for something real. The pattern repeated almost exactly.
| What they did | Where it broke | Evidence |
|---|---|---|
| Recalled a document exists | No obvious place to start | 11 of 14 opened a tool on a guess |
| Searched 3–4 tools | Keyword search missed anything reworded | Median 9 min before abandoning |
| Asked a colleague | Answer stayed in a DM, never written down | The same 4 people fielded most requests |
| Rewrote the document | Duplicates made the next search worse | 3 versions of one spec found in audit |
The reframe: this was not a search-quality problem inside any one tool. It was a fragmentation problem across all of them, and fixing search in OneDrive alone would have moved almost nothing.
03My role and approach
I owned product scope across ingestion, search, access and user workflows, and drove decisions on source coverage, search experience, sync operations, security requirements and production readiness — so backend services, frontend flows and background jobs shipped as one product rather than three.
Key decisions
- Unified repository over document search alone. I brought OneDrive, ClickUp, Teams, efficiency data and patent invoices into one index. It widened scope considerably, but the research said fragmentation — not search quality — was the actual problem.
- Two sources first, then three. I sequenced OneDrive and ClickUp into a four-week internal alpha before touching the others, so we learned whether people would change habits before paying for full coverage.
- Hybrid retrieval over keyword-only or vector-only. People searched for exact patent numbers and vague half-remembered topics in the same session. Either approach alone failed one of those.
- Security in v1, not as a follow-up. Azure AD authentication, JWT validation and signed short-lived media URLs shipped with the first release. A system indexing every sensitive document can't retrofit access control.
04What I cut
Shipped in v1
- Search across 5 sources
- AI answers with citations
- Azure AD sign-in
- Secure file preview
- Transcript timestamp jump
Deferred
- Slack and email sources
- Saved searches
- Usage analytics v2
Cut
- Per-document permissions
- Multi-language search
- Public-facing mode
Per-document permissions was the hardest cut. Existing SharePoint groups already covered roughly 90% of real sensitivity cases, and building a second permission model would have added a month for the remaining 10% — which we handled by excluding two folders from ingestion instead.
Out of scope for v1
- Per-document permissions. SharePoint group inheritance covers 90% of sensitivity cases (per the access audit). Remaining cases handled by excluding two named folders from ingestion. Revisit if exclusion list exceeds 5 folders.
- Multi-language search. Under 2% of indexed content is non-English. Defer indefinitely.
- Public-facing mode. No identified user. Removed from roadmap.
One page from the working PRD, with internal locations and dates generalised.
05How I got it agreed
The CTO wanted per-document permissions in v1. His concern was legitimate — the index would contain patent filings and unreleased silicon specs, and he didn't want to explain a leak to the board because a PM wanted to ship faster.
Arguing about risk tolerance wasn't going to resolve it, so I changed what we were arguing about. I pulled the SharePoint group data and showed that inherited permissions already covered every sensitive folder but two. That reframed the question from "how much risk will we accept" to "is a month of engineering the right price for two folders" — a question with an obvious answer.
He agreed on two conditions I hadn't planned to offer: the two folders stay out of ingestion entirely rather than being permission-filtered, and we revisit if the exclusion list ever exceeds five folders. Both went into the PRD as written commitments. The second condition turned out to matter — we hit four of the five, and per-document permissions moved back onto the roadmap pre-emptively, on his terms rather than as a fight.
06What was built
An internal knowledge platform combining document management, enterprise search and AI question answering in one interface. People search files, browse ClickUp documentation, jump through meeting recordings by timestamp, check task and efficiency analytics, and track patent invoice records — from one place.
- 1Citations sit inline, not in a footer. In the alpha people wouldn't act on an answer without seeing the source first, so the marker sits in the clause it supports and opens that exact passage. A meeting citation carries a timestamp and seeks the recording to the second it was said.
- 2Preview opens in-app. Opening OneDrive in a new tab broke the search flow and lost people's place in the results.
- 3Source filter is visible, not in settings. People often knew which tool a document lived in and wanted to say so upfront.
- 4Superseded copies are flagged, never hidden. The audit found three versions of one spec. A superseded copy still appears in the results, ranked under the current one and labelled — and the answer refuses to quote from it. Hiding duplicates would have made the guardrail this shipped against impossible to read.
The running demo rather than a mock-up — same code, same layout, on a synthetic corpus. Ten documents, four recordings and three videos stand in for the five connected sources, and every document, name, part number and figure is synthetic, created for publication. The two folders excluded from ingestion are absent from it by construction rather than filtered.Search this in the demo — opens the screen above ↗
Every file type in My Files opens inside the app rather than bouncing out to OneDrive in a new tab, which lost people their place in the results. Each opens in a reader shaped like the file, because a locator only means something if the surface has pages, or rows, or a timeline.
07Tradeoffs
| Tension | What I chose | What it cost |
|---|---|---|
| Breadth vs reliability | Five sources, each connector modular and independently schedulable | More integration surface to monitor; two connectors needed rework post-launch |
| Answer quality vs speed | Hybrid retrieval with structured context assembly | About 1.5s added latency versus generation alone |
| Ease of access vs data protection | Azure AD required, signed media URLs, tighter endpoint controls | No anonymous or link-based sharing, which people asked for repeatedly |
08Impact and outcomes
Before build, we agreed this failed if fewer than half the company used it in the first quarter, and that we'd watch duplicate document creation as a guardrail — a tool that made finding easier but copying easier too would have been a net loss.
How we counted. Active means at least one search or chat query in a calendar week, deduplicated by user. It deliberately excludes people who only opened a link someone else shared, since that measures sharing rather than adoption.
Technical configuration — 1000-char document chunks · 200-char overlap · 768-dim embeddings (all-mpnet-base-v2) · gpt-4o-mini for generated answers · 3 PM2 services on AWS EC2
09What I'd do differently
I shipped v1 without product analytics. For six weeks I had no idea which sources people searched or how often answers failed — the numbers above came from a database query and a survey, retrofitted. Instrumentation belonged in the first release, and the cost wasn't the missing data so much as the six weeks of decisions I made on intuition.
I also sequenced the connectors by how easy they were to build rather than by expected usage. OneDrive and ClickUp turned out to carry most of the traffic, but I only knew that afterwards — two of the five connectors could have waited a release and bought back the month the permissions work needed.