> ## Content Index
> Fetch the complete content index at: https://theseguysknow.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# Can a Non-Developer Build an App With Codex?
- URL: https://theseguysknow.io/building-an-app-with-codex-non-developer/
- Published: 2026-09-28T20:24:00.000Z
- Updated: 2026-09-28T21:25:22.000Z
- Description: We took a clickable prototype into Codex and built a live web app. Then we tried using it, found bugs the tests had missed and showed it to three people.
- Author: Mike Hazard
- Tags: Things to Use, Apps & Tools, #how we know

One of the first people to try Unfinished already kept track of paid and unpaid lessons in a notebook. Our app had accounts, saved records, email recovery and encrypted backups by then. She tried the form and found her notebook quicker.

We had set out to answer whether a non-developer could build an app with Codex, and by that point we had one running on a live server. Her notebook showed why we had to go further than asking for a handsome screen and declaring victory.

## Quick Answer

**Yes. A non-developer on our editorial team directed Codex to turn an existing clickable prototype into a live, invite-only web app.** Codex wrote and revised the application code. We set the design direction, decided how the money workflow should behave, set up the GitHub, Render, and Resend accounts and configuration, and tested what people could really do. The app runs in a browser on computers and phones. We have not released a native iPhone or Android app.

We documented the prototype work starting 16 September 2026, and the beta went live by 25 September. Three people tried it. We tested whether we could build and run the app with Codex; long-term use and paid demand were outside this experiment.

## Who Built What

One of our editors directed Codex without hand-coding the app's frontend or backend. They described what it should do, worked through service setup, and tested the result. This was a team project, so we use **we** for the product decisions and testing.

