RunFormance

• 

Inspiration

RunFormance started with a simple question:

Why should a runner have to look at several different apps and data sources just to understand one thing — what should I do today?

I started creating RunFormance from scratch on July 17, 2026, during OpenAI Build Week.

The original idea was to bring information from sources such as Apple Health, Garmin Connect, and Strava together to help runners maximize the benefits of their workouts, incorporate cross-training, and build customizable training plans around specific race distances and dates.

From the beginning, I also wanted environmental conditions to be part of the decision.

Where I live, wildfire season can last for months, and a large fire can cause air quality to deteriorate dramatically in only a few hours. I envisioned optional, privacy-controlled location data allowing RunFormance to consider weather and air quality when recommending the best time to train, whether a workout should be completed indoors or outdoors, and how a planned session might need to change while preserving its intended training benefit.

That original vision became the foundation for RunFormance.

The initial Build Week prototype established the product experience around four areas: Today, Plan, Coach, and Connections.

From there, the project evolved into something more important — a working GPT-5.6-powered Adaptive Decision Engine capable of evaluating a planned workout against recovery, training-load, and environmental conditions and adapting the recommendation when the context changes.

During Build Week, RunFormance also reached another milestone: the iOS beta was approved by Apple for external testing through TestFlight, opening the door for real beta testers to begin experiencing the product and providing feedback.

Better Runs. Better Recovery. Better Health.

---

What it does

RunFormance is an AI-powered running and recovery platform designed to bring training, recovery, health signals, and environmental conditions together into one adaptive experience.

Instead of simply displaying metrics, RunFormance is designed to interpret them.

A runner might open the app expecting to complete a hard workout, but poor recovery, elevated training load, insufficient sleep, declining HRV, extreme temperatures, or hazardous air quality may change what makes sense that day.

The RunFormance Adaptive Decision Engine evaluates that context and uses GPT-5.6 to return one of four decisions:

• KEEP — the planned workout remains appropriate.
• MODIFY — preserve the intended training benefit while changing intensity, duration, format, or location.
• DELAY — move the workout to a safer or more appropriate time.
• RECOVER — replace the planned session with recovery when current recovery or training-load signals make training unwise.

The live Adaptive Decision Engine evaluates structured inputs including:

• Planned workout
• Readiness score
• Sleep duration
• HRV trend
• Resting heart rate
• Recent training load
• Target training-load range
• Temperature
• Air Quality Index
• Wind
• Humidity

Each successful evaluation returns:

• An adaptive decision
• A recommended workout title
• A recommended workout description
• A concise summary
• Three specific reasons tied to the supplied signals
• An optional safety caution

On the Today screen, users can change recovery, training-load, and environmental inputs and select Re-evaluate with GPT-5.6.

RunFormance then sends the validated context through a server-side API route to GPT-5.6 Sol and displays the structured recommendation.

The interface also tracks changes between evaluations. If a user edits an input after receiving a recommendation, RunFormance warns that the displayed result is based on older information and should be re-evaluated.

In live production testing, a planned 50-minute progression run received a KEEP recommendation under strong recovery and favorable conditions.

When air quality was changed from AQI 34 to AQI 340, GPT-5.6 changed the decision to MODIFY, recommending an indoor progression run and warning against outdoor running because of hazardous air quality.

This was particularly meaningful because adapting training around rapidly changing air quality was part of the original RunFormance concept from the project's first day.

Additional production testing validated the broader decision framework.

RunFormance produced a DELAY recommendation when conditions suggested postponing the planned session was more appropriate.

In a more extreme scenario involving severely limited sleep, elevated resting heart rate, hazardous air quality, high temperature, and extreme humidity, GPT-5.6 returned RECOVER and recommended replacing the planned progression run with recovery.

All four Adaptive Decision Engine outcomes — KEEP, MODIFY, DELAY, and RECOVER — were successfully exercised in the live production experience.

The goal is not to replace the runner's judgment.

