Welcome to Part 6 of our SaaS-in-public breakdown series.

We’ve covered:

  • The problem
  • The product
  • The market
  • The pricing
  • The early users

Now it’s time to answer:

“How would we actually build this thing?”

The good news?
You can build this without plugins, without big servers, and without blowing your budget.

Let’s break it down.


The Core System Flow

The product needs to:

  1. Connect to a WordPress site using the REST API (via user-generated API key)
  2. Crawl all published pages/posts, grab raw HTML (DOM)
  3. Extract image URLs and create a list of “used images”
  4. Compare that list to the media library via the REST API
  5. Delete unused images via API and store them on a separate cloud bucket

That’s not a job for a bulky server.
It’s a job for serverless architecture.


Why Serverless Makes Sense

Platforms like AWS Lambda, Cloudflare Workers, or Vercel Functions allow you to run code on-demand — and only pay for what you use [1].

Advantages:

  • No idle costs
  • Instant scalability
  • Smaller deployment units (each function has a single purpose)

Our backend could be composed of micro-functions:

  • Scan site
  • Extract media references
  • Compare to library
  • Execute deletions
  • Upload to storage

For storage:

  • Amazon S3 for first 30 days
  • Lifecycle transition to S3 Glacier, then Deep Archive [2][3][4]

Tech Stack at a Glance

LayerStack
FrontendNext.js or SvelteKit (optional: Tailwind)
BackendAWS Lambda or Cloudflare Workers
AuthSupabase Auth or Firebase [5]
Data StorePostgreSQL (Supabase, Neon, PlanetScale)
StorageS3 with lifecycle policies [2]
Media DiffCompare wp-json/wp/v2/media with parsed img[src] from HTML
Restore FlowRe-upload files via /wp/v2/media endpoint, recreate variations if needed

Optional extras:

  • Scheduled scans via AWS EventBridge [6]
  • Background tasks via AWS SQS [7] or Google Cloud Tasks [8]

Recovery Logic: Not That Hard

Yes, recovering files into the media library may sound complex, but it’s manageable.

During deletion, we’d store:

  • Original file
  • All generated sizes (thumbnail, medium, large…)
  • Relevant metadata (alt, title, mime type, optionally original attachment ID)

When restoring:

  • Re-upload files via REST API
  • Allow the system to regenerate missing sizes if necessary
  • (Optionally) re-associate the file with a post or record

Even if perfect mapping isn’t always possible, restored files are safely back in the media library — ready to be used again.


Infrastructure Cost Estimates

Let’s look at what this might cost in real-world terms. These are not abstract — they’re based on published pricing from trusted providers:

ComponentCost Estimate (monthly)Notes
AWS LambdaFree up to 1M requests/month [1]
S3 Standard (hot)~$0.023 per GB [2]
S3 Glacier~$0.004 per GB [3]
S3 Deep Archive~$0.00099 per GB [4]
Supabase (Auth + DB)Free to ~$25/month [5]
Hosting (Vercel/Netlify)Free tier sufficient at MVP [6]
Transactional emailFree with Postmark/Resend dev plan [9]

Realistically, you could run this infrastructure for well under €30/month during early stages.


How Much Time Would It Take to Build?

Let’s give a realistic time estimate in hours, assuming an experienced full-stack team.

TaskEstimated Hours
Frontend dashboard (basic MVP)20–30
REST API integration & media diff30–40
Storage + recovery logic25–30
Auth, roles, API key flow15–20
Admin tools, reporting, logs10–15
Total MVP scope~100–130 hrs

Note: These are purely indicative.
Actual development time depends on the skillset and structure of your team.
Working with experienced developers who understand serverless, API-first thinking, and WordPress internals can drastically improve speed and code quality.


Tech Corner: Optional Tools That Scale With You

If you’re aiming to scale or automate even further, these technologies are worth exploring:

  • AWS EventBridge
    Used to trigger scheduled events like weekly scans or timed storage actions [6].
  • AWS SQS (Simple Queue Service)
    Useful for queuing tasks like image deletions, storage transitions, or recoveries [7].
  • Google Cloud Tasks
    An alternative to SQS for queuing and managing asynchronous tasks in Google Cloud [8].

These services are not mandatory for an MVP, but they help make your product scalable, resilient, and future-ready.


Final Thoughts

This is a classic example of a “lightweight but powerful” SaaS:

  • Small scope
  • Real value
  • Low cost
  • High leverage

And with the right choices — serverless architecture, simple REST API integration, and automated storage lifecycle — you could build it for pennies on the dollar.

In Part 7, we’ll share something different:
What we chose not to build, and why skipping features can actually make your SaaS stronger.

Stay tuned.


References

  1. AWS Lambda Pricing
    https://aws.amazon.com/lambda/pricing/
  2. Amazon S3 Standard Storage Pricing
    https://aws.amazon.com/s3/pricing/
  3. Amazon S3 Glacier Pricing
    https://aws.amazon.com/s3/storage-classes/glacier/
  4. Amazon S3 Glacier Deep Archive Pricing
    https://aws.amazon.com/s3/storage-classes/glacier-deep-archive/
  5. Supabase Pricing
    https://supabase.com/pricing
  6. AWS EventBridge Documentation
    https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html
  7. AWS SQS Documentation
    https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html
  8. Google Cloud Tasks Documentation
    https://cloud.google.com/tasks/docs
  9. Resend Email Pricing
    https://resend.com/pricing

Leave a Reply

Your email address will not be published. Required fields are marked *

Close Search Window