The first prototype was generated with [ChatGPT Work](https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex?ref=theseguysknow.io), not hand-coded by us. We had started there by mistake when the experiment was supposed to test Codex, so we brought its HTML, CSS, and JavaScript into a [Codex desktop project](https://developers.openai.com/codex/app?ref=theseguysknow.io). It already had the cream and dark-green look, an overview, forms, history and three fictional clients. Its interactions lived in memory, so reloading wiped changes; an unrestricted edit could also erase dates we needed to keep. Codex inherited the visual direction and working sketch, then built the persistent app with accounts and a deployment.

![Original Unfinished overview showing three fictional client records and three money categories.](https://storage.ghost.io/c/21/2f/212fa2d6-dfa3-4908-9426-ec8fc852e19d/content/images/2026/09/01-original-prototype-desktop.png)

Recovered original Unfinished prototype, captured locally on 28 September 2026 with its three fictional scenarios. The interface and in-memory interactions predated the Codex backend work; changes reset on reload. This is a new rendering of recovered source, not a historical production screenshot.

| Part of the work     | Codex did                                                                        | We did                                                                                                                                                                                                                                                                                                          |
| -------------------- | -------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Records and accounts | Wrote the server, SQLite storage, authentication and ownership checks            | Specified whose data each account could see and tried two accounts plus a logged-out browser                                                                                                                                                                                                                    |
| Payment workflow     | Implemented stages, dates, history, reminders and validation                     | Decided what each stage meant and checked that later promises never erased the original invoice due date                                                                                                                                                                                                        |
| Design and UX        | Built and revised the screens, components and interactions from our instructions | Set the visual and usability direction, chose which information and action belonged first, approved or rejected versions, and sent back changes                                                                                                                                                                 |
| Testing and repairs  | Wrote and ran automated tests, investigated failures and changed the code        | Entered ordinary records, checked the actual preview, supplied error output and repeated failed actions after fixes                                                                                                                                                                                             |
| Live beta            | Added production checks, email flows, backup and restore code                    | Created and pushed the private GitHub repository; configured Render's paid web service, persistent disk, environment and health check; verified the Resend domain, added its DNS records, stored a send-only mail key and sender address on Render; opened real emails and tried a backup restore on the server |

The table makes the division look tidy. The work itself was a conversation: we described a behavior, Codex changed the app, and we tried to use it. When something looked wrong, a screenshot or the exact error became the next instruction.

## Why We Chose Unfinished

Left to our own tastes, we would probably have built something closer to what TGK usually covers, but we wanted to test the claim that fills X, Reddit, and Instagram Reels, where someone builds and launches an app in a weekend and insists anyone can do the same. So we started the way those videos tell you to, doing market research with GPT and Claude, reading through forums and comparing more than 20 niches, looking for one that wasn't already overcrowded and wasn't so complicated that we'd be completely lost. We also wanted a build that would force real decisions about money, dates, records, and access, because that's where an app either works or quietly lets people down.

Unpaid client work fit all of that, since finishing a job doesn't always mean getting paid: the work might need approval, the approved job might still need an invoice, or a client might promise a new payment date after the original one has passed. We imagined a small business with email in one place, invoices in another, and all those in-between promises still in someone's head.

While researching, we also found plenty of products already working on parts of this problem. [QuoteChase](https://quotechase.app/?ref=theseguysknow.io) deals with estimates, [HoneyBook](https://www.honeybook.com/product/automations?ref=theseguysknow.io) covers much of the client relationship, and [Otterflow](https://www.otterflow.app/?ref=theseguysknow.io) and [Baiivo](https://baiivo.com/?ref=theseguysknow.io) come closer to the approval-to-payment journey we had in mind. We could see why someone might want a clearer view of money stuck between these steps, but also how much existing software already does, so we never claimed Unfinished had found an empty niche. What we really wanted to know was whether the "anyone can build this" promise holds up, or whether it's mostly clickbait and a sales pitch.

## What Working With Codex Looked Like

We used the Codex desktop app for the serious build, giving it ordinary-language requests about the workflow and bringing back failures from the browser or terminal. **Your move / Client's move** had to follow the payment stage while allowing a manual override; a later payment promise had to sit alongside the original invoice due date. If someone sent an invoice elsewhere, the app needed to record that fact without claiming it had sent anything. Codex turned these decisions into code and tests, then we checked the result.

### The design direction came from us

We brought a visual prototype into Codex, but the decisions about what a person should notice and do were ours. We wanted the dashboard to show actions due before the money totals, with the client, the blocker, and a clear next step visible together. Approval amounts and sent invoices had to stay separate so a large number would not suggest all that money was already owed. **Your move / Client's move** needed to follow the workflow, with room for a human override when the situation did not fit the default.

We also checked that the screens never showed something that hadn't happened. The original invoice due date had to stay visible after a client promised a later date, and the history had to show each change instead of overwriting the old one. A button could say an invoice had been recorded as sent elsewhere, but it couldn't suggest the app had sent it. We approved some layouts, rejected others, and sent revisions back when a clean-looking screen hid what the user actually needed to do. Codex built the screens from that direction; the principles were ours.

Currency was a good example of a decision Codex couldn't make for us. When we switched the workspace default to dollars, old records still showed euros, and at first we thought that was a bug. It wasn't. The default only applies to new work, and existing amounts stay in the currency they were entered in. Showing a €1,200 invoice as $1,200 without converting it would have been wrong, so we kept it that way. Codex wrote the code, but we had to decide which behaviour was correct.

The invoice button says **Record invoice sent** because Unfinished records an action completed outside the app. Its follow-up text can be copied into email or chat; the app does not send messages or read replies. We kept correcting language that suggested it had done more than it had.

![Action-first desktop overview with approval, invoicing and overdue-payment tasks above four separate money totals.](https://storage.ghost.io/c/21/2f/212fa2d6-dfa3-4908-9426-ec8fc852e19d/content/images/2026/09/02-local-desktop-overview.png)

Current local Unfinished build (`1fd32756`), with fictional records. Due actions appear before four separate money categories. This capture is from a disposable local workspace, not Render.

### What we set up on Render and Resend

First we created the private GitHub repository, sorted out Git authentication and pushed the code ourselves. We connected its `main` branch to a Render web service in Frankfurt, selected a paid instance with 0.5 CPU and 512 MB of memory, and attached a 1 GB persistent disk at `/var/data`. We set the build and start commands, placed the SQLite database and backups on that disk, configured the app's origin and other environment settings, and stored separate app and backup secrets in Render rather than in Git. When one early deploy failed, we checked the events, redeployed, and used `/healthz` and the running app to confirm which version was live. Later pushes could trigger Render's deployment automatically, but getting the service working in the first place was not something Codex did in our accounts.

Account email needed a second service, so we set up Resend, verified `theseguysknow.io` by adding its mail-authentication DNS records, and left the site's existing incoming mail setup untouched. We created a key restricted to sending from that domain, placed it in Render's secret settings, and set `hello@theseguysknow.io` as the sender. Then we registered a test account, opened the real verification and recovery emails, followed their links and checked the flows in the live app. Codex wrote the verification, recovery and email code, while we connected the services and found out whether the messages actually arrived.

We chose Codex because building with Codex was the point of this experiment, so we did not run a comparison against other coding agents.

0:00 

/0:42 

1× 

****Unfinished on an iPhone:** a screen recording of the live beta in the phone's browser, moving from the money overview to a payment follow-up. The records are fictional. The app prepares the follow-up message; the user sends it separately.

## Where the Tests Passed and the App Still Broke

**An ordinary record would not save.** Codex had reported the V1 usability changes complete, with its tests passing, but when we entered a Ready to invoice item in the local preview, the form failed. We brought the error back to Codex, which traced it to an old server process: the browser loaded a newer form while the process still held older backend code and rejected the new field with `400 Unexpected field.` We backed up the local database and restarted the server; the same entry then saved. Codex paired the frontend and backend at startup and added a test for the form's real HTTP request. A test of the code on disk is no substitute for trying the app running in front of you.

**A valid reset form could disappear.** We reported trouble around verification and password recovery. Codex could not reproduce the screen switch we saw, but its review uncovered another real failure: an old startup request could finish after a new reset link was accepted and make the valid password form disappear. Codex reproduced that sequence, guarded responses from older requests and added a test that completed the reset afterward. When a screen behaves oddly, the exact clicks and timing matter; investigating one report can expose a different bug.

**The first live restore needed a workaround.** On Render, we tried to restore an encrypted backup and the script failed because it expected an account-deletion ledger that did not exist yet. We made an empty file and the restore completed. Codex later changed the script so a missing ledger counts as empty while malformed or unreadable ledgers still cause an error, with new tests for those cases. We found this by running a restore before we needed one.

By **28 September 2026**, the latest local suite reported **97 passing tests**. That result mattered, and so did the failures we found by filling in a form and trying to restore a backup. Codex wrote tests during the build; we kept trying ordinary and awkward paths those tests might not cover.

## What the First Three Testers Told Us

Fictional clients made the dashboard look busy; real people used it differently. One tester, a lesson tutor, already tracked paid and unpaid lessons in a notebook and found our entry flow slower. We responded with a local **Add another like this** shortcut that carries over only the client, project, amount and currency into a new record. We have not yet timed that version with her.

![Fictional overdue invoice with original due date, separate payment promise and a preserved event history.](https://storage.ghost.io/c/21/2f/212fa2d6-dfa3-4908-9426-ec8fc852e19d/content/images/2026/09/04-local-atlas-history.png)

Fictional Atlas Creative history in local commit `1fd32756`: the original invoice due date remains visible alongside a later missed payment promise and prior follow-ups. The “Add another like this” button shown here is local-only, not on the verified Render frontend.

Another tester thought the interface looked like a template and cared about using it like an app on a phone. Our narrow Chrome layout looked tidy, but his point was about the experience of picking it up and recording a change. The third tester suggested user-defined fields or templates rather than a separate setup for every profession. That might make the app flexible, while the notebook complaint points toward asking people to enter less. Three reactions gave us useful design questions; they did not all ask for the same feature.

![Record a sent invoice dialog with sent, due and next-follow-up dates and an explicit confirmation button.](https://storage.ghost.io/c/21/2f/212fa2d6-dfa3-4908-9426-ec8fc852e19d/content/images/2026/09/05-local-record-invoice-action.png)

Unfinished records an invoice sent outside the app. This real dialog was opened for fictional Brightlane Media in local commit `1fd32756`; dates are editable and no invoice or email was sent. The dialog was cancelled after capture.

![Repeat-entry form with three immediate stage choices and four stable fields reused from fictional client work.](https://storage.ghost.io/c/21/2f/212fa2d6-dfa3-4908-9426-ec8fc852e19d/content/images/2026/09/06-local-only-fast-repeat.png)

Local-only “Add another like this” (`1fd32756`), not deployed on the verified Render frontend. Only client, project, amount and currency are prefilled; the new work has its own selected stage and editable date. No entry-time saving has been measured with a user. This dialog was cancelled after capture.

## When We Built and Tested It

| Date in 2026    | Recorded checkpoint                                                                                                             |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| 16 September    | The imported prototype and early account and workflow tests were documented. The prototype's original creation date is unknown. |
| 17 September    | We preserved a working local V1 and prepared the private beta.                                                                  |
| By 25 September | The beta was live, authentication repairs had been pushed, and a backup restore had been tried on Render.                       |
| 28 September    | We checked the live frontend, reran the local tests and prepared the fictional-data screenshots.                                |

These dates show the documented progression, not development hours or the exact first deployment time. The Render service used a paid 0.5 CPU / 512 MB instance listed at **$7 a month**, with a separate 1 GB persistent disk. That is the compute price, not a verified total Render bill. We have not confirmed the Resend account tier or its charge, nor do we have a complete bill for the Codex subscription and our own work. The plan and model used across the Codex sessions also still need confirmation from the account and thread history.

## What to Test Before Launching an App Built With Codex

1. Write down what must remain true when a record changes, such as keeping the original invoice due date after a later payment promise.
2. Read every important button as a user would. If it only records an invoice sent elsewhere, its label must say so.
3. Restart or redeploy after code changes, then make sure you are testing that version rather than an older process.
4. Create two ordinary accounts and try to reach one account's records from the other; repeat while logged out. Our [app-security checklist](https://theseguysknow.io/claude-code-security-checklist-before-launch/) uses Claude Code examples, but this account-isolation check applies to any app built with an assistant.
5. Enter an ordinary record yourself, including the path you expect people to use most often.
6. Open the real verification and recovery emails and follow their links. Test expired and reused links too; our authentication tests covered both.
7. Restore an encrypted backup to a new path before an emergency makes that your only option.

Codex can write tests for each of these. You still need to decide what the correct result looks like and try the running app.

## Final Verdict

We got a functioning, invite-only web app from an existing prototype into production with Codex. Our non-developer editor set the design direction and workflow rules, configured the hosting and email services, and tested the result while Codex wrote and repaired the application code. It holds separate accounts and records, handles the unfinished-money workflow and was used enough to expose bugs we then fixed. The result opens on a phone as a web app; there is no native App Store release.

The part we'd take into the next build is the habit of checking what Codex says it did against what the app lets someone do. We found our strongest evidence in the failed save, the disappearing reset form, the restore error and the lesson tutor's notebook, because each one forced us to look past a tidy result and deal with the thing in front of us.

#### Sources and evidence

- [OpenAI: ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex?ref=theseguysknow.io) explains the two experiences and where Codex runs.
- [OpenAI: Codex](https://openai.com/codex/?ref=theseguysknow.io) describes the coding tool used in this experiment.
- The official product pages for QuoteChase, HoneyBook, Otterflow and Baiivo are linked in “Why We Chose Unfinished.” They informed the market context; they are not evidence that someone would choose our app.
- ****TGK's experiment evidence:** [the public archive](https://github.com/theseguysknow/codex-app-experiment-evidence?ref=theseguysknow.io) contains fictional-data screenshots, dated checkpoints, sanitized test counts and a comparison with the live frontend. Internal build logs and deployment notes also informed the chronology but are not public in this archive.