The Work Tracker We Hid Inside SharePoint

Management wanted the work tracked in Azure DevOps. The team doing the work was a corporate communications group — writers, designers, video producers. Azure DevOps is built for software engineers. Sprints, backlogs, area paths, work item queries: vocabulary nobody on a comms team asked to learn, in a tool whose free "Stakeholder" tier won't even let you reorder a backlog.

The standard answers all cost something. Power Apps Premium runs $20 per user per month, and Microsoft retired the cheaper per-app plan in January 2026 — for a mid-size team, that's thousands a year before you build anything. Jira, Asana, and monday all mean another per-seat subscription, another login, another tab, and none of them talk to Azure DevOps out of the box. A proper Azure DevOps extension means a sandboxed iframe, a marketplace publisher account, and a maintenance obligation.

There was also a harder constraint, the kind that kills most projects quietly: no server. No Power Automate. No Azure Functions. No place to run a nightly job. The IT environment allowed exactly one thing this team already had — SharePoint.

So that's where the app lives.

An app hiding in a document library

The whole application is a single-page Vue app compiled to static files and dropped into a SharePoint document library. No app service, no container, no approval chain for new infrastructure. If you can put a file in SharePoint, you can ship this.

Hosting inside SharePoint buys more than a place to put files, because the app and the company's content share an origin:

• Authentication is inherited. Open the app, you're already signed in. There is no login screen in the entire product.
• SharePoint lists are the database. No CORS, no connection strings, no provisioning ticket. The app even ships a setup page that creates its own lists and columns from a schema definition — the database installs itself from the browser.
• Office is the file viewer. A PowerPoint attached to a job opens right in the app through Office for the web, the same viewer the intranet uses. One more click opens it in desktop PowerPoint, in edit mode, saving straight back to the library. That's not an integration we built; it's what being inside SharePoint gives you for free.

Each piece of this pattern is documented somewhere. The assembly — a static SPA in a document library, no SharePoint Framework, no Power Platform, making delegated-token calls to a second Microsoft service — is one we've found no other writeup of. It shouldn't be exotic. It's the cheapest architecture Microsoft never advertises.

The part that had no right to work: syncing ADO with no server

Management sees Azure DevOps. The team never opens it. In between sits a sync engine with a problem: sync engines run on servers, and there is no server.

Ours runs in the browser. Whenever a team member has the app open, it does the work a backend would do:

• Push: every edit that touches a mapped field mirrors to the matching ADO User Story — status, title, points, sprint, assignee, parent links.
• Durable outbox: a failed push writes a retry flag onto the job's own row in SharePoint. Any teammate's session, today or tomorrow, picks it up and retries. After six failures it stops hammering and raises its hand on the dashboard instead.
• Pull: a watermark loop queries ADO every few minutes for outside edits. Nothing is applied silently — changes land in an inbox where a human clicks Apply or Keep ours. Sync conflicts become a decision, not a surprise.
• Self-test: because the engine only truly runs in production, the app carries a 19-check test harness that exercises the real sync path from inside an authenticated browser session. The test environment is the production tab.

The team works in plain language — a request comes in, gets triaged, moves across a board, goes out for review, gets approved. The app folds eight content-team statuses into the five states the ADO process expects, derives priority from due dates instead of asking anyone to rank P1 through P10, and stamps every story with the current sprint. Management opens their ADO dashboard and sees a live, correctly-shaped board. Nobody typed anything twice.

Tracking that survives an audit

The tracking requirement wasn't just "use ADO." It was the usual management bar: who did what, when, and what did rework cost. The app records status history as an append-only log on each job — every transition, timestamped, attributed. That matters more than it sounds: Azure DevOps' own cycle-time widgets recalculate against your current board configuration, so changing a column can rewrite last quarter's numbers. An immutable log the app owns can't be rewritten by a settings change.

On top of that log sits the piece management didn't know it could ask for: change-cycle receipts. Every revision round is attributed — who requested the change, how many rounds each job took, how much time the rounds added, whether churn came from the team or the requestor. Sprint views separate planned work from break-ins, because interrupt-driven teams that pretend otherwise just fail their sprints quietly. When a sprint closes, unfinished stories split honestly: points earned stay in the closing sprint, the remainder rides a clone into the next one, and a ledger row records the split.

Asset management, or: five fewer places to lose a file

Communications work generates artifacts — decks, briefs, spreadsheets, hero images, video cuts. The default fate of those files is sprawl. Microsoft's platform sees around two million new SharePoint sites and two billion new files a day, and every org knows the local version of that story: the same deck in five folders, none of them canonical.

The app's answer is that every job is the canonical home for its own files. Attachments upload into one predictable folder per job and appear as preview cards on the job itself — with thumbnails, an in-app viewer, and change requests pinned to the specific artifact. "Slide 4 needs the new screenshot" lives on the deck, not in an email thread three weeks from findable. Written content that doesn't need a file at all gets drafted directly in the app, reviewable the same way.

One tab

Harvard Business Review measured knowledge workers toggling between applications about 1,200 times a day, burning close to four hours a week just reorienting. This team's version of that was real: the work tracker, the file library, the review thread, the status spreadsheet, and the engineering board were five different places.

Now the request intake, the kanban board, the calendar, the review-and-approval flow, the asset library, the capacity view, and the management reporting are one app, and the app is one tab. Requestors get their own lean view — status, the work itself, and a way to ask for changes — with everything internal hidden by default. The engineering tool still exists. It's just something the system maintains, not something a writer has to operate.

What it took

48 pages. 144 components. A ten-module sync layer, with 138 automated tests concentrated on the sync logic — the code that would otherwise only ever run in production. Incremental license cost: zero. New infrastructure: zero. New passwords for the team to manage: zero.

The interesting lesson isn't the feature list. It's that the most locked-down enterprise environment usually still contains one place you're allowed to put files — and a modern browser is a more capable runtime than most teams give it credit for. If the only ground IT will give you is a document library, you can build on a document library.

That's the kind of problem we like. If your team is stuck between a tool management mandates and a workflow that doesn't fit it, talk to us.