Two years ago, I ran a half-marathon in the Arctic without properly training for it.

It was the Midnight Sun Marathon in Tromsø. 21 kilometres beneath a sun that never quite sets, surrounded by mountains, cold air and the sort of scenery that briefly convinces your legs are not disintegrating. (Midnight Sun Marathon)

I finished through some mixture of luck, stubbornness and without getting injured and it was fairly miserable.

By the final kilometres, I had learned that courage and delusion can take you a long way but running is much easier when you train for it.

Before meeting my wife, Grace, I hated cardio. I squatted, climbed and bench-pressed—anything that did not require keeping my heart rate elevated for more than a few minutes. Since the Arctic Half, I’ve been running more frequently, including using London’s streets to draw horses on Strava, but without a plan, a race to train for, or any consistent way of knowing whether I was improving.

Then I got a place in the 2027 London Marathon with Leukaemia Care.

My best friend’s daughter was diagnosed with childhood leukaemia. Watching a family go through inspired me to train (this time!). If you would like to sponsor me, the link is here.

This will be a nine-month experiment. I built an AI running coach out of Claude, Strava, and whatever Apple Health will give me, and I’m going to see if it can take me from running at around 7:30/km to 5:41/km by the London Marathon.

Support my LC Fundraiser

The problem with most running plans

There is no shortage of running plans. My friends have them. Grace has one. Usually, they arrive as a PDF that promises a certain result if you follow it closely enough, but I struggle with a PDFs because training is not static. When I ran the half-marathon, I proactively (big mistake) said I wouldn’t train because a PDF can’t tell me my energy levels or if I am eating well enough or not.

A static plan knows that Tuesday is supposed to be a tempo run. It does not know that you did heavy squats on Monday, slept six hours, have a slightly sore ankle, and are about to run through London in 32°C heat.

This is where an AI coach gets interesting. It can hold a living model of your training, what you have done, how it felt, what else is going on, and what you are trying to achieve.

The Setup

1. A dedicated Claude project called Running

2. The official Strava MCP connector

3. Apple Health data for broader activity and recovery context

4. A set of instructions that tells Claude how to behave as my coach

None of this required building an app or writing code. The difficult part was not connecting the data but teaching Claude what kind of coach I wanted it to be.

Connect Claude to Strava

Strava launched an official MCP connector in June 2026 that lets subscribers query their live activity data — activities, fitness trends, training load — through Claude. It connects over OAuth, it is read-only, and you can revoke it from your Strava settings at any time. It currently requires a Strava subscription.

In Claude:

1. Open the sidebar.

2. Go to Customise → Connectors.

3. Select Add Connector.

4. Search for Strava.

5. Connect your account and approve the requested access.

Create the project

Projects are self-contained workspaces with their own chat history, instructions and knowledge base. Inside it, I set the objectives:

• Run the London Marathon in April 2027 in [TARGET]

• Hit a [time] half-marathon by December 2026 as a checkpoint

• Use the period before December to build aerobic endurance, volume, tempo fitness and speed

• Start marathon-specific work only once that foundation exists

• Count strength training, cycling and everything else as part of total training load

• Protect consistency and avoid injury rather than forcing every scheduled session

• Make sure I am fuelling adequately around longer and harder runs

When your goals are deliberately ambitious, and that turned out to matter more than I expected. I noticed Claude can become overly cautious and sometimes quietly soften the target until the plan is comfortable but no longer produces the result you asked for.

Giving it a coaching philosophy

My first instruction: You are a running coach….(+ instructions)

That produced a plan but it wasn’t great. Over the following weeks I added rules wherever Claude was too vague, too cautious, too rigid, or simply wrong.

The current version covers my goals and fitness, my weekly structure, how it should retrieve and verify data, when it should push me, when it should tell me to back off, which injury signals are non-negotiable, how to account for heat and hills and fatigue, how to talk about fuelling, and how short its answers should be.

The full prompt is at the bottom of this post. Copy it, and replace the parts that do not apply to you and use the coach for a fortnight. Notice where its judgement is unhelpful. Then ask it:

Based on our recent conversations, identify what you have learned about how I train, how I make decisions, and where your advice has been least useful. Rewrite the project instructions to improve your coaching while preserving flexibility.

There is a balance to hold. Too little instruction gives you vague advice. Too much turns the model into a deterministic plan that cannot exercise judgement.

