Inspiration
OpenAI says builders of all experience levels are encouraged to participate, and OpenAI’s recent Codex reporting says non-developers are now about 20% of Codex users and growing more than 3x as fast as developers. OpenAI also says Codex does the work around the work. Bizdex is built for that shift: a new business UX for the people who need AI most, even when they are not developers.
A procurement analyst should not need a terminal to resolve a contradiction. SAP says purchase order 4500-8821 is open for GBP 48,200. Company memory says vendor NORTHGATE was retired on 2026-03-04 after two failed quality audits. Bizdex turns that conflict into a governed business decision a nontechnical operator can actually make.
What it does
Bizdex gives business teams a surface for running real work, not just chat.
A user runs a routine from a simple surface, reads evidence in plain language, pauses when approval is needed, writes the outcome back into shared company memory, and publishes the result as a visible site and audit trail.
Procurement is the first workflow, not the only one. Bizdex is designed to extend into other approval-heavy business lanes where a nontechnical operator needs a repeatable, governed process.
It ships four procurement scenarios: Vendor Exception Review, Invoice Matching, Weekly Spend Summary, and New Vendor Onboarding.
How we built it
We built this as a spec-driven product and kept the evidence in the repo as we went. The trail includes the procurement memory graph spec, the substrate core requirements and design, the submission journal, the Codex session evidence, and the release notes.
The substrate memory layer lives in the generated repo at https://github.com/vigneshbarani24/substrate-repo-opena. It is the working memory behind Bizdex: a place where routines, policies, decisions, and evidence compound over time. Bizdex sits on top of that memory as the operator surface, so a nontechnical user can run the workflow without opening a terminal.
The build followed the superpowers flow: brainstorm the product shape, write the design, verify the implementation, and keep the evidence in the repo. Codex helped challenge the thin-slice plan, separate narrative readiness from technical readiness, and narrow the product to a judgeable business loop with clear receipts.
Challenges we ran into
The first challenge was resisting the trap of a demo that looks complete just because the first run passes. Codex pushed back early: the graph was too tied to a single run, some routines were still catalog entries, and the approval story needed to be visible and durable instead of implied.
The second challenge was honesty. The judging path uses deterministic SAP fallback data, so the story had to say that plainly instead of overselling live transport.
Accomplishments that we're proud of
Bizdex now gives non-coders a real business UX: run, review, approve, and publish from one surface.
The memory layer grows with each accepted outcome, so the next run starts smarter than the last.
The repo includes verification, session evidence, and a submission-ready narrative trail instead of only a prototype.
What we learned
GPT-5.6 was strong, but long-running turns could burn tokens faster than expected before the latest update. Codex surfaced that pressure proactively, which saved me from wasting the remaining budget on low-value churn. The bigger lesson was that constraints improve the build when they force judgment: stop polishing, tighten the scope, and spend the remaining effort on product truth.
What's next for Bizdex
Keep hardening the hosted path, replace the last placeholder demo step with the final video, and extend the same UX into other approval-heavy workflows when they add real decision value.
Built With
- codex
- gpt-5.6
- model-context-protocol
- next.js
- node.js
- postgresql
- react
- vercel