Ruby on Rails, since 1.0.

The claim

Rails since 1.0. Not a rounding error.

Prayantr's founder was writing Ruby on Rails when the framework was still edge rails — one of India's earliest Rails engineers, at the country's first Rails company. Two decades later, the stack is still Rails, PostgreSQL, Redis, and AWS, deliberately: boring technology, chosen on purpose, run by someone who has watched every major version arrive.

• Application development — new features and systems built the way production teams actually run Rails, not the way a tutorial does.
• Architecture & data modeling — built for the second year, not the demo.
• Performance & scaling — the database, the cache, the job queue, in that order, because that's usually where the time actually goes.
• Testing & CI/CD — a suite senior engineers trust enough to deploy from, not a coverage number nobody reads.

Who this is for

Two different problems, the same stack.

• Running Rails, need senior help — a CTO or lead engineer at a Rails-based product who wants a second, more experienced set of eyes on architecture, performance, or a specific hard problem.
• Inherited a Rails codebase — a founder, acquirer, or new CTO holding a revenue-bearing application several major versions behind, with the person who wrote it long gone and nobody confident enough to touch the upgrade.

Rails upgrades & legacy rescue

The version gap is rarely the real risk.

Most "just upgrade Rails" advice undersells what actually breaks: gems that stopped being maintained two major versions ago, a test suite too thin to trust, and behavior nobody wrote down because it was obvious in 2019. The approach that actually works, in order:

• Test coverage first — where coverage is too thin to trust an upgrade, that's the first work, not an afterthought.
• Dependency triage — every gem sorted into keep, replace, or remove, before touching the framework version.
• One major version at a time — a dual-boot approach where it's warranted, so the app runs on both the old and new version until the migration is proven, not a single risky jump.
• Deprecation burn-down — warnings fixed as they appear, not batched into a crisis at the end.

Sometimes the honest answer is that a full rewrite is warranted — but that's a rare answer, not a default one. Most "this needs a rewrite" codebases need an upgrade path and a firmer hand, not a restart.

How it runs

An assessment first, then a fixed-scope plan.

1. A 30-minute call

   The application, its age, its test coverage, and what's actually driving the urgency — a security concern, a hiring problem, a performance ceiling.

2. A fixed-scope assessment or proposal

   For a clear upgrade or build, a fixed-scope proposal within 48 hours. For anything murkier, a short paid assessment first — the dependency and test-coverage audit above, as a standalone deliverable — so the real scope is known before a bigger commitment is made.

3. The work

   Built or upgraded in the open, with the test suite as the safety net, not an afterthought. No hourly billing, so scope discipline is the plan's job, not a running meter's.

4. Handover

   Documentation and a warranty window for builds; a clean, deprecation-free codebase and a test suite your own team can extend, for upgrades.

The shape of it

How a build usually goes.

Client work is confidential by default, so what follows is pattern, not portfolio. Named references are shared in conversation.

Why this firm

Judgment travels. Hands-on work stays where it's world-class.

Fractional leadership and audits are stack-agnostic — the judgment applies regardless of what a client runs. Hands-on build and upgrade work stays exactly where Prayantr is world-class: Ruby on Rails, PostgreSQL, Redis, and AWS. Two decades in, principal-led, with no bench between you and the person doing the work. More on the entity and the person on The Firm.

MSA + SOW on every engagement · Fixed scope, fixed price, no hourly billing
IP assigned to you on payment · 30-day exit · USD invoicing, worldwide