DEV Community: Tejaswi Dhulipala

We deleted the pages that earned 63% of our search clicks. Here's the build check that stops it happening again

Tejaswi Dhulipala — Wed, 07 Oct 2026 16:51:02 +0000

We run a small Astro site on Netlify for Stillware, a UK studio that makes pay-once apps (Zeroed, an offline budgeting app, and RankUp Chess). Over six weeks this year we made the most expensive SEO mistake a young site can make, and nothing in our build noticed.

What happened

28 August: a "content cleanup" deleted 13 blog posts that looked off-topic for a budgeting-app company. They had no redirects. Two of them were the biggest pages on the site: one had 94 Google clicks and 4,517 impressions, the other 18,137 impressions at an average position of 4.6.
29 September: an audit spotted the 404s and turned them into 410 Gone. A 410 tells Google the removal is deliberate, so it drops the URL faster.
Result: the 17 deleted URLs that had ever earned an impression accounted for 63% of every Google click the site had ever had. Clicks per 28 days fell from about 65 to about 40.

None of it was malicious or careless in the moment. Each step had a reason ("off-topic", "clean up 404s"). The problem was that "is this page earning search traffic?" was nobody's job at the moment of deletion, and certainly not the build's.

The fix: make "never remove a working page" a failing build

We restored the pages at their original URLs, with the facts re-checked. Then we added scripts/verify-protected.mjs to the end of the build chain:

verify-content → astro build → verify-sitemap → verify-links → verify-protected

It reads two plain-text files in the repo:

seo/protected-urls.txt lists every path that has had at least one impression: 16 months of Google Search Console data pulled from the API, plus pages with Bing impressions or Copilot citations from Bing Webmaster Tools.
seo/approved-removals.txt holds dated exceptions in the form path | date | who | reason, written by the founder. Nothing else exempts a path.

For every protected path that isn't an approved removal, the build fails if:

there's no built file for it (/foo/ → dist/foo/index.html);
_redirects or netlify.toml has a 301/302/307/308/404/410 rule that matches it, even one a real file currently shadows (a non-forced Netlify rule can start winning the day someone deletes the file);
netlify.toml sends X-Robots-Tag: noindex for it;
the built HTML has noindex or a canonical pointing somewhere else.

There's a loud SKIP_PROTECTED_CHECK=1 escape hatch for genuine emergencies, which must be logged.

// core of the check (simplified)
for (const path of protectedPaths) {
  if (approved.has(path)) continue;
  const file = path.endsWith('/') ? join(dist, path, 'index.html') : join(dist, path);
  if (!existsSync(file)) fail(path, 'no built page');
  if (redirectRules.some(r => matches(r.from, path) && r.status >= 300)) fail(path, `rule ${r.status}`);
  const html = readFileSync(file, 'utf8');
  if (/<meta[^>]+robots[^>]+noindex/i.test(html)) fail(path, 'noindex');
  const canon = html.match(/<link rel="canonical" href="([^"]+)"/)?.[1];
  if (canon && new URL(canon).pathname !== path) fail(path, `canonical → ${canon}`);
}

The second rule: rewrites keep what ranks

Deletions weren't the only leak. On 29 September we also rewrote a comparison page. Its title had been "7 YNAB Price Increase Alternatives in 2026", and "ynab price increase" was the site's #1 query. The rewrite changed the title to "7 YNAB Alternatives After the Price Increase" and cut 20% of the words. Impressions fell from 22 a day to 7 within a week.

So every edit to a protected page now:

keeps the URL, the H1 and the exact words of its top queries in the <title>;
cuts no more than 15% of the words;
gets a row in seo/CHANGES.md.

A weekly job compares each changed page's impressions over the 14 and 28 days after the edit with the 28 days before. If a page drops more than 30% while the site as a whole didn't, the edit is rolled back, title first.

What we'd tell anyone running a small content site

"Off-topic" is a brand judgement; "earning traffic" is a fact. Check Search Console before deleting anything.
Prefer a 301 to the closest page over a 410, and do neither to a page that ranks.
Put the rule in the build, not in a doc. Docs get skipped at 9 pm; failing builds don't.
Check Bing too. Bing Webmaster Tools' AI Performance report showed Copilot citing one of our "off-topic" posts 10 times. It had no Google impressions, so a Google-only list would have let it go.

Stillware makes pay-once, offline apps: Zeroed (envelope budgeting) and RankUp Chess. More on how we build: stillwareltd.com.

Local-First Software: Your Device Is the Server, Not a Viewport

Tejaswi Dhulipala — Fri, 04 Sep 2026 16:32:45 +0000

