Complex day at Speak

Reconcile renewals before refunds commit the wrong money

Published Nov 6, 2026

You’re the software engineer. Your team is in the room.

The setting

offers , a platform where companies buy, set up and manage language-learning programs for their employees and get reports on how those programs are used.

Returning duplicate renewal payments risks undoing legitimate purchases.

Administrators want cash returned before their finance reviews, while finance wants to preserve cash through account credits.

Who you’d be doing this for

“Finance sent me two charges this morning. I've held the next department's rollout because I don't know what we're actually paying for.”

Farhad Kaya · Learning and Development Administrator · a character in this brief

Runs an employee language program at one of the companies that paused expansion after apparently repeated renewal charges.

What is at stake

Repeated renewal charges have put 74 companies' balances in doubt. You must weigh returning cash today against an irreversible refund of a legitimate purchase, without cutting off paid learners.

Why it isn’t already fixed

Every obvious fix costs something else. That’s the part you’d have to decide.

  • cash returned to customers vs cash retained as credits
  • refund certainty vs the submission cutoff
  • financial correction vs uninterrupted learner access
  • account isolation vs valid renewals continuing

Why Speak

Enterprise subscriptions connect company billing to learner entitlements, so a financial correction also puts employee access at stake.

Written with these in mind

Engineers building stateful servicesFull-stack engineers owning enterprise workflowsEngineers drawn to payment correctness

Not your kind of problem? 41 more at Speak, or browse every organization.

Where the organization context comes fromThe postings this brief was written from, and the reporting read before it.

The organization context comes from public information. The situation and characters are written for the brief.

Job postings it was written from

Public descriptions of the work at Speak. They are listed as sources, not as openings. The lines under a posting are its own words, where it meets this brief.

  • Full-stack Engineer (opens in a new tab)
    • You’ll set technical direction across the web acquisition and purchase journey, including public discovery, authentication, checkout, billing, provisioning, and measurement.
    • You’ll work primarily in TypeScript across Next.js/React, Node.js, and Postgres, partnering with engineers in adjacent pods where the experience crosses team boundaries.
  • Full-Stack Engineer - Enterprise (opens in a new tab)
    • You’ll work across the B2B product surface — partner portals, reporting, B2B subscription mechanics, admin experiences, and learner features that require an enterprise touch.
    • Near-term work includes B2B onboarding flows, partner-facing reporting, subscription and billing mechanics, and enterprise-ready features that support our growing Sales and CS motion.
  • Engineering Manager, Enterprise (opens in a new tab)
    • A strong technical background with hands-on experience in full-stack development and familiarity in our stack (TypeScript, React, Node.js, Postgres, BigQuery).
    • Lead the engineering strategy and execution for the S4B roadmap, delivering features and infrastructure that serve our business clients.

This is the setup. The work is inside.

Running it puts you in the room: the full situation and its constraints, stakeholders who push back in their own words, and the decisions that are yours to make. What you produce becomes a Day One Plan — work you can show someone instead of describing.

Other live briefs connected to this one, and what connects them.

Similar problems at other organizations

Like this one, each of these is about money moving incorrectly, late, or twice.

The same setting, from another role

Each is set around Speak’s Speak for Business, written for a different role. They’re separate briefs, not the same scenario.

Other problems with a similar purpose

In each of these, as in this one, the aim is to build high-assurance systems where a consequential change's correctness can be demonstrated, not merely hoped for.