u/Friendly_Tap737

I've been experimenting with spec-driven development: instead of prompting an AI agent with vibes, you write a real spec first (user story, requirements, API contract, acceptance criteria), let the agent implement it, then validate against the spec and update your roadmap. Loop until MVP.

The app is a Pomodoro timer where you describe your goal conversationally and the AI proposes a task plan sized in pomodoros ("2🍅 ≈50m"). There's a focus coach mid-session, sound cues, PWA install support, and since it's publicly hosted, a Cloudflare Turnstile gate + per-IP daily rate limit on the AI routes so strangers can't drain my DeepSeek credits.

Stack: Next.js 16, Bun, DeepSeek API, Upstash Redis. No database — plan state lives client-side.

What actually surprised me:

1. **Specs didn't slow me down**. Six features in, the AI agent was dramatically better when implementing a spec vs reading my mind. Code review became "does this match section F3?" instead of squinting at diffs.

2. **The spec caught drift.** When the model under-filled a response schema (returned 3 tasks when asked for 3 steps instead of the spec'd 4–8), it was obviously a contract bug, not "weird AI behavior."

3. **Re-planning after every feature** (updating mission/roadmap docs) is the part everyone skips and the part that prevents the codebase from rotting.

Happy to answer questions about the spec format or the abuse-guard setup — both were more interesting to build than the timer itself.

\- Live: \[https://ai-promodoro.vercel.app\\\](https://ai-promodoro.vercel.app)

\- Source (the \`specs/\` folder is the real content): \[https://github.com/adotey7/ai-promodoro\\\](https://github.com/adotey7/ai-promodoro)

Hi everyone — I've been working on a small side project that texts people weather alerts for their area in Ghana and wanted to share where it's at.

First post was a while back. Since then I've made a few changes.

Local weather alerts instead of regional

Originally if you picked Greater Accra you'd get alerts for the whole region.

Now the system uses your actual location to check conditions for your specific area. So if it's storming in Tema but clear in Adenta, only the Tema side gets notified.

Odaw/Dome Bridge flood checks (pilot)

Something I've been testing: for places near the Odaw/Dome Bridge drainage area, the system doesn't just check the weather at your spot. It also checks further up:

• Aburi Ridge
• Ashongman
• Madina

The idea is that water in that drainage doesn't always come from rain directly overhead — heavy rain up the hills can affect areas further down later. So it watches both.

If any of those upstream points look risky, it can flag it early.

Odaw/Dome Bridge

You can change your alert area after setting it up without starting over, the change needs to be verified first so nobody else can switch your area.

Where this is heading

Goal is to do something more useful than generic regional weather alerts, especially for people who don't sit on weather apps all day.

If you know the areas around Odaw or the drainage patterns there well I'd genuinely appreciate your input — trying to get the upstream monitoring right.

I just launched the first working version of StormAlert GH, an open-source SMS alert system for storm and flood-risk updates in Ghana.

​

People can subscribe with a Ghana phone number, verify with OTP, choose their region, and receive SMS alerts when weather risk thresholds are crossed. It currently uses weather data, regional thresholds, GitHub Actions cron, Neon Postgres, and Arkesel SMS delivery.

​

This started as a practical experiment in using software for public safety, especially for people who may not always be online when weather conditions change.

​

Try it here: Storm Alert link

​

Open to feedback, contributors, and ideas on how to make it more useful.