James PotterBilling and Business Systems · Operations Automation

I build billing and fulfillment systems: invoicing, subscriptions, prorate math, collections, order to cash. Billing became mine in 2024 and I started building the software behind it in 2026. The work usually starts when something takes too long, or when the numbers stop lining up. I check what the systems are actually doing before building on them, and document the back end and the interface so whoever uses it can run it without me.

Before that I ran support teams and owned QA on everything we shipped, from device firmware through the web application, including version-level release validation. In 2021 I moved into a VP role covering every function except sales.

jamesdpotter00@gmail.com LinkedIn

Fulfillment to billing, in one reviewed click

ProductionSaaS billing

Fulfilling orders took two people, several systems touched by hand, and a weekly batch to create the subscriptions afterward. I replaced it with a serial-level inventory dashboard that logs the shipment and creates the invoice and subscription in one reviewed step, with prorate math for mid-term changes and a full serial audit trail.

It stays simple enough that the people using it can see what it did and sort out most problems without me.

Software Apps ScriptDelugeZoho BooksMCP
Competencies Subscription billingInventory managementCRM integrationREST / OAuth integrationOrder to cashProrate logicSerial audit trailOperator-facing design

Churn analytics dashboard

ProductionSubscription analytics

The billing platform could not produce an accurate cancellation figure, so the people making decisions were working from a number that was close but wrong. I rebuilt the reporting on live billing and accounting data: MRR and subscriber trend, new-logo against expansion revenue, cancellation reasons, and tenure cohorts.

The findings on revenue sources led to the creation of the account management program.

I validated the MRR derivation before building on it. That pass caught a live defect: the paid-through rule was keyed on the wrong date field, so subscriptions that never billed were counting as active revenue.

Year-end was forecast three ways, so the projection carried its own sensitivity instead of a single number.

Software PythonopenpyxlHTML dashboards
Competencies Subscription MRRCohort analysisForecastingMetric provenanceData validationExecutive reporting

Cross-device Android signage app

Built, in QAAndroid

The app only ran on hardware the company shipped, and leaned on a WebView plus JS-player plus localhost-server stack. I replaced it with a native Kotlin app that installs on any consumer device, pulls playlists from the existing cloud, caches them, and plays offline.

Built entirely against the existing server contract, with no server-side changes. I read that contract off device logs, because no spec existed, then documented it so the next person would not have to.

Software KotlinJetpack ComposeMedia3 / ExoPlayerOkHttpGradle
Competencies Native AndroidOffline-first cachingProtocol reverse engineeringMedia playbackUnit testing

Self-service billing the platform could not do

Specification & integrationIn progress

Our terms require billing behavior the vendor's stock portal does not support, and the business chose to keep the terms rather than bend them to the software. At the same time most billing tickets are simple things a customer should be able to do without us: look at an invoice, pay it, change a card, update their details. This is the layer that closes both gaps.

There is one senior developer and their time is the constraint, so I did the expensive part first: recorded every request and response shape from the live billing org instead of trusting the published docs, exercised the calls against our test environment, and wrote the data layer and interface against what actually comes back. It runs standalone on fixtures for review and switches to live calls with one config change. The proxy is specified and not yet built. Demoed to leadership, waiting on development.

It does not stand alone. A past-due banner on the account when suspension is close means fewer accounts reach collections in the first place. Fields tying a serial number to the subscription it belongs to, a link that had never existed here, let fulfillment, billing and support read the same account.

Software Zoho Billing APIJavaScriptHTML/CSS
Competencies API reverse-engineeringSpec-vs-reality documentationIntegration designSelf-service flows

A collections system built between three sets of requirements

ProductionAR & collections

Took requirements from the collection agency, the CFO, and the billing platform and built the layer between them: daily automated pulls, accountant-ready late-fee calculation, and cost-per-recovery tracking.

Balances over 90 days fell more than 90% in the first year.

Software Zoho BooksMCP
Competencies Scheduled automationOrder to cashLate-fee calculationCost-per-recovery trackingThird-party requirements

Taking billing, and finding what was missing

ProcessOperations

Billing became mine in 2024. There was no collections process beyond the platform's default reminder emails and an occasional call from a rep, no way to see what was actually owed across a whole account, and no self-service anything. I found that out by working the problems one at a time: account audits, disputed charges, settlements, past-due chasing, cancellations that had to be dispositioned by hand.

Doing it by hand is what made the gaps specific enough to build against. The systems above came out of that year. None of them were planned in advance. They were the answers to problems I had already solved by hand a hundred times.

Tools Zoho BooksZoho BillingGoogle Sheets
Competencies Order-to-cashAR & agingDispute resolutionAccount auditProcess design
AR tracking maintained by hand AccountBalanceDaysNext step Northwind Hospitality$x,xxx.xx96refer to agency Contoso Retail$xxx.xx74suspend 4/1? Fabrikam Foods$x,xxx.xx61left vm, call back Adventure Works$xxx.xx38disputed, checking Tailspin Signage$xx.xx31— This sheet was the system. Every column that mattered later started as something typed here.

