Realisier Labs

We put BOLD's job fleet on one system you can watch.

  • Seventeen jobs in one place, from every 15 minutes to weekly
  • Every run recorded: what happened, how long it took, who started it
  • Email and a text message the moment one fails

Client: BOLD Precious Metals · bullion e-commerce, USA · running in production

Modernize your job fleet See all case studies
Why we built it

The jobs run the business. Nobody could see them.

Scattered console apps became one host, one dashboard, one run history.

17
jobs, one system
15 min
fastest job's cycle
24/7
running, unattended
Scheduled jobs dashboard listing every job with its last status, last run time, duration, next run and schedule, each with a Run now button
Scheduled jobs: last run, duration, next run, and Run now.Shown with demo data.
Manage jobs screen with a toggle per job, showing that an unticked job is skipped on its schedule and that changes take effect on the next run without a restart
Manage jobs: switch one off without restarting anything.Shown with demo data.
Architecture

One host, one pipeline, one place to look

Admin dashboard last run · next run · duration per-run logs · recent errors “Run now” button admin / viewer roles Worker host · .NET 8 Windows service Quartz scheduler one cron trigger per job Execution pipeline run id · status · alerting 17 jobs, business logic only order lifecycle · shipping sync · tax commit pricing feeds · supplier stock · fraud checks customer reminders · reviews · vendor invoices each job holds only its own logic; the rest is written once Monitoring database run history · correlated logs “Run now” queue · users separate from the business DB additive, never destructive Business database the same stored procedures as the jobs always called left exactly as it was External services shipping · tax · supplier stock typed clients, one per service sandbox before production Failure alerts 🔔 email and SMS to the ops team sent by the pipeline, not the job staging mail reroutes internally writes reads run status · logs polls “run now” calls existing procedures HTTPS on failure
Everything new is written to its own database. The one the business already runs on is left exactly as it was.
Before and after

We changed everything except the part that runs the business.

The rules that decide what happens never moved. That's why changing the rest was safe.

Before→After
Seventeen separate programs, the same setup code copied word for word into each one
→
One system. Each job is a small piece of its own; everything shared is written once
Passwords and keys sat in plain text inside the code, in every one of the seventeen
→
Kept outside the code entirely, where they can be changed without a release
To find out whether a job had run, somebody had to go and look
→
A dashboard showing every run, how long it took and what failed
A failure was found whenever somebody happened to notice
→
Email and a text message to the team the moment a job fails
Most of the fleet ran on software that stopped getting security updates in 2022
→
A current, supported platform, with automated tests
Built to fail safely

A job can fail. The fleet can't.

Seventeen jobs share a host, so one bad run must never take the rest with it.

  • One job's failure stays its own

    Logged, marked failed, alert sent. The host stays up and every other job keeps its schedule.

  • Watching can't break the work

    If the monitoring database is down or an alert can't send, the job still finishes. Recording a run never interferes with it.

  • Staging can't reach a customer

    One toggle reroutes every outbound email and SMS to an internal address. The same build ships to production with it off.

  • The existing system is never altered

    Jobs run the same routines they always did. Everything new is written to a separate database of its own.

In practice

Three things the rebuild turned up

  • The tax job that filed nothing

    Every filing came back rejected. One value was in the wrong part of the request. A single line to fix, and a job that had never once succeeded started working.

  • The duplicate that wasn't a bug

    A cancelled order appeared twice. The same code cancelled cleanly in staging. A second store connection was re-importing it: configuration, not code.

  • The fraud check that ignored latitude

    The distance to a blocked address was worked out with a formula that only holds true near the equator, and it was being handed half the details it needed.

How we work

AI-assisted, human-owned

A person sets the architecture and the safety bar. The AI does the volume work.

  • A person owns the design
  • Old code read line by line
  • Every assumption written down
  • Nothing runs on live data unwatched
  • Tested against a sandbox first
  • We never write to your database directly
  • Passwords never stored in code
  • Test emails can't reach customers
  • Documented so your team can take it over
Talk to Sachin

Sitting on a fleet of jobs nobody dares touch?

Realisier Labs modernizes the operational infrastructure that keeps revenue moving: fast, verified, and handed over so your team owns it.

Start the conversation