Six Weeks to Replace HighRadius: What Disciplined AI-Native Development Actually Looks Like
Most people treat “AI-Native development” as a productivity story. Write faster, debug faster, ship faster.
That’s the small version.
The larger version is this: with the right architecture and process discipline, a single developer can design, build, document, and validate an enterprise-grade platform in a timeframe that would be implausible otherwise. Not a prototype. Not a proof-of-concept with rough edges. A production-credible system with real architecture, full documentation, and a working test suite.
I know because I just spent six weeks doing it.
Table of Contents
The Problem
Cash application — the Accounts Receivable (AR) process of matching incoming payments to open invoices — is still manual work at most companies. The systems that automate it are expensive, slow to implement, and brittle when business logic changes. HighRadius is the 800-pound gorilla in the space. It works, but it’s a long cycle: sales, implementation, integration, configuration, training. Months before you’re live. More months before you trust it.
I wanted to know what a different model looked like. Not a vendor product with a sales cycle — an AI-Native platform, built from a clean sheet, with contextual intelligence at the foundation rather than bolted on top.
Six weeks. Three repos. One developer.
Here’s what happened.
The Development Infrastructure
Before a single line of product code was written, the development environment was already in place.
I’ve written before about my pgvector-studiojb semantic knowledge system — and what it produced in production. It’s a PostgreSQL/pgvector-backed MCP server that gives every AI agent I work with persistent, searchable context across all my repositories. Every session I run is logged, ingested, and searchable. Every architectural decision, every code review finding, every deferred item becomes part of a shared memory that any agent can query at the start of a new session.
That system was the backbone of this project. It powered code generation, test authoring, architectural decision-making, and cross-repo coordination throughout the six weeks. When an agent started a session on the remittance parser, it already knew what the matching engine expected. When a code review flagged a security issue, the fix was recorded and the next review built on it. Nothing was re-explained. Nothing was lost between sessions.
This is what made the pace possible. Not raw AI speed — contextual continuity.
The Product Architecture
The platform was built on Angular, .NET 10, and SQL Server — with AI integrated surgically. Sending financial data to third-party APIs is a security surface that demands respect, so integrations were scoped tightly to minimize blast radius. Here’s what it actually did.
Remittance Ingestion
Remittance data arrives in every format imaginable. CSV files from one customer, Excel spreadsheets from another, PDFs from a third, scanned check images with MICR encoding from a fourth. In practice, AR teams spend significant time just normalizing this input before any matching can happen.
The platform eliminated that step. An operator could drop any file — CSV, Excel, PDF, PNG, JPG — into an intake form, and the system would parse and normalize it to the database tables regardless of format. Text files, structured spreadsheets, unstructured PDFs, images with MICR encoding: all handled. If the remittance advice could be received, it could be ingested.
Matching and Intelligence
Once remittances were normalized, matching ran in two modes.
Exact matches were identified and applied automatically. No human required.
For everything else — partial amounts, missing invoice references, ambiguous customer identifiers — the system produced AI-estimated matches with confidence scores. Critically, these estimates improved over time. The more payment history the system accumulated, the better it understood each customer’s patterns: how they format remittances, how they apply discounts, what their common discrepancy types look like.
Customer aliasing handled the identity problem: the same customer arriving under different names, account numbers, or remittance formats would be recognized and consolidated. The system learned the aliases rather than requiring an operator to manually map them.
The result was a matching engine that got meaningfully smarter with use — not because the model changed, but because the historical context it reasoned against kept deepening.
The Stack
Multiple C# .NET 10 projects: controllers, unit tests, integration tests, and SQL integration testing via Docker. NetSuite integration over OAuth2 machine-to-machine. Email processing and outside bank sFTP intake. BAI2 bank file parsing. An Angular frontend with strict 2FA and passkey security — and CSP enforced end-to-end through the full stack.
Why the Repo Structure Mattered as Much as the Code
This is the part I want to spend time on, because it’s the part that made the difference between a clever prototype and something credible.
I worked across three coordinated repositories from day one.
Repo 1: The Core Codebase
The main application. Platform architecture, retrieval patterns, orchestration logic, API surface, data models. The actual thing.
To give a sense of scale: my Ballistics project — a complex C# system I’ve written about before — sits at 1,722 documents and 14,607 chunks in my semantic knowledge system. The cash application codebase was built after Ballistics and was considerably larger. We’re not talking about a weekend project.
Repo 2: The Artifacts and Documentation Repository
This one needs more explanation, because it’s not a standard part of most solo development workflows.
Every significant decision — architectural, implementation, integration — produced a corresponding artifact: a structured document describing what was decided, why, what was considered and rejected, and what the implications were. Every milestone produced a delivery summary. Every significant component produced a design document.
This isn’t documentation-as-afterthought. It’s documentation-as-delivery. The artifacts repo was active from day one and stayed current with the codebase throughout. At any point during those six weeks, you could read the artifacts repo and understand exactly what was built, why it was built that way, and where it was going.
That matters for two reasons. First, it’s what separates “I built a thing” from “I delivered a system.” A codebase alone isn’t an artifact — it’s potential. A codebase with full supporting documentation is an auditable, extensible platform. Second, the artifacts fed directly into the AI agents. My pgvector semantic knowledge system ingested both repos. When an agent started a new session, it had access not just to the code but to the reasoning behind the code.
Repo 3: Smoke Tests and Validation
A dedicated smoke-test repo to validate behavior quickly and continuously as the system evolved.
This deserves more credit than it usually gets. In rapid iteration work, the risk isn’t that you write bad code — it’s that you write good code that breaks something you built two weeks ago and don’t notice until it matters. A maintained validation suite eliminates that class of problem. It also creates a specific kind of confidence that no other practice provides: you can move fast because you know the floor is there.
Each development push could be validated against the full smoke suite. Regressions surfaced immediately. That’s what made the pace sustainable.
AI-Native Code Review as Engineering Process
One more piece that I want to name explicitly: AI-Native code reviews ran throughout the project, not just at the end.
Reviews covered security, best practices, code quality, and implementation discipline — structured across formal review stages with defined scope. Each review ran two passes: a full analysis first, then an evidence-validation pass to remove speculative findings before anything was reported. Security coverage was explicit and threat-modeled — SQL injection, XSS, CSRF, authentication bypass, cookie security, secret exposure, and dependency risks evaluated against the actual codebase, not generic checklists. Architecture compliance, performance patterns, and data integrity were assessed in parallel. Every finding was filed with a specific file path, line range, failure mode, and concrete fix. No generic advice. No assumptions. Each component reviewed, scored, and signed off before the next phase began.
The important framing here is that AI review is a force multiplier, not a substitute for engineering judgment. It catches things at scale that manual review misses at pace. Combined with the semantic knowledge system, the reviews were also cumulative: the agent reviewing a new component already knew what had been reviewed before, what issues had been found and fixed, and what patterns had been established. The later reviews were faster and more targeted because of the context built in the earlier ones.
What Six Weeks Produced
A viable operational foundation for AI-Native accounts receivable automation:
- A vector database-backed contextual retrieval and matching layer
- Multi-agent orchestration for specialized reasoning tasks
- Universal remittance ingestion — CSV, Excel, PDF, PNG/JPG, MICR, plain text
- Payment and remittance intake pipeline (including BAI2 bank file, email, and sFTP)
- NetSuite integration over OAuth2 machine-to-machine
- AI-Native invoice-to-payment matching with confidence scoring
- History-driven match improvement and customer aliasing
- Workflow-guided exception decisioning
- Angular frontend with 2FA and passkey authentication
- Fully versioned artifacts and documentation repository — structured for automated technical and user manual generation
- Smoke-test and validation suite
- Multi-agent AI code review history across the codebase
Not every layer built to final production depth. But a serious architecture, built with real engineering discipline, that extends cleanly.
Why AI-Native Development Changes the Equation
Enterprise software is frequently built as though speed and rigor are in tension. The conventional wisdom is: you can move fast or you can do it right, and most fast projects produce the kind of debt that takes years to repay.
I don’t think that’s the fundamental constraint. I think it’s an artifact of manual processes that don’t scale. When documentation, review, and validation are part of the development loop — powered by the same AI systems doing the work — the tradeoff largely disappears.
This project was fast. It was also documented, reviewed, and tested. Those things coexisted because the tooling supported it.
What Comes Next
The architecture extends well beyond cash application. Once you have a foundation of contextual retrieval, multi-agent reasoning, documented delivery, and workflow-oriented validation, you have a template.
The same model applies to any enterprise workflow that involves matching, exception handling, document interpretation, or complex decisioning across fragmented data. DMS platforms, claims processing, compliance workflows — the category is large.
The specific opportunity is not “adding AI to software.” It’s building software around contextual intelligence from the foundation. That changes what’s possible, and it changes what a single developer can deliver in six weeks.
This post is part of an ongoing series on AI-Native development. Related reading: Building a Semantic Knowledge System with pgvector and 9 Days With a Semantic Knowledge System in Production.
More coding articles