Cruxly › Forward deployed engineer › Decomposition Cases

Rapid Internal Tool Under a Deadline

a fast wrong tool costs the contract; a slow right one never gets the chance to

Prompt: a logistics customer wants an internal dashboard so their dispatchers can see which trucks are behind schedule, "before the board meeting next Thursday" — four days away. They currently track this in a shared spreadsheet that three people edit by hand.

45 minutes first. The deadline is real and the temptation is to treat this as a pure speed problem. The actual question is which four days of work leaves the customer in the best position on Friday, not just at Thursday's meeting.

Clarifying questions that matter here

"What decision gets made at Thursday's meeting, using this dashboard?" If the board is deciding whether to approve budget for a bigger logistics system, the dashboard's job is to look credible and tell a clear story — accuracy to the last minute doesn't matter as much as the trend being right. If dispatchers will actually use it Friday morning to reroute trucks, staleness of even a few minutes is a real operational cost. These are different products wearing the same four-day deadline.

"Where does the spreadsheet's data actually come from right now?" If it's manually typed from a GPS tracking system's web portal, the real first win might just be reading that portal's data automatically — the "dashboard" is almost secondary to removing the manual re-typing, which is probably also the source of the errors dispatchers are currently fighting.

"Who else touches this spreadsheet, and will they keep updating it in parallel?" If three people keep hand-editing the spreadsheet after your tool launches, you now have two sources of truth and a customer confused about which one is right — a worse outcome than the tool not existing. This needs an explicit answer, not an assumption that everyone switches over on day one.

"Is Thursday a hard product deadline or a demo deadline?" A demo can survive being narrower and more scripted than a shipped tool; treating a demo like a production launch wastes days hardening edge cases nobody will hit before Thursday, at the cost of the one thing that actually needs to be solid: the story the data tells.

The decomposition: automate the input before touching the output

Slice 1 (day 1) — replace the manual data entry, keep the spreadsheet as the interface. If GPS tracking data is being hand-typed into the spreadsheet, write a small script that pulls it automatically and writes it into that same spreadsheet, via its existing API. This is unglamorous and produces no new UI, but it removes the actual source of the errors dispatchers complain about, is low-risk because the interface everyone already knows doesn't change, and is realistically buildable and testable in a single day.

Slice 2 (days 2-3) — a read-only dashboard view on top of the now-automated data, showing exactly the one thing asked for (trucks behind schedule) and nothing else. No user management, no editing, no configuration — a single page that answers one question clearly, because a four-day build that tries to also be a general-purpose tool ends up half-finished at everything on Thursday morning.

Slice 3 (day 4) — harden for the meeting, not for production. Add whatever makes the Thursday audience trust the number (a "last updated" timestamp, a simple trend line if the board decision is budget-related) rather than adding features. This is the point where "what does Thursday's meeting actually need" from the clarifying questions directly determines which of two very different day-4 checklists you're working from.

Why input-first, not output-first: building a polished dashboard on top of manually-typed, error-prone data means the demo looks good but is showing wrong numbers some fraction of the time — worse than a plain dashboard on clean data, because a wrong number in a polished UI is more convincing and more damaging than an obviously rough one.

The parallel-spreadsheet risk, and what ships after Thursday

If people will keep hand-editing the spreadsheet, that has to be resolved before or immediately after Thursday, not left implicit. The honest options, stated to the customer directly: stop hand-editing entirely and trust the automated feed (requires their buy-in, ideally before Thursday), or make the automated feed additive — a separate sheet or tab the dashboard reads, so the humans' spreadsheet remains untouched and the risk of two conflicting truths disappears by construction rather than by asking people to change a habit under deadline pressure.

What ships Friday matters as much as what demos Thursday, and this is the part a pure "hit the deadline" mindset misses: if the dashboard is memorable but nobody maintains the automation script, or the customer's IT team can't find it in a month, the four days produced a demo, not a tool. A brief handoff — what it depends on, who owns re-running it if it breaks — costs an hour on day 4 and is the difference between a prototype that becomes the real system and one that quietly stops working two weeks later.

Naming this out loud is itself part of the deliverable: "here's what I built for Thursday, here's what would need to happen for this to become the permanent system rather than a one-time demo, and here's the one manual step still in the loop that I'd remove next." A forward-deployed engineer's four days are judged as much by what happens the week after as by the demo itself.

Follow-ups they will ask

"The board loved it. Now they want it rolled out to twelve other logistics hubs by next month." The four-day build made deliberate, load-bearing assumptions for exactly one hub — one GPS provider's API shape, one spreadsheet's column layout, one team's definition of "behind schedule." Twelve hubs is not the same build run twelve times; it's a discovery project to find out how many of those assumptions were actually hub-specific, and the honest answer is "let me spend two days finding out how different these hubs actually are before I estimate the twelve-hub timeline," rather than assuming linear scaling from a sample size of one.

"Can dispatchers edit the data directly from the dashboard now, not just view it?" This is a bigger ask than it sounds, because it reopens the exact conflict the parallel-spreadsheet risk was designed to close — a dashboard that both reads automated data and accepts manual edits is now a second writer for the same facts the automation owns. The honest scope for this request is a new, explicitly-designed write path (an override with an audit trail, reconciled against the next automated sync), not a quick edit button bolted onto day 4's read-only view.

"Why does the truck position sometimes look wrong for a minute or two after it moves?" This is the freshness cost from the very first clarifying question surfacing as a bug report. If it was never explicitly told to the customer that the feed has a polling interval, "wrong for a minute" reads as a defect instead of a stated trade-off — which is why naming the refresh interval on day one, even briefly, is not a technical footnote but a way of pre-answering the question before it becomes a complaint.

"This worked so well, can you stay another month and just keep building on it?" A forward-deployed engineer's four days are meant to prove a concept and hand it off, not become a permanent, unstaffed dependency on one person. The answer that protects the customer is naming what a real second phase would need — proper ownership on their side, a maintenance plan, a decision about whether this becomes a supported product — rather than quietly becoming the single point of failure the four-day handoff was explicitly designed to avoid.

How to say it in the interview

"Four days is enough to build something real if I'm disciplined about what 'real' means here — it is not enough to build the dashboard I'd design given a month, and pretending otherwise is how you ship something that impresses Thursday and gets abandoned the following week. Let me find out what actually needs to be true by Thursday versus what just needs to look true."

Checklist

Asked what decision Thursday's meeting actually makes before deciding what 'the dashboard' means
Asked where the spreadsheet's data currently comes from, not just what the dashboard should show
Asked explicitly whether people would keep hand-editing the old spreadsheet in parallel
Automated the data input before building any dashboard UI
Scoped day 2-3 to one question answered clearly, not a general-purpose tool
Resolved the parallel-spreadsheet risk explicitly, either by buy-in or an additive, non-conflicting design
Included a handoff for what happens after Thursday, not just what demos on Thursday

Practice this interactively