The idea
The project is a SaaS platform designed for WordPress site owners and agencies who need reliable automated testing for forms and checkout flows. Its purpose is to detect broken forms, failed payments, and email delivery issues before customers encounter them, thus preventing lost leads and revenue. It provides scheduled testing with detailed failure reports and email verification, functionality not available in traditional monitoring tools.
// Pulumi deploys a bucket to GCP defined by this code
const appDataBucket = new gcp.storage.Bucket(`checkview`, {
location: gcp.config.region,
forceDestroy: true,
publicAccessPrevention: "enforced",
lifecycleRules: [
{
action: { type: "Delete" },
condition: {
age: 90,
withState: "ARCHIVED",
},
},
],
});Tech Stack
Details The platform is built using a microservices architecture
on Google Cloud Run. The frontend uses Next.js 14 with Stripe integration for
billing, while the backend consists of specialized services: test-runner
orchestrates execution via Pub/Sub, test runs Playwright in isolated
containers as Cloud Run jobs, and generator programmatically analyzes
WordPress forms to automatically generate test steps. Notable technical
features include ephemeral job-based execution for cost efficiency, a custom
WordPress helper plugin for API
access, 40+ step types for form automation, and GCS storage for test
artifacts. Pulumi manages all infrastructure as code, enabling
version-controlled deployments and consistent environments across production
and test stacks.
Obstacles
The main technical hurdle was building a reliable programmatic test step generator that could analyze arbitrary WordPress forms and automatically create executable test flows. The challenge involved parsing form HTML to identify field types, understanding validation rules, handling dynamic fields that appear conditionally, and mapping WordPress plugin-specific markup to generic test steps. The solution required building a progressive scanner that walks through form submissions, detects validation errors, and adjusts field values iteratively until a successful submission path is found, then converts that path into reusable test steps stored in the database.
// Scan to generate test steps (heavily truncated for brevity)
async function progressiveScanner(context: FormGeneratorContext) {
while (true) {
const inputs = await getInputs(context);
for (const input of inputs) {
context.currentInput = input.locator;
await processInput(context);
context.currentInput = undefined;
break;
}
}
}Lessons Learned
The project provided valuable insights into two key areas. Firstly, architecting with ephemeral Cloud Run jobs instead of always-on services proved critical for both isolation and scalability. Each test execution gets a fresh container with no state contamination, while the platform can handle burst traffic without pre-provisioning resources. This is critical for large quantities of tests scheduled at the same hour. Secondly, the importance of designing for failure recovery became evident. By implementing retry logic at multiple layers (individual steps, full test runs, and scheduled execution), the system handles transient WordPress API failures and network issues gracefully. This layered approach to resilience proved more reliable than attempting to prevent all failures upfront.