Inspiration
I am an artist and a musician, not a developer.
Temple Flow did not begin as a startup idea, a hackathon strategy, or an attempt to invent a profitable problem.
It began with a real problem in my own life.
One Friday evening, while watering my plants, I started a voice conversation with ChatGPT about something that had been frustrating me for a long time.
I was constantly reaching for my phone.
I would open a social network, switch to my emails, watch part of a video, move to another application—and often forget why I had picked up the phone in the first place.
I asked ChatGPT to help me explore my attention patterns. Not as a medical diagnosis, but as a way to understand what I was doing and what I was actually looking for.
The answer became increasingly clear:
I was looking for stimulation.
But I did not want to spend more of my life consuming stimulation passively.
I wanted to create music, write, develop ideas, move meaningful projects forward, reflect, walk, rest, and feel present.
I realized that the real problem was not the phone or the applications themselves.
The problem was autopilot.
Between the impulse and the action, my intention was disappearing.
That evening, I had an idea:
What if the first application I opened did not ask for my attention, but asked for my intention?
What if, instead of pulling me into another feed, it understood my projects, priorities, creative interests, available time, and energy—and helped me choose one action that actually mattered?
At first, I imagined building a small private application only for myself.
I thought I could use Codex to create a personal interface, host it on my own website, and use it whenever I felt scattered.
The following evening, while brushing my teeth, I received the email announcing the OpenAI Codex Hackathon.
The timing felt almost impossible.
I had just decided to build my own application with Codex, based on a painful and deeply personal problem—and suddenly there was an open challenge inviting anyone to build exactly that kind of project.
So I did not go to sleep.
I spent the next two hours walking through the quiet streets near my home, talking through the idea, refining its philosophy, and inventing what would become Temple Flow.
Four days later, the application was online.
What Temple Flow does
Temple Flow is a calm, context-aware ritual that helps people move from automatic distraction to intentional action.
It begins with one question:
What matters right now?
The user can choose between six paths:
- My intention — I already know what I want to do.
- Move a project forward — Choose the next useful action.
- Create — Give shape to an idea.
- Find inspiration — Discover something that can nourish my work.
- Recharge — Make space and restore my energy.
- Reflect — Pause, organize, and regain clarity.
If the user already knows what matters, Temple Flow does not interfere. They can write their own intention and begin.
If the user feels uncertain, a quieter secondary option allows Temple Flow to suggest a direction.
The application then asks how much time is available:
- 10 minutes
- 30 minutes
- 1 hour
- No preference
Temple Flow combines the selected intention and duration with the user’s personal context.
That context may include:
- current priorities;
- active projects;
- next actions;
- creative interests;
- preferred ways to recharge;
- suggestions the user wants to avoid.
The result is not a catalogue of possibilities.
It is one clear action.
For example:
Record the first 30 seconds of a new song.
Then Temple Flow gets out of the way.
Because the goal is not to spend more time inside the application.
The goal is to return to real life.
Personal context without friction
Temple Flow lets users add their context through:
- a structured AI profile;
- pasted JSON;
- pasted plain text;
- a short manual form;
- a built-in demonstration profile.
The profile remains editable and is stored locally in the browser.
The current hackathon version uses a deterministic local suggestion engine. It combines the user’s context, chosen intention, and available duration to select a concrete action.
This decision made the prototype:
- reliable;
- private;
- easy to demonstrate;
- tolerant of incomplete profiles;
- safe from exposed client-side API credentials.
The suggestion layer is separated behind a clear abstraction so a secure model-backed provider can be connected later.
The central principle remains the same:
Temple Flow should understand enough to offer one meaningful next step—and then become quiet.
Why a temple?
When a Flow ends, Temple Flow does not say:
- Congratulations
- Mission accomplished
- You won
- Keep your streak alive
It simply says:
You honored your intention.
Then the temple evolves.
The temple is not a score.
It is not a productivity meter.
It is not a status symbol.
It is not proof that the user performed well.
It is a memory.
Each architectural evolution represents a moment when the user chose intention over autopilot.
That moment may have been spent:
- creating music;
- writing;
- coding;
- walking;
- resting;
- reflecting;
- calling someone;
- or moving a meaningful project forward.
The central crystal represents intention.
The surrounding clouds represent noise, possibility, stimulation, and mental fog.
As more intentions are honored, the sanctuary gradually emerges from the clouds.
The temple does not merely grow larger.
It matures.
Architecture appears. Water arrives. Paths form. Vegetation develops. The sanctuary gains depth.
The long-term vision is a silent visual autobiography: a place shaped by different seasons of a person’s life—beginning a creative practice, building a project, returning to music, becoming a parent, or choosing a period of rest.
The temple remembers without judging.
How I built it
I built Temple Flow with:
- OpenAI Codex
- Next.js
- React
- TypeScript
- CSS
- Local Storage
- GitHub
- Vercel
Codex helped me turn a product philosophy into a complete working application.
It contributed to:
- responsive component implementation;
- TypeScript data modeling;
- personal-context onboarding;
- JSON and plain-text import;
- manual context editing;
- six intention paths;
- custom intentions;
- duration-aware suggestion logic;
- Flow timing;
- persistent history;
- temple milestone selection;
- the post-Flow reveal animation;
- demo controls;
- targeted demo-data reset;
- accessibility improvements;
- English interface adaptation;
- testing;
- and focused debugging.
GPT-5.6 helped me reason through:
- the product philosophy;
- the attention-versus-intention framing;
- the personalization model;
- the six intention categories;
- the role and personality of the AI;
- the temple symbolism;
- the visual progression;
- the microcopy;
- the product film;
- and the narrative behind every interaction.
The deployed prototype does not claim to call GPT-5.6 directly from the browser.
No API key is exposed in the client.
The production path would connect the existing suggestion abstraction to a secure server-side model provider.
The hardest challenges
Protecting the idea from becoming another productivity app
The easiest version of Temple Flow would have included:
- scores;
- streaks;
- levels;
- dashboards;
- statistics;
- achievements;
- reminders;
- endless recommendations.
But that would have contradicted the original problem.
The world already contains enough products designed to retain attention.
Temple Flow had to return it.
For every feature, I repeatedly asked:
Does this help someone return to their life, or does it create another reason to remain inside the application?
That question led me to remove explanations, reduce choices, simplify screens, and preserve one primary action at a time.
Making personalization feel real
Generic creative exercises were not enough.
If Temple Flow knew that I was building a demo, making music, and preparing a submission, it needed to reflect that reality.
The context system therefore became a core part of the product—not a decorative onboarding screen.
Designing progression without turning it into a reward system
The temple needed to evolve enough to feel meaningful, but never resemble a game.
Every milestone had to preserve:
- the same visual language;
- the same camera;
- the same atmosphere;
- the same crystal;
- the same clouds;
- a coherent architectural progression.
The reveal needed to feel like memory taking form, not like unlocking a level.
Building as a non-developer
AI made implementation radically more accessible, but it did not remove the need for judgment.
The first versions were not good enough.
Some were visually inconsistent. Some were too complicated. Some felt generic. Some broke the progression logic. Some made the demo state interfere with the real Flow count.
I had to iterate, test, reject, refine, and debug repeatedly.
Codex could propose and implement.
I still had to decide what deserved to remain.
Accomplishments I am proud of
In four days, I went from a voice conversation about my own distraction to:
- a complete product philosophy;
- a Canon and Design Bible;
- a responsive web application;
- personal-context onboarding;
- six intention paths;
- free-form personal intentions;
- duration-aware personalized suggestions;
- a working Flow timer;
- persistent history;
- multiple temple milestones;
- a cinematic reveal sequence;
- a demonstration mode;
- a resettable filming workflow;
- an English interface;
- a public GitHub repository;
- a Vercel deployment;
- and a complete product film.
Most importantly, I built something that I now genuinely want to use.
Even if Temple Flow never wins a prize, I still leave the hackathon with the application I needed before the hackathon existed.
What I learned
Before this project, I did not consider myself capable of building a complete software product.
I am an artist. I compose music, write, create images, and develop ideas.
Codex changed what felt possible.
But the most important lesson was not simply that AI can generate code quickly.
It was this:
When building becomes more accessible, taste, persistence, intention, and meaning become even more valuable.
AI can create an interface.
It can implement a state machine.
It can debug a progression system.
But the human still has to decide:
- what problem is worth solving;
- what experience feels right;
- what should be removed;
- what deserves attention;
- and what kind of technology should exist.
Temple Flow was built with AI.
But it was shaped by a deeply human need.
What makes Temple Flow different
Temple Flow is not designed to maximize engagement.
Its success is not measured by daily active users, session duration, or how frequently someone returns.
It succeeds when the user leaves.
Its principles are:
- Intention before action
- Calm before engagement
- Life before the application
- Memory before reward
- Simplicity before abundance
We are not building a feed.
We are building a threshold.
We are not capturing attention.
We are returning it.
The world constantly asks for your attention.
Temple Flow begins by asking for your intention.
What’s next
The next version could include:
- secure GPT-powered suggestion generation;
- deeper understanding of changing priorities and energy;
- encrypted synchronization between devices;
- context portability and export;
- richer memories linked to previous Flows;
- interactive temple areas connected to periods of life;
- more nuanced architectural evolution;
- user-defined rituals;
- multilingual support;
- improved accessibility;
- and a temple that matures across years of intentional living.
I created Temple Flow because I was tired of feeling scattered.
In four days, with Codex, I built the application I wished already existed.
Now there is only one thing left to do:
Keep growing the temple.
Try Temple Flow
Live application:
https://temple-flow.vercel.app
Demo mode:
https://temple-flow.vercel.app/?demo=true
Source code:
https://github.com/JordanSery22/temple-flow
Built With
- gpt5.6

Log in or sign up for Devpost to join the conversation.