Twenty-eight years of it, mostly for manufacturers and integrators, and from the PLC and the robot up to the browser — getting data off machines and onto screens, joining systems that were never meant to talk, and replacing legacy databases that quietly run a department.
Ruby on Rails
The applications people work in all day: registers, tracking, scheduling, reporting. Long-lived systems that keep changing for years — and the new home for whatever the business is running on now.
.NET
The part that talks to equipment. Reading PLCs, trackers and instruments over their own protocols, on machines that keep working when the network doesn't, and handing clean data to the systems above.
"Full stack" usually means the browser and the server. In a plant it has to mean more than that. I've worked at every one of these layers, which is mostly useful because it means I know what the layer below is actually able to give me.
A legacy database that runs a department. A mod_perl application nobody dares deploy. A VB6 tool one person maintains. It still works, which is exactly why replacing it is hard — there's no crisis to justify downtime and no tolerance for losing anything.
I move these onto Rails with a minimum of downtime. The method is always the same, and the order matters.
Besides the documentation, look at the data — it usually tells you more. Old systems accumulate rules that live nowhere but in the records themselves: the status code that means something different after 2009, the field reused for a second purpose. I read the real database before proposing anything.
A one-off conversion script gets you one attempt. A repeatable import lets you re-run against live data as often as you like, so every assumption is tested against reality months before cutover. This single decision removes most of the risk.
Existing URLs keep working. Passwords migrate silently on first login rather than forcing a reset. Vocabulary stays whatever your people already call things. A migration users have to be trained through is a migration that gets resisted.
By the time it happens the import has run dozens of times and the new system has been checked against the old one on real records. Cutover should be a rehearsed, boring operation — and reversible if it isn't.
My own platform: a plant looking after its own installations and a supplier servicing the ones it sold, both served by one asset register — because the hierarchy hangs off a company.
Kegs tracked through filling and washing, line stoppages explained to the minute, and data pipelines an engineer configures in a browser — .NET and Akka.NET at the edge, Rails for the analysis on top.
One map of a mixed fleet, showing not just where each vessel is but what its onboard systems are reporting — fuel, machinery state, running hours — plus who is aboard.
Member records, board composition and a shared calendar for a three-tier federation — off mod_perl and onto Rails, including a password migration no member ever noticed.
Paper questionnaires and hand-calculated scores replaced by a link the client fills in and results that compute themselves — and a new instrument needs no code changes to the core.
