Beyond student loans: three benefits for everyone else

The people who do not have loans are not short of money problems. Many are paying down someone else’s debt, or paying for a course that would get them a better job, or quietly worrying about a child’s college years that are closer than they look. Roughly half of Americans do not know what a 529 savings plan is, about a quarter of families save in one, and college costs have risen more than nine-fold since the early 1980s.

For the employer, a benefit that only a third of staff can use is a hard sell internally. For Summer, it was the objection that came up in nearly every sales conversation.

Each one gives a different kind of customer a reason to say yes. Retirement Match gives payroll and retirement-plan partners something cheaper to offer than an employer paying down loans directly. Education Assistance wins employers away from the older tuition-reimbursement providers. The College Savings Planner was paid for by a city for its residents and is the extra that helps close state deals.

The catch is that once these exist, the app can no longer assume anything about the person logging in. Some employees only ever use one of them, and they may have no loans at all. So onboarding cannot open with questions about loans, personal details are collected only when a benefit needs them, and a benefit someone skips today has to be easy to pick up later. That constraint came out of these three products, and it now shapes the redesign of Summer’s core app: a home that is one template with slots for whichever benefits a person has, and a first run that never asks about loans first.

The 2023 version started where the data was: employees connected their loan accounts, transactions synced in, and a document upload covered the gaps. I designed the dashboard that showed payments per institution, the simulation that let an employer see what a match would cost, and the partner payment report that the product is really sold on. Then the operational pieces: credential resync when a servicer login changes, identity checks so the connected account belongs to the employee, and operations views with duplicate flagging.

What the clients taught us. A large financial-services employer calculates annually in January, which forced a split match period with a year-end catch-up. A direct employer in insurance reached roughly two-thirds adoption among eligible employees in 2025, far ahead of the payroll channel, which told us the problem was reaching people, not the in-app journey. The employee-facing piece I care most about is the decision experience: a payment is approved, rejected or pending, and a notification deep-links into a status screen that explains why. I prototyped it with AI tooling and handed it to engineering.

Verified data was the moat, and the data source has changed underneath it; the product idea survived the move. The 2026 direction, which I am designing, pulls up to twelve months of payment history on enrolment and asks the employee to confirm, deselect and attest. Making trusted data user-confirmable removes most of the manual review rather than automating it.

The 2023 MVP was deliberately a two-page form: submit a request, then a claim, with the request created on submit rather than tracked as a long-running state the way the forgiveness flow works. That plainness let real launches set the roadmap. A large employer moved to Summer mid-programme in December 2024, which meant transition and in-flight data for people already part-way through a course, and partial reimbursement by grade (full for top grades, half for the middle, nothing below). A multi-site healthcare client with about a dozen locations needed each request routed to the right approver by location; it was in active use within a month. A fiscal-year client needed fiscal and calendar years handled side by side, with a combined view of what was pre-approved against what was actually paid.

On the employer side I designed the eligibility module: add employees by form or spreadsheet, validation, upload and audit history, benefit status, limits and spend tracking, and benefit-specific reporting. Two clients then asked for the thing reviewers actually need, a per-submission history with submitted, pre-approval, claim and decision dates, so deadlines tied to course completion or quarter close can be enforced at the submission being reviewed instead of in back-office data.

In 2025, 96 percent of people who reached the landing page went on to the submission form, and about 30 percent of account creators submitted a request. The flow is low friction; the work left is getting eligible employees to it.

The scope decision was the design decision. With a deadline and a small team, we chose four or five small standalone tools over a unified planning journey, and let the unified idea live in the core app redesign instead. A third-party college aid service was removed so users were not routed to a product with weaker privacy and security control.

The 529 finder defaults to the user's state from onboarding, explains the in-state tax advantage against national plans, compares two or three plans at a time, and keeps lists thin with detail on demand. It links to each plan's own page so the product keeps its attribution without sending traffic to a data vendor. For the city, the savings programme appears as targeted placements, a banner on the 529 page, a home-state callout and a homepage notification for residents with dependents, rather than a flow that interrupts. The calculator got a state selector with in-state tuition as the default, which fixed inflated estimates, and shows today's cost beside the projected one with the inflation assumption a click away.

The scholarship finder shipped with one must-have and one nice-to-have. Filters lead instead of a weak text search, provider logos were dropped for consistency, navigation to the provider's site is explicit, every result carries its source, and a closes-soon cue adds urgency. Sales response was strong, especially for resident programmes, and usage taught us about placement: the city's My Plans surface generated roughly eight times the referrals of the 529 page itself. Tools that sit behind a navigation item do not get found; tools that sit where people already are do.

The biggest consequence is structural. Because Retirement Match, Education Assistance and College Savings users exist, Summer's home can no longer be a loan dashboard with extras attached. The core app redesign starts from a template with benefit slots and an onboarding that collects what a benefit needs when it needs it. These three products are why.