Inspiration
I built TheOne because I was tired of digging through old chats. That same problem shows up when work turns into invoices: I can talk about several projects in one place, then lose track of which client a draft belongs to.
I wanted one chat where I could describe the work, check the project and amount, and create a draft I could trust enough to review later.
What it does
TheOne Invoice Desk turns a message into a proposed project and invoice line. It shows the configured test recipient, amount and description before anything reaches PayPal. I can correct the project during review. Approved proposals become unsent PayPal Sandbox invoice drafts; the app reads each draft back and checks the project reference, recipient, line and total.
Drafts stay in their own project ledger. A repeated approval returns the existing invoice. Unclear requests ask for details. Household spending is a notes-only topic, so it cannot create customer invoices.
How I built it
This is a new standalone adaptation built October 11 on a separate MIT-licensed TheOne branch. The original repository began September30. I reused the repository infrastructure and the one-chat/topic idea; this version does not mount the DSH plugin or access its conversations. Previous TheOne competition demos are not evidence for this integration.
It uses Node24, SQLite, PayPal Sandbox OAuth and Invoicing v2, and actual Nebius nvidia/nemotron-3-super-120b-a12b inference through an OpenAI-compatible endpoint. The model only proposes a plan. Recipients come from server configuration, and the model never receives those addresses.
Codex assisted code, tests, documentation and demonstration preparation. I am an independent developer, not a company. No revenue, customer adoption or production accuracy is claimed.
Challenges I ran into
An early genuine model response returned an empty explanation on an otherwise valid invoice proposal. I made that explanation optional while keeping the execution fields strict. A synthetic monthly-budget message also produced unnecessary clarification; that limitation remains documented, rather than being hidden behind an accuracy claim.
Another problem is uncertainty after a remote request. The app never automatically repeats invoice creation after a timeout. If it has a remote ID, it can reconcile by reading it. If not, the user must check the Sandbox dashboard manually.
Accomplishments that I'm proud of
A synthetic 480 EUR design invoice went through real model inference, browser review, PayPal Sandbox creation and authenticated read-back as DRAFT. A separate read confirmed the reviewed fields. Replaying approval made zero remote requests and returned the same invoice ID. The draft remained after restarting the server.
Eleven focused tests cover money/schema validation, review correction, concurrent approval, replay/restart, unknown request outcomes, remote mismatches and loopback HTTP protections. Their external services are explicitly mocked; genuine cloud evidence is recorded separately. The demo uses one existing Sandbox buyer across its invoice-enabled topics, so it does not prove separation between different buyer accounts.
What I learned
A model suggestion needs a reviewable execution boundary. Keeping the plan, approval and remote verification separate made errors easier to inspect and helped prevent a retry from becoming a second invoice.
What's next
Better handling of ambiguous expense messages, clearer correction history, and integration with the original TheOne conversation flow. Sending invoices and real payments remain outside this version.
Running and testing
The public branch README includes complete local setup instructions for Node24, an existing PayPal Sandbox application and buyer account, and an OpenAI-compatible model provider. No public hosting is required; this is a loopback desktop build. Judges can use their own Sandbox credentials and provider, as described in the README. Credentials and raw responses are not published.
The English video uses actual browser frames held and edited for pacing, with scripted synthetic inputs. It shows one genuine remote draft, a separate local review/correction and an actual clarification. It is not a real-time capture or a benchmark.
Log in or sign up for Devpost to join the conversation.