AI-assisted KPI management system: 4 months of development and still no working application. Advice needed.

[peteshop01-boop]

Hi everyone,
I'm looking for practical advice from experienced developers who have built business applications using ChatGPT, Codex or similar AI coding tools.
I'm an operations manager at a UK charity, with a background in technology project management, but I'm not a software developer.
For the past 3–4 months, I've been developing a KPI management system using AI. We've generated significant amounts of code, automated tests, documentation and various builds, but still haven't delivered a reliable, working end-to-end application.
I'm beginning to question whether the development process, choice of platforms or overall approach is fundamentally wrong.
What I'm trying to build
A KPI management system for approximately 25 employees that:
Allows staff to create individual workplans and KPIs.
Supports manager review, approval and amendments.
Records quarterly progress, targets, outcomes and supporting evidence.
Links individual KPIs to organisational strategic objectives.
Automatically calculates performance and RAG ratings.
Produces interactive management dashboards and Board reports.
Includes appropriate permissions, audit trails and version control.
Works reliably on desktop and mobile.
Platforms and technology currently being used
ChatGPT
OpenAI Codex
GitHub
Microsoft 365
Microsoft Power Apps / Power Platform
Microsoft SharePoint
Cloudflare Workers
JavaScript / HTML / CSS
Node.js
Windows Mini PC
Desktop Commander (MCP)
Restrictions and requirements
Preferably use existing Microsoft 365 infrastructure and licensing.
Keep hosting and ongoing costs low.
Ensure appropriate security for employee information.
Maintain separate development, testing and production arrangements.
Deliver something that non-technical staff can maintain and operate.
Avoid the need for an ongoing full-time developer.
Where things have gone wrong
We've spent months developing different components of the system.
Automated tests have passed, but the complete application has not reached an acceptable working state.
There are numerous local files, scripts, different builds and development records.
We have a GitHub repository, but I'm not confident that our development process consistently maintains one authoritative, up-to-date codebase.
AI has effectively acted as developer, tester and project manager, but progress has become fragmented. Development work doesn't consistently translate into tested, usable functionality.
Despite extensive development activity, we still don't have a complete application that staff can use.
Questions I'd appreciate advice on
Are these the right platforms for this type of application, or have I overcomplicated the architecture?
Would you build this in Power Apps, as a custom web application, or using another platform entirely?
What is the most effective way to organise an AI-assisted software development project using Codex?
How should I structure GitHub, local development, testing and deployment so everything stays synchronised?
How do experienced developers prevent AI coding agents from producing disconnected code and repeatedly rebuilding or breaking previously completed functionality?
Would you recommend auditing and recovering the existing code, or starting again with a simpler approach?
What would your first five steps be if you inherited this project today?
Realistically, how long should a competent developer take to deliver something like this?
I'm open to changing platforms, simplifying the requirements or adopting a completely different development process.
What I'm really looking for is a proven approach to taking an AI-assisted project from requirements through development, testing and deployment, without losing control of the code or continuously revisiting completed work.

[TheodorNEngoy]

I’m building Turnfeed with Codex, and passing tests didn’t catch several problems I found by using the deployed site. I’d start by making one complete workflow work reliably before adding more.

My first five steps would be:

1. Preserve the existing files, choose one repository and branch as the source of truth, and record which commit is actually deployed.
2. Write one acceptance path with dummy data: a staff member creates a KPI → submits it → a manager approves → progress is updated → the dashboard reflects the saved result.
3. Run that path in a separate test environment using both roles, refreshing or reopening after each change. Check that each role cannot perform the other’s restricted actions.
4. Give Codex the first failing step, expected versus actual result, and relevant error. Ask it to trace the existing implementation and fix that one failure.
5. Rerun the whole path before expanding scope.

I haven’t seen your code, so I wouldn’t choose a new platform or estimate delivery time yet. What is the first concrete failure in that smallest workflow?

[peteshop01-boop]