Building the case for a platform rebuild

RequirementsOperations

The company was acquired in 2021 and I moved into the VP role, running every function except sales while it changed hands completely. The platform underneath it was slowing down, extended by junior developers on top of the founder's original build for years and degrading further as customers added content.

Complaints alone were never going to move that, so I built the case out of measurement. Then I supplied a major share of the requirements and led QA through the rebuild. The same years produced new hardware and the first piece of purchase automation.

Tools Zoho DelugeZoho InventoryAndroid
Competencies RequirementsQA leadershipBeta programHardware sourcingProcess automation

QA on everything the company shipped

QualityDiagnostics

Within months of joining I was asked to take over support, and QA came with it: everything the company shipped, from device firmware to the web application, including version-level release validation.

Most of what reached development came out of the field. I read raw device logcat, ran controlled tests on my own devices, and wrote bug reports detailed enough for developers to reproduce a fault every time. The fixes that came out of that work cut ticket volume and held the system together as customers scaled it.

Tools Android logcatDevice firmwareRelease validation
Competencies QA ownershipRoot-cause analysisDefect reportingRequirementsAccount retention

PotterSabers

Hobby businessHardware

Designed the chassis in Fusion 360, wired and assembled the electronics, and wrote per-build configuration in C++ against nine firmware versions across three open-source board ecosystems. Sold them through my own storefront and wrote the setup documentation that shipped with each one.

The chassis went through many designs and revisions, exported for both in-house 3D printing and industrial SLS.

Software Arduino IDEFusion 360Adobe Creative Suite
Competencies Embedded C++CAD / mechanical designElectronics & assemblyFirmware configurationStorefront & fulfillment

Broadcast design and animation

Client workBroadcast & animation

Built the on-air package for a sports talk show carried on local FOX affiliates, across a decade of seasons: title sequence, transitions, lower thirds, and the static frames behind them. The open runs 24 seconds through a 3D set, an animated logo build, and stylised talent treatments. Every lower third and static frame in the package was built from scratch.

Around it, a decade of client work: interstitials for the broadcast Emmys, a looping animation played behind my school's 2014 commencement address, advertising animation, logo design, audio editing, and website builds. Also Layer 8, a proof-of-concept animated pilot about IT support I wrote, rigged, animated and composited solo, voicing several of the characters. A 2015 demo reel collects the rest. All of it solo, start to finish.

Software After EffectsCinema 4DMayaIllustratorPhotoshopPremiere
Competencies Motion design3D animationTitle designBroadcast deliveryCharacter rigging

Fulfillment to billing, in one reviewed click

Simplified from the production screen. Sample serials, real rules.

Before this: a rep logged serials by hand, billing built the invoice, and someone created the subscriptions once a week. The service plan was disconnected from the ship date it was meant to start on.

Try it. Toggle serials on the left and watch the review pane. The last one is already on an invoice.

1 · Serials on this shipment

2 · What this click will do

Nothing committed yet. Toggle serials on the left, then run the reviewed click.

Start date. Subscriptions open on the ship date under our terms, not the invoice date. That link had been broken for years, and recurring revenue reported wrong because of it.

Reviews, does not submit. Billing checks the screen and commits. The people using it can see what it did and fix most problems without me.

What the dashboard holds. Condition, model, and a full changelog on every unit, with three years of shipment history and warranty status attached, so a question about one unit is a lookup instead of an investigation. A rep can record a physical count through a form, and the dashboard shows how far accounting stock has drifted from what is actually on the shelf.

One invoice, two systems. Both systems wanted to bill the customer. I reconciled them: the customer sees a single invoice on ship day, while the service plan still lives as a real subscription for revenue tracking. The subscription's own first invoice is suppressed, so nobody gets charged twice.

Mid-term changes prorate correctly. Adding devices mid-term checks the subscription and its current rate, including any price change already queued for renewal, then applies month-bucket prorate math and merges stacked changes.

Guardrails before anything writes. It refuses serials that are not in inventory and blocks shipping more units than the sales order allows, counted across every shipment against that order. A price problem stops and asks for confirmation. Anything bigger hands the job back to a person.

Why it all hangs off the sales order. The first piece was a Deluge automation that creates a sales order from a customer-signed quote, a conversion the platform does not offer. The sales order then becomes the binder for the whole transaction: the invoice, the shipping label, the packing slip, and any credit notes or returns all hang off it, which gives every later step one place to read from and write to.

It moves real money, so I treat it like production. I keep a severity-ranked tech-debt log with line references: idempotency gaps on retry, an O(N²) bulk-receive loop, missing LockService write locks, UTC/DST date drift in prorate and warranty math, and server-side enum validation. I closed five financial and customer-visible items in a dedicated refactor pass; the rest stay logged and ranked.

