Anesh Parvatha

Wingspan's bulk payroll upload lets a payer invite contractors and submit payables for processing. When we closed a client representing $5+ million in payroll volume, their files jumped to 100,000+ rows, 10x what our pipeline supported. The existing process ran entirely in-browser with no concurrency and took 20 minutes per 10,000 rows, a hard onboarding blocker.

I owned this solo end to end. I migrated the pipeline from Flatfile Portal 2.0 to Flatfile Platform, removing the browser dependency. For concurrency, I used Flatfile's multi-part jobs, splitting data into chunks that are processed in parallel with p-map (concurrency: 50) and automatic retries. I added missing database indexes for contractor lookups and a Redis cache to eliminate redundant lookups caused by out-of-order row processing, then tuned back-end autoscaling for the new load.

I rolled this out gradually via an internal feature-flag system, validating with clients across payroll-volume tiers before the full launch and stress-testing up to 500,000 rows in staging.

IMPACT
100,000-row files are now processed in 20 minutes, validated up to 500,000 rows with no degradation, and the client was onboarded with a zero-risk rollout.

Wingspan's Support and Ops teams resolved customer issues via Notion runbooks: SSH into production through a jumpbox, then copy-paste scripts by hand. Non-technical teams running raw scripts against a payroll production database are friction-heavy and a real compliance risk, especially with broad database access, some of it write.

I proposed and built an internal portal to remove this entirely. Team members search for any user or resource by ID, then use purpose-built tools for common requests: submit a form (a user ID and a reason for disabling an account, for example) instead of running a script by hand. I iterated on this over time: added role-based access control so tools are scoped to who should run them, built an approval system where a manager signs off before a request executes, and added AI-agent-backed workflows, where submitting a form triggers an agent to debug the issue, run root cause analysis, and return findings and resolution steps in the portal.

Result: cut engineering's dependency on maintaining these scripts, restricted production database access down to a handful of people with read-only access, and meaningfully reduced customer turnaround times, improving SLAs overall.

Wingspan's payer invoicing lacked a configuration layer: every client used the same invoice-creation flow, regardless of how they wanted to work with contractors. This was a long-standing ask from our earliest customers and, by the time I picked it up, had become a blocker for other clients too, and a barrier to new business.

I owned the payer invoicing configuration system end-to-end, from design through deployment. Clients can configure whether contractors submit their own invoices or the client creates them directly, and add custom guidelines shown to contractors. On line items, clients set predefined values, and enable discounts, late fees with configurable percentages, and expense reimbursement. Beyond line items, clients configure default due dates, a recurring payable frequency, contractor splits, and extras such as requiring a project name, mandatory attachments, or payment reminders. The invoice creation UI renders dynamically per client configuration.

Result: shipped a long-overdue feature that became core to several major clients' workflows, unlocked new business by removing a recurring sales blocker, and gave clients a clear way to reconcile invoices and track contractor payments.