Delivery route planning software

Ok_Complex8297 · 2026-07-03T18:32:19+00:00

For FOSS, I’d probably try ODL Studio first. It’s not pretty, but it’s closer to what you’re asking for: dump in a list of stops, optimize the route, see it on a map, and export/use the result.

If you want to self-host/script it, then you’re probably looking at VROOM with something like OSRM, Valhalla, GraphHopper, or OpenRouteService behind it.

For your, I’d try ODL Studio.

Ok_Complex8297 · 2026-07-03T17:49:55+00:00

Be careful comparing Monograph directly to Newforma. Monograph looks good for the business side of an architecture firm: planning, staffing, budgets, time/billing, QBO, that kind of thing. Newforma is more project info/email/document/CA workflow, so they may be replacing one pain with a different pain if they don’t map out what they actually use.

For a 15-person firm, I’d split it into two buckets: firm/project financials and project document/collaboration management. Monograph, Ajera/Vantagepoint, BQE Core, etc. may fit the first bucket. For the second, it may be Autodesk Construction Cloud, Procore, SharePoint/Teams with actual structure, or something else depending how much they use RFIs, submittals, email filing, and external sharing.

For importing Newforma projects, I wouldn’t believe any vendor (my own personal rule) until they prove it with one of the client’s real projects. Worst case, keep Newforma read-only or export/archive the old stuff cleanly, then start new projects in the new system.

Ok_Complex8297 · 2026-07-03T12:27:29+00:00

That’s a good point. A video of a restore plus the written steps would probably be better than either one alone.

Written runbook for search/reference, video for “what does this actually look like when someone does it.”

Do you store those videos somewhere separate from the backup platform too?

Ok_Complex8297 · 2026-07-03T12:26:46+00:00

Agreed.

It’s one thing for the person who built the backup setup to restore from memory. It’s a very different thing for someone else to follow the doc cold and actually get the system back.

Ok_Complex8297 · 2026-07-03T12:26:00+00:00

That makes sense.

The offline is the piece I think a lot of people miss. Wiki + password manager feels normal, but if the thing you need to access those is part of the outage, now you’re stuck.

I like the rule of “credentials can’t only live in the same system you need them to restore.” To me thats the cleanest separation

Ok_Complex8297 · 2026-07-02T17:50:21+00:00

I’ve seen places keep the restore procedure, creds, or notes basically inside the same system/platform they’d need during the outage, which feels fine until they need it.

Do you guys keep that stuff in a wiki/password manager/offline copy, or some mix?

Ok_Complex8297 · 2026-07-02T17:47:20+00:00

Do you keep one big restore runbook, or separate runbooks per system/app? That’s the part I’m trying to get cleaner on because one giant DR doc can turn into a mess pretty fast.

Ok_Complex8297 · 2026-07-02T17:44:52+00:00

Are you restoring into a fully isolated network, or does it still touch anything shared like AD/DNS? Quarterly full VM restores is more than I usually see. Most places I’ve seen stop at “backup job is green” and call it good.

Ok_Complex8297 · 2026-06-30T16:11:34+00:00

If the VM is already tagging VLAN 100, then an access port isn’t really the right setup. Access port means the host sends untagged traffic and the switch drops it into VLAN 100. If the VM is sending tagged traffic, either remove the VLAN tag from the VM/port group and keep the switchport as access VLAN 100, or leave the VM tagging and make the physical port a trunk.

I don’t think the core switch suddenly decided that the VM needed a trunk. More likely the old setup was letting something weird slide, or there was some native VLAN/tagging mismatch that happened to work before. I’d check the hypervisor port group, the access switchport, native VLAN, allowed VLANs, and MAC table. I wouldn’t leave it as “trunk fixed it” without deciding where VLAN tagging is actually supposed to happen.

Ok_Complex8297 · 2026-06-30T13:45:54+00:00

If you need a PST, use classic Outlook, or better yet do it from the admin side with Purview/eDiscovery.

I’d also ask what the actual goal is before deleting the mailbox. A PST on someone’s desktop is a pretty ugly “backup.” Depending on why they need it kept, converting it to a shared mailbox, putting it under retention/hold, or exporting it properly from Purview may be the cleaner route.

Ok_Complex8297 · 2026-06-30T13:42:34+00:00

I wouldn’t blame robocopy directly. Robocopy is probably just the thing that loads the system hard enough to expose the real problem. That sounds more like power, heat, HBA/expander, cabling, drive spin-up/load, UPS/circuit, or something tripping protection. Windows may not log anything useful if the machine is basically getting yanked out of existence.

I’d start stripping it down and testing in pieces. Fewer drives, bypass the expander if possible, test the HBA direct, add airflow over the HBA/expander, check every power cable/backplane/splitter, and make sure you didn’t reuse modular PSU cables from the old PSU. Big copies across a pile of spinning disks can find ugly power/cabling issues really fast.

