Sarah
Schmirl

Before Paymerang built invoice and purchase order automation, finance teams were drowning in manual work. Each month, clients processed anywhere from 200 to 10,000 invoices by hand — routing them internally for signatures and approvals through email chains, spreadsheets, and inter-office mail. Invoices fell through the cracks, payments ran late, and purchase orders had to be manually created before any invoice could even be approved. It was the missing two-thirds of the payment lifecycle, and every client felt it.

We were building two greenfield products simultaneously on a foundation that didn't exist yet, with a six-month runway to beta testing — and ERP integrations were expected to follow immediately after. The hardest constraint wasn't technical; it was the infinite possibility problem. When the sky is the limit, it's easy to lose sight of what to build first. I needed to get a viable MVP out the door on a solid foundation, knowing that every architectural decision I made early would either enable or limit everything that came after.

I started by desk-hopping. I sat with our finance team to understand the general ledger. I had our CFO walk me through the full invoice lifecycle — the pain points, the failure modes, the edge cases. I spent time with risk and fraud to understand how bad actors could exploit a payment automation system. I sat with sales to understand prospect verticals, org sizes, and invoice volumes. Most importantly, I sat with existing clients — anyone who approved invoices and was willing to show me their actual workflow. I wanted to understand the sad path just as much as the happy path. That fieldwork gave me the foundation to prioritize features by real impact and build a roadmap that held up under pressure.

The core invoicing workflow was standardized enough across industries that we didn't have to limit our initial target market — we could go broad from day one, which was the right call. The harder decision came with ERP integrations. We quickly discovered that each accounting system outputs data in fundamentally different formats, meaning there was no clean universal connector. Rather than slow down feature development to build perfect integrations, I made the call to prioritize product fundamentals — if paying invoices was still frustrating, no integration would save us. We built the integrations incrementally, prioritized by client demand and deal size.

When Microsoft announced it would no longer support InfoPath, we knew we were on borrowed time. The platform powered critical implementation workflows for 200+ client experience reps — and without Microsoft's support, any bug in production would have no fix path. The bigger problem was what we discovered during discovery: over the years, both the sales and service organizations had developed their own workarounds and ancillary processes on top of the system in ways nobody had documented. There were no subject matter experts who could tell us exactly what the system was doing, for whom, or what would break when we replaced it.

There was no 1:1 relationship between the old system and anything we could build on modern infrastructure — the foundational code simply didn't work the same way. We were doing discovery and development simultaneously, uncovering use cases as we went. Migration also had to happen without disrupting active client onboarding. With hundreds of implementations in flight at any given time, a hard cutover was not an option, and stakeholders across sales, service, and engineering all had different opinions on how to sequence the work.

With widespread buy-in on the need to migrate but no consensus on how, I focused on getting alignment on a phased rollout with a defined hard cutover date at the end. Rather than redesign workflows during migration — which would have multiplied complexity — I made the call to replicate existing functionality as faithfully as possible first, get the team safely onto the new platform, and revisit redesign post-cutover. We ran parallel systems during the transition so no active implementations were disrupted.

The most consequential decision was to replicate functionality rather than redesign it during migration. It was tempting to fix everything at once — the old workflows had real problems — but redesigning while migrating would have doubled the timeline and tripled the risk. I accepted that there would be a known amount of rework post-cutover, communicated that tradeoff clearly to stakeholders, and got alignment on it. That decision is what made zero client service disruption possible.

Before we built a self-onboarding application and implemented agentic AI workflows, successfully onboarding one client location required resources from sales, three different service teams, project managers, client success, and the client themselves. There was a lengthy document checklist that had to be delivered before implementation could even begin. Bottlenecks were everywhere — stalled clients, wrong specialist assignments, weeks of back-and-forth. We were processing hundreds of new clients a day across implementation coordinators in all 50 states. The onboarding experience was the first real touchpoint in the client relationship, and it was consistently frustrating. I've always believed that first impression sets the tone for everything that follows.

The most complex constraint was data sensitivity. We were collecting highly sensitive payroll information from clients, which meant the AI couldn't freely ingest documents — we needed secure delivery, OCR-based ingestion that didn't require clients to reformat anything, and strict data validation at every step. We couldn't account for every edge case, so we implemented chatbots and help articles to handle common stalls, and used machine learning to intelligently predict next steps and guide clients by asking questions rather than expecting them to know what came next. We still find edge cases — and we designed the system knowing we would.

We started by mapping the existing manual workflow in detail, and in some areas had to first standardize the sales and service processes themselves before we could automate anything. AI agents combed through thousands of internal wikis and hours of recorded implementation sessions to identify gaps and disseminate institutional knowledge. We used Claude and Copilot on both the product side and the engineering side — writing stories the AI could consume, letting AI accelerate sprint commitments. This let us fail forward, iterate fast, and redeploy without traditional waterfall overhead.

We took a deliberately conservative approach to AI autonomy. Given the sensitivity of payroll data, every significant AI decision required human review. We set explicit constraints around tone, required data validation at every step, and encoded our values and ethics directly into the agent prompts. We built extensive escalation logic and ran far more testing iterations than originally planned. That conservatism slowed us down at times, but it's what earned stakeholder trust and got the system into production.