DEV Community: Sreegeethesh

Your SaaS Isn't Production-Ready Just Because `npm run build` Works

Sreegeethesh — Wed, 02 Sep 2026 11:48:48 +0000

A few days ago, I was going through one of my SaaS applications before shipping it.

The product worked.

The UI looked good.

The API worked.

Authentication worked.

And technically, I could have deployed it and called it done.

But opening DevTools, viewing the page source, checking how Google would understand the site, and looking at the production bundle told a different story.

A working application is not necessarily a production-ready application.

So I ended up doing a complete frontend production-hardening pass.

Here is the checklist I now use before calling a SaaS frontend ready for production.

1. Build a Proper Page Source

Modern React applications can easily produce pages where the initial HTML tells crawlers almost nothing about the application.

The browser eventually renders everything correctly, but crawlers, link previews, search engines, and other machines still benefit from meaningful HTML.

I started checking the actual page source instead of judging the application only from what React rendered on screen.

The page should expose enough meaningful information for machines to understand what it represents.

2. Build a Custom 404 Page

A default server error or blank React page is a terrible dead end.

A proper 404 page should:

clearly explain that the requested page doesn't exist,
maintain the product's branding,
provide navigation back into the product,
link to important pages,
and return the correct HTTP status where possible.

Even error pages are part of the product experience.

3. Give Every Page a Unique Title

One of the easiest mistakes in a SPA is having every route use the same title.

For example:

My SaaS

is much less useful than:

AI Video Editor | ProductName

or:

Pricing | ProductName

Every important route now gets its own descriptive title.

This improves search visibility, browser-tab usability, bookmarks, and link previews.

4. Write Useful Meta Descriptions

I also stopped using generic descriptions such as:

The best platform for everything.

Every important public page gets a description explaining what that specific page actually offers.

Good metadata should help someone decide whether the page is relevant before they even open it.

5. Add Canonical URLs

Applications often accidentally expose the same content through multiple URLs.

Query parameters, alternate paths, trailing slashes, campaign URLs, and routing behavior can all create duplicate versions of a page.

Canonical tags tell search engines which URL should be considered the authoritative one.

A small detail, but an important one.

6. Use One Clear Primary Heading Per Page

Design systems make it surprisingly easy to build pages that look visually correct while having terrible document structure underneath.

Each page should have a clear purpose.

The primary heading should communicate that purpose.

Then the remaining headings should form a logical hierarchy.

Not because an SEO plugin says so.

Because semantic HTML makes the page easier for search engines, accessibility tools, browsers, and humans to understand.

7. Generate a Sitemap

If the application contains publicly indexable pages, I add a sitemap.xml.

It contains the canonical public URLs I actually want crawled.

The important part is not merely generating a sitemap.

It is making sure the sitemap doesn't advertise pages that should never be indexed in the first place.

8. Configure `robots.txt`

Then comes robots.txt.

It communicates which sections crawlers should or shouldn't access and points them toward the sitemap.

For SaaS products, this becomes especially useful when separating public marketing pages from dashboards, authenticated routes, internal tools, or temporary environments.

9. Add `llms.txt`

This one is newer.

Alongside traditional search-engine optimization, I also started thinking about how AI systems understand products.

I added an llms.txt file containing a concise, machine-readable explanation of the product and its important resources.

Whether llms.txt becomes a universal standard or not, the underlying idea is worth paying attention to:

websites are increasingly being consumed by machines other than traditional search crawlers.

SEO is slowly becoming broader than Google.

10. Stop Treating the Favicon as an Afterthought

That tiny icon appears everywhere:

browser tabs, history, bookmarks, shortcuts, search interfaces, and sometimes mobile surfaces.

I replaced the placeholder favicon with something simple, recognizable, high-contrast, and consistent with the product identity.

Small visual elements can have an outsized effect on how finished a product feels.

11. Add Internal Links and Breadcrumbs

A lot of SaaS landing pages behave like isolated islands.

I started deliberately connecting related pages.

Features → relevant use cases.

Blog posts → related documentation.

Documentation → product pages.

Child pages → parent sections.

Where the information hierarchy justified it, I added breadcrumbs as well.

Good internal linking helps users navigate while also helping crawlers understand the structure and relationships between pages.

12. Add Structured Data

Humans understand a page through visual context.

Machines don't always get that luxury.

Structured data gives additional context about what the page represents.

Depending on the page, this can describe things such as:

the organization,
software/application information,
articles,
breadcrumbs,
FAQs,
or other supported entities.

For breadcrumb-enabled pages, I also added breadcrumb structured data rather than relying only on the visual component.

13. Fix Every Production Console Error

One rule I started following:

a production browser console should be boring.

No mysterious errors.

No failed requests.

No hydration problems.

No missing assets.