It is to give the runner better context for making decisions.

---

How I built it

RunFormance was created from scratch during OpenAI Build Week, beginning on July 17, 2026.

The original product concept combined several ideas:

• Bringing together fitness and health information from sources such as Apple Health, Garmin Connect, and Strava
• Helping runners maximize the benefit of their training
• Incorporating cross-training
• Creating customizable running plans based on race distance and race date
• Optionally using location for environmental context
• Considering weather and air quality when deciding when and where to train
• Adapting workouts when wildfire smoke or other conditions make outdoor training unsafe

These ideas represented the product vision. Not all of these integrations were implemented during Build Week.

I first developed the initial RunFormance product experience, including the Today, Plan, Coach, and Connections views, along with beta waitlist and feedback functionality.

An early Build Week prototype checkpoint is preserved in Git commit:

7a49b3e

That commit represents an early Build Week version of RunFormance before the GPT-5.6 Adaptive Decision Engine was implemented.

During the same Build Week period, I used Codex for the major Adaptive Decision Engine development phase.

Codex inspected the repository architecture and Git history, helped plan an additive implementation that preserved the initial product experience, and helped implement the core AI integration.

RunFormance uses:

• Next.js
• React
• TypeScript
• Zod
• OpenAI Responses API
• GPT-5.6 Sol
• GitHub
• Vercel
• Formspree

The Adaptive Decision Engine uses a server-side Next.js API route so the OpenAI API key is never exposed to browser code.

Requests are validated against strict schemas before being sent to OpenAI. GPT-5.6 Sol returns a structured recommendation contract rather than unrestricted free-form text, giving the application a predictable response format.

The production implementation includes:

• OpenAI Responses API
• Explicit gpt-5.6-sol model ID
• Medium reasoning effort
• Structured Outputs
• Server-side OPENAI_API_KEY
• Strict input and output validation
• Request timeouts
• Duplicate-request prevention
• Explicit refusal and failure handling
• Privacy-safe production diagnostics
• Automated tests

I also made the product decision to send only the structured training, recovery, and environmental context required to generate a recommendation.

Names, email addresses, beta waitlist information, Formspree data, and unrelated personal information are not included in Adaptive Decision Engine requests.

For OpenAI's safety_identifier, RunFormance creates an anonymous random browser identifier stored in an HTTP-only cookie. The server hashes that identifier using SHA-256 and sends only a shortened privacy-preserving hash to OpenAI.

API requests are configured with store: false, so RunFormance does not request that generated responses be stored as application state by the OpenAI API. OpenAI's handling and retention of API data remains governed by its applicable API policies.

The public web experience is deployed at runformance.app, allowing judges and beta users to interact directly with the live Adaptive Decision Engine without requiring an account.

Separately, the RunFormance iOS beta has been approved by Apple for external testing through TestFlight. This provides another path for real-world beta testing as the product continues to develop.

---

How I used Codex and GPT-5.6

Codex played a major role in the Adaptive Decision Engine phase of RunFormance.

I used Codex to:

• Inspect and understand the initial Build Week prototype
• Review repository architecture and Git history
• Plan the Adaptive Decision Engine
• Build the server-side OpenAI integration
• Define structured request and recommendation schemas
• Implement the interactive Today-screen AI experience
• Add validation and error handling
• Create and strengthen automated tests
• Review API-key security
• Audit the anonymous safety identifier
• Review privacy and data-retention language
• Add privacy-safe production diagnostics
• Diagnose production API failures
• Validate builds and TypeScript
• Document the Build Week implementation and evidence trail

I remained responsible for the core product vision and decisions.

The original idea of bringing multiple fitness data sources together, building customizable training plans, incorporating cross-training, and using optional location, weather, air quality, and wildfire-smoke conditions to influence training decisions came from the product concept I developed at the beginning of the project.

