Varisya takes over custom software abandoned by a previous developer or agency. We audit what you have, recover the access you are missing, stabilise what is breaking, document the system properly, and then put a named engineer on it under an annual retainer from ₹39,000/year. You keep the software your business already runs on — no rebuild.
The pattern is familiar. A freelance developer or a small agency built your billing system, inventory app, dealer portal, or website three or four years ago. It worked. Then they raised prices, got busy with a bigger client, took a full-time job, or simply went quiet. The software still runs, so nothing feels urgent — until something outside your control changes and there is nobody to change the software in response. These are the five things that actually take businesses down, roughly in the order they arrive.
Takeover is not a support ticket queue bolted onto someone else's software. It is a defined piece of work that ends with you in control of your own system — and with a written record of it that survives any individual engineer, including ours. Each component below is completed during the takeover and then maintained on the annual retainer.
Component 1
Asset and access inventory
A written list of every asset your software depends on — domain registrar, DNS, hosting account, server access, database, source repository, SSL certificates, payment gateway, SMS/DLT and WhatsApp Business API accounts, any third-party keys — and, against each, who actually controls it today. Most owners have never seen this list, and it is the document that determines how exposed you are.
Component 2
Recovery of what you do not control
For each asset held by the previous vendor, Varisya works the recovery route: registrar and hosting ownership-verification using your company registration, GST records and payment evidence; provider account recovery; and reconstruction from the live server where an artifact is genuinely gone. Where a .in domain sits in the vendor's name and cannot be released, we prepare the evidence pack and set out the NIXI arbitration route honestly.
Component 3
Backups, before anything else
A verified, restorable backup of your database and application, held on infrastructure your business controls, established as the first technical act of the engagement — and then automated on a schedule with restores actually tested. Almost every abandoned system we assess either has no backups or has backups nobody has ever restored from, which is the same thing.
Component 4
Security and runtime stabilisation
Framework and language versions moved onto supported releases, known vulnerabilities in dependencies patched, hard-coded credentials removed from the codebase and rotated, server hardened, and certificate renewal automated so the 200-day TLS lifetime is a non-event rather than an outage. The system stops being one provider decision away from breaking.
Component 5
Statutory compliance catch-up
Where the software touches Indian statutory processes, it is brought current: GST rate masters aligned to the prevailing slabs, e-invoice and e-way bill integrations updated to the current GSTN API contract, TDS and reporting logic checked, and payment integrations reviewed against RBI's tokenisation and authentication requirements. Then kept current as rules change — which is the part a project-based vendor never signs up for.
Component 6
The documentation nobody left you
Architecture and data-flow notes, a deployment and rollback runbook, an environment and credential inventory kept in your own password manager, an integration register, and a failure runbook for the issues most likely to recur. It is handed to you, it is written in plain language, and it stays yours if the retainer ends. This is what makes you replaceable-vendor-proof rather than dependent on Varisya.
If you are a 15–200 person Indian business whose day-to-day operations depend on custom software that a previous developer or agency built and no longer maintains — billing, inventory, a dealer or customer portal, an internal ERP — takeover is almost always the right move. The fit is strongest when your team knows the software well and works around a handful of known bugs, when your transactional history lives inside it, and when the fear stopping you from acting is that a new firm will insist on rebuilding everything from zero. Varisya's default position is to keep what works.
If your software is an off-the-shelf licensed product from a vendor still trading — TallyPrime, Zoho, a SaaS subscription — this is not the service you need; go to that vendor's support or an authorised partner, and Varisya will point you there. If the application is compiled or obfuscated with no source available and the original vendor cannot be reached at all, honest expectations matter: we can often keep it running on stabilised infrastructure, but we cannot change behaviour we cannot read, and a staged replacement is the realistic path. And if the codebase turns out to be genuinely unsafe to build on, we will say so in the assessment and recommend replacement rather than sell you a retainer on a system we do not believe in.
| Your options | Rebuild from scratch with a new agency | Find another freelancer to patch it | Varisya takeover + dedicated support |
|---|---|---|---|
| Time before the bleeding stops | Months — the old system stays unmaintained for the whole build | Days, for the one symptom raised — underlying risks untouched | Backups and the critical risk list addressed in the first weeks |
| Your historical data | Migration project in its own right; inconsistencies surface late | Stays where it is, still unbacked-up | Stays in place, backed up and verified before any change is made |
| Business rules your staff rely on | Must be re-specified from memory — the commonest cause of overrun | Preserved, but still undocumented | Preserved and written down as the system is learned |
| Retraining your team | Full retraining on a new interface, during cutover | None | None — same system, fewer bugs |
| Access and credential recovery | Usually out of scope — you are told to sort it out first | Out of scope | Explicitly in scope, including registrar and hosting ownership routes |
| GST, e-invoice and RBI rule changes | Current at launch, then a change request each time rules move | Only when you notice something has broken | Tracked and applied on the retainer as part of ongoing support |
| Documentation you end up owning | Varies — frequently thin once the project team moves on | None | Architecture notes, runbooks and credential inventory, handed over and yours |
| If the individual engineer leaves | Project knowledge leaves with the team | You are back exactly where you started | Named engineer with a documented handover — continuity is the point |
| Who owns code, servers and accounts | Depends entirely on the contract — read it carefully | Frequently ends up in the freelancer's personal accounts again | Everything registered in your company's name from day one |
| Pricing model | Project fee, then a separate AMC | Per-incident, unpredictable | Annual retainer from ₹39,000/year, with a monthly pool of dev-days |
The sequence below is deliberately ordered by risk, not by convenience. Backups and access come before features, and we will not begin cosmetic work while your data has no verified copy or your domain renewal sits on a card that is not yours.
Our developer has stopped replying and we do not have the source code — is the situation hopeless?
Usually not. If the software is still running, the code is on the server that runs it — a working application is itself a copy of the source. The first job is regaining control of that server, which is normally done through the hosting provider's ownership-verification process using your business registration and payment records rather than through the developer. Once Varisya has server access, we can retrieve the running code, take a full database backup, and put the system under version control for the first time. The genuinely hard cases are compiled or obfuscated applications, and situations where the hosting account itself was opened in the developer's personal name and paid from their card — there, recovery depends on the provider's process. We tell you which case you are in during the first triage call, rather than after you have paid for a project.
Our agency shut down and our .in domain is registered in their name — how do we get it back?
There are two routes. The first and usually faster one is the registrar's own ownership-transfer process: registrars will move a domain when you can evidence that the business behind the name is yours, typically with company registration documents, GST registration, trademark records if you hold one, and proof that you paid for the registration. The second route is formal arbitration — for .in and .भारत names, NIXI operates the .IN Domain Name Dispute Resolution Policy (INDRP), which currently carries a filing fee in the region of ₹35,000 and generally resolves within 60 to 90 days. INDRP is only realistically winnable if you hold a trademark on the name, because you must show the domain is identical or confusingly similar to your mark, that the registrant has no legitimate interest in it, and that it was registered or is being used in bad faith. Varisya prepares the evidence pack for the registrar route, and will tell you plainly if arbitration is the only path left.
We run on custom billing software nobody has touched in two years and it still works — why should we pay for support when nothing is broken?
Because unmaintained software in India does not fail on your schedule, it fails on a regulator's or a certificate authority's. Three concrete examples from the last year. GST rates were restructured in September 2025, so a system with stale rate masters keeps issuing invoices at slabs that no longer exist, causing short payment and input tax credit mismatches for your buyers. GSTN's e-invoice and e-way bill APIs changed on 1 August 2026 to require Ship-To GSTIN capture — an integration that was not updated has its payloads rejected at generation, which means goods do not move. And the maximum lifetime of a TLS/SSL certificate dropped to 200 days from March 2026, falling further in later years, so certificate renewal is now a recurring operational task rather than an annual purchase; nobody watching it means a browser security warning on your customer-facing system. A retainer is what keeps someone watching those dates, instead of you discovering them at the counter.
Would it not be cheaper to just rebuild the software from scratch with a new agency?
Sometimes, and Varisya will say so when it is true. But a rebuild quote almost never prices the things that make rebuilds expensive: re-specifying business rules that currently exist only inside the working system, migrating years of live transactional data with its accumulated inconsistencies, running old and new in parallel while your team learns the replacement, and the period of reduced throughput after cutover. A takeover starts from a system your staff already knows and your data already lives in, so the spend goes on stabilising and improving rather than on re-reaching the position you are in today. Our honest test is the codebase assessment in step three: if the code is unsafe to build on — no separation of concerns, credentials hard-coded throughout, a framework version with no upgrade path — we recommend a staged replacement and say which parts to replace first. If it is ordinary, unglamorous, working code with no documentation, which is the common case, takeover is the cheaper and lower-risk path.
How do we know Varisya will not also disappear on us the way our last developer did?
The honest answer is that you should not take any vendor's word for it — you should require the structural protections that make disappearance survivable. Varisya's engagements are built so that everything sits in your name: the source code lives in a repository you own, the software runs on infrastructure registered and paid for by your business, domain and hosting accounts are held under your company rather than ours, credentials live in your password manager, and the documentation written during takeover is handed to you and stays yours. If you end the retainer, you keep all of it, and any competent engineer can pick the system up — because we wrote the documentation that makes that possible. That is the opposite of how the last arrangement worked, where the leverage was in what only the developer knew and only the developer could log into.
The previous vendor left no documentation and the code has no comments — can a new engineer realistically pick that up?
Yes, and it is most of what this service consists of. Undocumented business software is normal rather than exceptional, and the way in is not to read every line but to work backwards from behaviour: trace what happens when an invoice is raised, follow the data into the tables, map the integrations by watching what the system calls out to. In practice, a business application of typical SME size becomes safely modifiable within two to four weeks of an engineer working on it. The difference from your previous arrangement is that this understanding is written down as it is built — architecture notes, data-flow diagrams, a deployment runbook — so it becomes an asset your business holds, rather than knowledge locked in one more individual's head.
We are a 40-person distribution business, our software runs billing and stock, and the vendor is unreachable — what should we do first, today?
Take a backup, before anything else. If you have any access to the server or the application's admin area, export the database and download it somewhere your business controls — the single worst outcome in this situation is a server suspended for non-payment while the only copy of your transactional data is on it. Second, find out who actually holds the accounts: check which email address receives the hosting and domain renewal notices, and whether the renewal card on file is yours or the developer's, because an expiring registration on someone else's card is your nearest cliff edge. Third, stop making changes through unofficial channels — a well-meaning freelancer patching a live server without version control or backups is how recoverable situations become unrecoverable. Then get an assessment. Varisya's triage call covers exactly these three points and produces a written risk list, and we will tell you if the right answer is something other than hiring us.
Once the system is stable, it moves onto the standard dedicated software support retainer. If the assessment concludes that replacement is the better path, that work runs through Varisya as your software implementation partner. For background on why ownership of code and infrastructure matters so much in this situation, read who owns your software, and for how a retainer compares with the informal arrangement you are coming from, see dedicated support vs a freelance developer retainer.
A 30-minute triage call — we map what your system depends on, identify which assets you do not currently control, flag the compliance and security items closest to stopping your business, and give you a written risk list you keep either way. From ₹39,000/year once the system moves onto the retainer.
No checkout, no lock-in. Every engagement routes through a consultation.