My SaaS runs on static HTML. The build was the easy part.

PingClass — Thu, 08 Oct 2026 16:20:56 +0000

Honestly,
When I tell people PingClass has no frontend framework — no React, no build step, just .html files — the first question is always about the stack. "Doesn't that get unmanageable?"

Honestly? The rendering layer has never been the hard part. I launched on static HTML plus Supabase, and then real tuition centers started using it. Everything that got hard was underneath: money, automation, and the database boundary.

This is what shipping a no-framework SaaS actually looked like after launch.

The stack that never changed

Still static HTML + vanilla JS on Vercel, still one Supabase project (Postgres + Auth), still a handful of serverless functions for the dynamic bits. In months of adding payments, reminders, notifications and scheduled jobs, I have not once thought "this needs a framework." Every page is a real .html file, so Googlebot, ClaudeBot and PerplexityBot read it natively — that part was solved on day one and stayed solved.

The interesting work was the plumbing.

Rendering: solved, don't touch it

Briefly, because it's the least interesting now: marketing pages are static, dashboards are static pages that talk to the database directly, and dynamic content like approved reviews is also rendered statically on the homepage so crawlers see it. Scripting then skips what's already in the HTML. Rating data is baked in as JSON-LD, llms.txt tells AI crawlers what's what, and IndexNow pings Bing on every deploy.

None of that has needed maintenance. It just works, which is the point.

Money is a state machine, not a button

The moment I added payments, the naive version stopped being okay. A "Pay" button is easy. What's hard is that money-as-a-state can be wrong in ways a normal bug can't:

Orders are created server-side, never on the client, so the amount can't be tampered with.
The success callback is verified server-side against a signature — the browser claiming "paid" means nothing.
Payment is idempotent: the same event arriving twice must not create two subscriptions.
Every state change is recorded so it can be reconciled later.

I stopped thinking of "subscribe" as an endpoint and started treating it as a state machine with a verified transition. That mindset shift mattered more than any library.

The automation is what makes it feel like a product

A dashboard alone is just a nicer spreadsheet. What actually earned the subscription was the stuff owners never have to remember:

Dues auto-generate per student × batch for the current period, with a duplicate guard and a nightly scheduled job.
Payment reminders, escalation, and receipts go out by email and push.
Attendance produces absence alerts and a daily reminder, with dedupe so nobody gets pinged twice.
Plan-expiry notices, invites, and announcements all fire themselves.

All of it is scheduled functions and managed Postgres jobs. No queue, no worker fleet, no scheduler SaaS.

Error reporting without a vendor

I didn't want to add a third-party error tracker as yet another dependency, so I built the small version I needed. Every page loads a tiny script that prints a light developer greeting and captures uncaught errors and unhandled rejections. Those reports go to my own endpoint, which merges duplicate crashes so I see distinct problems instead of a flood.

Little, dependency-free, and good enough — which is the recurring theme.

Security lives in the live database, not your migrations

The scariest issue I've dealt with wasn't in my application code. It was in database permissions.

Here's the part I wish someone had told me earlier: the effective privileges in a system live in the live database, not in your migration files. Your history can look perfectly locked-down while the actual, running database has drifted away from it. A revoke you rely on can be quietly undone by some later, unrelated change — and staring at git log will never reveal it.

So I stopped reasoning from the files and started asking the database itself. Now, after any change that touches permissions, I verify against the live system directly: which objects are reachable by which roles, and whether that matches intent. If the live answer disagrees with the files, the live answer wins.

That one principle has done more for my sleep than any framework ever did, and it costs nothing but discipline.

Backups, or you don't have a business

Once institutes keep attendance and fee records in your system, "did the backup run?" becomes existential. So snapshots run automatically, and something alerts me if one didn't. There's a retention policy and self-serve account deletion to go with it.

Backups you have to remember to check aren't backups. They're a liability with extra steps.

What I deliberately did not add

A frontend framework. The static pages have had no build-step problems because there's no build.
A queue / worker system. Scheduled functions and managed Postgres jobs cover every background task I have.
A third-party error tracker. The small in-house version does exactly what I need.
A separate "app." It's a PWA with a service worker and push notifications. Close enough for now.