Hi thanks for this sorry been off line i've actually done another post that might give clearer direction as to where i am now

After roughly two months, we have substantial code, tests and project documentation, but we still have not demonstrated the basic end-to-end result we need: an ordinary employee saves their information, closes the application and reopens it, with another employee unable to access it.

I am overseeing this as the business owner rather than the hands-on software developer. I would welcome honest feedback on the architecture, code, testing and the way we are organising the AI-assisted delivery. I am open to being told that we have made the wrong choices or overcomplicated something.

The source code and supporting review material for both projects are available in one public repository:

Microsoft 365 applications: code and developer-review pack

An initial assessment of one part would be useful. I am not expecting someone to review everything before commenting.

What we are building

1. KPI and employee workplans

Employees select their Core KPIs, create their own Impact KPIs, choose development behaviours and set quarterly targets. They need to save an incomplete private draft, return to it and make changes.

The wider application includes submitting the workplan to a manager, requesting changes, approving and locking an agreed version, quarterly progress updates, evidence and consolidated reporting.

The source uses SharePoint Framework, React and TypeScript. The intended draft Save updates a private SharePoint record through the employee’s signed-in connection. A separate protected record holds ownership, year, status and the link to the editable draft. Manager approval is a separate process.

The question is whether that separation and its permission controls are proportionate, and what is missing between the existing code and a reliable installed application.

KPI source and tests

2. Expenses and mileage

Employees enter multiple expense lines against a monthly claim, select account codes, attach receipts or explain their absence, and record mileage. Managers approve or query individual lines. Finance reviews claims and later exports information for payroll.

This also uses SharePoint Framework, React and TypeScript, but its Save design differs. The browser submits a private request. A trusted Power Automate workflow is intended to establish the employee’s identity, validate the claim and write the expense and related records.

The design includes duplicate-request handling, version checks, receipts, claim totals, processing results, audit records and recovery after interrupted writes. I would particularly welcome a challenge to whether the amount of processing and checking is justified for our needs.

Expenses source, workflow code and tests

The intended processes and data relationships are explained here:

Architecture, Save and approval diagrams

How we have organised the AI-assisted work
The approach has involved a project lead/adviser, a delivery PM, build agents and separate technical, security and QA review roles. I provide the business requirements, decisions and user acceptance.

We have used requirements and sprint plans, isolated code branches/worktrees, GitHub, automated tests, review evidence and handovers between agent sessions. Development has involved Windows machines and GitHub-hosted checks, with a separate Microsoft 365 TEST environment.

The intention was to have clear ownership and independent checking. In practice, we have repeatedly seen individual checks or reviews finish without the next delivery step starting. There have also been repeated handovers, approval questions and later-feature work while the first usable Save remained unfinished.

I would like to understand whether we have created too much coordination and administration, and what a simpler, more effective AI-assisted delivery model should look like.

The agents are helping build the software. They are not intended to sit inside the finished applications making employee approval decisions.

Delivery approach and questions for review

Where we are stuck
There is useful code and there have been historical automated test successes. KPI has also progressed with private test-record setup, ordinary-user reads and further source wiring.

However, that does not yet establish that the current installed version passes the complete Save, fresh reopen and two-user privacy checks. Expenses likewise has processing code without a demonstrated, accepted installed Save journey.

The remaining questions include first-record creation, connecting the intended services, reconciling schemas and permissions, choosing the correct source version, executing the relevant tests and installing that same checked version.

There have also been browser failures, local script errors and tool refusals. These need distinguishing from application defects and delivery-management problems, rather than becoming one general explanation for lack of progress.

Current issues, evidence and next actions

What I would like help reviewing
Architecture and platform choice. Is SPFx, SharePoint and Power Automate a sensible approach for these applications? Which parts should remain, and which could be simplified? Would an existing template, Power Apps or another approach genuinely reduce the remaining work? We want to use our existing Microsoft 365 investment where practical, but I am open to a justified alternative.