I also made the core decisions about which recovery and environmental signals should influence the Adaptive Decision Engine, how the KEEP / MODIFY / DELAY / RECOVER framework should work, how recommendations should be explained, how stale results should be presented after inputs change, and how the experience should balance personalization with safety.

GPT-5.6 Sol powers the live Adaptive Decision Engine itself.

It evaluates the validated runner context and produces the adaptive decision, recommended workout, summary, three context-specific reasons, and optional caution displayed by RunFormance.

The combination allowed me, as a non-traditional builder without a conventional software-development background, to move from an idea to a live AI-powered application in a matter of days.

---

Challenges I ran into

One of the biggest challenges was turning a broad idea into a focused product.

Running and health platforms can generate enormous amounts of data. The challenge is not displaying more information — it is determining which signals matter at a particular moment and how they should influence an actual training decision.

The original RunFormance vision included data from multiple health and fitness platforms, personalized plans, cross-training, location, weather, air quality, and environmental guidance.

Trying to build everything at once would have created complexity without necessarily proving the core idea.

The decision was to focus first on the intelligence layer: Can RunFormance take meaningful context and turn it into one useful, explainable decision about what a runner should do today?

Another challenge was making the AI behavior explainable.

I did not want RunFormance to simply say:

"Do this workout."

The runner should understand why.

That led to the structured recommendation format and the requirement that GPT-5.6 provide exactly three reasons tied to the supplied recovery, training-load, or environmental signals.

There were also practical engineering challenges involving:

• Server-side API integration
• Structured Outputs
• API-key security
• Input validation
• Responsive UI behavior
• Production deployment
• Privacy considerations
• Safe error handling
• Model access configuration
• Production debugging

One particularly useful challenge occurred when the first live GPT-5.6 requests repeatedly returned HTTP 502 errors.

Instead of exposing internal upstream errors to users, I worked with Codex to add privacy-safe server diagnostics. Those logs captured only non-sensitive metadata such as failure stage, HTTP status, OpenAI error code, error type, and request ID.

The diagnostics eventually revealed an OpenAI string_above_max_length error.

The privacy-preserving safety_identifier was being generated as:

rf_ + a full 64-character SHA-256 hexadecimal digest

That produced a 67-character value.

The implementation was corrected to preserve the rf_ prefix while using the first 61 hexadecimal characters of the digest, producing exactly 64 characters.

After redeployment, the complete production flow succeeded:

RunFormance → server-side API route → OpenAI Responses API → GPT-5.6 Sol → structured adaptive recommendation → RunFormance UI

Another challenge was moving quickly from concept to something that could actually reach users.

During the same Build Week period, I worked through deployment, beta infrastructure, feedback systems, and Apple's TestFlight external beta review process.

Seeing both the live web experience functioning in production and the iOS beta approved for external TestFlight testing made the project feel less like a concept and more like the beginning of a real product.

Working through the entire process reinforced an important principle behind RunFormance:

Complexity should happen behind the scenes so the experience presented to the runner can remain simple.

---

Accomplishments that I'm proud of

I am proud that RunFormance went from an idea on July 17 to a functioning, deployed AI-powered application during OpenAI Build Week.

The project now includes:

• A live production web application
• An iOS beta approved by Apple for external testing through TestFlight
• A defined RunFormance visual identity
• Today, Plan, Coach, and Connections experiences
• A beta waitlist
• An integrated beta feedback channel
• A real GPT-5.6-powered Adaptive Decision Engine
• Structured AI recommendations
• Editable recovery and environmental context
• KEEP, MODIFY, DELAY, and RECOVER decision support
• Context-specific explanations
• Safety cautions
• Stale-recommendation detection
• Server-side API security
• Strict structured validation
• Automated tests
• Privacy-conscious anonymous safety identifiers
• Privacy-safe production diagnostics

One of the moments I am most proud of was seeing an idea from the very beginning of the project become a working production feature.

On July 17, I described a scenario where wildfire smoke could cause local air quality to deteriorate dramatically within hours and envisioned RunFormance adapting training accordingly.

