Ten minutes. That is how long it took to find one error log. Open the Azure portal, find the right resource, filter by time, scroll, copy, paste, switch to another portal, cross-reference timestamps, and pray the log had not already rotated. Every single time. The fix — a centralized log search tool that collapsed those multiple portals into one search bar — was a weekend build. This is the story of why I did it without asking anyone.
The ritual nobody questioned
I was on an eShop project with a support team that was quietly drowning. Not in bugs — in process. Every time a developer hit an issue in production, the same ritual started. Open the Azure portal. Find the resource. Switch to a second portal for a different service. Cross-reference timestamps between them because the clocks never lined up cleanly. Scroll through walls of text. Copy something. Paste it somewhere else. Repeat until you found the line that mattered.
Ten minutes if you were fast. Fifteen if the log had already rotated and you had to go hunting in cold storage.
And here is the part that actually bothered me: developers could not even do this themselves. Access to the logging portals was locked down to ops. So a developer would hit a bug, write up a ticket, and wait. Someone from ops would pick it up, run the same ten-minute ritual, paste the result back into the ticket, and move on. Multiply that by every bug report, every day, across a whole team.
I sat through two weeks of watching this before I snapped.
The weekend build
I did not ask permission. I did not file a proposal or open a discussion in the backlog. I went home on Friday, opened my laptop, and started building.
The design goal was almost aggressively simple: one search bar. Type the error. Hit enter. Get the log. No portal-hopping, no timestamp math, no access requests.
Under the hood it was three moving parts:
- A Python backend to pull logs from the different sources and expose a single search API.
- Elasticsearch doing the heavy lifting — full-text search across everything, so "find me every occurrence of this exception in the last hour" became one query instead of five manual lookups.
- Docker containers wrapping the whole thing, so it would deploy anywhere without me babysitting environment setup.
By Sunday night it worked. You typed the error message, hit enter, and results came back in about thirty seconds. From ten minutes across five portals to thirty seconds in one box.
Monday morning
I showed the team Monday morning. I was not expecting much — I had built it mostly to stop my own frustration.
The support lead literally hugged me. The developer who had been spending half his mornings copying logs between browser tabs just stared at the screen and said, "why didn't we have this a year ago."
Then the numbers moved. Support tickets dropped hard over the following weeks. Not because the bugs disappeared — they did not. Tickets dropped because developers could finally find their own answers. No portal access needed, no ops queue, no waiting. A developer hit an error, typed it into the search bar, and had the log before they would have finished writing the ticket. The whole "file it and wait" loop just… evaporated for a big chunk of cases.
Why the uninvited projects win
I have shipped a lot of things that were carefully specced, estimated, and approved. Almost none of them got hugged.
The tools that land hardest are the ones nobody asked for. They come from a specific place: someone doing the work gets annoyed enough, often enough, to fix the thing over a weekend. No roadmap. No approval. Just friction and a text editor.
There is a real lesson in that if you are an engineer trying to be the person your team actually wants around:
- Watch for the daily ritual. The ten-minute task everyone does without complaining is a goldmine. People stop noticing pain they have normalized.
- Do not file a feature request. Build the fix. A working demo beats a beautifully written proposal every single time. Nobody hugs a Jira ticket.
- Ship it small. One search bar. One clear before-and-after. You do not need a platform — you need to delete ten minutes from someone's day.
- Show the result, not the plan. "Watch this" is a much stronger pitch than "here is what I would like to build."
None of this was on any roadmap. It was two weeks of watching smart people burn time on a broken process, one weekend, and three commodity tools glued together with a stubborn refusal to keep filing tickets.
That is usually how the best internal tools get built. Not with permission — with frustration and a laptop.