Verirow - B2B Data Reconciliation SaaS
Verirow is a B2B data reconciliation SaaS that independently verifies whether records synchronized correctly between business systems. It detects missing records, duplicate keys, and field-level mismatches after an integration run.
It is designed for one specific gap in integration workflows: a process can report success without proving that the source and target data actually match.
I designed and built the product as an independent reconciliation layer that runs after an integration, compares the two sides, classifies data issues and keeps a history of what was verified.
What began with Boomi as the first focused integration use case has expanded into a broader verification platform with dedicated workflows and product pages for multiple integration environments, including Workato.
For the first focused use case, see how to verify data after a Boomi process run.
THE PROBLEM
Integration monitoring usually tells you whether a process executed successfully. But process-level success and data-level correctness are not the same thing.
A completed sync can still leave missing records, wrong field values, duplicates or partial mismatches between the source and target systems.
The difficult part is that these issues may remain invisible until someone notices them downstream. I wanted a system that could answer a different question after the integration finishes: what actually arrived?
THE PRODUCT
Verirow adds an independent verification step after the existing integration workflow.
Integration runs → Verirow is triggered → Source vs target reconciliation → Result recorded
The product compares records using a defined key and selected fields, then separates the result into clear reconciliation states: OK · Missing · Different · Duplicate.
Boomi became the first focused use case because the distinction is easy to understand: Boomi moves the data. Verirow verifies the result.
The verification layer does not replace the integration platform or create a second sync process.
THE RESULT
Verirow became a working B2B SaaS platform for independent post-sync verification rather than a single-purpose comparison utility.
The product now combines:
Source and target connections
Saved verification checks
Record-level reconciliation
Missing / Different / Duplicate detection
Run history
Integration-triggered execution
Alerts
Multi-tenant workspaces
Email/password and Google authentication
Workspace-scoped billing
Paddle subscription management
Encrypted credentials
Security controls for external connections
Boomi and Workato integration-specific product flows
Public guides, onboarding and pricing
The backend test suite covers the reconciliation engine and security-critical connector behavior, and performance tests have been run against datasets up to 100,000 records.
The most important product decision was keeping verification independent from the integration itself.
Instead of trusting that process success automatically means data success, Verirow creates a second, explicit answer:
Verify every row. Trust every sync.
Try Verirow
Verirow adds an independent verification step after an integration run so teams can compare source and target data and review OK, Missing, Different and Duplicate results.
Dedicated integration flows are also available for Boomi and Workato.
SYSTEM ARCHITECTURE
Verirow is built as a multi-tenant SaaS platform rather than a one-off comparison script. The system coordinates several product layers:
Connections - reusable source and target connection configuration for HTTP JSON and structured data workflows.
Saved Checks - persistent verification definitions containing the source, target, matching key, selected fields and comparison configuration.
Reconciliation Engine - record matching and classification logic that identifies OK, Missing, Different and Duplicate results.
Run History - completed checks remain available with status, issue counts, trigger information, duration and timestamps.
External Trigger - integrations can start a saved verification after their own process completes instead of requiring a manual run.
Alerts - verification outcomes can feed notification workflows when issues require attention.
Workspace Layer - multi-tenant accounts, workspace membership, role-aware access and workspace-scoped data isolation.
Authentication Layer - email/password and Google OAuth, session versioning, revocation, recovery and verification flows.
Billing Layer - Paddle subscriptions are linked to workspaces, with signed webhook processing and persistent subscription state.
Connect → Define Check → Trigger → Reconcile → Review → History
The architecture keeps the integration process and verification process separate. That makes Verirow useful as an independent control layer rather than another system responsible for moving the data.
THE RECONCILIATION ENGINE
The core product logic begins by identifying the same logical record on both sides of the sync. A stable key connects source and target records, while selected fields define what should be compared.
The result is classified into four operational states:
OK - the expected record exists and selected values match.
Missing - a source record cannot be found in the target.
Different - both records exist but one or more compared values differ.
Duplicate - the comparison finds repeated keys where a unique record was expected.
This turns a broad question like “did the sync work?” into a reviewable set of record-level outcomes.
REPEATABLE SAVED CHECKS
A verification workflow becomes more useful when it can be reused. Saved Checks let the user configure the comparison once and run the same verification after future integrations.
The user can define the source, target, key and comparison fields without rebuilding the setup every time. This also gives the product a clean separation between configuration and execution: the check describes what should be verified, while each run records what happened at a specific point in time.
HISTORY AS AN AUDITABLE RESULT
Verification should not disappear when the browser closes. Verirow records completed runs in History with the run status, source and target, number of checked records, issue count, trigger type, duration and date.
This creates a visible operational trail instead of reducing reconciliation to a temporary console output.
MULTI-TENANT WORKSPACES
Verirow now includes a workspace model rather than treating every account as a single isolated user. Users belong to workspaces through explicit membership records, with role information and an active workspace carried through the authenticated session.
Connections, saved checks, run history, alerts, audit events and billing state are scoped to the active workspace. That creates a clean tenant boundary and makes the product architecture suitable for teams rather than only individual accounts.
AUTHENTICATION AND ACCOUNT FLOWS
The application includes email/password authentication and Google OAuth, with first-workspace creation built into onboarding. Session versioning allows sessions to be invalidated when account security changes, while password recovery and email verification complete the account lifecycle.
Authentication is connected to the workspace model, so the session identifies both the user and the workspace they are currently operating in.
BOOMI INTEGRATION WORKFLOW
For Boomi, I designed the integration around a protected external trigger. A Boomi process can complete normally and then call Verirow to start a predefined saved check.
The existing integration architecture remains unchanged. Verirow acts as the verification layer after it.
Boomi process → Protected trigger → Saved check → Reconciliation → History
I also built a dedicated Boomi landing page and setup guide around this use case so the product can be understood without presenting it as another generic integration tool.
BEYOND A SINGLE INTEGRATION PLATFORM
The product architecture was intentionally kept independent from one integration vendor. After the Boomi workflow, I added a dedicated Workato product page and guide while keeping the same underlying verification model.
The public product layer now includes a generic Verirow landing page plus integration-specific pages and setup guides. This lets the product speak directly to different integration environments without changing the reconciliation engine underneath.
BILLING AND SaaS MONETIZATION
Verirow now includes production billing for the Founder plan at $29/month.
Paddle Checkout handles payment collection, while subscription state is stored against the workspace rather than only the individual user. Signed Paddle webhooks are verified before billing state is updated, and webhook event IDs are stored to prevent duplicate processing.
This makes billing part of the same multi-tenant product model as authentication and data access instead of a disconnected checkout layer.
SECURITY AND TENANT ISOLATION
Because Verirow connects to external systems and stores reusable configuration, security had to be part of the application architecture rather than an afterthought.
The product includes account authentication, workspace-level tenant isolation, encrypted connection credentials, session expiry and revocation, rate limiting, URL validation and SSRF protections for external HTTP workflows.
External verification triggers are protected so they can be called by an integration workflow without exposing a general unauthenticated execution endpoint.
PRODUCTION INFRASTRUCTURE AND TESTING
The production architecture separates the application layers: the Next.js frontend is deployed on Vercel, the Fastify API runs on Render, and PostgreSQL is hosted on Neon.
The automated test suite covers the reconciliation engine, credential security, URL validation and HTTP connector resilience. Performance testing has also been run against datasets up to 100,000 records.
BUILT AS A REAL SaaS PRODUCT
I designed and developed Verirow end-to-end: product definition, UX/UI, reconciliation logic, API architecture, authentication, database structure, connection management, workspace tenancy, security controls, external triggers, history, alerts, billing, onboarding, integration-specific guides and deployment.
The frontend is built with Next.js, React and TypeScript. The API uses Fastify, with PostgreSQL on Neon as the production data layer. The frontend is deployed on Vercel and the API on Render.
Billing is handled through Paddle, with subscriptions linked to individual workspaces and webhook events verified before subscription state is updated.