Code and application design. Are there unnecessary layers, duplicated approaches or missing connections? Are ownership, permissions, approval rules and data relationships handled in the right places? What would make the applications easier to maintain?

Save, security and recovery. What is the smallest secure path to an employee saving and reopening their own information? How should we handle first-time creation, conflicting edits, repeated clicks, uncertain network responses and, for Expenses, receipts and partially completed writes?

Testing and release. Which tests should run first? How should we prove the difference between a passing mock test and real Microsoft 365 behaviour? What evidence should connect a source version to its tests, installed package and user acceptance?

AI delivery structure. How many agent roles are actually useful? How should tasks, project instructions, context handovers, reviews and human decisions work? Where should an experienced human developer take ownership, and how do we avoid spending more effort coordinating agents than delivering software?

A practical recovery plan. What would your next three to five actions be for each project, in order? What should be delivered in the first small sprint, and how would we prove it is complete? Any estimate would be most useful with coding, configuration, testing and external waiting separated.

What is available in GitHub
The pack includes actual implementation source and tests, workflow generators, diagrams, schema information, the Expenses requirements and delivery plan, outstanding issues, acceptance scenarios and publication-review notes.

The best starting point is the code-reading guide, which identifies the relevant entry points rather than leaving reviewers to search the whole repository.

There are deliberate limitations. This is a separate review copy, not a deployment-ready checkout. Private records, credentials, actual tenant configuration and original development history are excluded. Missing fixtures and assets are documented. The source snapshots also represent different stages of development, which the guide explains.

Missing material and snapshot limitations

Testing and user-acceptance plan

A useful response could be as focused as: “This connection is missing”, “This permission design is more complicated than necessary”, or “These three tests would establish what is really working.”

Please reply here or leave a GitHub issue, ideally naming the project, file or function, the concern and the smallest proposed change or test.

I would also welcome recommendations for someone with the right experience to undertake a defined technical assessment. I am not asking anyone to access production or work with real staff or financial records.

Thanks,

Pete

[TheodorNEngoy]

Thanks Pete. I read the guide/current blockers and limited the source check to PerformanceHubWebPart.ts. Its supplied host uses a transport that rejects POST, wraps the draft gateway so updateExact rejects, and passes nativeWritesHeld: true to the screen. Changing a request header or UI flag alone therefore would not establish a working Save.

I would make the next milestone one reconciled candidate installed in TEST, with the protected-record binding and permissions ready—not simply removing those guards. With the prepared dummy pair: save a distinctive value as the ordinary employee, close/reopen, then edit and reopen again. An unrelated ordinary user should be denied direct reads and updates of both underlying records; an empty screen alone does not prove privacy.

Keep the source commit, installed package/version and those results together, and fix the first failing step. A prepared pair deliberately leaves first-workplan creation and approvals unproved.

I haven't run the app or accessed the tenant. This review snapshot cannot establish how your later private binding behaves, so I wouldn't recommend a rewrite or estimate delivery from this limited check.

[bomtobe-hgkim]

Given the approval and audit requirements, I’d make the first vertical slice one employee and one KPI: draft → manager amendment/approval → quarterly update with evidence → RAG calculation → one dashboard. Before generating more features, hand-write a tiny fixture with expected ratings, including a boundary value, missing evidence, and a changed target. Keep the approved target and evidence version visible in the result so a dashboard number can be traced to its source. That makes the “one end-to-end workflow” advice testable. I work on Orke at BOMTOBE, a desktop workspace for Claude Code and Codex; I haven’t seen or run your app.

[landjunge]

Based on my own experience with AI-assisted development, your description gives me the impression that the project may have grown incrementally: new features and tools were added while the architecture evolved alongside them. That can easily happen, especially with a substantial business application like yours. Permissions, approvals, version history, calculations and reporting all need to work individually and reliably together.

