Intake
Next.js product UI, authenticated task creation, Cloudflare R2 document storage
Owned Product Case Study
BankScanPro: building an operated document-data product
A production web product that converts bank statement PDFs into structured export formats through an AI-assisted extraction and validation pipeline.
AI integration and data workflowsRelationship. BankScanPro is built and operated by Pure Insight Technology Ltd. It is owned-product evidence, not client work.
Evidence note. This case uses architecture and product behavior verified against the live product and source repositories. Public product marketing metrics are not repeated here unless they have passed Pure Insight's separate claim review.
Problem
What the system had to resolve.
Bank statements arrive as digital PDFs, scans, and variable layouts rather than one stable table format.
A useful result must become structured data for spreadsheets and accounting workflows, not just extracted text.
Long-running document work needs progress, retry, failure, and cleanup behavior outside a request-response cycle.
Constraints
What made the work non-trivial.
- Document quality and layouts vary across institutions and time.
- Financial documents require explicit storage, access, retention, and deletion boundaries.
- Model output can be syntactically valid while still containing implausible values.
- The product includes authentication, usage control, payments, support, and operations beyond the extraction model.
System path
Architecture expressed as operating responsibilities.
Orchestration
Cloudflare Workers, D1 task state, Queues, progress and callback paths
Extraction
Text and image-aware document processing with model-assisted normalization
Validation
Schema checks, balance relationships, diagnostics, and localized repair paths
Delivery
Structured Excel, CSV, and accounting-oriented export workflows
Operations
Authentication, usage accounting, Stripe payments, email, logs, and support
Approach
How the work was structured.
STEP / 01
Separate intake from processing
The web application accepts work, stores files, records task state, and places processing onto an asynchronous path rather than holding a browser request open.
STEP / 02
Turn extraction into stages
Document parsing, page interpretation, normalization, validation, repair, and export are observable stages with distinct failure information.
STEP / 03
Validate against document logic
Structured output is checked with schemas and statement relationships so uncertain or inconsistent results can be identified before export.
STEP / 04
Operate the whole product
Usage, authentication, payments, email, customer feedback, deployment, and product content are treated as part of the production system.
Evidence
What this case can support publicly.
Inspectable live product
The public product demonstrates the customer workflow and export proposition. Architecture statements were checked against the corresponding source repositories.
Production system boundary
The implementation spans a Next.js Cloudflare Worker, D1, R2, Queues, a separate processing worker, payments, identity, and operational notifications.
Evaluation is part of implementation
The repository documents operation-specific model evaluation, cost boundaries, validation attempts, and diagnostic artifacts rather than treating model choice as permanent.
Transferable lessons
What carries into client delivery.
- A document model is not a document product; reliable intake, state, validation, exceptions, exports, and operations carry much of the engineering work.
- Representative test documents reveal more than generic model benchmarks.
- Deterministic checks and probabilistic extraction should be designed together.
- Provider and model choices need an evaluation and replacement path because capability, cost, and behavior change.
Limitations
What the case does not prove.
- No extraction method is correct for every document layout or scan condition.
- Human review remains appropriate when confidence is low or the downstream consequence is high.
- Accuracy, scale, security, and compliance superlatives from product marketing are not used as service claims on this site.
- Product operation is evidence of implementation experience, not proof that the same architecture fits another organization's data boundary.
Related service
Apply the relevant method to your system.
Technical fit review
A case study is context. Your system still needs its own evidence.
Share the system, workflow, or delivery risk you need to resolve. The first review focuses on fit and a practical next step.
Request a Technical Fit Review