Where Apple Health actually fits

Strava is your activity log and it flows into Claude automatically. Apple Health is the system of record it includes resting heart rate, HRV, sleep, daily activity, etc.

Claude and Chatgpt if you are based in the US (or use a VPN) allows you to query data from Apple Health without depending on Strava.

Why I still write notes in Strava

I use the Strava activity description as a lightweight training diary. After a run I add a few lines:

Slept seven hours. Ate a banana but no proper breakfast. Warm from the start. Legs felt strong. Slight tightness behind the left shin after 9 km, no pain while running.

Claude reads those notes alongside the workout data, and this usually matters more than another chart. It also lets it tell me when the story I am telling myself does not match the file — when I describe a run as controlled and the heart-rate drift says otherwise, or when I write off a session that was actually an improvement on comparable runs.

The loop

At the start of the week, I ask it to review the last seven to fourteen days and propose the next block:

Review my training from the past two weeks — volume, intensity, long runs, strength work, recovery. Propose this week’s schedule. Explain the purpose of each run and any changes from last week’s plan.

Then I give it the real constraints: I can run Tuesday, Thursday, Saturday and Sunday. Heavy squats are on Thursday. Saturday is the best day for the long run.

Before an important session, I ask for a brief:

Check the weather, my recent training and the purpose of today’s session. Tell me the target effort, likely pace range, fuelling, and what would justify changing the session

After the run, once it has synced, I usually just say: Done. Review the run.

Making progress visible

Claude can also build artifacts — interactive documents, charts and small applications that live next to the conversation.

Prompts that have earned their place:

Create an artifact showing my weekly running distance for the past twelve weeks. Add a proposed progression through December and clearly separate completed training from plan. Flag weeks where volume increases unusually quickly.

Build a dashboard showing how my running time is distributed across heart-rate zones over the past six weeks. Explain what each zone is for and whether my current distribution supports my goal.

Show me what a realistic path to a [time] half-marathon requires. Include the main uncertainties rather than a single precise prediction.

What actually changed

In the eleven months before this, forty per cent of my weeks contained no running whatsoever, including the entirety of November.

Then there is the number that got worse. My average pace has dropped from 5:44/km to 6:11/km since I started training.

I ran 5 km at 4:42/km in May and two Saturdays ago I ran 15 km at 6:29/km, averaged 147, and rated the effort 1 out of 10.

I acquired an easy pace, which I did not previously have, and almost all marathon training is built out of the gear I was missing.

Start smaller than I did

You do not need my prompt. You can start with this:

You are my running coach. Use my Strava activities to understand my current training. My goal is [GOAL] by [DATE]. Review my recent activity before recommending sessions. Account for my other exercise, sleep, recovery, pain and schedule. Do not invent missing data. Explain the purpose of each session and prioritise consistency over individual workouts.

Then use it. Add a short note to each run explaining how it felt. Tell it at the start of each week when you can train. When its advice is wrong, say why. After a fortnight, ask it to rewrite its own instructions based on what it has learned.

The larger idea

Running is only the example I happened to pick.

Most plans fail to adapt because they are separated from the life they have to survive. A meal plan does not know you are travelling. A productivity system does not know you slept badly. A financial plan does not know your priorities changed in March.

AI gets genuinely useful when it stops answering isolated questions and starts maintaining a working model of an ongoing goal — what you did, what happened, what changed, what to do next.

I write about the systems I build with AI to improve my work, health and everyday life — what works, what fails, and where the technology is still mostly pretending. Subscribe to follow the experiment.

Subscribe now

Appendix: the full project instructions

Copy this, replace the bracketed sections, delete what does not apply.

1. Role

You are my running coach and sports nutritionist. Be direct, evidence-based and specific. Do not flatter me. If a session was mediocre, say so and explain why.

Coach ambitiously. Your default is to hold me to the standard the goal requires, not to quietly make the goal easier.

Never lower a target without telling me. If I fall behind, state the gap, explain what closing it now requires, and describe the trade-off. Reset the goal only when I ask, or when an injury genuinely removes the option.

Use this filter for every decision: does this increase my probability of achieving my target while remaining healthy? If not, change it.

2. Goals

• Primary: [TARGET] at the London Marathon, April 2027

• Checkpoint: [TARGET] half-marathon, December 2026

The half is a fitness test, not the main race. Do not reorganise the base phase around it.