No repeated warnings that everyone has learned to ignore.

Warnings have a tendency to become background noise.

And when the important error finally appears, nobody notices it.

14. Disable Production Source Maps When They Aren't Needed

Development source maps are incredibly useful.

Production source maps require more thought.

Depending on the deployment model, publicly accessible source maps can expose significantly more information about the application's source than intended.

For applications that don't need publicly shipped source maps, I disable them in the production build or upload private maps only to the monitoring platform that requires them.

15. Reduce Massive JavaScript Bundles

Then I opened the bundle output.

This is where things usually get interesting.

A beautiful landing page shouldn't require downloading a ridiculous amount of JavaScript before becoming useful.

I started looking for:

oversized dependencies,
libraries imported globally,
components that could be lazy-loaded,
routes that could be code-split,
duplicate dependencies,
unused packages,
and features that shouldn't be in the initial bundle.

Bundle size is not just a Lighthouse metric.

It affects actual humans using slower hardware and slower networks.

16. Remove Every Default Vite/React Placeholder

This sounds obvious.

Yet production applications constantly ship with traces of their scaffolding.

Vite logos.

React favicons.

Default metadata.

Placeholder page titles.

Starter README text.

Example assets.

Development console messages.

Boilerplate copy.

I now search the repository before release and remove anything that makes the application look like a starter template instead of an actual product.

The Bigger Lesson

None of these changes individually feels revolutionary.

That is exactly why they get ignored.

Developers naturally focus on the difficult parts:

authentication,
databases,
payments,
AI pipelines,
background jobs,
infrastructure,
and application logic.

Then we finish the feature and mentally declare the product complete.

But production quality lives in hundreds of smaller decisions surrounding the feature.

Can Google understand the page?

Can an AI system understand the product?

Does the browser console stay clean?

Does a broken URL still feel like part of the application?

Are users downloading JavaScript they don't need?

Does the website still advertise the framework used to scaffold it?

Does every page actually explain what it is?

These aren't glamorous engineering tasks.

But together they make the difference between:

“I built a React app.”

and

“I shipped a product.”

My current pre-production frontend checklist:

Meaningful page source
Custom 404
Unique page titles
Page-specific meta descriptions
Canonical URLs
Semantic page headings
sitemap.xml
robots.txt
llms.txt
Product-specific favicon
Internal links + breadcrumbs
Structured data
Zero unexplained console errors
Production source-map strategy
JavaScript bundle optimization
Zero framework placeholders

I'm probably going to keep extending this checklist as I ship more products.

Because shipping the feature is only half the job.

The other half is making the web understand what you shipped.

# I Built My Developer Portfolio as Peter Parker's Lab 🕷️

Sreegeethesh — Thu, 13 Aug 2026 06:21:19 +0000

I could have built another developer portfolio.

You know the one.

Dark background.

Glowing buttons.

"Full Stack Developer | AI | Cloud | DevOps"

Six project cards.

GitHub link.

Done.

But honestly, that doesn't feel like me.

Before I was interested in AI, software engineering, cloud, automation and all the other things I keep breaking and rebuilding, I was just a kid who loved Spider-Man.

And the older I got, the more I realized that I didn't actually relate to Spider-Man because he was a superhero.

I related to Peter Parker.

The curious kid.

The awkward kid.

The kid who builds things.

The kid who experiments.

The kid who fails and somehow keeps going.

That felt familiar.

So when I started building my portfolio, I wanted it to represent that.

I called it:

🧪 Peter Parker's Lab

The idea is that my portfolio is basically my digital lab.

A place where I can show what I'm building, what I'm learning and what I'm experimenting with.

🕷️ Peter Parker → curiosity

🕸️ Spider-Man → persistence

💻 Developer → everything I'm building today

And honestly, "lab" describes my development journey pretty well.

I build something.

It breaks.

I investigate why.

I fix it.

Then I get another idea and break something else.

😂

That's the fun part.

I'm currently interested in building things around:

AI
AI agents
automation
full-stack applications
developer tools
cloud infrastructure
DevOps
local-first software

I'm not trying to pretend I've mastered all of it.

I'm trying to keep learning by building real things.

That's what I want this portfolio to show.

Not just a list of technologies.

Not just a list of GitHub repositories.

But the problems I'm curious about and the things I'm actually trying to create.

🌐 Peter Parker's Lab

https://peterparker-lab.vercel.app/

This is version one.

I'll keep changing it as I change.

New projects.

New experiments.

New ideas.

Probably new bugs too.

Because maybe the best portfolio isn't one that says:

"Look how much I know."

Maybe it's one that says:

"Look what I'm curious enough to build next."

🕷️❤️

And yes...

I still think Spider-Man is one of the coolest characters ever.

Some things don't change.