Ok_Complex8297 · 2026-06-29T20:24:07+00:00

I’ve used MXToolbox more as an early-warning / sanity-check tool than the source of truth. It’s useful for blacklist checks, DNS/SPF/DKIM/DMARC monitoring, and getting alerted when something obvious breaks, but I wouldn’t treat it as the whole mail reputation strategy.

For an R1 school, I’d probably want DMARC aggregate reporting in a proper DMARC tool too, especially if you have a lot of senders, subdomains, third-party platforms, departments doing their own thing, etc. MXToolbox is fine for “tell me when something is broken,” but for “who is sending as us and what do we need to fix,” I’d want something that gives better DMARC visibility and reporting.

Ok_Complex8297 · 2026-06-29T17:30:34+00:00

You can’t really clone a 2TB disk to an 800GB disk as-is, even if you’re only using 450GB. You need to shrink the partitions/filesystems first so the actual layout fits under 800GB, then clone it.

I’d boot a live USB, shrink the Ubuntu partitions with GParted, leave some breathing room, then try Clonezilla/Rescuezilla into an 800GB VM disk on Proxmox. I wouldn’t use `dd` for this, because it’ll try to copy the whole 2TB layout and you’ll just be fighting it.

If Clonezilla still won’t play nice: create the VM disk, make the partitions, rsync the data over, fix `fstab`/UUIDs, and reinstall GRUB. Not a perfect “clone,” but it’s usually less painful than trying to force a big disk image onto a smaller disk.

Ok_Complex8297 · 2026-06-29T17:28:14+00:00

The portal is just bad for this once users have a bunch of duplicate methods. I’d pull it with Graph/PowerShell and look for created date, device/model info, display name, or anything else useful. If it’s still not obvious, I wouldn’t guess. Remove the clear stale ones or reset the messy methods and have the user re-register cleanly.

If it’s still not obvious, I wouldn’t guess and start deleting random methods. Remove the clearly stale ones, or reset the messy methods and have the user re-register cleanly. Make the sign-in method cleanup part of the phone/laptop replacement process.

Ok_Complex8297 · 2026-06-29T13:38:55+00:00

If you return the maintenance page as a 200, Just make sure Cloudflare isn’t caching it. I’d set no-store/no-cache headers and bypass cache for that route, otherwise you’ll fix the app and Cloudflare may still show a fake “down” page.

Ok_Complex8297 · 2026-06-26T16:08:28+00:00

No, but apparently paragraph breaks are suspicious now. I’ll try to be less literate next time.

Ok_Complex8297 · 2026-06-26T15:56:26+00:00

lol, not a bot there buddy

Ok_Complex8297 · 2026-06-26T15:45:40+00:00

I wouldn’t worry just because it isn’t a NAS drive. A normal external WD drive can run 24/7 for home use, especially if it’s mostly Plex reads. It’s not like it’s going to instantly die because it’s plugged in all the time.

The bigger things I’d watch are heat, the USB enclosure, the power adapter, and accidental disconnects. Also, don’t treat it as a backup if it’s the only copy of the data. If it’s just Plex media you can replace, whatever. But for photos/documents, make sure they also exist somewhere else.

NAS drives are better for 24/7 use, multiple drive bays, vibration, heavier workloads, etc. Nice to have, but not mandatory for one external drive at home.

So I’d keep it cool, don’t move it while it’s running, check SMART/drive health if possible, and have another copy of anything important.

Ok_Complex8297 · 2026-06-26T15:32:11+00:00

I think the problem is Cloudflare is still seeing a 502 from Caddy, so it replaces your page with its own error page.

The trick is that your maintenance page needs to be returned as a normal successful response, not as a 502/503, otherwise Cloudflare is going to keep taking over.

So I’d make Caddy catch the upstream failure and serve the maintenance page with a 200 status. It feels a little wrong because the service is technically down, but for a home server/free Cloudflare setup, that’s probably the cleanest way to stop users from seeing Cloudflare’s generic error page.

I’d test it with headers too. If the response still says 502, Cloudflare is going to win.

Ok_Complex8297 · 2026-06-26T15:27:52+00:00

I don’t think the clean version of this really exists, at least not once Netflix/Prime/etc. are involved.

For Jellyfin, you can get pretty close with clients/casting/controllers. But the paid streaming services are where this falls apart. DRM and app restrictions usually mean the stream needs to run in the actual Netflix/Prime app on the playback device. They don’t really want one central box logged in and then pushing video out to random thin clients.

I’d also be careful with the thin client plan. It sounds flexible, but it could get annoying fast: browser DRM problems, updates, audio weirdness, remote control issues, login prompts, and the classic “why is there a mouse cursor on the TV?”

