ApproKai

An approval platform for businesses of any size. It turns plain-language policies into structured, editable workflows and dynamically routes requests based on roles, hierarchy, and business data.

Comment

ApproKai: From Approval Complexity to Conversation

Inspiration

Over the years, I have built approval processes in many different ways: Power Automate, Microsoft Forms, ServiceNow, and custom PHP applications. Each tool solved part of the problem, but I repeatedly encountered the same limitations. Building a workflow took too much time, customization became difficult as requirements evolved, and the result rarely matched how the organization actually worked.

What I wanted was not another fixed approval application. I wanted a platform that could adapt to different forms, organizational structures, routing rules, and approval scenarios without requiring a developer for every change.

A few weeks before OpenAI Build Week, I decided to explore whether Codex could help me build it.

I began with a relatively simple list of approval features. However, as I worked with Codex, our conversations pushed the project toward a much broader enterprise design. We considered questions such as:

  • How should requests be routed through managers, roles, departments, and conditional rules?
  • How should workflow versions and changes be controlled?
  • What happens when an approver is unavailable?
  • How can every action remain traceable?
  • How should the platform integrate with Microsoft 365 and Teams?
  • How can administrators test a workflow before releasing it?

My initial feature list quickly became a complete platform specification. By the end of the first night, Codex had helped turn that specification into a runnable application.

The First Challenge: Dynamic Workflows Are Hard

Getting an application to run was only the beginning.

Dynamic approval workflows involve much more than moving a request from one person to another. The platform must evaluate conditions, resolve approvers, support sequential and parallel steps, handle delegations, calculate required approval counts, preserve workflow versions, and respond safely when no approver can be found.

Even after the first version was built, I sometimes could not understand how to configure or use my own application. I had to work back and forth with Codex - testing scenarios, identifying unclear behavior, improving the interface, and strengthening the workflow logic.

That iterative process eventually produced a platform where administrators could configure request forms, dynamic workflows, approval matrices, notification channels, delegations, Microsoft 365 user synchronization, audit logs, APIs, webhooks, and operational reports.

But then I discovered another problem.

The platform was configurable, yet configuring it was still manual. Instead of writing application code, administrators now had to manually define fields, workflow steps, routing conditions, and approver rules. I had moved the complexity to a different layer, but I had not eliminated it.

The Build Week Idea

When I discovered OpenAI Build Week, I initially struggled to see where AI should fit into the project. I did not want to add a chatbot simply to claim that the platform used AI. I wanted AI to solve a real problem.

Then the idea became clear:

What if an administrator could describe an approval process in plain language, and AI could translate it into a safe, executable configuration?

For example, an administrator could request:

Create a purchase request form. Requests under $5,000 require manager approval. Higher-value requests also require Finance approval."

GPT-5.6 could interpret the request and produce a structured plan containing the form fields, workflow steps, conditions, and approver rules. ApproKai would then validate that plan, show a preview, explain its assumptions, and create the configuration only after explicit human confirmation.

This became the AI Configuration Assistant - the major new capability I added during Build Week.

How I Built It

I first used Codex (model 5.6) to challenge the idea, explore possible user flows, and identify the safety boundaries required when converting natural language into application configuration.

I then worked with Codex (model 5.6) to implement the complete feature inside the existing platform. Approximately one hour later, I had the first end-to-end version available to test. Reaching a reliable result required many more iterations, but that initial speed completely changed how I thought about software development.

The assistant follows a controlled process:

  1. The administrator describes the required form and approval policy.
  2. An AI Model (via API) either asks clarification questions or returns a structured configuration plan.
  3. ApproKai validates every field, condition, user, role, department, and routing rule.
  4. The administrator reviews a preview containing assumptions, warnings, and the resulting workflow.
  5. Only after explicit confirmation does ApproKai create draft forms and workflows.

The model does not directly publish workflows, execute database commands, or silently modify production configuration. AI proposes; deterministic application code validates and executes; a human remains in control.

Codex helped me throughout the process: architecture, implementation, debugging, test scenarios, validation rules, user experience, and documentation. It acted not only as a code generator, but also as an engineering partner that continuously challenged incomplete requirements.

Challenges I Faced

The hardest challenge was translating flexible human language into deterministic workflow rules. A model can suggest a reasonable process, but enterprise software cannot depend on "reasonable". User references must exist, form-field names must match exactly, numeric conditions must contain valid values, and every workflow must have a safe outcome.

I addressed this through constrained structured output, catalog-aware prompting, server-side validation, previews, draft-only execution, and explicit confirmation.

Another challenge was balancing speed with reliability. Codex could create features remarkably quickly, but I still had to make product decisions, test edge cases, and decide which actions AI should never perform automatically.

Finally, I learned that explaining a workflow is almost as important as executing it. Administrators need to understand why a step was included, which rule matched, who will approve it, and what happens when configuration is incomplete.

What I Learned

My most important lesson is that the difficult part of enterprise AI is not generating an answer—it is creating a trustworthy boundary between probabilistic AI and deterministic software.

I also learned that Codex is most powerful when treated as a collaborator rather than a replacement for engineering judgment. The quality of the result still depends on clear requirements, careful decisions, testing, and iteration. Codex dramatically reduces the distance between an idea and a working implementation, while leaving responsibility for the product with the engineer.

After 20 years as a software engineer, I believe a platform with this scope would traditionally require a senior team and many months of work. Building ApproKai showed me that a single experienced engineer working deeply with Codex can now explore, implement, and validate ideas at a completely different speed.

What's Next

My next goal is to make ApproKai capable of understanding existing policies and helping organizations continuously improve their workflows - not only creating them.

I plan to add policy-document analysis, conversational workflow revisions, richer simulations, multilingual configuration, and clearer explanations of every approval decision.

ApproKai began as an attempt to build a better approval system. It became an exploration of how AI and human judgment can work together to create enterprise software that is both flexible and trustworthy.

Share this project:

Updates