Engineering Proof

The public launch needed to explain several related exterior home-improvement services without making homeowners decode trade terminology. Service details, Tampa Bay coverage, community reviews, and estimate requests also needed clear destinations instead of competing on one overloaded page.

Launched a focused managed website with dedicated routes for seamless gutters, pool screen enclosures, screen repair, soffit and fascia, and gutter guards. The information architecture also separates service areas, reviews, privacy information, and the estimate path so visitors can move from a specific need to a relevant next step.

The live site now gives each major service an indexable destination and connects the primary customer journeys to an estimate request. It also provides one maintained public reference for services and coverage instead of relying on disconnected descriptions elsewhere.

A paid-search visit begins on mendola.tech but signup and onboarding continue on customer.mendola.tech. Campaign parameters, Google click identifiers, landing-page context, and purchase events can be lost or duplicated when that handoff is treated as an ordinary outbound link.

Implemented a shared GA4 property and cross-domain linker, forwarded UTM fields plus GCLID, GBRAID, WBRAID, and landing variant into the hash-routed signup, sanitized and stored those values server-side, and instrumented the funnel from signup through a transaction-ID-based purchase event.

Repository tests now verify the complete synthetic attribution payload on both sides of the handoff, require lead tracking only after a successful submission, and require purchase values to come from the recorded checkout amount and currency instead of a hard-coded number.

Public review data can arrive through different Google surfaces, service-area business discovery can be inconsistent, and a partial refresh must not silently replace a richer verified cache or inflate structured-data claims.

Built a Places API path using a configured Place ID, guarded fallback queries, and a browser extractor for public review pages. The pipeline preserves original customer wording, supports rating-only reviews, sanitizes provider failures, keeps richer cached data when a refresh is partial, and synchronizes visible review output with business schema safeguards.

Mendola.Tech now has a dedicated review page, reusable review components, visitor-safe fallback actions, and automated fixtures covering API normalization, public-page extraction, missing fields, lookup alternatives, and empty results.

A managed service becomes confusing when its public price, signup language, disclosures, checkout, billing portal, and backend routes describe different versions of the offer. Removing an old option from one screen is not enough if another active surface still exposes it.

Aligned the active $299 monthly managed-website offer across the marketing site and customer panel, versioned the current disclosure, updated checkout and subscription handling, and removed obsolete add-on routes and controls. Cross-surface tests scan the active offer files for the current terms and for stale pricing or retired options.

The active customer journey now presents the same base offer through pricing, signup, disclosure acceptance, checkout, and billing management. Automated checks fail when an outdated $199 price or removed add-on reappears in those covered surfaces.

Organization-specific analytics and local-presence data need delegated Google access, but OAuth credentials and refresh tokens cannot be pushed into frontend code. Customers also need understandable states when a property is unselected, an API is unconnected, or Google has not approved enough quota.

Added server-owned OAuth configuration, connection records, callback and management handlers, organization-level admin controls, GA4 reporting ranges, and Google Business Profile surfaces. The frontend receives status and permitted results while client secrets remain server-side, and provider failures are translated into clean precondition or quota messages.

Administrators can manage Google connections for an organization and request the enabled analytics or business-profile views through one permissioned integration boundary. Tests verify the connection surfaces and confirm that the configured OAuth secret does not appear in frontend assets.

A customer portal needed employee access, organization assignment, and sales attribution without sending staff through customer onboarding or treating current account ownership and original sales credit as the same relationship.

Built a dedicated tokenized employee invitation and signup path, an access-management console, a reusable employee directory, assignment and sales-credit selectors, and separate organization fields for the assigned employee, seller, and close date. Conversion logic fills missing organization attribution while keeping the organization as the durable record.

The platform now models ongoing responsibility independently from sales credit and keeps employee account creation outside billing and customer onboarding. Tests cover navigation, tokenized signup, access promotion and removal, directory-backed selectors, and pay-period reporting fields.

A third-party backlink provider can expand discovery, but its live and lost labels are external claims rather than proof. Credentials, pagination, retries, daily spend, response size, and incomplete snapshots also create operational risks if the integration is allowed to write directly into local truth.

Built one backend-only DataForSEO client with HTTPS and endpoint restrictions, bounded timeouts and response size, finite pagination, idempotent-read retries, persisted request and cost ceilings, and safe structured errors. Provider claims are stored separately, deduplicated as candidate edges, and passed to an independent source-page verifier before local state changes.

The platform can use bounded provider snapshots to widen discovery without letting an omitted or provider-lost record directly mark a link as locally lost. Persisted usage accounting and per-run and per-day limits stop additional requests after configured ceilings are reached.

Historical links can disappear from a current provider snapshot while remaining discoverable in public archives, crawl graphs, or first-party referral records. The same target may also have moved between apex and www hosts, so searching only one hostname can miss relevant evidence.

Built separate discovery lanes for Common Crawl, Wayback history, host-graph data, and GA4 referral target pages; normalized apex and www target identities; preserved source-specific evidence; and sent recovered candidates through exact target matching and live source-page verification.

The recovery workflow can reintroduce historical candidates from either host form without treating archive absence as proof that a link never existed or is currently lost. Tests cover dual-host resolution, archive metadata, compressed index ranges, and candidate handoff boundaries.

Long-running crawls and archive workers can be interrupted by API restarts, deployment changes, network failures, or resource pressure. Leaving those runs marked as active, replaying completed work, or losing every worker's progress makes later reports difficult to trust.

Added durable run and job states, leases, idempotency keys, independent worker checkpoints, bounded concurrency, disk reserves, recovery routines, and explicit restart handling for crawl, backlink, graph, archive, and news-ingestion lanes. Recovery behavior is tested separately from completed terminal records.

The database-backed recovery test proves that an interrupted crawl and its job are closed once with an explanatory event, a completed crawl is left unchanged, and repeating recovery is a no-op. Other pipeline lanes preserve checkpoints so restart work can resume from durable boundaries instead of beginning blindly.

A React site needed a maintainable research workflow in which one approved article record controls the visible page, canonical metadata, Article schema, RSS item, sitemap date, prerendered route, and internal links while unapproved drafts remain outside every public surface.

Built a validated Markdown contract, separate draft and published collections, sanitized rendering, generated React records and routes, canonical and Article metadata synchronization, RSS and sitemap generation, static prerendering, and negative tests that assert draft slugs never enter routes or feeds.

The August 2026 deployment published three approved research articles, generated 28 prerendered site routes and 24 sitemap URLs, and kept three additional drafts at 404 responses and out of RSS and the sitemap. The repository's 27-test suite and GitHub Pages build passed before deployment.