Vol. 01 — 2026

Building From Junagadh 2026: 06:00 to Midnight Playbook

Building From Junagadh 2026: 06:00 to Midnight Playbook

Quick Answer: Building from Junagadh in 2026 runs on a fixed daily loop: 06:00 deep work, 09:00 client calls, 12:30 deploys, 15:30 code review, 18:30 telemetry, and 21:00 writing. That rhythm shipped 40+ projects at P95 41ms while keeping infrastructure at ₹6K per month and commute at zero.

Author: Deepak Bagada — founder of SaaS Next, creator of Curro, AI developer in Junagadh, Gujarat. I have worked from this city since 2020 and shipped for clients in Surat, Rajkot, Ahmedabad, Dubai, and Berlin. The engineering journal is where I publish the numbers.

Key Takeaways

  • A fixed schedule beats motivation. The 06:00 block is non-negotiable; everything else moves around it.
  • Client calls belong in one window. Batching them at 09:00 protects two long build blocks per day.
  • Infrastructure costs ₹6K per month for a four-core VPS, backup storage, and a UPS for the router.
  • The hard part is not isolation. It is saying no to work that does not fit the loop.

Why I Stay in Junagadh

Metro agencies carry overhead I cannot justify to a client paying ₹85K for an agent build. Office rent, commute, and a sales layer add cost without adding code. From Junagadh, a four-core VPS and a fiber line deliver the same 41ms P95 latency to a client in Berlin as a desk in Bengaluru.

The city also removes the temptation to fill the calendar with meetings. There is no coworking scene to drift into at 15:00. The day has fewer inputs, and that is the point.

Time IST Block What happens Output
06:00–08:30 Deep work One hard problem, no messages Shipped feature or failing test
08:30–09:00 Reset Walk, breakfast, inbox scan Clear head
09:00–11:30 Client window Calls, demos, discoveries Recorded decisions
11:30–12:30 Build Implementation of call decisions Merged PR
12:30–13:30 Deploy and lunch Staging to production, monitoring Green deploy
13:30–15:30 Deep work Second hard block Code or writing
15:30–17:00 Review PR review, QA swarm findings Merge queue empty
17:00–18:30 Buffer Overflow, errands, family Slack cleared
18:30–20:00 Telemetry and writing Logs, ledger, journal draft Daily ledger entry
21:00–22:30 Optional Study, side project Notes for tomorrow

The table is not aspirational. I print it and tick the blocks. On a bad day I lose the 13:30 block, not the 06:00 one. Protecting the first block is what makes the rest of the schedule survivable.

The ₹6K Infrastructure Reality

Item Monthly cost Why it is enough
4-core VPS ₹3,400 Hosts 6 client apps at 41ms P95
Backup storage ₹900 Daily encrypted snapshots, 30-day retention
UPS for router ₹0 amortized ₹4,800 one-time, 4 hours of uptime
Fiber 300Mbps ₹1,700 Two Zoom calls plus 40GB deploys
Total ₹6,000

I do not run Kubernetes. Six client apps fit on one VPS with FrankenPHP, Valkey, and Postgres. When a client outgrows it, they move to a dedicated node and the cost conversation is honest: here is the metric that says you need more.

The power backup field notes cover the UPS wiring and the failover test I run every quarter. A backup you have never tested is a decoration.

Production War Story: The Fiber Cut at 12:31

On 9 September 2026 a JCB cut the main fiber line two streets from my building at 12:31. I was mid-deploy: database migration applied, new code uploaded, cache cleared, and the verification step still running. The laptop lost connectivity with the deploy half-finished.

I switched to a phone hotspot in 90 seconds because the deploy script had a --resume flag and the migration was idempotent. The verification completed over 4G, and the client saw a 3-minute window of degraded performance instead of a broken checkout.

That incident produced two changes. The deploy script now refuses to run without a verified backup taken in the previous hour, and it writes a resumable state file after each step. The state file is four lines of JSON and has saved me twice since.

#!/usr/bin/env bash
# deploy.sh — resumable deploy for a single VPS
set -euo pipefail

APP_DIR="/var/www/app"
STATE="/tmp/deploy-state.json"
STEPS=("backup" "pull" "migrate" "cache" "reload" "verify")

resume_from() {
  if [[ -f "$STATE" ]]; then
    jq -r '.last_completed // ""' "$STATE"
  else
    echo ""
  fi
}

mark_done() {
  jq -n --arg step "$1" '{last_completed: $step}' > "$STATE"
}