I Built an Open-Source AI Video Clipping Pipeline

Sreegeethesh — Sat, 08 Aug 2026 06:46:05 +0000

I Built an Open-Source AI Video Clipping Pipeline

I wanted a tool that could take a long video and turn it into social-ready clips without uploading the entire video to some SaaS platform.

So I built AutoClip.

The idea is simple:

YouTube URL / Video File
          ↓
      Transcription
          ↓
   LLM Clip Selection
          ↓
   Vertical Reframing
          ↓
    Speaker Tracking
          ↓
   Animated Captions
          ↓
     MP4 Export
          ↓
    Buffer Scheduling

The interesting part is that the video processing happens locally.

AutoClip uses an LLM to identify moments worth clipping, but only the transcript text is sent to the LLM. The actual video stays on the user's machine.

It supports multiple caption styles:

Word Pop
Karaoke Fill
Clean Lower Third
Boxed

The final clips are rendered as 9:16 MP4s ready for social platforms.

Publishing Architecture

I also wanted publishing to follow the same privacy model.

Instead of building a cloud scheduler, AutoClip uses a BYOK approach.

The stack is:

Your PC
  ↓
AutoClip processes video
  ↓
Cloudflare R2
  ↓
Buffer
  ↓
Social Platform

The R2 bucket acts as temporary media storage so Buffer can access the video.

Once the job is handed off, the user's computer doesn't need to stay online.

No central media storage.

No SaaS layer.

No subscription.

No watermark.

No telemetry.

Just your infrastructure and your API keys.

Why I Built It

There are plenty of AI video tools already.

I wanted one where I could actually understand and control what happens to my content.

The goal was:

Your machine edits.
Your Buffer publishes.
Your content stays yours.

AutoClip is open source.

GitHub:

SREEGEETHES / Autoclip

AutoClip

The local-first AI clipper that finishes the job. Drop in a long video → get ranked, caption-burned, speaker-tracked 9:16 clips out — and schedule them to post while your PC is off.

Paste a YouTube link or drop a file. AutoClip transcribes it, uses an LLM to find the moments actually worth clipping, reframes them to vertical while tracking whoever is speaking, burns in animated captions, exports platform-ready MP4s — then hands the finished clips to Buffer to publish on schedule. No accounts with us. No uploads to our servers. No watermarks. No subscription.

Your machine edits. Your Buffer publishes. Your R2 bridges the media. Nobody owns your content but you.

What it does

Ingest anything — a YouTube URL or a local file, hours long or minutes.
Find the real hooks — an LLM reads the transcript and ranks the moments worth clipping, down to the word. Timing…

View on GitHub

I'd love feedback from anyone building content automation, video tooling, or local-first AI applications.

How I built an offline semantic photo search app (Python + Vector DB)

Sreegeethesh — Mon, 03 Aug 2026 10:51:14 +0000

Show DEV 🚀

I built OmniCard, a local-first AI media manager.

Features:

• Semantic image search

• AI captions

• Smart tags

• Duplicate detection

• SQLite + LanceDB

• Desktop application with pywebview

The goal was simple:

Search photos by what's inside them instead of by filename.

Example:

"Drone over mountains"

instead of

IMG_4829.jpg

The app stores everything locally, so your media never leaves your computer.

Live demo:
https://sreegeethes.github.io/Omnicard/

GitHub:
https://github.com/SREEGEETHES/Omnicard

Release:
https://github.com/SREEGEETHES/Omnicard/releases/tag/v1.0.0

Would love feedback from other Python and AI developers.

DEV Community: Sreegeethesh

Your SaaS Isn't Production-Ready Just Because `npm run build` Works

1. Build a Proper Page Source

2. Build a Custom 404 Page

3. Give Every Page a Unique Title

4. Write Useful Meta Descriptions

5. Add Canonical URLs

6. Use One Clear Primary Heading Per Page

7. Generate a Sitemap

8. Configure robots.txt

9. Add llms.txt

10. Stop Treating the Favicon as an Afterthought

11. Add Internal Links and Breadcrumbs

12. Add Structured Data

13. Fix Every Production Console Error

14. Disable Production Source Maps When They Aren't Needed

15. Reduce Massive JavaScript Bundles

16. Remove Every Default Vite/React Placeholder

The Bigger Lesson

# I Built My Developer Portfolio as Peter Parker's Lab 🕷️

🧪 Peter Parker's Lab

I Built an Open-Source AI Video Clipping Pipeline

I Built an Open-Source AI Video Clipping Pipeline

Publishing Architecture

Why I Built It

SREEGEETHES / Autoclip

AutoClip

What it does

How I built an offline semantic photo search app (Python + Vector DB)

Show DEV 🚀

8. Configure `robots.txt`

9. Add `llms.txt`