FixMyWorkflow

Inspiration

Small-business processes rarely start as formal workflows. They usually live in someone's head, a group text, an email thread, or a spreadsheet.

I wanted to see whether AI could do more than write instructions for those processes. Could it create the form people submit, the tasks a team completes, and the dashboard that shows what still needs attention? That question became FixMyWorkflow.

What it does

A user describes a repetitive process in plain English. FixMyWorkflow turns that description into an intake form, ordered workflow steps, owner roles, task templates, and reminder suggestions.

The property-maintenance demo starts with a manager explaining how tenant repair requests should work. The app creates the tenant request form and a six-step process for reviewing the issue, assigning a vendor, notifying the tenant, tracking the repair, and confirming completion.

When the tenant submits the form, FixMyWorkflow creates a real workflow run. Tasks can be completed from the dashboard, progress updates immediately, and the workflow remains available for the next request.

That is the difference from asking ChatGPT for a checklist: the result can actually receive requests and track work.

How I built it

I built FixMyWorkflow with Phoenix, LiveView, Ecto, and PostgreSQL. Workflows, intake fields, steps, runs, and tasks are persisted and isolated by organization.

The OpenAI integration converts a plain-English process into structured workflow data. Before saving anything, the app validates and normalizes the generated fields, steps, owners, task templates, and reminders. Related records are written together so a failed generation cannot leave half a workflow behind.

After a workflow is activated, its generated intake form can create a run and an ordered task checklist. Completing the current task updates progress and advances the next handoff.

I also added a clearly labeled property-maintenance sample so the complete demo still works when the OpenAI request is unavailable. It uses the same database records, intake form, run creation, and task dashboard as the AI path.

Challenges I ran into

The biggest product challenge was answering a simple question: why use this instead of asking ChatGPT for a checklist?

My first versions focused too much on the generated blueprint. The useful moment did not appear until the blueprint could be activated, accept a real request, create tasks, and preserve progress. Connecting that entire path became more important than adding more generation options.

AI reliability was another challenge. A model response can time out, contain invalid data, or be unavailable during a demo. I added a strict response contract, validation, transactional persistence, clear error handling, and an honestly labeled fallback instead of pretending every result came from a live model call.

I also had to separate the work I built during the event from the Phoenix application shell that already existed.

What I learned

The most valuable part of AI workflow generation is not the generated prose. It is turning that output into application state people can operate.

I also learned that a small complete path is more convincing than a large collection of disconnected features. Describe, generate, activate, submit, complete, and track became the test for every product decision.

What I'm proud of

I'm most proud of the moment when a tenant submission becomes a live task dashboard. The original process is no longer advice on a screen. It has consistent input data, owners, handoffs, reminders, and visible progress, and it can be run again for the next request.

What's next

The next steps would be editable generated blueprints, public intake links, real email or SMS notifications, richer assignment rules, and integrations with the tools small teams already use.

OpenAI Build Week work

The Phoenix application shell, authentication, and organization infrastructure existed before OpenAI Build Week.

During Build Week, I built the FixMyWorkflow data model, structured workflow generation, generated intake experience, activation flow, workflow runs, task dashboard, deterministic demo, landing experience, tests, and submission documentation.

Codex with GPT-5.6 helped me design the Ecto model, implement the Phoenix LiveView journey, validate structured AI responses, write and refine tests, review the UI, and dogfood the complete demo. The runtime OpenAI workflow-generation call is separate from that development collaboration.

Built With

• codex
• ecto
• elixir
• gpt-5.6
• openai-api
• phoenix
• phoenix-liveview
• postgresql