Cloud-first design assumes your phone or computer is a dumb terminal. It's a viewport into an application that lives on a company's server. Your data, your logic, your entire experience is piped through their infrastructure. The app icon on your home screen is just a doorway.

Local-first flips that model. The primary copy of your data, and the software that processes it, lives on the device in your hand. Your phone isn't a terminal; it's the mainframe. This isn't just a technical detail — it changes everything about privacy, cost, longevity, and capability.

When we built Zeroed, we tested it against subscription-based budgeting tools. The most glaring difference wasn't the price tag; it was the latency. Opening a cloud app meant waiting for a server handshake, even to see your own budget from yesterday. A local-first app loads your financial history instantly because it's not asking for permission from a data center in Oregon.

The practical test: does it work on a plane?

This is the simplest litmus test for local-first software. Can you open the app at 30,000 feet, in airplane mode, and do meaningful work?

For a budgeting app, that means reviewing your remaining grocery budget, logging a coffee you just bought at the airport, scanning a receipt with your phone's camera, adjusting next month's plan.

If the app stutters, demands a "reconnection," or shows blank screens, it's cloud-first. Its value proposition depends on a persistent, silent conversation with a server you don't control. A local-first app treats the internet as a useful optional feature — like a backup tool — not as its life support system.

The most common request we get is automatic bank syncing via services like Plaid. We say no every time. It's not a technical limitation; it's a philosophical line. Once you tether your app to a third-party API that requires cloud authentication, you've moved the locus of control. You're no longer local-first. You've built a cloud conduit into the heart of the app.

The ownership spectrum: tenant vs. owner

	Cloud-first (you are a tenant)	Local-first (you are the owner)
Data location	Company servers. You access it.	Your device. You possess it.
Primary access	Requires your password and their server's health.	Requires your device (or your own encrypted backup).
Cost model	Subscription (rent). Stops working if you stop paying.	One-time purchase (asset). Works forever after one payment.
Offline capability	Limited or none. Core features often disabled.	Full. The app is designed to operate independently.
Long-term risk	Company can change terms, raise prices, or shut down.	You retain a working copy. The company can vanish; your tool remains.

Being a tenant is convenient until the landlord changes the locks. For personal, critical data — your finances, your journals, your creative work — you shouldn't be a tenant. The five-year cost difference isn't a small discount either: it's paying $500+ to rent access to your own financial data versus one payment to own the tool outright.

A worked example

Follow a transaction through both architectures. You buy a book for $24.99.

Cloud-first: You open the app. It checks for an internet connection. It authenticates your session with a server. You enter the transaction. The data is sent to the cloud, processed, and the updated "Books" envelope balance is sent back to your phone. If the server is slow or down, you wait, or the entry fails.

Local-first: You open the app. It instantly shows your current envelope balances. You enter $24.99 as "Books." The balance updates immediately, calculated on your device's processor. The transaction is saved to your phone's encrypted storage. Later, if you choose, the app silently backs up the encrypted data file to a folder in your personal Google Drive.

The second flow isn't just faster; it's more resilient. The speed and reliability aren't optimizations; they are direct consequences of the architecture.

Why this movement is growing now

For decades, the default answer to any software problem was "add a server." It centralized control, made updates easier, and created lucrative subscription pipelines. But the downsides are now in plain sight: data breaches, vendor lock-in, feature bloat, and the quiet creep of surveillance for "product insights."

The local-first movement is a correction. It asks a simple question: does this task need a server? For an alarming number of personal productivity apps — budgeting, note-taking, photo editing, document writing — the answer is no. Your smartphone has more processing power than the computers that sent men to the moon. It doesn't need to beg a remote server to add two numbers.

This isn't about rejecting the cloud entirely. It's about demoting it from master to servant. In our case, the user's Google Drive acts as a dumb, encrypted filing cabinet they control — not as the brain of the operation. They hold the encryption keys. We just provide the wallet.

The trade-offs (because nothing is free)

Local-first isn't a magic bullet:

No real-time collaboration. You can't have a Google Docs-style live-editing session. Sync becomes a deliberate merge, not a continuous stream.
Developer responsibility. If the app's local encryption is flawed, the user's data is directly exposed. There's no server as a buffer.
Setup friction. Bring-your-own-Drive sync takes a one-time setup that "Sign in with Google" cloud apps don't.

These aren't weaknesses to hide; they're design constraints that flow from the core principle: user sovereignty over convenience.

Curious what this community thinks: which apps in your daily stack would actually get worse as local-first — and which are cloud-first purely because of the business model?

Originally published on our blog. Zeroed is a pay-once, offline envelope-budgeting app for Windows, Android and macOS (34-day free trial, no card).

Why We Don't Do Subscriptions (For Software That Runs On Your Device)

