RunWisp VS ViewForge

RunWisp's answer

Almost everything is written in Go, except for Web UI where we use Svelte with TypeScript.

ViewForge's answer:

• TypeScript
• Shopify metaobjects, as the fitment data store
• Shopify theme app extensions for the storefront components: fitment search, saved-vehicle garage, compatibility table, product-page fit notice
• Shopify Storefront API, for querying fitment from the theme
• Shopify Admin GraphQL API, for writing and exporting fitment records
• NHTSA vehicle database, for VIN decoding
• ACES and PIES XML parsing, for automotive catalog import

RunWisp's answer

It's the rare infrastructure tool that's actually a pleasure to run:

• Set up in minutes, not an afternoon. One ~25 MB binary, no Python, no Node, no external database. Download it, point it at a TOML file, done — or run runwisp import cron / import supervisord to bring your existing setup over automatically.
• Three polished interfaces, all built in. A clean web dashboard, a real terminal UI, and a REST API ship inside the single binary — see every job, every run, every exit code and log line at a glance. No add-ons, no separate services.
• Lightweight and fast. A single static Go binary running in ~25 MB of RAM. It disappears into the background instead of becoming another thing you have to babysit.
• Nothing silently fails. Every run is recorded with its exit code, duration, and output, and you're alerted when a job fails or when a scheduled run never fires.

ViewForge's answer:

Three things. (1) Data ownership: ViewForge writes fitment as Shopify metaobjects native to your store — most competitors store fitment in their own database. (2) 8 verticals out of the box: auto, motorcycle, tractor, marine, power equipment, bicycle, printer, electronics — most competitors are automotive-only. (3) Smart Parse: extract fitment automatically from your existing product titles and descriptions instead of re-typing everything.

RunWisp's answer

The monitoring tools (Cronitor, Healthchecks, Dead Man's Snitch) only watch - they wait for a ping and tell you it didn't come, but they never run or restart anything. The execution platforms (Rundeck, Windmill, Dagu) run jobs but pull you into a heavyweight control plane, enterprise-gated team features, or a DAG/workflow model that's overkill for what most servers actually need. And nearly all of them are per-server SaaS with a recurring bill and your job data living on someone else's servers.

RunWisp is the tool that both runs and watches, self-hosted, in one ~25 MB binary you install in minutes. Full per-run history and failed/missed-run alerts, a genuinely good web dashboard and terminal UI out of the box, no external dependencies, no monthly invoice, no data leaving your infrastructure. It does the two jobs most servers need - scheduling and supervision - and makes them effortless to run and easy to see, without asking you to adopt a platform.

ViewForge's answer:

Data ownership. Fitment lives in your Shopify metaobjects, so uninstalling does not take your compatibility data with it. Convermax, EasySearch and PartFinder all keep it in their own databases, and getting it back depends on their export tooling on the day you cancel.

Cost at the low end. The search widget, the compatibility table on the product page and the saved-vehicle garage are all on the free tier, up to 50 products, with no expiry. EasySearch puts the table and the garage behind its $75/month Premium plan. Convermax starts at $250/month.

Automotive and non-automotive coverage. Eight built-in templates, and fully custom templates from $19/month, for catalogs that do not decompose into Year/Make/Model at all.

RunWisp's answer

Two groups.

First, developers and DevOps teams who want their scheduled jobs and services defined as code: the entire setup lives in a single runwisp.toml that goes straight into your git repo, so a change to a cron job is a reviewable commit, not an undocumented edit on some server. It gives developers and ops a shared, versioned source of truth for what runs where and makes handoffs and audits painless.

Second, self-hosters and homelab operators (like the Raspberry Pi and home-server crowd) who want real visibility into their scheduled jobs without running heavyweight infrastructure. One tiny binary, ~25 MB of RAM, no external database or runtime, and a clean web dashboard to see everything at a glance.

ViewForge's answer:

Shopify merchants whose customers need to know whether a part fits before they will buy it — and who do not have an engineer on staff to build that themselves.

Concretely: auto and truck parts retailers, powersports and motorcycle dealers, tractor and agricultural parts sellers, marine and outboard suppliers, small-engine and power equipment stores, bicycle and e-bike component shops, printer supply merchants, and electronics accessory sellers.

Catalog sizes run from a few dozen products on the free tier up into the tens of thousands; it is running in production on a catalog of roughly 40,000 SKUs. The common thread is not the industry — it is that "does this fit my thing" is the question deciding the sale.

RunWisp's answer

RunWisp started with a problem its founder ran into twice. At two different companies, he needed a way to let developers see whether their scheduled jobs had actually run (browse the history, read the output, and trigger a job themselves when needed) without handing everyone an SSH login to a production server. Giving out shell access just to check on a cron job invites mistakes; the alternative was leaving developers flying blind.

No existing tool handled it cleanly, so he built the internal dashboard he wanted: every job, its full run history and output, and a one-click trigger (no server credentials required). When the same need came up again at the next company, it was clear this shouldn't have to be rebuilt everywhere. RunWisp is that tool, productized: a single binary that schedules and supervises your jobs and gives the people who need it a clear, safe view of what's running, without a shell account on the box.

ViewForge's answer:

ViewForge came out of agency work. Normal View was building for a parts retailer running roughly 12,000 SKUs who needed fitment search, and every app we evaluated stored the merchant's compatibility data in the vendor's own database.

That is a strange trade when you look at it directly. Fitment data is genuinely expensive to produce — it is weeks of work — and the merchant would not own the result. It would belong to whichever app happened to be installed that year.

Shopify metaobjects made a different answer possible: write fitment as native structured data inside the merchant's own store. The theme reads it, the Storefront API queries it, Admin GraphQL exports it, and it is still there after an uninstall. That decision is what the rest of the app is built around.

Everything else came from real catalogs rather than a roadmap. Eight verticals exist because a tractor catalog is not Year/Make/Model. Smart Parse exists because that retailer had already written fitment into 12,000 product titles, and nobody was ever going to retype them.