run_step() {
  local step="$1"
  local last
  last="$(resume_from)"
  if [[ -n "$last" ]] && [[ "$(printf '%s\n' "${STEPS[@]}" | grep -n -A99 "^$last$" | wc -l)" -gt 0 ]]; then
    if [[ "$(printf '%s\n' "${STEPS[@]}" | sed -n "/^$last$/,/^$step$/p" | grep -c "^$step$")" -eq 0 ]]; then
      echo "skip $step (already completed past)"
      return 0
    fi
  fi

  case "$step" in
    backup)
      pg_dump "$DATABASE_URL" | gzip > "/backups/$(date +%F-%H%M).sql.gz"
      ;;
    pull)
      cd "$APP_DIR" && git pull --ff-only
      ;;
    migrate)
      cd "$APP_DIR" && php artisan migrate --force
      ;;
    cache)
      cd "$APP_DIR" && php artisan optimize:clear && php artisan config:cache
      ;;
    reload)
      cd "$APP_DIR" && php artisan octane:reload
      ;;
    verify)
      curl -fsS --max-time 10 https://app.example.in/health | jq -e '.status == "ok"' >/dev/null
      ;;
  esac

  mark_done "$step"
  echo "done $step at $(date -u +%FT%TZ)"
}

for step in "${STEPS[@]}"; do
  run_step "$step"
done

rm -f "$STATE"
echo "deploy complete"

The verify step is the one people skip. It is also the only one that tells you whether the deploy succeeded from a user's perspective.

Production War Story: The CA Firm Deadline and the Power Cut

A CA firm needed a GST reconciliation agent live before the 20 September filing deadline. On 18 September at 22:40, a scheduled outage took down power for 70 minutes. My UPS held the router, but the laptop had no battery left because I had ignored the low-battery warning during a long build.

I lost 40 minutes of work on an eval script that had not been saved. The deploy still landed at 01:20 because I rebuilt the script from the shell history, but the cost was a wasted night and a lesson about tooling, not talent.

Now the laptop stays plugged in during any deploy window, and the eval script runs from a git-tracked file, not an editor buffer. I also moved the filing-deadline build to start three days earlier than I thought necessary. Deadline math should include one failure, not zero.

What Solo Remote Work Actually Costs

The schedule looks clean in a table. The real cost is the absence of a colleague who notices when you have been staring at the same stack trace for two hours. I pay for that with a weekly review call with another developer in Rajkot and a monthly code audit from a Pune consultant.

Cost Amount Purpose
Peer review call ₹0 (swap) Weekly second pair of eyes
External code audit ₹8,000 / month Quarterly deep review
Coworking day ₹600 / month One day of human contact
UPS and network ₹4,800 one-time Uptime

I also track sleep and walking minutes, because a founder who ships at 01:20 three nights a week is borrowing against next month. The solo founder health routine documents the changes that kept me out of that loop.

When NOT to Use This Playbook

Do not copy this schedule if you have a team of five. Calls, reviews, and unblocking people will fragment the 06:00 block, and forcing the same shape will make you the bottleneck.

Do not copy it if your clients are in a timezone that requires live support at 02:00 IST. I serve EU and US clients with async updates and overlapping evening hours. A business that needs instant voice support needs a shift rotation, not a solo founder.

Do not copy it if you cannot protect the first two hours. A schedule that exists only on paper is worse than no schedule, because it hides where the time actually went. Track one week before committing.

The Ledger That Keeps Me Honest

Every evening I log four numbers: hours in deep work, client calls, deploys, and revenue invoiced. The 90-day JSONL ledger is the same practice I use for client performance claims. It is hard to argue with a row that says 06:00–08:30 shipped a failing test, and it is impossible to pretend a week was productive when the deep-work column reads 4.5 hours.

If you are building from a tier-2 or tier-3 city, the model works. The constraint is not the city. It is whether you can defend the first block, batch the calls, and tell a client no when the scope does not fit the loop. The discovery call notes cover the conversations that decide this before the contract is signed.

Frequently Asked Questions

Is it possible to run a software business from Junagadh?

Yes. I have run SaaS Next from Junagadh since 2020, shipping 40+ projects to clients in India, Dubai, and Berlin. A ₹6K monthly infrastructure budget covers six production apps, and fiber plus a UPS handles uptime.

What does a solo developer's daily schedule look like?

My loop is 06:00 deep work, 09:00 client calls, 12:30 deploy, 13:30 second build block, 15:30 review, 18:30 telemetry, and 21:00 optional study. The first block is fixed; the rest flexes around client needs.

How do you handle internet outages during deploys?

I keep a phone hotspot ready, write resumable deploy scripts with a state file, and verify each step from the server side. A UPS keeps the router alive for four hours. The worst outage this year caused three minutes of degraded performance, not an outage.

How much does it cost to run client apps from home?

About ₹6,000 per month for a four-core VPS, backups, and fiber. That covers six applications at 41ms P95. A one-time ₹4,800 UPS protects the network. I add dedicated nodes only when a client's traffic justifies it.

Bottom line

Building from Junagadh is not a lifestyle story. It is a cost and focus decision: ₹6K infrastructure, zero commute, and a fixed 06:00 block that produces the work. The schedule only holds if you batch client calls, write resumable deploys, and track the ledger every night. If you want the same build rhythm on your project, start a conversation and I will tell you honestly whether it fits.

KEEP READING

← All journal articles Get in touch →