In production testing, that concept became real.

Under favorable conditions, GPT-5.6 evaluated a planned 50-minute progression run and returned KEEP.

After changing the air quality from AQI 34 to AQI 340, RunFormance recognized that the previous recommendation was stale. GPT-5.6 then re-evaluated the same planned workout and returned MODIFY, recommending an indoor progression run and explaining that hazardous air quality made outdoor running unsafe.

I also tested more extreme scenarios.

The system successfully returned DELAY when postponing the planned workout was the more appropriate choice.

When recovery and environmental conditions became severely unfavorable — including only one hour of sleep, elevated resting heart rate, hazardous AQI, high temperature, and extreme humidity — GPT-5.6 returned RECOVER and recommended replacing the progression run with recovery.

That demonstrated the core idea behind RunFormance in a very tangible way:

The plan provides direction. The context determines what makes sense today.

Having the iOS beta approved for external TestFlight testing was another meaningful milestone. It means RunFormance can begin moving beyond development and into the hands of real beta testers whose feedback can help shape what comes next.

---

What I learned

I learned that building with AI is most effective when AI is treated as a collaborator rather than simply a tool that generates answers.

The process still requires human decisions.

I had to decide what RunFormance should do, what information matters, how users should interact with it, when recommendations should change, how safety should be handled, and what a useful explanation looks like.

Codex dramatically accelerated the process of turning those decisions into a working implementation.

I also learned that one of the most important parts of building a product is knowing what not to build yet.

The long-term RunFormance vision includes live data from fitness and health platforms, personalized training history, environmental services, and deeper integrations.

For Build Week, the priority became proving the intelligence at the center of that vision: that AI could take recovery, training-load, and environmental context and turn it into an adaptive, explainable training decision.

I also learned that good AI integration is not just about connecting an application to a model.

The surrounding system matters just as much:

• Input validation
• Structured outputs
• Privacy
• Error handling
• Testing
• Production diagnostics
• User experience

I learned a lot about moving a product toward real users — from creating the web experience and beta feedback channels to deploying production infrastructure and working through Apple's external TestFlight beta process.

Testing all four Adaptive Decision Engine outcomes also reinforced the importance of explainability. A recommendation becomes much more useful when the user can see not just the decision, but what changed and why the decision changed.

Finally, I learned that the strongest opportunity for AI in fitness may not be generating more data.

It may be helping people understand the data they already have and turning it into useful decisions.

---

What's next for RunFormance

The next stage is to move RunFormance from a working AI-powered prototype toward the broader adaptive coaching platform I envisioned at the beginning of the project.

With the iOS beta now approved for external TestFlight testing, one of the immediate priorities is bringing real beta testers into the product and using their feedback to guide development.

Future development includes:

• Deeper integration with Apple Health
• Garmin Connect integration
• Strava integration
• Live wearable and recovery data
• Personalized training history
• Customizable plans based on race distance and race date
• Cross-training recommendations
• Dynamic training-plan adjustments
• Richer recovery analysis
• Optional location-aware environmental conditions
• Live weather and air-quality integrations
• Wildfire-smoke and rapidly changing AQI awareness
• Best-time-of-day workout recommendations
• Indoor versus outdoor training guidance
• Longer-term training-load modeling
• User accounts and cross-device personalization
• More sophisticated rate limiting and production safeguards

The goal is to connect those data sources to the intelligence layer that RunFormance now demonstrates in production.

Beta testing and real-world user feedback will play an important role in determining which features provide the most value.

The long-term vision is straightforward:

Give runners one intelligent place where their training, recovery, health, and environment work together.

Better Runs. Better Recovery. Better Health.

Built With

• apple
• capcutai
• codex
• css
• formspree
• github
• gpt-5.6
• javascript
• next.js
• openai
• react
• responsesapi
• testflight
• typescript
• vercel
• zod