Weekend Productivity Challenge - FocusFlow AI

A serverless AI planner that takes an unstructured brain dump and returns a structured, prioritized action plan via Amazon Bedrock (Nova Lite). Covers the architecture, prompt design, Terraform deployment, and lessons learned from a weekend build.

Belinda Ntinyari

Cloud/DevOps Engineer

Published Jul 11, 2026

Last modified Jul 11, 2026

The problem
Most mornings, my task list isn't a list  it's a dump. Half-finished thoughts, urgent things mixed with "someday" things, no order, no context. I open a notes app, stare at it, and lose ten minutes just deciding where to start. I didn't need another to-do app. I needed something that could take the mess as-is and hand back a plan.
That's what I built for this challenge: FocusFlow AI.
What I builtFocusFlow AI is a focused productivity tool with exactly one job: take a messy brain dump of tasks and turn it into a prioritized action plan using Amazon Bedrock. No project management suite, no calendar sync, no scope creep just paste your tasks, click a button, and get back priorities, a rough schedule, a focus tip, and a motivational nudge.
Live app:  https://focusflow-ai-unhne6gupqkds6txtbjjn4.streamlit.app/  Source:  https://github.com/Bel-94/FocusFlow-AI 
How it worksThe application follows a straightforward workflow:
The user enters today's tasks into the Streamlit interface.
Clicking Generate Plan sends the tasks to an Amazon API Gateway HTTP API.
AWS Lambda validates the request before building a structured prompt.
Lambda invokes Amazon Bedrock Nova Lite ( amazon.nova-lite-v1:0 ).
The model returns structured JSON containing priorities, a schedule, a focus tip, and motivation.
Lambda stores the generated plan in a DynamoDB table named FocusPlans.
The API returns the response to the frontend.
Users can also view previously generated plans through the History page, which calls the  GET /history  endpoint.
One small usability improvement I enjoyed adding was automatically clearing the input box after a successful plan generation, making it feel ready for the next planning session.
ArchitecturePlain text
Streamlit UI (Streamlit Community Cloud)
        │
        ▼
Amazon API Gateway (HTTP API)
   POST /generate-plan
   GET  /history
        │
        ▼
AWS Lambda (Python 3.12)
        │
        ▼
Amazon Bedrock (amazon.nova-lite-v1:0)
        │
        ▼
Amazon DynamoDB (FocusPlans, PK: planId, on-demand)
        │
        ▼