I’ve had to restart some of my own projects because further patching of the existing code was no longer producing meaningful progress. It may be worth considering that possibility too—but your description alone isn’t enough to determine whether it would be appropriate here.

For a more specific assessment, I would need to examine the code, its size and, especially, its structure and dependencies. A large, tightly coupled codebase can make targeted fixes considerably harder. However, line count alone doesn’t determine whether an AI coding tool can work effectively on it.

Were the requirements, core architecture and scope of the first usable version established at the beginning, or did they grow during development? How large is the codebase, and how is it divided into modules?

A sanitised project overview and one concrete failing workflow would be a useful starting point for comparing recovery of the existing implementation with a clearly scoped rebuild.

[peteshop01-boop]

HI Mark thanks for this - i kinda have and havent started again - see this latest posting and im hoping this gives a clear picture - expenses is more of a restart KPI more a structure restart.

Hi everyone,

I work in operations for a small UK charity and would appreciate an experienced developer’s perspective on two internal software projects we have been building with AI coding agents.

After roughly two months, we have substantial code, tests and project documentation, but we still have not demonstrated the basic end-to-end result we need: an ordinary employee saves their information, closes the application and reopens it, with another employee unable to access it.

I am overseeing this as the business owner rather than the hands-on software developer. I would welcome honest feedback on the architecture, code, testing and the way we are organising the AI-assisted delivery. I am open to being told that we have made the wrong choices or overcomplicated something.

The source code and supporting review material for both projects are available in one public repository:

Microsoft 365 applications: code and developer-review pack

An initial assessment of one part would be useful. I am not expecting someone to review everything before commenting.

What we are building

1. KPI and employee workplans

Employees select their Core KPIs, create their own Impact KPIs, choose development behaviours and set quarterly targets. They need to save an incomplete private draft, return to it and make changes.

The wider application includes submitting the workplan to a manager, requesting changes, approving and locking an agreed version, quarterly progress updates, evidence and consolidated reporting.

The source uses SharePoint Framework, React and TypeScript. The intended draft Save updates a private SharePoint record through the employee’s signed-in connection. A separate protected record holds ownership, year, status and the link to the editable draft. Manager approval is a separate process.

The question is whether that separation and its permission controls are proportionate, and what is missing between the existing code and a reliable installed application.

KPI source and tests

2. Expenses and mileage

Employees enter multiple expense lines against a monthly claim, select account codes, attach receipts or explain their absence, and record mileage. Managers approve or query individual lines. Finance reviews claims and later exports information for payroll.

This also uses SharePoint Framework, React and TypeScript, but its Save design differs. The browser submits a private request. A trusted Power Automate workflow is intended to establish the employee’s identity, validate the claim and write the expense and related records.

The design includes duplicate-request handling, version checks, receipts, claim totals, processing results, audit records and recovery after interrupted writes. I would particularly welcome a challenge to whether the amount of processing and checking is justified for our needs.

Expenses source, workflow code and tests

The intended processes and data relationships are explained here:

Architecture, Save and approval diagrams

How we have organised the AI-assisted work
The approach has involved a project lead/adviser, a delivery PM, build agents and separate technical, security and QA review roles. I provide the business requirements, decisions and user acceptance.

We have used requirements and sprint plans, isolated code branches/worktrees, GitHub, automated tests, review evidence and handovers between agent sessions. Development has involved Windows machines and GitHub-hosted checks, with a separate Microsoft 365 TEST environment.

The intention was to have clear ownership and independent checking. In practice, we have repeatedly seen individual checks or reviews finish without the next delivery step starting. There have also been repeated handovers, approval questions and later-feature work while the first usable Save remained unfinished.

I would like to understand whether we have created too much coordination and administration, and what a simpler, more effective AI-assisted delivery model should look like.

The agents are helping build the software. They are not intended to sit inside the finished applications making employee approval decisions.

Delivery approach and questions for review

Where we are stuck
There is useful code and there have been historical automated test successes. KPI has also progressed with private test-record setup, ordinary-user reads and further source wiring.

