A walkthrough of a web app

These defects share a pattern: UI, API and background services each made their own assumption about data ownership, permissions or layout, and nothing checked the mismatch until a user hit it. Most were cheap to prevent with shared validation, a single entitlement source, and a test that walks each route.

What went wrong, and how to avoid it

1. Job cards were created with a random UUID as the client, so every ad-hoc card pointed at a client that never existed and could not be invoiced or filtered Why: The client generated the identifier itself instead of letting the user pick a real client, and the API stored any id without checking it, because the column had no foreign key.Avoid it: Never let a client invent a foreign key; require the user to choose an existing record and have the API reject ids that do not belong to the workspace. Add foreign keys so the database refuses orphans even when an endpoint forgets.
2. An add-on customer's drawing uploads were cancelled with an upgrade prompt, even though the purchased add-on was what let them open the feature Why: The background pipeline re-checked entitlement from only the plan flag, while the API granted the feature from three sources: plan, add-on and override.Avoid it: Keep entitlement logic in one place and call it from every service that gates work, rather than reimplementing the check. Test each grant source end to end, including the background run, not just the button that opens the feature.
3. A floating activity dock covered page action buttons, so New Lead and other primary actions could not be clicked on smaller desktop windows Why: The dock floated above content at a high z-index and shifted upward on short screens, while pages used the full width underneath it with no reserved gutter.Avoid it: Treat fixed overlays as consuming layout space: reserve a gutter for them at every breakpoint where they appear. Add a smoke test that clicks each page's primary action at common window sizes.
4. Campaign creation failed with a raw NOT NULL database error because the schema relied on database defaults that the standard setup never creates Why: Hand-written SQL inserts assumed defaults that exist only in one migration path, while the client-side ORM normally supplies those values, so a database built the documented way had none.Avoid it: Generate ids and timestamps explicitly in every insert so they do not depend on how the database was built. Run the integration suite against a database created exactly as the quick start instructs.

Read the full report on the home page →