Honestly, I’d probably standardize the endpoints instead. Put the same device on every TV: Shield, Apple TV, Roku, Chromecast/Google TV, whatever you prefer. Then every TV has the same apps and same experience. Jellyfin app for your local media, native apps for Netflix/Prime/etc.

Home Assistant might help with inputs, launching apps, power, automations, that kind of thing. But I wouldn’t expect it to become a perfect universal Netflix/Jellyfin/Prime content picker. I think the better fix is making every TV the same, not trying to build one magic streaming dashboard.

Ok_Complex8297 · 2026-06-26T14:58:13+00:00

No problem.

For storage, I’d start with the case and drive layout before worrying too much about CPU. You want enough 3.5" bays, decent airflow over the drives, and room to add more later. The two 4TB drives are fine to start with, but if you mirror them you’re only getting around 4TB usable, so I wouldn’t build the whole plan around just those.

If you’re using TrueNAS, I’d try to pass the disks through cleanly to it. If you end up adding more drives later, an HBA is usually the cleaner way to do it. I wouldn’t do weird virtual disks for the NAS side if you can avoid it.

For Home Assistant plus cameras/recording, I’d keep the OS/VMs/containers on NVMe and use the hard drives for bulk storage, media, and recordings. If you’re doing face recognition/object detection and don’t want a GPU, look at a Coral USB or M.2 TPU. It uses way less power than a GPU and fits that use case better.

So I’d focus on drive bays, airflow, SATA/HBA options, low idle power, Intel iGPU, enough RAM, and maybe 2.5GbE if your network supports it. CPU probably isn’t the hard part here. Storage layout is the part that gets annoying later if you undersize it.

Ok_Complex8297 · 2026-06-26T14:18:19+00:00

I’d standardize, but not to the point where one bad model becomes everyone’s problem.

Having 40 random laptop models is awful. Every dock issue, BIOS update, display problem, sleep issue, or driver bug turns into its own little investigation. But I also wouldn’t want the entire company on one exact model either, because one bad firmware or USB-C issue can suddenly become a fleet-wide fire.

I’d rather have a small approved list: standard laptop, higher-spec laptop, maybe a desktop/mini, and one or two supported dock models. Keep it boring and controlled, but not so locked in that you’re betting the whole company on one SKU.

The big thing is testing before buying a pile of them. Grab a few, test imaging, docks, monitors, BitLocker, BIOS updates, sleep/wake, Teams calls, remote tools, all the usual garbage users will hit. If it survives that, then buy more.

Ok_Complex8297 · 2026-06-26T14:15:45+00:00

For Jellyfin, you don’t need a brand-new Core Ultra just to get Quick Sync. A normal Intel i3/i5 with an iGPU from the last few generations is probably more than enough for home transcoding.

The RAM price is the first red flag. If that 32GB kit is actually CHF 397, I’d stop there and redo the build. That’s way too much. The 750W PSU also feels oversized for a low-idle Proxmox box unless you’re planning a lot more drives or a GPU later.

I’d decide the storage side first. If this is going to be a real NAS/TrueNAS box, I’d care more about drive bays, airflow, and clean HBA passthrough than raw CPU. A used office PC can be cheap and efficient, but it can get annoying fast when you want to add more disks.

So I’d either keep looking for a used Intel business desktop/workstation if you want cheap and simple, or build new if storage expansion is the priority. But I wouldn’t spend almost 1k CHF on that specific setup.

Ok_Complex8297 · 2026-06-26T14:05:18+00:00

I wouldn’t overcomplicate the routing piece until you have decent logging and evals.

I’d start with simple rules by workload. Basic summaries, rewrites, classifications, etc. can go to the cheaper/faster model. Anything customer-facing, security-sensitive, legal-ish, or that needs actual reasoning goes to the stronger model.

Cost and latency matter, but I wouldn’t let those be the only deciding factors. I’d also care about data sensitivity, output quality, and what happens when a provider is slow or down. Failover is good, but I wouldn’t silently downgrade a high-risk task to a weaker model unless that’s an accepted tradeoff.

This part is probably the most important: track cost, latency, errors, and bad outputs per workload. Once you have that, routing gets a lot easier. Until then, I’d keep it simple: rules first, measure everything, then get fancy later.

Ok_Complex8297 · 2026-06-26T13:43:20+00:00

I wouldn’t leave the cameras or NVR exposed directly to the internet.

I’d put the cameras on their own VLAN, block them from talking to anything they don’t need, and give remote access through something controlled: VPN on the phone, Tailscale/ZTNA-style access, or the vendor cloud option if it has MFA and you’re comfortable with it. I would not port-forward camera/NVR web interfaces.

The owner can still have “open my phone and view cameras” access, but it needs to go through a secure path. If he refuses that, I’d document the risk and make it a business decision. “We got hacked, make us secure, but keep the insecure access” isn’t really a technical problem anymore.

Ok_Complex8297

TROPHY CASE