Dev.to WebDev 🛠 Dev 👁 0 📖 2 min read

Our own status notes were wrong. The one rule that caught it before launch.

Here's an uncomfortable finding from a project we just shipped. Several claims in our backend team's own progress notes were wrong or incomplete. Not because anyone was careless, and nobody was lying. A written status u

Here's an uncomfortable finding from a project we just shipped.

Several claims in our backend team's own progress notes were wrong or incomplete. Not because anyone was careless, and nobody was lying. A written status update is a claim, and claims drift from reality the moment nobody re-checks them.

We caught it during development, not in a staging walkthrough days before launch. Here's the setup, and the one rule that did the catching.

The setup

We were replacing Increddy's commerce backend under a live storefront:

  • Frontend: Next.js, deployed on Vercel, with its own owner
  • Backend: Medusa v2, deployed on AWS EC2, owned by someone else
  • Separate repositories, built in parallel

The obvious reaction is "put it all in a monorepo."

We didn't, because a shared folder doesn't solve this. It won't make the frontend dev guess what shape the API will return, or the backend dev guess what the frontend actually calls. The problem was the contract, not where the code lived.

The two documents

A gap tracker. Every frontend data need, mapped to the backend capability that serves it, marked built, planned or missing. "Does the backend support X yet?" stopped being a Slack question and became something anyone could look up.

Matched task lists with dependency IDs. One list for the backend, one for the frontend, with each frontend task pointing at the exact backend task it was waiting on.

A task list tells you what's being worked on. Dependency IDs tell you what's safe to start and what's still blocked. That's the question a team on a separate repo actually needs answered, without a meeting.

The rule that mattered more than the documents

Documents drift too. A gap tracker can say "done" because someone updated it hopefully.

So both teams had one standing instruction:

Verify every claim against running code and a live backend. Not against the other side's notes. Not against your own.

Your own is the important part. Checking other people's work is natural. Checking your own status notes against reality feels unnecessary, and that's exactly where the wrong claims were hiding.

Steal this

If two teams can't share a codebase, don't force it. Give them:

  1. a living contract (gap tracker plus dependency-linked tasks), cheap to maintain and checkable without a meeting
  2. one rule: verify against running code, on both sides, including your own

What were these two teams building? A full backend swap, Shopify to self-hosted Medusa, under a storefront that never went down. Read the Increddy case study on kryeo.com →

The longer write-up is on the Kryeo blog, and this is how we run every engagement: see our process.

We're Kryeo, a software agency building headless commerce on Medusa, Directus and Next.js.

📰 Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.