By Devashish Pawar · version 1.0 · 4 October 2026
Personal projects come with a surprising amount of recurring work. A research project needs new sources, reading notes and a way to revisit useful papers. A growing dataset needs discovery, provenance and review. Documents need to be organised and searchable. Everything needs a backup.
Each task is manageable on its own. Together, they create a steady demand for attention: remember to search, check whether a job ran, find its output, inspect the results and decide what to do next.
I started building The Daily Desk to make that work easier to manage. It combines background automation with a personal dashboard that gives me a bird’s-eye view of my projects and research.
The setup uses a Dell running Windows 11 Pro, WSL2 Ubuntu and Docker as the execution node. My Mac is the place where I open the results, read, review and make decisions. The dashboard brings those activities together in one interface.
Start with the work that repeats
My starting point was JaiBholeNath, an ongoing project concerned with Shiva temples and Shaiva heritage. Growing its discovery dataset involves recurring searches, saved source context and careful review of candidate places.
Alongside that, I wanted to keep finding research methods relevant to the project: knowledge graphs, entity resolution, multilingual retrieval, spatial humanities and provenance.
These were good candidates for automation because the repeatable parts had clear inputs and outputs. A worker could take locations from a queue or query scholarly metadata, preserve what it found, and record the outcome. I could then spend my attention on the material it collected.
That became the guiding question for each addition: what can run repeatedly, produce a useful saved result, and leave a clear record of what happened?
Give each workflow a clear responsibility
The system gradually grew into several connected workflows:
| Workflow | What it handles | Where my judgement remains necessary |
|---|---|---|
| Temple Discovery Scout | Bounded searches from a location queue, saved candidate listings, provenance and run accounting | Checking identity, Shiva association and geography against evidence |
| Research Scout | Scholarly metadata collection, a persistent archive and a Friday reading shortlist | Reading originals, assessing relevance and taking research notes |
| Document library and search | English/Hindi OCR, document organisation, and local keyword and semantic retrieval | Checking OCR, choosing useful metadata and evaluating retrieved passages |
| Backups and health | Encrypted snapshots, service checks and isolated restore checks | Making the manual off-device copy and responding to failures |
| Temple quality queue | Flags on saved listings that need closer inspection | Reviewing evidence and recording a reasoned decision |
These services have different rhythms. The scouts run on daily schedules. Documents are processed when uploaded, and their search index refreshes in the background. Health checks run periodically. A saved weekly brief gathers a broader view of progress.
Having a clear responsibility for each workflow makes the system easier to extend. A new project can introduce its own worker, state and report without becoming part of one large script.
Separate execution, state and presentation
The architecture has three main layers.
Execution is where scheduled and background work happens. The Dell runs the workers. n8n schedules the two scouts; other maintenance and background services use their own schedules. The Mac can be asleep during these jobs.
State preserves the work: queues, database records, run journals, source context and saved reports. The discovery worker retained its existing MySQL database. Research and document services use PostgreSQL, while the semantic search index uses SQLite. The existing state stores serve their respective workflows.
Presentation is where I understand the results. The Daily Desk reads status and report summaries and links to the individual workspaces for deeper inspection.
- Scheduled and background triggers
- Dell workers
- Records, run journals and reports
- The Daily Desk on my Mac
- Read, review and choose next actions
This separation also helps when connectivity fails. The Mac viewer can retain the last successful status report and identify it as stale. Saved output remains useful, with its age visible to the reader.
Record enough to explain a run
Scheduling a job creates a recurring opportunity to do work. To understand whether it succeeded, I also need its start time, outcome, saved output and any reason it could not proceed.
That became especially clear with the Discovery Scout. At first, confirming the next run involved manually checking Google Cloud usage, comparing it with the worker’s records and supplying a fresh observation. Screenshots covering different time windows made that process harder to interpret.
The system now has automatic read-only usage checks that feed its readiness assessment. It considers the configured request allowance, existing reservations and the freshness of the observation before the next scheduled batch. A readiness label includes a timestamp and an expiry, so its basis is inspectable.
The worker also has bounded requests and duplicate-run protection. An interrupted run leaves a journal to inspect before recovery. These controls make an unattended job easier to reason about: there is a record of what it attempted and a limit on what it can consume.
Each workflow needs an explicit policy for downtime and retries. Some tasks can catch up after the machine returns; others require inspection before another attempt. Those choices belong to the workflow, because repeating a search, rebuilding an index and retrying a backup have different consequences.
Build the dashboard around the questions I ask
The Daily Desk’s job is to make the system readable. When I open it, I want to answer five questions quickly:
- Are the services and backups healthy?
- What work has completed?
- What is due next, and is it ready?
- What needs my attention?
- How recently was this information checked?
The front page therefore gives priority to current health and the next discovery run. The weekly brief summarises discovery, research, document activity and operational health. Reading picks and next actions sit alongside those summaries. Links take me to the underlying library, search interface or review queue.
I chose a newspaper-inspired design because the dashboard is something I read. A masthead, a dated edition, clear headlines and a noticeboard give the information a familiar structure.
Dates matter here. A weekly report is a historical snapshot. Its recommendation to refresh an allowance may have been correct when published, even after a later check has resolved the issue. The interface labels those notes with their publication time and keeps current readiness on the front page.
That is an important part of a useful bird’s-eye view: it preserves the context behind a summary.
Make privacy and recovery part of the system
The document library introduced another requirement: some files might contain sensitive personal information.
OCR and semantic indexing run on the Dell. Normal document processing and search use a locally stored model. The document services have outbound network access blocked, while private access from the Mac uses the existing SSH connection over Tailscale. That private connection can travel over the internet; local processing and private access are separate properties.
The main dashboard shows aggregate document counts and processing status. Document titles and contents stay in their dedicated workspace.
Recovery needs similar care. Source code is versioned separately from runtime data. Encrypted backups include databases, application configuration and document files, and isolated restore checks inspect the saved contents. I have chosen to copy backups off the Dell manually, so that step remains part of my routine. A tested backup on the same machine still needs an off-device copy to protect against losing the machine itself.
A practical way to build your own version
The useful starting point is one recurring task you already perform and understand.
Define what goes in, what should come out, and what decisions still need a person. Run the worker manually first. Save its output and a run record that can explain success, partial completion or failure.
Then add a schedule, resource limits and a clear retry policy. Keep execution independent of the interface you use to view it. Add a small dashboard that shows the latest result, its timestamp, the next expected run and anything requiring attention.
As the system grows, give each workflow its own responsibility and bring its summary into the same interface. Preserve source context and test how you would recover the data.
For research, this produces a useful division of labour. Automation gathers inputs and organises the review queue. Reading, interpretation and evidence-backed decisions remain deliberate human work.
An ongoing personal system
I built The Daily Desk iteratively with AI coding assistance, guided by real project requirements and checks against the running system. Its current value is concrete: recurring outputs are saved, operational problems have visible records, and the workspaces are accessible from one place.
It is still evolving. Search quality needs evaluation against more real documents. Discovery candidates and research matches need review. New projects, including the early Monsoon to Mandi work, need their own source and data audits before collection expands. Longer-term run history will help me assess reliability and measure how much routine work the system removes.
The Daily Desk gives me a place to begin each day: see what happened, understand what is coming next, and choose where to spend my attention.