Tejaswi Dhulipala — Wed, 02 Sep 2026 05:24:20 +0000

The average person now pays for dozens of software subscriptions. Streaming, storage, productivity, notes, passwords, VPNs, budgeting. Each one is "just $5/month" — until you add them up.

Some of those are honest. Streaming pays for licenses and bandwidth. Cloud storage pays for disks someone has to keep spinning. Real ongoing cost, real ongoing service.

But for a budgeting app — software that lives on your device, stores data on your device, and depends on no remote infrastructure to function — charging you forever is a different beast entirely. You're not paying for ongoing work. You're paying so they don't take it away.

For a personal finance tool whose entire purpose is to help you spend less money, that contradiction is hard to ignore. So when we built Zeroed, we wrote a different rule: we don't charge subscriptions for software that runs on your device.

The test

The line is simple. If you stop paying, what actually stops working?

If the answer is "a tool sitting on my hard drive" — that's rent extraction. That's the model we refuse.

If the answer is "the servers, the phone numbers, the AI models, and the people running them on my behalf" — that's a service. Services have real ongoing cost, and pretending otherwise is dishonest pricing.

That's why our rule as a two-person-sized indie studio is simple:

Our apps are pay-once. They run on your device. They don't need us to keep working. No recurring fees, ever.
If we ever ship something with real ongoing cost — servers, AI inference, infrastructure we run for you — it will be an optional, monthly, cancel-anytime service with full data export. And the app you bought will always work fully without it.

We charge for what we actually do — never for software sitting on your hard drive.

What you're really paying for (when it's wrong)

When a personal-software company charges you monthly for an app that runs on your hardware, here's what your money is buying:

Server infrastructure to hold your data hostage
Growth metrics to satisfy investors
Retention tactics to make it painful to leave

Your monthly payment isn't buying features. It's buying the company permission to keep your data on their servers — data they could monetize, lose in a breach, or hold hostage if you try to cancel.

The math

A typical subscription budgeting app at $99/year versus a one-time license:

Time period	Subscription	Pay once
Year 1	$99	$19.99, once
Year 3	$297	$19.99
Year 5	$495	$19.99
Year 10	$990	$19.99

The subscription costs nearly $1,000 over a decade.

I'd genuinely like to hear where other devs draw this line — especially if you ship desktop/mobile software with a subscription and think I'm wrong. What's the honest defence of recurring pricing for local software?

Originally published on our blog. Zeroed is a pay-once, offline envelope-budgeting app for Windows and Android (34-day free trial, no card).

How We Do Bank-Grade Encryption and Cross-Device Sync Without Running a Server

Tejaswi Dhulipala — Sat, 29 Aug 2026 10:16:32 +0000

Most budgeting apps store your financial data on their servers. This means:

They can see your transactions, balances, and spending habits
A server breach exposes your financial life
If the company shuts down, your data may be lost
They can — and often do — monetize aggregate financial data

We built Zeroed to make all of these impossible. Here's the architecture.

Local-first architecture

Zeroed stores your entire financial database locally on your device in an encrypted SQLite database. The encryption key is derived from your device and never transmitted anywhere.

This means:

We cannot read your data — we don't have the key
We cannot lose your data — we don't have a copy
We cannot sell your data — we literally don't have access to it

Cross-device sync via Google Drive

The obvious question: if there's no server, how do you sync between your phone and laptop?

The answer: your own Google Drive.

When you enable sync, Zeroed creates a folder called ZeroedData in your personal Google Drive using the drive.file scope. This scope means Zeroed can only access files it created — it cannot see your photos, documents, or anything else.

Your encrypted database is uploaded to this folder. Any other device running Zeroed and signed into the same Google account will detect the folder, download the encrypted database, and decrypt it locally.

Licensing without license servers

Your Zeroed license also lives in Google Drive as a secure verification file. When you purchase a license, the key is placed in your ZeroedData folder. Any device that connects to that Drive sees the key and unlocks the full app automatically.

No license servers. No activation limits. No "you've used too many devices" errors.

AES-256 encryption

All data synced through Google Drive is encrypted with AES-256 — the same standard used by governments and financial institutions. The encryption happens on your device before the data leaves for Google Drive, and decryption happens on your device after download.

At no point does unencrypted financial data exist outside of your device's memory.

What this means for users

Switch phones freely — sign into Google Drive and you're synced
Use the app fully offline — sync when you reconnect
Your financial data is mathematically inaccessible to anyone but you

Happy to answer questions about the architecture in the comments — the trade-offs of serverless sync (conflict resolution, key management, the no-web-app constraint) are genuinely interesting problems.

Originally published on our blog. Zeroed is a pay-once, offline envelope-budgeting app for Windows and Android (34-day free trial, no card).