Where we are.
An honest read on the current state of Heritage CloudHub, written by someone who has spent the last forty-eight hours inside the codebase. Most of it is recoverable. Some of it is not the foundation a long-lasting product should be built on.
Heritage CloudHub is, today, four separate applications that share almost nothing in common: a WordPress marketing site held together by a single eleven-thousand-four-hundred-line plugin, a React customer portal, a React admin dashboard, and a Node API. None of them know about the others. Each was built, in some sense, in a different decade by a different person.
The plugin alone, hch-ui-polish.php, is doing the work of six unrelated programs: a giant inline stylesheet with twelve hundred and seventeen page-specific selectors, a JavaScript engine that rewrites the page after Elementor finishes drawing it, a blog system with a hand-built data model, a virtual-page renderer for the legal pages, an output buffer that rewrites copy on the fly, and a collection of header and footer markup. To change anything visible on the marketing site requires reading a meaningful slice of that file to understand which override is going to win. Recent debugging confirmed the shape of this problem: the back-side text on the homepage flip cards refused to turn white because a homepage-wide rule beat the override on specificity, and even after fixing it the SiteGround cache served an older version of the page for another half-hour.
The portal and the admin dashboard are nearly identical applications with no shared code. Both import the same Radix UI components, the same Tailwind, the same Zustand. A change to a button has to be made in two places. A bug fix to the auth flow has to be applied twice. Visual drift between the two is inevitable; some of it is already there.
The database underneath the API has no migration history. The schema is regenerated on every server restart by Sequelize's sync({ alter: true }) call. There is no audit trail of when columns were added, no way to roll back a deployment that introduces a schema change, no record that anyone is able to verify against. This is a real production risk, not a stylistic one.
Backend deployments happen automatically when code lands on the main branch. Portal and admin deployments are gated behind a manual click. So when a backend change requires a frontend change to also ship, the backend ships first and the frontend trails by minutes or hours, with no visibility into the gap.
None of this is anyone's fault. Most of this state was inherited from the legacy vendor whose work has been getting repaired for the last several months. Every fix in the plugin solved a real problem; the plugin just grew to compensate for problems the current team did not put there.
What is working
The product technically functions. The portal lets paying members sign in, manage their vaults, upload content, invite family, and view their plan. The API serves these flows reliably enough that the last several months have not been dominated by outage management. The marketing site renders correctly for the visitor; the back-end fragility is invisible to the buyer.
That is real. The bar for an early-stage product is that it works for the customer, and Heritage CloudHub does.
What is not working
The product feels generic against the competition. The marketing site reads as a heritage-themed cloud-storage company, which is what every other product in this market also reads as. The differentiators that could be there are not visibly there. The aesthetic is dated in ways that are subtle on a Tuesday and damning on a Sunday morning when an actual prospect is comparing it against Storyworth or Remento on her phone in bed. Seen with fresh eyes, the marketing site reads older than the audience Heritage CloudHub is actually trying to reach.
The product also does not yet have a defensible position. The features Heritage CloudHub leads with — a private family vault for photos, recipes, voices, stories — are features that any well-funded competitor could replicate in a quarter.
The maintenance tax on every change is high enough that adding new features is several times slower than it should be, which compounds the competition problem.
Why the status quo will not sustain
None of this would be a crisis if Heritage CloudHub had eight engineers and a runway of three years. It does not. The compounding cost of a slow-to-change codebase against a category that is filling up with capitalized competitors is the real risk. By the time the first marketing campaign generates serious attention, the product needs to be at a place where a visitor can see a clear reason to pick this over the alternatives. It is not at that place yet.