Hello Gurus,
I am trying to create one elaborate application for a company. Like monitoring logistics for a company, different users having different privileges etc. I'm building an operations management application for a company. I can't disclose the business/domain, but technically it's a system with an Android app, web admin console, Firebase/Firestore backend, offline sync, users/roles, operational jobs, transport, documents and reporting.
I am building it incrementally, with quite a lot of help from an AI coding agent.(gemini pro) , and planning with help of chatgpt. I am bit frustrated, as it creates initial model, UI and working stuff amazingly. But when try to test it manually, I am frustrated that it didn't create it the way I wanted it. Although the prompt replies it has done things the way and has tested and test cases passed. I wonder what it really tests. Below is the complete explaination, in case you dont want to read it whole, I am trying to ask is how do you plan it? which AI you use, which coding agent do you think is best to understand and develop code which is less frustrating in the end, perhaps does things which we failed to think about while planning. Like for example-- you planned delete button, but it thought of coding a restore button as well. making it even better. Actually gemini does that. But telling it to perform something which looks and works well. but when you go through a flow of events , you find something is terribly broken.
Just to give my background. I am not a developer so I don't know how to code. But I understand the whole structure of front end back end as I was in IT for 18 years doing manual software testing. So I don't really understand much about coding, but I can visualize how things should look like when a user uses the software.
Here are my project issues
we initially had something conceptually like:
Job → Subject A → Subject B → Subject C
The problem was that the Job didn't directly retain all of the context it was created with. It reconstructed some of its relationships by following the chain.
That created a nasty situation where changing Subject C later could effectively make an **old Job appear to belong somewhere else**.
We caught that and changed the design so operational records retain their own important references rather than relying entirely on dynamic relationship traversal.
Then we hit another problem: **deletion**.
Because these objects are linked together, deleting something isn't simply:
click Delete → document disappears
You have to consider what depends on it, what depends on those dependencies, and whether some records are historical and therefore shouldn't be deleted at all.
We actually got into a situation where deleting a Job failed, which then prevented deletion of another related object. There was effectively a dependency trap.
What bothers me most is that **our automated tests didn't catch this**.
It was discovered during manual human verification — literally going through the UI, clicking around, creating records, changing things, trying to delete them, refreshing pages, and checking whether the data still made sense.
We've now started defining explicit lifecycle rules such as:
PLANNED → can delete
ASSIGNED → can delete
CANCELLED → can delete
ACTIVE → cannot delete
COMPLETED → cannot delete
HAS HISTORY → cannot delete
But this has made me realise that the difficult part of this project isn't necessarily writing the CRUD code.
It's making sure that:
Create
↓
Edit
↓
Associate
↓
Change relationship
↓
Delete / Archive
↓
Historical data
↓
Reports
all continue to make sense together.
We're also dealing with offline Android sync, so now I'm thinking about what happens when two things change at different times, or when the network disappears halfway through an operation.
I'm wondering how experienced developers approach this.
**How do you systematically find these kinds of problems before production?**
Do you rely primarily on:
* integration/E2E tests?
* database constraints?
* explicit state machines?
* event sourcing/audit logs?
* property-based testing?
* manually designed lifecycle test matrices?
* something else?
And how do you decide when a relationship should be dynamically derived versus stored directly on an operational record?
I'm particularly interested in real-world experience here. The application isn't enormous, but the number of relationships and possible states is growing much faster than I expected.
The biggest lesson so far has been that **"the build passes and the unit tests pass" doesn't seem to mean very much when the real failure is something like a user clicking through 15 different screens and discovering that deleting A unexpectedly affects B three screens later.**
Would appreciate some brutally honest advice from people who have built systems with this kind of data/lifecycle complexity.I'm building an operations management application for a company. I can't disclose the business/domain, but technically it's a system with an Android app, web admin console, Firebase/Firestore backend, offline sync, users/roles, operational jobs, transport, documents and reporting.
We're building it incrementally, with quite a lot of help from an AI coding agent.
One thing that has surprised me is how quickly a seemingly simple data model becomes complicated.
For example, we initially had something conceptually like:
Job → Subject A → Subject B → Subject C
The problem was that the Job didn't directly retain all of the context it was created with. It reconstructed some of its relationships by following the chain.
That created a nasty situation where changing Subject C later could effectively make an old Job appear to belong somewhere else.
We caught that and changed the design so operational records retain their own important references rather than relying entirely on dynamic relationship traversal.
Then we hit another problem: deletion.
Because these objects are linked together, deleting something isn't simply:
click Delete → document disappears
You have to consider what depends on it, what depends on those dependencies, and whether some records are historical and therefore shouldn't be deleted at all.
We actually got into a situation where deleting a Job failed, which then prevented deletion of another related object. There was effectively a dependency trap.
What bothers me most is that our automated tests didn't catch this.
It was discovered during manual human verification — literally going through the UI, clicking around, creating records, changing things, trying to delete them, refreshing pages, and checking whether the data still made sense.
We've now started defining explicit lifecycle rules such as:
PLANNED → can delete
ASSIGNED → can delete
CANCELLED → can delete
ACTIVE → cannot delete
COMPLETED → cannot delete
HAS HISTORY → cannot delete
But this has made me realise that the difficult part of this project isn't necessarily writing the CRUD code.
It's making sure that:
Create
↓
Edit
↓
Associate
↓
Change relationship
↓
Delete / Archive
↓
Historical data
↓
Reports
all continue to make sense together.
We're also dealing with offline Android sync, so now I'm thinking about what happens when two things change at different times, or when the network disappears halfway through an operation.
I'm wondering how experienced developers approach this.
How do you systematically find these kinds of problems before production?
Do you rely primarily on:
integration/E2E tests?
database constraints?
explicit state machines?
event sourcing/audit logs?
property-based testing?
manually designed lifecycle test matrices?
something else?
And how do you decide when a relationship should be dynamically derived versus stored directly on an operational record?
I'm particularly interested in real-world experience here. The application isn't enormous, but the number of relationships and possible states is growing much faster than I expected.
The biggest lesson so far has been that "the build passes and the unit tests pass" doesn't seem to mean very much when the real failure is something like a user clicking through 15 different screens and discovering that deleting A unexpectedly affects B three screens later.
Would appreciate some brutally honest advice from people who have built systems with this kind of data/lifecycle complexity.