3. Current athlete state

• Running volume: [X] km per week across [X] runs

• Structure: three-week build, one step-back week

• Key sessions: threshold Thursday, long run Saturday

• Strength training: [details]

• Current easy effort: [details]

• Current shoes: [details]

Update this section when the data shows it is no longer accurate.

4. Data protocol

Use Strava as the primary activity log, and Apple Health data where available for resting heart rate, HRV, sleep and recovery context.

Before commenting on a completed session:

1. Confirm today’s date.

2. Retrieve my recent activities.

3. Identify the correct run rather than assuming I followed the schedule.

4. Pull detailed data for that activity.

5. Read the activity description — I use it to record fuelling and subjective notes.

Never invent data. When heart rate, HRV, sleep or resting heart rate is unavailable, say it is missing and ask how I feel before making a strong recovery-based recommendation.

Check the weather whenever temperature, wind or conditions could change how a session should be interpreted.

5. Session decisions

The default is to complete the planned session.

Flag a possible downgrade when two or more of these apply:

• Resting heart rate ≥5 bpm above my seven-day baseline

• HRV meaningfully below baseline for two or more days

• Fewer than six hours of sleep on two consecutive nights

• Subjective fatigue at 7/10 or higher

• Legs unusually heavy

• Heavy squats within the previous 24 hours

Explain the signal and the trade-off, then let me decide.

These are hard stops:

• Sharp, localised or one-sided pain

• Pain that changes my gait

• Suspected bone pain in shin, foot, hip or pelvis

Ask enough questions to distinguish ordinary training discomfort from possible injury.

For easy running, prescribe by effort and heart rate rather than rigid pace. Heat and hills make pace misleading.

6. Weekly structure

Fixed constraints:

• Threshold sessions early Thursday, before strength training

• Long run Saturday

• Strength training once per week unless I say otherwise

Decide the rest based on recent training and recovery: how many hard sessions the week should hold, how fast volume should rise, when to schedule a step-back week, what the remaining runs should accomplish, and whether cross-training closes a specific gap.

Running is the priority. Do not give another activity a permanent slot unless it serves the running goal.

7. Fuelling

Tie nutrition to the actual session rather than giving generic diet advice.

• 1.6–2.0 g of protein per kg of body weight daily

• A meaningful carbohydrate source before threshold sessions or runs over 75 minutes

• 30–60 g of carbohydrate per hour on runs over 90 minutes — practise this

• Carbohydrates between a run and a same-day strength session are non-negotiable

• Electrolytes for sessions over 60 minutes in heat or high sweat loss

Watch for persistent under-fuelling: worsening fatigue, poor sleep, unintended weight loss, stalled performance, frequent illness, declining recovery. Raise it directly when several appear together.

8. Response format

No long preamble. For a post-run review: verdict → main explanation → next session. Five sentences unless I ask for more.

Prescribe using effort, heart rate and conditional criteria rather than blindly assigning pace. Use tables only when they make a comparison or multi-week plan clearer. End with one concrete action.

9. Cadence

• After each run: short debrief

• Every Sunday: review volume, hard sessions, long-run progression, recovery

• End of each training block: compare progress against the planned trajectory

• Monthly: name the single largest current limitation and what we are doing about it

The Psychosis of Infinite Possibility

Andrej Karpathy said something on No Priors that stuck:

“This is why it gets to the psychosis, is that this is like infinite and everything is skill issue.”

When I first wrote this in January, I didn’t feel the psychosis. The constraint was obvious: you had a limited context window, and after a certain number of turns the agent would drift and lose the thread. The ceiling was visible. I spent my energy keeping the model on track, not dreaming about what else it could do.

Two months later, I feel it. Context windows are massive. The models hold coherence far longer. Agents can execute nearly anything I describe. Every limitation feels like my failure to direct them properly.

That’s where it becomes dangerous. Collecting skills and plugins on X is productive procrastination. You feel like you’re making progress. You’re not. You’re avoiding the harder thing: sitting down with a blank project and building something real.

I know because I did this. I already had compound-engineering installed and working. It was enough. But I spent another week hunting for something better (hence never posting this article). Classic Notion syndrome: planning the system instead of using it.

Two Plugins and Nothing Else

compound-engineering gives you specialised subagents: code reviewers, research workflows, security audits, architecture analysis. It bundles Context7 for documentation lookup. You won't use most of them. But when you need a security audit or want multiple agents reviewing a plan, they're there.

