The easiest way to build what Nuclear Software does would have been three separate products: a scheduling tool, an approvals tool, and a reporting tool, connected by webhooks. It's the standard pattern, and it's also exactly the problem we set out to fix.
Why three products stitched together wasn't good enough
Webhook-connected tools eventually disagree. A sync fails, a webhook retries out of order, and now the schedule and the report built from it tell two different stories. Every team we talked to already lived with this pattern and hated it — that was the whole reason they were looking for something else.
One data model, three views
Nuclear Software's scheduling, approvals, and reporting features all read from and write to the same underlying data model. A shift isn't copied between systems — there's one representation of it, and scheduling, approvals, and reporting are three different views onto that same record.
That means a report is never "an export from an export." It's built from the same data the schedule and approvals are, at query time, which is why a report is never more than moments behind reality.
What we gave up to do it
Single data model architecture is significantly harder to build initially than gluing independent services together, and it's a lot less flexible if we ever wanted to spin off scheduling or reporting as a standalone product. We decided that trade-off was worth it: the entire premise of Nuclear Software is that these three things should never disagree, and the only reliable way to guarantee that is to make disagreement structurally impossible.
Curious about the technical details? We're happy to walk through the architecture directly — reach out and mention this post.