- How long does a typical frontend modernization take?
- Most engagements run 60-90 days for a single-product modernization. The audit and roadmap lands in week 1, the first slice of rewritten UI ships behind a flag by week 3, and full handoff happens between weeks 11-13. Larger codebases or multi-product organisations scope longer; we say so in the proposal.
- Does Hotreloads rewrite from scratch or refactor in place?
- Refactor in place using the Strangler Fig pattern. New routes proxy through the old monolith until each module is fully on its replacement. No big-bang cutover, no weekend migration, no period where customers cannot reach the product. The old system keeps paying the bills while the new one comes online.
- Can Hotreloads work alongside our in-house engineers?
- Yes. The default engagement is a senior pod of 2-4 engineers embedded with your existing team. Weekly demos, shared Slack, full commit visibility. Your engineers learn the new patterns alongside us and own the system after handoff. We have no interest in being a black-box vendor.
- Which frameworks and stacks does Hotreloads work with?
- Production: React 19, Next.js, Vite, TypeScript, Astro for marketing surfaces. APIs: tRPC, REST, GraphQL. Auth: Auth.js, Clerk, custom. Testing: Vitest, Playwright. We will not move you onto a stack we cannot maintain ourselves; if your current stack is sound, we modernize within it rather than swap for swap's sake.
- What does fixed-scope actually mean in practice?
- The proposal lists each surface to be rebuilt, each API to be refactored, and each acceptance criterion in writing before week 1. We sign for that scope. If you change scope mid-engagement, we re-quote in writing before any work starts on the change. No silent scope creep, no hourly surprises.
- What does the first week of a frontend modernization engagement look like?
- Week one is mostly listening and reading. Three calls: eng lead, product owner, and whoever is on call when the build breaks. We read the codebase end-to-end, run the test suite, and trigger the deploy pipeline ourselves. By Friday you get a written diagnosis with the work split into "do first" and "can wait." We do not write production code in week one. If something demands a same-week fix we will do it, but the default is: understand before changing.
- How does Hotreloads ship without breaking what users are already using?
- Every change ships behind a feature flag and rolls out to a small slice of traffic first. We do not replace pages; we replace components, page by page, with a parity test that screenshots both versions on every commit. The old code keeps running until the new code matches its behavior on the metrics that matter (conversion, error rate, Core Web Vitals). The flag flips when the parity test has been green for at least seven days under real traffic. If anything regresses, the flip reverses in one config change, no redeploy.
- Can Hotreloads work in mixed-stack codebases that have legacy Angular and modern React side by side?
- Yes. Most modernization engagements start in a codebase that has both. We use module federation or single-spa to mount the new framework alongside the old one, route by URL prefix during the transition, and share session state through a small Redux-or-Pinia bridge so neither side has to know the other exists. The engineers familiar with the Angular code stay on the Angular code until each React replacement is shipped and parity-verified; nothing gets deleted until users have used the new path for thirty days without an incident.