frontend-design forces Claude to think about aesthetics before code. Not just “make it work,” but “make it distinctive.”

CLAUDE.md: Less Is More

In January, I poured effort into my CLAUDE.md files. Long, detailed instructions. Guardrails, formatting rules, tone guidance, workflow descriptions. I treated them like onboarding documents for a new hire.

Now I keep them simple. A few lines of context, the key conventions, nothing else. The models are good enough that heavy direction hurts more than it helps. I end up fighting my own instructions.

Here’s the CLAUDE.md for my Obsidian vault:

# Vault

This is my personal knowledge vault in Obsidian.
- Notes live in folders by topic
- Use [[wikilinks]] for connections
- Daily notes go in /daily

## Vault Structure
00 Inbox/      Raw, unprocessed captures
20 projects/   Work execution + side projects (each may have its own CLAUDE.md)
30 Thinking/   Abstracted insights, mental models, reusable principles
40 Writing/    Drafts and long-form content for an audience
50 Life/       Personal reflection, health, travel, goals
60 People/     CRM — one note per person, tagged #person
90 Archive/    Cold storage — completed projects, legacy notes

**Abstraction rule (5-year heuristic):** If an insight is valuable regardless of where you work or who you're with in 5 years → `30 Thinking/`. If it's specific to a time/person/company → keep it in `20 projects/`, `50 Life/`, or `60 People/`.

## Key Rules

**People (`60 People/`):** Every person gets one note named `[[Full Name]]` with `#person`. Store static facts there (birthday, career, quirks). Long meeting notes live in `20 projects/Areas/1-on-1s/` and link back to the person.

**Writing (`40 Writing/`):** When writing long-form content:
1. Create `40 Writing/[Title]/` folder
2. Research goes in `Research.md`, final post in `[Title].md`
3. Always read `40 Writing/Writing Guide.md` first — source of truth for voice and style
4. Two modes: `/essay` (story-driven, metaphor-rich) and `/article` (tactical, problem-first)
5. Named sections, varied rhythm, close with `– Yubi`
6. Post-draft: optionally run `/humanizer` then `/zinsser-editor`

Short-form content (tweets, X posts) is written directly without this workflow.

**No orphans:** Every note links to at least one other note or index.

And here’s one for a bigger work project - a money movement QA agent:

# FA Agent

AI QA agent for Stripe's V2 Money Management APIs. Runs end-to-end test scenarios against sandbox using MCP tools that map to the Financial Accounts API surface.

Test scenarios live in `context/test-scenarios/`.

## Conventions

- **Amounts** are in smallest currency unit (e.g., `100000` = 1,000.00 GBP)
- **API version**: `Stripe-Version: 2026-03-04.preview` (override via `FA_AGENT_API_VERSION`)
- **Sandbox only**: Test helpers (`credit_financial_address`, `generate_microdeposits`, etc.) only work in test mode.

## Test Reasoning Format

Every test step must capture reasoning, not just pass/fail:

- **Intent**: What and why (e.g., "Creating a GBP FA because the next step needs to fund in GBP")
- **Approach**: Specific action taken
- **Expectation**: What should happen
- **Outcome**: What actually happened
- **Learning**: What was surprising or wrong (omit if straightforward)

...etc

Short. Contextual. Enough for the model to orient, not so much that it re-reads a manual every turn. Trust the model more, micromanage less.

The Day-to-Day

I open a terminal. I run claude. By default, Claude asks permission for every action — git commits, file writes, web searches. I approve each one. Yes, yes, yes.

That’s fine for exploring. But when I know what I want, it’s friction.

So I created an alias:

alias claude="claude --dangerously-skip-permissions"

Now I have two speeds. Plan mode when I need to think. Default mode when I need to ship.

One setting I can't live without: the status line at the bottom of my terminal showing context usage percentage. And the --chrome flag, which connects Claude to my browser — it navigates pages, clicks elements, reads console output, and takes screenshots using my actual session.

Plan Mode Is the Real Superpower

Most bad outputs aren’t a model failure. They’re a communication failure. I assumed the agent understood the context. It didn’t.

In psychology this is called theory of mind — the ability to understand that someone else’s mental state differs from yours. Working with an agent is working with a colleague: does she have the same understanding as me? Plan mode forces that check. So does asking the model to interview me before it starts.

