Dayfork

Inspiration

Would you pay more to live closer to campus? Is a coffee machine worth buying if you already get coffee every day? Should you get an annual membership or stick with a monthly plan?

We kept coming back to decisions like these. You can compare prices, but that only tells you part of the story. We wanted a way to work through the numbers and get a feel for what each choice could look like in everyday life.

That's where Dayfork started.

What it does

You type in a decision you're thinking about, and Dayfork helps you explore two options.

You can fill in missing information, adjust the numbers, and pick the factors you care about. Depending on the question, it can compare monthly costs and time, show when an upfront purchase becomes cheaper, or compare subscription payments over a chosen period.

Some decisions don't have useful numbers to compare. For those, you can focus on things like flexibility, convenience, or changing needs.

Once you're happy with the setup, you can generate a story for each path. These are hypothetical scenes that help you picture both choices, with practical suggestions for each one. Dayfork leaves the decision to you.

How we built it

We used React, TypeScript, and Vite for the frontend, with Zustand for state management and Recharts for the charts. The backend runs on Java and Spring Boot. We connected NVIDIA-hosted Nemotron to help turn the user's question into structured options and generate the stories.

We kept all the money and time calculations in application code. The AI provides the structure and writing, while our calculation functions handle the math.

That also makes it easy to experiment. Changing a price or selecting a factor updates the comparison locally, without another AI call. Stories only regenerate when you ask them to.

We use Zod and backend validation to check the generated data, and the backend independently checks the calculations before requesting a story.

Challenges we ran into

One of the trickiest parts was figuring out how to represent different decisions. Rent and commuting fit a monthly comparison pretty well. A coffee machine needs an upfront cost and a cost per cup. An annual subscription needs to account for paying for a whole period at once.

Missing information was another issue. If someone doesn't give us a price, we need to ask for it instead of letting the model quietly fill it in.

The stories also needed more checking than we expected. In one test, a coffee story mentioned months even though we had only calculated a break-even point in cups. We added checks around numerical claims and made the facts passed into story generation more explicit.

We also had to handle what happens after an edit. If you change your assumptions, the old story might no longer make sense, so we mark it as outdated until you generate a new one.

Accomplishments that we're proud of

We're happy that we got the whole flow working, from a question written in plain language to an editable comparison and two stories.

We also got several different comparison types working in the same app. You can explore housing costs, coffee purchases, subscription plans, or a choice that mostly comes down to qualitative factors.

A lot of work went into the less visible parts, too: keeping missing values unknown, catching invalid inputs, and making sure the charts and stories use consistent numbers. We checked the app with automated tests, desktop and mobile browser checks, and real model responses.

What we learned

We learned how much work happens around the model call. The response needs to fit the app's data structure, stay consistent with the user's inputs, and still make sense after those inputs change.

We also learned to be careful about what we try to quantify. Cost and time can be calculated from known inputs. Things like comfort or flexibility need a different kind of discussion.

Testing actual stories helped us catch problems that wouldn't show up in a calculation test. A response can have the right format and still describe the situation poorly.

What's next for Dayfork

We'd like to add local saving so people can come back to a comparison later. We also want to improve the stories, try more kinds of decisions, and add automated browser tests for the main user flows.

The next step is getting people to try it with their own questions and seeing where it helps, where it gets confusing, and what we've missed.

Built With

• java
• nvidia
• react
• recharts
• spring-boot
• tailwind-css
• typescript
• vite
• zod
• zustand