Comparison
RainDelayLog vs Raken
Raken is built so a foreman can finish a complete daily report from the field without dreading it, while RainDelayLog is built so one of those days survives an owner's challenge a year later.
Comparison
Procore is built to run the whole commercial project from contracts to closeout, while RainDelayLog is built to make one weather day hold up in front of a reviewer who was never on the site.
If your company already runs Procore for contracts, RFIs and submittals, keep it. The question is narrower than which platform wins. RainDelayLog exists because a weather day has to survive a reviewer who was never on the site, and that takes a station reading tied to the hour work stopped, photos of standing water, crew hours lost and a notice date you can point to. A broad platform records the day. This records the day the way a delay claim gets read. Plenty of our sites run both.
| What you are deciding | RainDelayLog | Procore |
|---|---|---|
| What it is built to do | One job: capture, prove and package qualifying weather days on a commercial site. | A broad construction management platform spanning the project lifecycle from preconstruction to closeout. |
| Weather record | Nearest qualifying station reading pulled and stamped against the entry every day, including the days you worked through. | Weather is one part of a general daily log; how the reading is sourced depends on how your team sets it up. |
| Baseline day table | Monthly anticipated weather day table from climate normals sits beside the running actual count all year. | Scope is the whole project, so tracking a monthly baseline against actuals is something your team arranges itself. |
| Notice clock | Contract notice window set per job, counting from the first qualifying hour, with a dated record of what went out. | Notice and correspondence live in the wider project record, and the timing discipline stays with your team. |
| Claim packet | Exports logs, station data, photos, crew hours and the day table in the order a claim gets read. | Reporting and export are general purpose across the platform, shaped to whatever module you are working in. |
| Who enters the day | The superintendent on the tailgate in about two minutes, or the project engineer from the trailer. | Field and office roles working across many modules, with training scoped to the whole platform. |
| Rollout | One site live the same morning, with the station and the day table set in one sitting. | Platform adoption is normally scoped with their team across a company's project portfolio. |
| Cost shape | $59 a month for Single Site, $149 for Multi Site, $349 for Enterprise Site. | Priced as a full platform for a company, so ask them directly for current terms. |
The right hand column places Procore by scope and by the sort of operator it serves, with no attempt at a priced feature list. Both keep changing, so check the current shape of each one before you choose. RainDelayLog is published by MLJ, SASU and this page is written by Jimenez Julien.
Every daily report tool has somewhere to note the weather. That field answers the question of what the sky did. A delay record has to answer four harder questions: what the measured precipitation or temperature was at a source the contract will accept, which scheduled activities could not proceed and why, how many crew hours and equipment hours were lost, and when written notice went out. A reviewer who wants to strike the day only has to find one of those four missing.
That is the gap RainDelayLog fills. The log entry is structured around the four questions rather than around a free text box, so the superintendent cannot accidentally leave the load bearing part blank. When the packet is pulled fourteen months later, the entries from a wet March read the same way as the entries from a dry September, because the same fields were required both times.
Most of our multi site customers keep their platform as the contractual system of record and use RainDelayLog as the weather day instrument. The superintendent logs the day once in the morning, and the exported packet or the day summary gets attached to the platform record so the owner sees it in the place the contract points at. Nobody types the day twice.
The split works because the two tools are answering different people. The platform answers the project team and the accounting department. The weather day record answers a scheduler and, if it goes that far, a claims consultant. Those readers want different things in a different order, and trying to make one export satisfy both is where a lot of contractors lose days.
A broad platform is deliberately neutral about how you run a weather clause, because it has to serve heavy civil, healthcare, tenant improvement and industrial work at the same time. That neutrality is a feature for a company that has its own claim process and wants software to stay out of the way. It is a problem for a superintendent who has never assembled a delay claim package and is being asked to build the record for one while running the job.
RainDelayLog takes a position. It assumes you are working under a contract that counts weather days against a baseline, that a named station or a site gauge will be argued about, and that notice has a deadline. If those assumptions are wrong for your contract, a general platform serves you better. On most US commercial work they are right.
Yes, and that is the most common setup we see. The Single Site tier exists for exactly that case, usually a job where the weather exposure turned out worse than the bid assumed. The packet exports as a dated document set you can attach wherever your project record lives.
It does not, as long as the day is entered once and the export is attached to the contractual record. Problems come from two people entering two versions of the same day. Set the rule that the weather day starts in RainDelayLog and travels outward from there.
A scheduler wants the measured weather at an acceptable source, the affected critical path activities, the lost hours and the notice date, laid out in that order. Whichever tool produces that document is the one they want. Our export is built to that order because that is the only thing it has to do.
Comparison
Raken is built so a foreman can finish a complete daily report from the field without dreading it, while RainDelayLog is built so one of those days survives an owner's challenge a year later.
Comparison
Autodesk Construction Cloud connects design, models and field execution across a project, while RainDelayLog stays on one narrow contractual problem that starts the morning it rains.
A criteria table only takes the decision so far. Send us a job that is already losing calendar time and we will enter one qualifying morning the way a reviewer reads it, from the station reading through the released crew hours to the notice date. If what you run today already produces that packet, we will say so and you can get back to the schedule.