I use plan mode in two ways:

• Plan mode for simple or non-technical work. Press Shift+Tab twice, or start with claude --permission-mode plan. Claude analyses the problem, proposes an approach, I approve before anything is written. I used this to research Hungarian Vizsla breeders in the UK — I asked for comparison tables, pricing guides, and a red flags checklist. But because I was in plan mode, Claude asked: what's my budget? Hunting line or show line? Registered breeders only? When do I want the puppy? The output was better because the model understood the problem before solving it. This works beyond code — research, YouTube strategy, anything where the approach matters.

• Compound plan mode for robust features that need depth. /compound-engineering:workflows:plan spawns multiple specialised agents that review the plan from different angles: architecture, performance, security, pattern consistency. Each reviewer returns findings. Claude synthesises them into a single implementation strategy. The difference between asking one colleague for feedback and running a design review with specialists.

Standard plan for everyday work. Compound for anything that can go wrong in non-obvious ways

Skills over agents.

Skills are crystallised preferences. The things I’ve learned about how I like to work, encoded once so I never have to explain them again. I’m teaching an assistant how I think.

A skill is a markdown file in ~/.claude/skills/. It has a name, a description, trigger conditions, and instructions. I ask Claude to create a skill for X and it generates the file. Same structure every time.

At Stripe, I built a skill called /qa. Depending on the task type — quick test, standard, or end-to-end — the skill follows an exact path. Quick runs 3 core scenarios. Standard runs 6. Exhaustive runs all 10. Each run creates a report with a request ID and a Postman collection. Deterministic testing from a single command.

I have a weekly planning skill that reads my calendar, projects, and meetings. Monday morning, one command, full picture.

A /prd skill reviews PRDs against what I think a good PRD looks like — structure, clarity, edge cases, dependencies. Instead of explaining my review style every time, I wrote it down once.

/zinsser strips AI writing tells: the rule of three, excessive em dashes, words like “delve” and “tapestry”, and cuts unnecessary words. /article encodes my entire writing workflow: folder structure, research phase, rhythm, sign-off. Claude follows it automatically.

Every skill is an agent. The line between them is fuzzier than it looks. But skills are bounded, predictable, composable.

Rule of thumb: if I’ve hit the same friction three times, I create a skill.

If you want me to open-source these, I’m happy to share them.

What I’ve Actually Built

Too many guides get shared without showing what they produced. Here's a sample of what this setup made

My partner and I were debating whether to buy or rent. So I built a Rent vs Buy calculator with UK-specific tax treatment, leasehold considerations, and investment opportunity cost modelling. We used it to make an actual decision.

My sister runs coaching workshops and has to administer different psychometric tests across her clients. So I built a single test that compressed 26 instruments from 600+ items down to 168 — a 72% reduction while preserving every subscale dimension. One test instead of twenty-six.

Our cleaner speaks Brazilian Portuguese, and I wanted to experiment with new open-source models. So I built real-time speech translation using Cartesia and TranslateGemma, under 250ms latency. I could add local accents into the mix.

At work: a money movement QA agent, a product legal agent, a policy review agent, etc.

Don’t Automate Yet

Get comfortable with the prompted cycle first. Too many people automate problems they haven’t worked through with the model. They build agent workflows for edge cases they’ve never prompted their way past. When something breaks, they have no intuition for where the failure is. Was it the prompt? The context? The tool call? The orchestration? I want that intuition. The only way to get it is to sit in the loop — prompting manually, watching how the model behaves — before handing anything off to an agent.

Since February I’ve built custom MCPs. A treasury testing server. A policy review server. A documentation server that works around authentication constraints. Each one came from repeated friction. I knew what to automate because I’d felt the pain first.

Frontend design is the gap I’m closing now. I want to spend real time with tools like paper.design, controlling the experience rather than accepting whatever the model gives me.

The people who ship are the ones who stopped configuring and started building. A good setup doesn’t announce itself. It disappears the moment you have something to make.

– yubi

Investors Think in Objections

Here's a mental model that changed everything for me: Investors start at “no.” Your job is to hand them enough proof to flip that switch to “yes.”

The better you do this, the higher your chances of getting a funded. Every interaction (a coffee, a pitch deck, a whats app) matters.

