Scryent
meteor migration and modernization
Your Meteor app still pays the bills. Keep it that way.
I have run Focuster, a production Meteor SaaS, since 2016. Every upgrade, every deprecation, every performance cliff: I hit it on my own app first. When I modernize your Meteor codebase, it is not my first rodeo. It is my tenth year of the same rodeo.
What I take on
- Meteor version upgrades. Stuck on 1.x or 2.x? I plan and execute the jump to current Meteor and current Node, including the package archaeology nobody enjoys.
- Migration off Meteor. When leaving is the right call, I move apps to modern stacks incrementally, keeping the product shippable the whole way. No big-bang rewrite that dies at 80%.
- Performance. Oplog tailing pain, publication fan-out, method latency, MongoDB query tuning. I find the actual bottleneck instead of guessing.
- Testing. Retrofit automated test coverage so future upgrades stop being leaps of faith.
Why a Meteor specialist
Meteor apps fail in Meteor-specific ways: reactivity storms, publication memory blowups, build system quirks, packages abandoned a decade ago. Generic Node consultants relearn this on your invoice. I also maintain open-source Meteor packages, including meteor-public-env and meteor-mock-id, and durabl, a Mongo-backed durable execution framework that fits Meteor apps perfectly. I am a contributor to Meteor itself.
Common engagements
- Meteor upgrade assessment: what breaks, what it costs, in what order
- Hands-on version migration with test coverage as we go
- Meteor to Next.js or NestJS incremental migration
- Performance audit of a slow production Meteor app