Inspiration

Stress and mental health are becoming a bigger issue for students and young professionals. In 2023, 39.7% of U.S. high school students reported poor mental health, and diagnosed anxiety among U.S. adolescents increased by 34% from 2016 to 2023.

At the same time, consumer health apps have gotten very good at collecting data. Wearables can track sleep, heart rate, HRV, recovery, temperature, and activity. The problem is that most of these tools still leave the user to interpret the numbers on their own. They show what happened, but they do not always explain what it means, why it matters, or what action someone should take next.

Pulse was built around that gap. It turns health signals, calendar context, and personal patterns into simple, timely stress support throughout the day.

What it does

Pulse connects biometric data with real-life schedule context to provide personalized stress guidance.

It can:

  • Gather Oura data like sleep, HRV, heart rate, breathing rate, and temperature
  • Read calendar data to understand schedule pressure, meeting density, deadlines, and recovery gaps
  • Compare current signals against the user’s normal baseline
  • Classify the user’s current load as low, steady, or high
  • Identify what may be driving stress, such as poor sleep, a packed schedule, or limited breaks
  • Send a specific recommendation at the right time, such as taking a short walk during an open calendar slot

Pulse is not meant to diagnose stress or mental health conditions. It is meant to help users make better decisions with the data they already have.

How we built it

We used Kiro as both a development tool and a system design partner. The main goal was to build a product that could take multiple inputs, reason through them, and return one clear next step for the user.

We started with a spec-driven approach. Before building, we defined the core system: the Oura data flow, Google Calendar data flow, structured signal layer, LLM output, API contract, JSON response schema, fallback logic, frontend structure, and expected user experience. This gave us a clear foundation before writing code and helped keep Kiro aligned with the actual product direction.

Once the structure was clear, we used Kiro to move quickly. It helped us generate a Node.js backend that connects Oura, Google Calendar, SMS, and Claude, and a React frontend that matched the backend API. We also used it to build the logic for interpreting daily load and refine the recommendation language so it felt clear and useful.

A big part of the build was constraining the LLM. Instead of giving broad prompts, we required the LLM to return a fixed JSON structure with fields like:

  • stress_level
  • drivers
  • action_recommendation
  • summary

Each field had specific rules. For example, stress_level had to be Calm, Elevated, or High. drivers had to be 2 to 4 short phrases. action_recommendation had to reference a real calendar slot when one was available. summary had to explain the situation clearly without sounding too clinical or generic.

We kept that structure consistent across the whole stack. The backend creates structured inputs like baselines, body signals, and free calendar slots. The LLM turns those inputs into a defined output. The frontend renders that output directly without extra transformation. This made the system easier to debug and easier to iterate on.

We also built a custom hook to keep the project focused. It helped avoid unnecessary auth, database work, and extra abstractions while validating API responses against the expected schema.

For design, we used the Figma MCP server to connect design context directly into development. This helped reduce the gap between the design and the final implementation.

Challenges we ran into

One challenge was that Kiro sometimes changed things we did not want changed. It occasionally added back patterns we had already rejected, like changing the UI structure or adding unnecessary backend complexity. We fixed this by making the specs more explicit and adding stronger constraints.

Another challenge was figuring out the right balance between spec-driven development and vibe coding. At first, we mixed the two too much. We learned that specs are better for defining the system, setting constraints, and keeping the product stable. Vibe coding is better for moving quickly, testing ideas, and improving the experience.

We also had to make sure the LLM output was actually useful. A generic response like “take a break” was not enough. We wanted Pulse to recommend something specific that fit into the user’s actual day, so we made the recommendation depend on both body signals and calendar context.

Accomplishments that we're proud of

We built a complete product from scratch, including the concept, design, backend, frontend, and working system.

We are proud that we:

  • Built a working backend that connects Oura, Google Calendar, SMS, and Claude
  • Created a frontend that presents stress load and recommendations clearly
  • Designed a calm and simple UI that fits the problem space
  • Built proactive reminders that can reach users without requiring them to open the app
  • Created a system that combines health data, calendar context, and LLM reasoning into one recommendation

The biggest accomplishment was getting the full loop to work: user data comes in, the system interprets it, and the user receives a useful next step.

What we learned

We learned that AI-assisted development works best when the product direction is clear.

The main takeaways were:

  • Clear specs make AI-assisted development more reliable
  • Constraints help prevent unnecessary changes and inconsistent outputs
  • LLMs need structured inputs and structured outputs to be useful in a product
  • A full-stack AI product needs clean data flow between the backend, LLM, and frontend
  • AI tools can speed up development, but product judgment still matters

We also got more experience building a full-stack product with:

  • Backend APIs
  • React frontend
  • Oura integration
  • Google Calendar integration
  • SMS reminders
  • LLM-generated recommendations
  • End-to-end product flow

What's next for Pulse

Next, we would want to build:

  • More personalized stress management plans based on what has helped the user before
  • Long-term pattern detection for recurring high-stress periods
  • Better support resources, such as breathing exercises, short breaks, or grounding tools
  • Dashboard insights for focus, recovery, and learning readiness
  • A friend feature to help users stay connected and supported
  • More advanced preference learning so Pulse can adapt to each user over time

Built With

Share this project:

Updates