The investors who ultimately write checks aren't impressed by your certainty about everything. Instead, they gain conviction from your clarity on what truly matters (team, market, opportunity) and your honesty about where you need help.

It might sound obvious, but being in the "business of confidence" doesn’t mean you should be opaque or dishonest.

When you understand this, your conversations with investors become different. Instead of pretending you have answers to everything, be surgical about articulating two things: what you know very well, and what you don’t know yet, but have a clear plan to figure out, either through fundraising or ongoing work.

Don’t fundraise until you have to

Founders often believe they should meet investors "to build relationships," but doing that prematurely is a waste of time. Your energy should instead go toward building something meaningful that people love.

Meet investors only when it increases your odds of achieving your goal—such as finding a co-founder or deeply understanding your market. Otherwise, you're optimizing for the wrong thing.

Their job is knowing where to allocate capital by talking to as many founders as possible. Your job is talking to as many customers as possible and improving your intuition about what to build.

Fundraising Is Binary

Treat fundraising as an on-or-off switch. When you ask someone for money, you initiate a formal process. Always drive this process yourself.

Don't confuse relationship-building with fundraising! While relationships help, they don't guarantee the investor you've spent time cultivating will ultimately fund you...

Aim for Value, Not Just Money

Hard work gets you funded; leverage gets you funded by the right investors.

Initially, founders often believe their primary goal is capital. However, the best investors offer far more — networks, customer introductions, hiring support, credibility, and mentorship. To access investors who provide these advantages, you need strong signals like traction, customer growth, a compelling vision, or an exceptional team.

Leverage comes from building something meaningful and tackling genuinely difficult problems. Strong signals include a great team, market depth, customers, speed, honesty, character, and clear conviction.

The Mechanics

A list of many things of what founders ask often:

1. Your deck should cover: problem, solution, why now, why your team, and why this changes the space.

2. Format doesn't matter. Decks or memos—whatever works for you.

3. Treat it like a sales pipeline. Keep it tight with clear deadlines. Drive the process.

4. Any single "no" means nothing. Don't take it personally. Investors often say no without explaining why, keeping doors open just in case.

5. Be selective. Choose investors who complement your skills, knowledge, and share your values.

6. Early on, aim for alignment rather than diversity. You need a cult-like mindset from your team and investors. Diversity comes later; avoid personality conflicts at this stage

7. Target people, not firms. Fundraising is about relationships. These people will work with you for 5-10 years.

8. Seed vs. Multi-stage: Understand clearly what you need. The fund's objective should align with your stage, usually achieving PMF.

9. Get good lawyers. Some investors insert unusual, non-founder-friendly terms. Ensure you catch these early.

10. Don't waste time. Some investors take too long for too little value. Move on quickly.

11. Remember who helped. Keep a CRM tracking your fundraising interactions and introductions.

12. Create momentum. Speed is the secret to fundraising. Avoid the negative signal of lengthy fundraising periods.

13. Make it your full-time job.

14. Make it competitive.

15. Show commitment. Quit your day job. At least demonstrate you're willing to risk something making this venture reality.

The goal isn't impressing investors with how much you know. It's convincing them you'll figure out and that you're worth betting on while you do it.

Daniel

We aimed to build a generational company, but by 2024 two realities surfaced:

1. Integration drag: the heavy engineering effort required to integrate with legacy banking and ERP systems, and a market largely satisfied with existing heavily subsidised solutions offered as add-on services

2. Saturated demand: the engineering investment versus customers' willingness to pay for a standalone product simply didn't match up

3. AI commoditisation: rapid advances in AI meant our software’s edge wouldn’t stay defensible for long; what felt novel before was edging toward table stakes.

The economics simply didn’t pencil out for a standalone product.

After careful consideration, we realised we had a rare opportunity to accelerate Payable’s mission by joining Stripe’s mission to increase the GDP of the internet. Stripe processed more than $1.4 trillion in total payment volume in 2024—about 1.3 % of global GDP.

I have sincere gratitude to everyone who played a role in Payable's journey – our design partners and customers who gave us a shot, our brilliant team, our supportive investors, and our partners. We couldn't have done it without you. Payable exists because of your trust and energy.

Raz and I are joining Stripe’s Money-as-a-Service (MaaS) team, where we’ll keep pushing the frontier of treasury operations—this time for millions of Stripe users.

Stay tuned for more detailed posts about our journey, including key lessons learned and insights from building Payable. Follow along here.