A collections system built between three sets of requirements

Case study. Employer internals generalized.

Building the case for a platform rebuild

2021 to 2024. Measurement, requirements, and what the same years produced.

The platform had been extended by junior developers on top of the founder's original build for years, and it slowed further as customers added content. Making the case to replace it needed more than the complaint queue.

The argument. I mapped complaint frequency and severity against measured load times, and documented for development exactly when the degradation appeared and, just as usefully, when it did not.

The rebuild. I contributed a major share of the requirements, fed the design process throughout, and led QA. That included recruiting a beta group of customers who ran the new interface and flow at no cost in exchange for their input, and validating the platform across current and next-generation devices running different Android versions.

Hardware. In 2020 I was asked to start shopping manufacturers for new devices. Shipping started in 2021, once internals, molds, quantities, and freight were worked out. That hardware cut returns of defective devices by over 75%. When the platform needed another upgrade, I ran the same process again for a second model that launched in 2025.

The first automation. Zoho has no native conversion from a signed quote to a sales order and no way to configure one, so I wrote it in Deluge: signed quotes dropped straight into a fulfillment queue. I added Zoho Inventory alongside it to track stock movement and DOA equipment. It is the direct ancestor of the fulfillment automation at the top of this page.

Through all of it, the acquisition. The company changed hands completely in 2021. I moved into the VP role at that point and kept every function except sales running while it did.

QA on everything the company shipped

2017 to 2021. Support, QA, and the fixes the field forced.

Support and QA for four years, across everything the company shipped: device firmware through the web application, including version-level release validation.

Turning symptoms into defects. I read raw device logcat, ran controlled tests on my own devices, and wrote bug reports detailed enough for developers to reproduce a fault every time. That is what turned a reported symptom into a confirmed one worth fixing.

The fixes that mattered. A cache check so the device stopped overloading its own storage. A long run of video memory work. An app UI refresh. And network toggles, including Connection Assistant for devices that kept missing check-ins, and Force HTTPS, built in 2017 for a priority customer whose network allowed nothing over port 80.

One queue. I directed the bug reports and feature requests and set their priority with sales, which put support, development, and sales on one queue and steadily cut ticket volume.

A second product. I specified the customer-side requirements and admin portal for a separate signage product built for a national auto-parts retail program, again handling QA and bug reporting throughout development and launch. It had to be usable by store staff with little to no technical background.

The mining account. A large mining customer's devices kept dropping offline, across sites with dirty environments, constant power surges, and a very old network. The CTO and I met with their decision makers and offered to monitor offline status across their locations, alert each site when one went down, and find the pattern behind it. The data showed their own network was dropping the connections, and which sites were the problem. We built a small workaround specific to their setup and kept monitoring until connection rates came back to acceptable levels. Those sites also surfaced faults that cleaner installs never did, which fed the fixes above. They stayed, kept buying hardware and service, and were still renewing years later.

Cross-device Android signage app

Case study. QA passed on three device classes, not yet in production.

PotterSabers

Build photography. Chassis, electronics, finishing.

Churn analytics dashboard

Four panels, rebuilt with generated sample data. No customer figures.

Play to Win, title sequence

Full open, 24 seconds. Broadcast master, re-encoded for web.

Layer 8, promo

30 seconds. Written, rigged, animated and composited solo.

Demo reel, 2015

Broadcast, animation and design work.

Customer billing portal

Simplified from the mock. Invented account and figures, real rules.

Three things a customer should never have to ask a person for: a copy of their own paperwork, a change to the card on file, and turning their own service on or off. All three were support tickets. This is the account view that hands them back.

Try it. Open a document, then switch the account to manual pay and watch what the payment panel has to say.

1 · Their documents

2 · What they can do with it

Card on file Visa ending 4242
Service · next phase 2 screens active
Pick a document on the left.

Their paperwork, without asking. Invoices and statements are the single most common billing request, and none of them need a person. A customer pulls their own copy, sees what is outstanding, and pays it from the same screen.

Their card, without reading it to someone. Updating a stored payment method used to mean a phone call. It hands off to the vendor's hosted page, so the details never touch our servers and nobody here ever sees a card number.

Their service, eventually. The phase after this is letting a customer turn a screen on or off themselves, which needs the device-agnostic app to take the instruction.

None of it stands alone. These systems feed each other and the value is in the joins. A past-due banner on the account when suspension is close means fewer accounts reach collections at all. Fields tying a serial number to the subscription it belongs to, a link that had never existed here, are what let fulfillment, billing and support finally read the same account.

Why it could not just be configured. The platform's own portal cannot express our terms, and it has no way to tell a manual-pay account that there is no card on file at all. Toggle the payment switch to see the state it cannot render.