However, that does not yet establish that the current installed version passes the complete Save, fresh reopen and two-user privacy checks. Expenses likewise has processing code without a demonstrated, accepted installed Save journey.

The remaining questions include first-record creation, connecting the intended services, reconciling schemas and permissions, choosing the correct source version, executing the relevant tests and installing that same checked version.

There have also been browser failures, local script errors and tool refusals. These need distinguishing from application defects and delivery-management problems, rather than becoming one general explanation for lack of progress.

Current issues, evidence and next actions

What I would like help reviewing
Architecture and platform choice. Is SPFx, SharePoint and Power Automate a sensible approach for these applications? Which parts should remain, and which could be simplified? Would an existing template, Power Apps or another approach genuinely reduce the remaining work? We want to use our existing Microsoft 365 investment where practical, but I am open to a justified alternative.

Code and application design. Are there unnecessary layers, duplicated approaches or missing connections? Are ownership, permissions, approval rules and data relationships handled in the right places? What would make the applications easier to maintain?

Save, security and recovery. What is the smallest secure path to an employee saving and reopening their own information? How should we handle first-time creation, conflicting edits, repeated clicks, uncertain network responses and, for Expenses, receipts and partially completed writes?

Testing and release. Which tests should run first? How should we prove the difference between a passing mock test and real Microsoft 365 behaviour? What evidence should connect a source version to its tests, installed package and user acceptance?

AI delivery structure. How many agent roles are actually useful? How should tasks, project instructions, context handovers, reviews and human decisions work? Where should an experienced human developer take ownership, and how do we avoid spending more effort coordinating agents than delivering software?

A practical recovery plan. What would your next three to five actions be for each project, in order? What should be delivered in the first small sprint, and how would we prove it is complete? Any estimate would be most useful with coding, configuration, testing and external waiting separated.

What is available in GitHub
The pack includes actual implementation source and tests, workflow generators, diagrams, schema information, the Expenses requirements and delivery plan, outstanding issues, acceptance scenarios and publication-review notes.

The best starting point is the code-reading guide, which identifies the relevant entry points rather than leaving reviewers to search the whole repository.

There are deliberate limitations. This is a separate review copy, not a deployment-ready checkout. Private records, credentials, actual tenant configuration and original development history are excluded. Missing fixtures and assets are documented. The source snapshots also represent different stages of development, which the guide explains.

Missing material and snapshot limitations

Testing and user-acceptance plan

A useful response could be as focused as: “This connection is missing”, “This permission design is more complicated than necessary”, or “These three tests would establish what is really working.”

Please reply here or leave a GitHub issue, ideally naming the project, file or function, the concern and the smallest proposed change or test.

I would also welcome recommendations for someone with the right experience to undertake a defined technical assessment. I am not asking anyone to access production or work with real staff or financial records.

Thanks,

Pete

[Khalil-Work]

The failure pattern you describe (lots of generated code, tests and docs,
nothing that runs end-to-end) usually means the AI has been asked to build
wide instead of deep. What works better:

1. Pick ONE stack and stay on it (for 25 users, boring is right: Django or
   Laravel + PostgreSQL, or even Airtable/Power BI if the requirements fit
   — a week configuring those beats months of custom code).
2. Define ONE vertical slice first: staff member logs in → creates a
   workplan → manager approves → it appears on one dashboard. Nothing else
   exists until that slice runs in production.
3. Write the acceptance test for that slice by hand and make CI run it from
   day one. Then every AI change is measured against a real, running
   system instead of piling onto a draft.
4. Keep AI edits PR-sized with a human-readable spec doc as the single
   source of truth, and delete dead experiments without sentiment.

The AI is excellent at step 3-style loops (small change → test → merge)
and poor at big-bang integration — flipping the process to match that is
usually what turns these projects around.

[peteshop01-boop]

thanks so much for your responses, one slice and short sprints - im hearing all loud and clear - its been a huge failing. Altering tact - one thing can anyone review the below set up for AI and give opinion

