-
-
$19,694 spent in 30 days, $1,113 in potential monthly savings, and 13 decisions awaiting review.
-
Dark mode shows the 14-day spending mix: 56% AI, 34% SaaS, and 10% expenses, alongside a peak near November 2.
-
Anthropic costs climb sharply as the dashboard highlights $2,840 in potential monthly routing savings and 56.6K candidate calls.
-
56 unused seats across subscriptions costing $6,065 monthly. Cursor has 14 paid seats but only 6 active.
-
Of $1,462 in employee expenses, Nobu accounts for $680. Five charges are approved, one flagged, and two pending.
-
A $1,400 test charge to Cursor is ready to submit, with automatic categorization, a company card, and an optional memo.
Inspiration
Early-stage startups need financial oversight before they can afford a dedicated finance team. Founders manage subscriptions, expenses, and renewals alongside building their business, leaving unused seats, rising AI costs, and missed negotiations unchecked.
We built Runway as an AWS-powered AI finance team that handles recurring tasks, helping startups extend their runway while keeping founders involved in important decisions.
What it does
Runway combines three finance workflows:
AI spend: Detects spending spikes and surfaces cheaper-model recommendations from supplied usage data.
SaaS subscriptions: Highlights dormant seats, overlapping tools, unused add-ons, and upcoming renewals.
Expense compliance: Checks charges against policies and requests explanations for flagged expenses.
The dashboard displays spending trends, potential savings, and pending decisions. Through iMessage, founders can ask spending questions and approve negotiations. Runway then emails vendors, processes replies, makes counteroffers, and tracks progress across sessions.
Our scripted Cursor demo takes a $1,400 monthly subscription to a 22% discount, representing $308 in potential monthly savings, not a verified customer result. Live email is implemented; cancellations and model-routing changes require external follow-through.
How we built it
The backend uses Python, FastAPI, and Pydantic; the dashboard uses JavaScript, Vite, and Chart.js.
Our AWS architecture includes:
Amazon Bedrock: Claude-powered classification, drafting, and questions answered using company-data tools.
AWS Lambda and API Gateway: Application endpoints and background processing.
Amazon DynamoDB: Transactions, policies, alerts, messages, and negotiation state.
EventBridge Scheduler: Negotiation checks and scheduled digests.
Amazon SES: Outbound negotiation emails.
CloudWatch and AWS SAM: Logging and infrastructure deployment.
A Node.js bridge connects iMessage on a Mac to the backend. Code handles calculations and policy checks; Claude handles language tasks. Known merchants use predefined routing rules to reduce inference costs.
Our proposed pricing is $99 per company per month, with usage limits and a $25 monthly cloud and messaging cost target. These assumptions require pilot validation. Implementing the demo’s $308 monthly discount would leave a customer $209 per month after the subscription fee.
Challenges we ran into
We linked approval prompts to specific alerts so a reply like “yes” does not approve an older request after an unrelated conversation.
Persistent negotiation state, version checks, and an outbox let queued work resume across worker runs. Numerical validation and deterministic fallback templates help reduce invented financial figures.
Connecting iMessage required a separate Mac bridge, creating a deployment constraint to address before commercialization.
Accomplishments that we're proud of
We connected transaction ingestion, spending analysis, messaging, approvals, and persistent renewal negotiation in one prototype, supported by a dashboard, transaction simulator, live email implementation, local development mode, and AWS deployment configuration.
Validation passed 100 backend tests, six bridge unit tests, backend lint and formatting checks, and the frontend production build. Tests cover approvals, negotiation progression, storage conflicts, authentication, and mocked integrations. Live services require separate validation.
What we learned
Financial automation needs clear boundaries between identifying opportunities, receiving approval, executing changes, and verifying savings.
Reliable state and explicit rules matter as much as language generation. Financial explanations must reflect the correct records and lead to the correct action.
Founder attention and operating costs also shape the product: notifications should prioritize meaningful decisions, and model usage should remain proportional to customer value.
What's next for Runway
We plan to pilot Runway with small startups, starting with subscription renewals. Priorities include live billing and usage integrations, stronger negotiation safeguards, customer authentication, tenant isolation, and invoice-based savings verification.
We will expand dashboard controls and add messaging options alongside iMessage, measuring verified savings, founder time saved, negotiation outcomes, and operating cost per customer.
Our goal is to give startups financial oversight while preserving the money and time they need to grow.
Built With
- amazon-api-gateway
- amazon-bedrock
- amazon-cloudwatch
- amazon-dynamodb
- amazon-eventbridge
- amazon-ses
- applescript
- aws-lambda
- aws-sam
- chart.js
- fastapi
- javascript
- node.js
- pydantic
- python
- sqlite
- vite