The meta-lesson

Spend your complexity budget on the database boundary — permissions, payments, backups — and keep the rendering layer boring. Static HTML plus a managed Postgres plus a CDN has carried this further than I expected, at near-zero cost, and it made the "will people find it?" problem trivial because every page is HTML that search engines and LLMs read natively.

The framework was never going to be what made this work. The unglamorous stuff did.

PingClass is live — free up to 20 students, then ₹249/mo and ₹599/mo, also on Product Hunt and G2. Happy to go deep on the money state machine, the static-HTML approach, or the tuition-center niche.

I built a tuition management SaaS with plain HTML, Supabase and Vercel

PingClass — Mon, 21 Sep 2026 15:50:44 +0000

I spent a few weeks building PingClass — institute-management software for small tuition and coaching centers in India (1–5 teachers, under ~200 students). The kind of businesses that still run on a patchwork of Google Sheets, paper registers, and four WhatsApp groups.

The interesting part isn't the product though, it's how it's built: no framework, no frontend build step, static HTML files, a Postgres database, and a free CDN. I want to share the stack and what I learned, because this is the least-discussed way to ship a SaaS that runs and ranks.

The constraints that pushed me here
I'm a solo maker shipping in evenings. I didn't want a toolchain I have to babysit.
The customers are offline-first small business owners. They open a link, it should just work, load fast, and not break.
I wanted the site's marketing pages to be instantly crawlable by Google, Bing, and the AI search bots — static HTML is the most undisputed, indexable thing that exists.
The stack
Static HTML + vanilla JS -> Vercel (free tier, global CDN)
Supabase (Postgres + Auth) -> tenant data, users, reviews
JSON-LD structured data -> SEO / AI answer engines
llms.txt -> explicit signal for AI crawlers
IndexNow -> instant Bing re-crawl on deploy
Why static HTML
Every page is a real .html file. There's no hydration, no #app shell, no client routing. Googlebot, ClaudeBot, PerplexityBot and GPTBot all just read the HTML — headings, text, structured data — directly. The marketing site lives in the most defensible form SEO can have.

The interactive parts (auth, dashboards) are separate static pages that talk to Supabase with client-side JS.

Supabase for everything data
A single Supabase project handles:

Postgres — core tables: students, batches, attendance, fees, announcements, parents.
Auth — email-based sign-in with admin/teacher/parent roles.
RLS policies — row-level security so an institute only ever sees its own rows, enforced at the database level.
The fee module auto-generates monthly dues per student × batch and lets owners send due reminders — that's where the "fewer spreadsheets" pitch actually lands.

One query the site runs for its public reviews section:

const { data: reviews } = await supabase
.from('reviews')
.select('author_name, quote, rating, institute')
.eq('status', 'approved')
The tricky bit: reviews are loaded client-side, so they'd be invisible to crawlers. I solved it by rendering the approved reviews as static HTML on the homepage too, and having JS skip authors that are already statically present. Same for the aggregateRating structured data — crawlers get the facts front-and-center.

What I'd do differently (maybe)
Payment gateway. Ledgers and reminders work; actual collection is still manual. A Razorpay integration is the next obvious wedge.
Mobile app. Parents want an app. Web-first was the right place to start, but "Is there an app?" is the #1 question.
Validate before building as much. The fee/attendance/parent-communication triangle seems right, but I'd have liked real signed-up centers earlier rather than a polished product first.
The meta-lesson
You don't need React + a queue system + Kubernetes for a tool that two dozen tuition centers might use. Static HTML + a managed Postgres + a CDN handled everything, cost almost nothing, and made the "will people find it?" problem dramatically easier — because every page is HTML that search engines and LLMs read natively.

If you're building a small vertical SaaS and feel the pull toward a heavier stack, ask whether the extra machinery earns its keep.

PingClass is live — free tier up to 20 students, then ₹249/mo and ₹599/mo. As also featured on Product Hunt and G2. Happy to answer questions about the stack or the tuition-center niche.

DEV Community: PingClass