Zapply - From Web to Desktop

In the world of indie hacking, ideas don’t just evolve—they mutate under fire. What started as a plan to build a cloud-based automation tool for remote software engineers has now taken a sharp turn toward something even more efficient, scalable, and resilient—a desktop app.

Why the Pivot?

Originally, the plan was to build Zapply as a fully web-based SaaS that automates job applications. Users would sign up, connect their accounts, and let our cloud bots handle the job hunt.

But then we hit a wall. Actually, two massive walls:

1. Anti-bot detection in the cloud is brutal. Running bots from cloud servers means every request comes from a small range of IPs, triggering reCAPTCHAs, verification emails, and all sorts of annoying security measures from applicant tracking systems (ATS) like Greenhouse and Lever.

2. Cloud bots aren’t cheap. Running headless browsers in the cloud at scale is a financial black hole. Spinning up thousands of instances to handle job applications for users means high infrastructure costs, even before revenue starts rolling in.

We could have brute-forced our way through, but indie hackers don’t burn cash like VC-backed startups. Instead, we find smarter ways to hack the system.

Introducing Zapply Desktop App

Instead of running job application bots from a central server, what if we run them on users’ own machines? That’s exactly what we’re doing.

We’re shifting Zapply from a cloud-based service to a desktop application powered by JavaFX + Playwright. Here’s why it makes perfect sense:

✅ Bypasses Bot Detection – Instead of all requests coming from a few cloud IPs (which get flagged instantly), Zapply will run locally from each user’s machine, making every job application look like a real person applying from a real home network. No reCAPTCHA hell. No email verification codes. No flagged IPs.

✅ No Expensive Cloud Costs – Instead of maintaining a fleet of cloud bots, each user runs their own automation locally. No cloud infrastructure needed, which means low operational costs for us and no limits for users.

✅ More Control for Users – Users can see the bot working, tweak application settings, and even interact manually if needed. This removes the mystery box problem—users actually know what’s happening.

✅ Easier Scaling – Instead of worrying about server scaling and cloud bot limits, we let users scale themselves. Every new user just downloads the app—no backend load increase, no added hosting costs.

What Will the MVP Look Like?

Since speed is everything, we’re keeping the MVP as lean as possible. Here’s the core architecture:

1️⃣ Landing Page (Already Live)

• Purpose: Marketing & App Download Page
• Stack: Static HTML, CSS, JavaScript (hosted on Netlify)
• Features
  • ✅ Lead collection (Mailchimp)
  • ✅ Analytics (Google Analytics, Twitter Pixel, Fathom)
  • ✅ Stripe integration (for premium users)

🚀 No major changes here—just add the desktop app download link later.

2️⃣ Backend (Spring Boot REST API)

• Purpose: Handles auth, stores user data, tracks application history, and manages premium users.
• Stack
  • ✅ Spring Boot (REST API)
  • ✅ PostgreSQL
  • ✅ Auth: JWT-based login or Google OAuth
  • ✅ Stripe Integration: Verifies active subscriptions

🚀 Fastest way to deploy: Fly.io or Heroku (simplest for an MVP).

3️⃣ Desktop App (JavaFX + Playwright)

• Purpose: Automates job applications directly from the user’s machine.
• Stack
  • ✅ JavaFX (for UI)
  • ✅ Playwright (Java) (for bot automation)
  • ✅ SQLite or Backend API (for local storage & tracking)
  • ✅ Auto-Updater (so users don’t need to manually reinstall updates)

🚀 This is where the real magic happens.

Potential Downsides?

No pivot is perfect. While the desktop approach solves major problems, it does come with its own trade-offs:

❌ Users must install an app. Some people prefer pure web-based tools, but for real automation, a desktop app is the only viable way to bypass bot detection.

❌ Users need their machine on. If the bot runs on their machine, it won’t work if their computer is off. Solution?

→ We allow users to run jobs manually or set schedules (e.g., auto-run every morning).

❌ Software distribution & updates. We need an auto-updater, so users don’t have to reinstall new versions manually.

Next Steps - Here’s the fastest path to launch:

1️⃣ Deploy a test backend on Fly.io or Heroku

2️⃣ Build the JavaFX Desktop App (basic UI + Playwright bot)

3️⃣ Test the bot on different machines (Mac, Windows)

4️⃣ Implement an auto-updater for seamless updates

5️⃣ Release MVP & collect real-world feedback

Final Thoughts

This pivot makes Zapply stronger, cheaper to run, and way harder to detect. Instead of fighting a losing battle with bot detection in the cloud, we’re going straight to the source—running from the users’ own machines.

Will this work better than a cloud-based approach? Only one way to find out: ship it and see what happens. 🚀

Stay tuned. Zapply is about to drop.