In productionOwner & Founder2025
AiGrow
A SaaS growth platform hardened and taken to marketing-ready state.
AiGrow is a SaaS growth platform that was taken from an 8 out of 10 risk posture to a 2 out of 10, rebuilt on a prerendered React front end with an Express and PostgreSQL API behind a from-scratch OAuth 2.0 identity provider.
What it is
SaaS growth platform brought to marketing-ready state: hardened security, SEO-prerendered frontend, and an auto-blogging engine that researches, writes and publishes optimized articles without human input.
Checkable facts
- 110K+ community built around the platform
- SEO auto-blogging engine (Express + PostgreSQL)
- Security hardened: risk cut from 8/10 to 2/10
What an 8 out of 10 risk posture looks like
A risk score is a judgement about how much of the system an attacker can reach and how far they get once inside. An 8 means the exposed surface is large, the authentication boundary is soft, and a single compromised credential reaches data it should never have been able to reach.
The number is not a vanity metric and it is not a scanner output. It is an assessment of exploitability across the running system: what is exposed, what authenticates, what authorises, and what an attacker holds after the first success.
Scanners find known vulnerable dependencies. They do not find an endpoint that authenticates correctly and then fails to check whether this user may act on this object, which is the finding that actually matters and the one that only reading the system produces.
Where the risk actually was
The largest reductions came from the authorisation layer, not the dependency list. Moving authentication onto a single identity provider with OAuth 2.0 and PKCE removed a whole class of session handling from the application, and per-object authorisation checks closed what remained.
Authentication answers who you are. Authorisation answers what you may touch. Systems fail at the second far more often than the first, because the first is a library and the second is a decision that has to be made at every endpoint.
Consolidating onto PeakCore Auth meant the token lifecycle, the rotation policy and the reuse detection existed once and correctly, instead of being reimplemented per application with a different set of mistakes each time.
Rebuilding the front end for machines as well as people
The front end is React 19 on Vite, prerendered to static HTML and served by Nginx. Prerendering was a requirement rather than an optimisation: a client-rendered marketing site is a blank document to anything that does not execute JavaScript, and that includes several of the crawlers that matter.
The same architecture runs this site. The pages are complete HTML before any script executes, which means the content is legible to a crawler, to a reader with a slow connection and to anything retrieving a passage to quote.
Tailwind 4 on the presentation side, with the API as Express 5 over PostgreSQL.
The publishing engine, and its safety gate
In July 2026 a blog engine was integrated as two API modules, blog-engine and learn, producing search-optimised articles automatically. An unattended publisher writing into a production site needs a gate that rejects its own bad output, and that gate is the part that took the work.
An automated writer will invent a citation, break a version string, or repeat the same call to action eight times, and it will do all of it without failing. The failure mode of generated content is not an error, it is plausible text that is wrong.
The lesson generalises past this project: any unattended process writing into a system you own needs a check at the boundary that is stricter than the process itself. Build the gate before you turn the engine on, not after you find what it published.
Questions
- How is a risk posture score calculated?
- It is a judgement about exploitability across the running system: exposed surface, strength of the authentication boundary, per-object authorisation, and how far a single compromised credential reaches. It is not a scanner output, because scanners find vulnerable dependencies and miss broken authorisation, which is the finding that matters most.
- What produced most of the risk reduction?
- The authorisation layer. Consolidating authentication onto one OAuth 2.0 provider with PKCE removed session handling from the application entirely, and adding per-object authorisation checks closed the class of flaw where an endpoint verifies who you are and then never asks whether you may touch this particular record.
- Why prerender a SaaS marketing site?
- Because a client-rendered page is an empty document to anything that does not run JavaScript, and that includes several crawlers and retrieval systems. Prerendering makes the content present in the HTML itself, which is the precondition for being indexed at all and for being quoted by an engine that retrieves passages.
Facts on this page verified 2026-07-26