AI platform: ChatGPT/Codex using GPT-6 Astra (Extra High) for development. (currently getting a lot of random resets - but otherwsie use 6.1 sol)

Project Lead: ChatGPT acts as Sponsor Adviser, setting priorities, challenging progress and overseeing delivery. (so non work non codex)

Delivery PM: One main Codex agent owns the project, including coding, testing, deployment and progress reporting. at astra or sol 6.1

Specialist agents: Separate AI agents provide technical, security and QA reviews. They challenge the developer's work independently.(sub agents of agent above)

Agent handovers: Agents rotate when their conversation context reaches approximately 55–65% capacity, transferring code status, outstanding tasks, decisions and evidence to a successor (e.g. PM149 → PM150). - is this worth it!?

Continuity: Git repositories, local project files, requirements registers and handover documents preserve the project history between agents.

Development: AI agents write code, run automated tests, investigate failures and deploy to a Microsoft SharePoint TEST environment.

Quality controls: Independent reviews, automated tests and real-user testing are required before accepting functionality.

Tools: Codex works with the codebase; Remote Desktop Commander gives ChatGPT access to project files and command execution - rather than having a work chat? unsure direction here also.

Just be good to hear other peopls structures and if you use CODEX (desktop app) or alternate methods and if so pros and cons of any? currently running a 200gbp a month pro plan with OpenA

[TheodorNEngoy]

I’m using Codex desktop, with one main chat owning the next complete outcome. I use helpers for bounded independent reads/reviews and keep one owner for edits and deployment.

For your next Save milestone, I’d simplify to that owner plus a focused reviewer. A review should end with a specific fix or retest assigned back to the owner, rather than another handover.

I’d avoid routinely rotating agents at a fixed context percentage. Keep a short current record: source commit, installed TEST version, checks actually completed, remaining blocker and exact next action. When a handover is necessary, the successor should resume that action.

Keep your business decisions and acceptance criteria available in the working chat too. A separate adviser can help, but its decisions need to reach the chat doing the implementation.

[Theaxiom]

Pete, on the structure question, from running several coding agents against one codebase:

1. One owner per outcome. Let the main Codex agent own the Save milestone end to end. A reviewer returns either a specific defect with a retest, or a pass, never a handover.
2. Drop the fixed 55 to 65% rotation. Rotate when the agent starts losing the thread, and make the handover a short state record rather than a narrative: deployed commit, installed TEST version, checks actually run with their output, the one blocker, the exact next action. If a successor cannot act from it in the first minute, it is too long.
3. Put the adviser's decisions where the builder reads them, in the repository (AGENTS.md or a decisions file), not in a separate ChatGPT conversation.
4. Keep it to two or three agents with clear boundaries. In my experience more roles mostly produce more status reports.
5. You stay the acceptance gate: nothing is done until you have saved, closed, reopened, and confirmed a second user cannot see it.

The coordination overhead is the symptom. One owner and a short record is the fix.

[jianrec]

A practical setup would be to keep one primary Codex task responsible for implementation and use specialist reviews only at clear checkpoints. I would not rotate agents on a fixed context percentage; rotate when the handoff artifact is complete and the next task is independently testable.

Keep one repository and one deployed commit as the source of truth. Store a short status file with the current scope, accepted decisions, open failures, and the exact command that reproduces each failure. Every change should be one small PR with an acceptance test and a deployment check.

For this KPI system, I would build one vertical slice first: employee creates one KPI → manager approves or amends it → quarterly evidence is saved → the RAG value is calculated → the dashboard reads the saved result. Use a separate test dataset and test both roles after every change. Add permissions, audit history, and versioned evidence to this slice before expanding to bulk import, mobile polish, or advanced dashboards.

If the existing code cannot complete that slice after a short recovery pass, freeze it and simplify the scope. A smaller working system will tell you more than another round of generated components.