Amazon CloudWatch Logs
Everything runs in  us-east-1 , and all of it is provisioned with Terraform, with IAM roles scoped to least privilege no  AdministratorAccess  anywhere in the stack.
AWS services usedAmazon Bedrock — the reasoning engine. I call the Nova Lite model with a system prompt that turns it into a productivity coach and forces a strict JSON response shape.
AWS Lambda — the glue. Validates requests, calls Bedrock, handles errors, and talks to DynamoDB. Python 3.12, kept intentionally small and single-purpose.
Amazon API Gateway (HTTP API) — the front door. Exposes  /generate-plan  and  /history  as clean REST-style routes for the Streamlit frontend to call.
Amazon DynamoDB — storage for generated plans. On-demand capacity,  FocusPlans  table keyed on  planId , so I don't pay for idle throughput on a weekend project.
Amazon CloudWatch Logs — visibility into Lambda execution, which was essential for debugging Bedrock and DynamoDB errors during the build.
All free-tier-friendly, and nothing here needs to be provisioned in advance; Lambda and DynamoDB on-demand mean I'm not paying for idle infrastructure between demos.
Prompt engineering notesThe prompt does the real work. I instruct the model to act as a productivity coach and to return only valid JSON with four fields:  priority ,  schedule ,  focus_tip , and  motivation . Two things mattered most:
Forcing valid JSON. Without strict formatting instructions, the model would occasionally wrap the output in explanation text. I tightened the prompt until responses were parseable JSON every time.
Task-specific tips, not generic ones. A generic "take breaks" tip is worthless. I explicitly instruct the model to reference the actual tasks in the  focus_tip  and  motivation  fields, so the output feels like it read what I wrote, not like a template.
Build & deploy processThe backend  Lambda, API Gateway, DynamoDB, IAM is entirely defined in Terraform, so I can tear it down and rebuild it identically. The frontend is a Streamlit app hosted on Streamlit Community Cloud, configured with an  API_BASE_URL  secret pointing at the API Gateway endpoint. Being honest about the split: Streamlit Cloud hosts the UI because it's the fastest way to get a public, shareable frontend; AWS runs the actual AI logic and storage. I didn't try to force the UI onto AWS just for the sake of an all-AWS badge, I used the right tool for each job.
The API base is  https://f4wluoskhh.execute-api.us-east-1.amazonaws.com . Hitting the root returns "Not Found"  that's expected, since the real routes are  /generate-plan  and  /history .
Demo / proof it worksThe live app is here:  https://focusflow-ai-unhne6gupqkds6txtbjjn4.streamlit.app/ 
﻿
﻿
﻿
﻿
﻿
Challenges & lessonsAmplify vs. Streamlit for a Python app. I initially considered AWS Amplify for hosting, but Amplify is built around JS/static frontends, not Python apps like Streamlit. Streamlit Community Cloud was the pragmatic choice for getting a working public URL fast.
API root returning "Not Found." This tripped me up briefly until I remembered HTTP APIs don't serve a root route by default, only the routes I explicitly defined ( /generate-plan ,  /history ) respond.
Clearing the input after submit. Getting the brain-dump text box to reset after a successful generate required managing Streamlit's  session_state  directly rather than relying on default widget behavior.
Shared history, no auth. In this version,  /history  returns a shared table of plans — there's no per-user login, so it's not private multi-user history. That's a deliberate v1 scope cut, not an oversight.
Reflection: what I discoveredThis challenge pushed me beyond "just calling an AI API." The biggest shift was thinking in systems: frontend → API → Lambda → Bedrock → DynamoDB → logs.
Amazon Bedrock (Nova Lite) taught me that model quality isn't only the model  it's the prompt. Forcing strict JSON, a coach persona, and task-specific tips made the output useful instead of generic.
AWS Lambda + API Gateway showed how clean a small serverless backend can be: two routes, validation, and clear errors without managing servers.
DynamoDB was a simple win for persistence. One table ( FocusPlans ) was enough for a weekend MVP and reminded me that shared history is fine for a demo, but real products need auth and per-user data later.
Terraform changed how I deploy. Instead of clicking around the console, I defined IAM (least privilege), Lambda, API Gateway, DynamoDB, and CloudWatch as code I can recreate.
Hosting was the surprise lesson. I assumed Amplify would host Streamlit easily. Streamlit needs a live Python process, so Amplify static hosting isn't the right fit. Streamlit Community Cloud got me a public UI fast while keeping the AI backend on AWS  a practical tradeoff for shipping on time.
I also learned small but painful builder details: API root URLs return  Not Found  if you only defined  /generate-plan  and  /history , and Streamlit  session_state  can't update a widget key after it's created in the same run.
Overall, I discovered a pattern I'll reuse: focused AI feature + serverless AWS backend + IaC + ship a public URL early, then improve.
What's nextAdd Amazon Cognito so history is private per user instead of shared.
Tighten CORS configuration on the API Gateway routes.
Add a Global Secondary Index (GSI) on DynamoDB to query plans by user/date instead of scanning.
Look at Bedrock Guardrails to add a safety layer around model input/output.
Final ThoughtsOne thing I appreciated about this challenge is that it encouraged builders to solve a real problem without over-engineering the solution.
FocusFlow AI doesn't try to replace an entire productivity platform. It simply helps transform a messy list of tasks into a clearer plan for the day and that's often enough.
If you'd like to try it, you can explore the live application here:
 https://focusflow-ai-unhne6gupqkds6txtbjjn4.streamlit.app/ 
And if you're interested in the implementation or want to recreate something similar, the complete source code is available here:
 https://github.com/Bel-94/FocusFlow-AI 
I hope this walkthrough gives other builders a practical starting point for experimenting with Amazon Bedrock, serverless architectures, and Infrastructure as Code in their own projects.