Apartment List~5 min read

Could six weeks rebuild trust across 20% of at-risk ARR?

We built the company’s first billing product that didn’t need a salesperson.

Role: Research and product design
Timeline: 6 weeks
Team: 1 PM, 1 engineer, me
Impact: 20% of at-risk ARR recovered
Platform: Web

A billing task management dashboard displayed on a laptop beside a vault and gold bars.

Impact

At-risk ARR recovered

0% ↓

Billing support tickets

45% of partners a month, down to 14%

Upgrades without Sales

up from 1%

Measured against targets I set at the outset and reported on after launch. Still holding when I left Apartment List in 2024. The 20% is a share of the $5m the company had already flagged. Billing questions were a separately tagged category in the support tool, distinct from the access tickets in the roles and permissions study, two projects, two measures. Still outstanding: the ship date, which is what turns “still holding” into a duration, and the partner count behind the percentages.

The short version

Apartment List did not have a billing product. Invoices were scattered through email threads, support tickets, and whichever spreadsheet Finance had made that month. Partners only learned what they owed when an invoice arrived. Roughly $5m in ARR had already been flagged as at risk.

We had six weeks, one PM, and one engineer. We shipped a rates calculator, itemized invoices, and self-service upgrades, then cut the rest. Billing questions moved from 45% of partners a month to 14%. Self-serve upgrades moved from 1% to 8%. A fifth of the at-risk ARR was recorded as recovered.

What I owned

I owned

The design brief: problem space, constraints, risks, milestones
Partner research, and the internal interviews with Sales, Marketing, and Finance
MVP scope: the three levers, and the decision to cut full billing visibility
Both experiments end to end: the rates calculator and the upgrade paths
The success targets, and reporting against them after launch

Shared with the PM and the engineer

Sequencing six weeks of scope against what one engineer could build
Running the reviews with Sales, Marketing, and Engineering
The build-versus-buy assessment that set the direction

Problem

“Billing confusion” was the symptom. The missing billing product was the problem.

Charges arrived without warning, with nothing to check them against. Partners could not predict a bill, see what drove it, or change a plan without calling an account executive.

That cost showed up three ways: support hours, slow collections, and suppressed spend. The last one was both the least visible and the most expensive.

Before

$0m

ARR flagged at risk

Partners raising a billing ticket, monthly

Upgrades without Sales

The $5m was the company’s own figure, set before this project started. The ticket rate is the share of partners raising at least one billing-tagged ticket in a month, not ticket volume. Billing and access were tagged separately in the support tool, and are two separate projects.

“It made me want to spend less” set the priority. Confusion was suppressing spend. That costs more than the support hours everyone was counting, and it never appears in a ticket queue.

Three levers, not a billing system

Could three levers do the job of a billing system?

We chose three narrow levers built in-house, rather than full billing visibility in six weeks or a third-party billing platform: predictable rates, itemized invoices, and self-service upgrades. With six weeks and one engineer, the full-visibility prototype could not be built in time, and the build-versus-buy framework moved leadership to this direction. Three partial answers could feel unfinished and the cut scope might never be funded, so each lever had to stand on its own; even a partner using only the calculator got a working answer. All three shipped within six weeks, while full visibility and auto-billing alerts had a place to go afterwards rather than being abandoned.

The MVP billing prototype, showing invoice history and rate breakdowns. — The full-visibility prototype. Building it is what established it could not ship in six weeks.

What will this change cost?

What will this change cost me?

We chose a real-time interactive calculator over a static invoice view or summary table so partners could see what a change would cost before committing. A calculator detailed enough to trust could overwhelm them and send them back to their account executive, so the default view answers the cost question and itemized cost drivers stay collapsed until requested. Billing questions fell from 45% of partners a month to 14%.

Billing view showing an itemized rate breakdown. — Shipped: itemized, with the breakdown available on demand.

Alternative billing view aggregating charges to a single price. — Rejected: a single aggregate price. Simpler to read, and property managers could not reconcile it against anything.

The shipped Billing screen: a 2024 ZIP code rate calculator with a search field and an estimated base price of $0 before a code is entered, and beneath it a Rates table grouped by ZIP code — one row expanded to show four communities, each with its 2024 estimated rate, 2023 rate, LIFT rate, and 2024 LIFT floor. — The calculator as it shipped. The default view answers one question — what will this cost — and the per-community breakdown underneath is the part that stays collapsed until somebody asks for it.

Upgrade without leaving the plan

Why make a partner leave the plan view to upgrade?

We embedded self-service upgrades in the existing workflow instead of routing partners through Sales or a separate billing portal. Giving a pricing change to someone who had never made one risked misclicks, accidental upgrades, and disputes landing on Finance rather than Sales, so confirmation shows the new charge before anything is billed and the itemized invoice records it afterwards. Self-serve upgrades rose from 1% to 8%, and Finance could forecast without manual reconciliation.

Plans dashboard with an embedded upgrade modal. — Shipped: the upgrade sits inside the plan view.

Standalone bulk upgrade flow. — Rejected: a standalone bulk flow. Faster to build, and harder to compare options in.

The Edit LIFT side panel over the Plans list: Ashbrook Village at $800 with a $650 floor, five price tiles reading Floor $650, Single price $629, Good $760, Better $740.79, and Best $1202.26, and a panel below estimating search position 22 and 1.84–1.93× impressions. — Shipped: five named tiers, and the projected search position and impressions for whichever one is selected.

The same Edit LIFT panel with the tiers as a continuous slider instead, running Floor $650, Single $680, Good $700, Better $800, Best $1,200, with the handle set to a lift price of $655. — Explored: the same tiers as a slider. The named tiles made the discrete pricing options easier to inspect, so that is what shipped.

What shipped

We shipped a ZIP-code rates calculator with real-time totals, itemized invoices that showed what drove each charge, and self-service upgrade and premium-placement paths inside the existing workflow.

We cut full billing visibility, auto-billing alerts, and the differentiating features from the original scope.

The shipped Invoices screen: three summary cards reading all invoices $150k, paid invoices $109k, and pending invoices 37k at 20% of portfolio, above a table of communities each showing a status pill — Overdue, Due in 14 days, Paid, Overdue by 2 days — an $800 amount, and a Download action. — The record afterwards. Status, amount, and a download per community — the three things every billing call had been asking for.

The plan that shipped was not the plan I chose

The uncomfortable truth: I put full billing visibility in the MVP before proving we could build it. The early prototypes showed that one PM, one engineer, and six weeks could not carry it, so we shipped predictable rates, itemized invoices, and self-service upgrades instead. Those three levers were a response to a failed plan, not the original strategy. The prototypes established the schedule limit, not that the levers were the best long-term billing product. The smaller set shipped. Whether it was enough for a durable billing product was never established.