DEV Community: Oscar Caldera

Your team approved it in Slack. The code shipped something else.

Oscar Caldera — Tue, 07 Apr 2026 21:27:59 +0000

It doesn't happen dramatically. It happens quietly.

Two weeks before the PR, someone in #product-decisions writes:
"Only admins can export user data. Confirmed." Three people react
with a thumbs up. The tech lead says "got it."

Then the sprint moves fast. The developer who wrote that export
service wasn't in that Slack thread. Or they were, and forgot.
Or they remembered but misread the scope. The PR looks fine.
The reviewer checks logic and style. Nobody checks it against
what was actually decided.

It merges. It ships. A customer exports data they shouldn't see.

The real problem isn't the code

Code reviewers are good at catching bad code. They're not designed
to remember every product decision made in Slack six sprints ago.

That's not a process failure. It's a memory problem. Decisions
live in Slack. Code lives in GitHub. Nothing connects them.

So the drift happens silently:

Decision: "Users can't delete their own account — legal requires 30-day hold"
PR: removes the deletion delay "to simplify the flow"
Decision: "Feature X is behind a flag until Q3"
PR: removes the flag check
Decision: "Payments go through Stripe only — no fallback"
PR: adds a PayPal fallback "just in case"

Every one of those was approved somewhere. None of them made it
to the diff review.

What we built

We ran into this enough at our agency that we built Mo — a bot
that sits between Slack and GitHub.

When someone tags @mo in a channel to approve a decision, Mo
stores it. When a PR opens, Mo checks the diff against every
stored decision and flags conflicts before the merge.

It doesn't review code quality. It doesn't care about naming
conventions or test coverage. It only asks one question: does
this PR contradict something the team explicitly approved?

If it does, it blocks the merge and shows exactly which decision
is being violated and where in the diff. → hey-mo.io

Why this is hard to catch otherwise

You could try to solve this with documentation. Write every
decision into Confluence or Notion. The problem is that nobody
does it consistently under deadline pressure, and even when they
do, nobody checks it during PR review.

You could try to solve it with better PR templates. "Did you
check the decision log?" Same problem — it becomes a checkbox
nobody reads.

The only fix that works is making the check automatic and
putting it exactly where developers already are: in the PR
itself, before merge.

If this has burned your team, I'd be curious how you handled
it — and if you want to try Mo, it's at hey-mo.io.
7-day free trial.

How to turn a Gantt chart into tickets for Jira / Asana / Monday

Oscar Caldera — Fri, 27 Mar 2026 18:33:43 +0000

A Gantt chart looks great. Until you try to execute it.

The gap
Most teams do this:

Build a Gantt chart
Share it with stakeholders
Then manually create tickets in Jira/Asana

That’s where things break.
Why?

Because:

Tasks get simplified
Dependencies get lost
Timing becomes approximate
Ownership gets unclear Now your execution differs from your plan.

The real issue
A Gantt chart is visual.
But execution tools need structured tasks.
If you don’t convert properly, you lose:

sequencing
dependencies
timing logic

What a proper conversion should include
Each Gantt item should become a ticket with:

clear ownership
start + end window
dependency links
step context (design / build / test / deploy) Not just: “Build API”

What most teams miss
They recreate tickets manually, but:

don’t preserve order
don’t link dependencies
don’t reflect real capacity So the timeline starts drifting on day 1.

Better approach
Your plan should be:
1 model → multiple outputs
Meaning that the same structure generates:

Gantt
tickets
timeline
team schedule No duplication.

Example of a delivery plan generating tickets and exports.
This is from Motionode, where the same delivery model generates timelines, tickets, and exports.

Simple rule
If your tickets were not generated from the same structure as your Gantt:
Your execution plan is already outdated.

TL;DR
Gantt → tickets is not copy/paste.
It’s a model transformation problem.
Solve it once, or manually fix it forever.

How to compare team capacity before committing to a software deadline

Oscar Caldera — Fri, 27 Mar 2026 18:10:49 +0000

What most people expect

Change the team → change the timeline.

More devs → faster delivery.

What actually happens

In many cases, the timeline barely changes.

But:
Same duration. Very different execution risk.

Why?

Because:

The total work stays the same
The steps are still sequential (design → build → test → deploy)
Someone still has to do each step

So instead of reducing time, you just redistribute it.

What really changes

Different team setups change how your project behaves:

idle time between steps
how busy each person is
how much coordination is needed
where bottlenecks appear

Not necessarily the final date.

What this looks like in practice

This is from Motionode, where you can simulate different team setups and expose execution risk, even when the timeline stays the same.

You can run 3 different team setups and still get ~4 weeks.

But:

one has overloaded devs
one has idle time
one has smoother flow

This is why many projects don’t fail because of bad estimates. They fail because the execution model was never stress-tested.

If your planning process only outputs a date,
you’re missing the part that actually determines whether you hit it.