Why "Launch and Vanish" Is the Real Risk for Indian Small Businesses

The Pattern Most Indian Buyers Have Lived Through

A small business owner in Indore decides their saree shop needs to be online. They ask around, and a friend's nephew — a freelance developer — quotes ₹35,000 for a "complete website with admin panel". Money changes hands, a WordPress site goes live, and for two weeks the developer is responsive. Then the messages slow down. By month three, the contact form silently stops sending email. By month six, the SSL certificate has expired. By month nine, the developer's WhatsApp is on read-receipts-disabled and replies stop coming.

This is the launch-and-vanish pattern. It is the single most common Indian web-vendor failure mode, and it transforms what was supposed to be a growth tool into a liability that quietly corrodes the business's credibility every day it stays broken.

This essay describes the pattern honestly, explains the structural reasons it persists, and walks through the specific contractual mechanism Dwize uses to close it.

Section 1: The Anatomy of Vendor Abandonment

Launch-and-vanish is not laziness. It is rational behavior under the wrong contract structure. When an Indian web vendor's compensation is paid in full at launch, and the contract is silent on what happens afterwards, the rational economic move is to redirect attention to whichever new prospect is willing to pay the next launch invoice. Continued attention to the previous customer is a cost without revenue.

The pattern has consistent symptoms:

• The site or app continues to exist as a URL, but stops being maintained.
• Plugins, themes, dependencies, and OS-level packages quietly accumulate vulnerabilities that nobody patches.
• The contact form silently fails — usually because an email API expired, a cron job died, or a hosting plan was downgraded.
• The hosting renewal lapses without warning, and the site goes dark for hours or days while the owner figures out who actually owns the credentials.
• The SSL certificate expires. Browsers start showing red warnings. Customers leave.
• WhatsApp messages to the developer go unanswered. New phone numbers appear. The relationship has structurally ended without anyone formally ending it.

For an MSME owner without internal technical staff, every one of these symptoms is a small crisis that requires expertise the business doesn't have. The owner ends up paying a different developer to "just get it working again" — usually after committing to another launch-and-vanish cycle with a new vendor.

The strategic cost of this pattern is bigger than the cash. It teaches the buyer that digital investment is risky, slow, and fragile. The buyer becomes risk-averse. The next time digital comes up, they postpone it. Indian MSMEs have, collectively, postponed enough digital adoption to amount to a national-scale loss of competitiveness.

Section 2: Why "Maintenance Plans" Don't Solve It

The standard response to launch-and-vanish is to add a "maintenance plan" — typically a recurring monthly fee for unspecified attention. These plans suffer from two problems.

They are vague. "Maintenance" can mean anything from "we'll log in once a month and click Update Plugins" to "we run continuous security monitoring." The buyer has no way to assess what they are actually paying for. The vendor has no contractual obligation to do specific things on specific cadences.

They renew under different terms each year. Most maintenance plans escalate annually. The buyer who signed up at ₹2,000/month sees ₹3,000/month in Year 2 and ₹4,500/month in Year 3 — without obvious change in service. Maintenance plans become a way for vendors to extract more revenue from already-anchored customers, which corrodes the relationship over time.

A "maintenance plan" addresses launch-and-vanish at the symptom level. The structural problem requires a structural answer.

Section 3: The Care Year — A Written Operating Contract

Dwize sells one product structurally: a 12-month operating contract called the Dwize Care Year. The artifact (Site, App, Store, or Brand) is what is delivered inside the year. The year is what is paid for.

This is not semantic. The contract appendix on every Care Year carries eight written covenants:

1. Same-price renewal — Renewal at the same product tier costs exactly Year 1 price. Lifetime, not negotiated annually.
2. Two-day update — Any in-scope content update is live within 2 business days of receipt.
3. Two-hour acknowledgement — Inquiries are acknowledged within 2 business hours during business days.
4. Named operator — One assigned human at Dwize. Their WhatsApp number is in the contract appendix.
5. Monthly check-in — Even when the buyer is silent, Dwize reaches out at least once a month with a status update and one question.
6. 99.95% uptime SLA — Measured monthly. If we miss it, a credit goes to the next renewal automatically.
7. Honest 30-day out — Pro-rata refund if the buyer is not satisfied within the first 30 days.
8. No-lock-in handover — At year-end, if the buyer doesn't renew, clean code/content/domain handover plus 30 days of read-only hosting.

The covenants are written down and enforced. Each one closes a specific failure mode that launch-and-vanish exhibits.

Section 4: How Each Covenant Closes a Failure Mode

Same-price renewal and no-lock-in handover work together as a system. Without the handover, the locked renewal is a trap (you can't leave, so the locked price becomes the floor of your future costs). Without the locked renewal, the handover is a threat (vendor can raise the price arbitrarily and dare you to leave). Together, they create a relationship where the customer stays because the year was good — not because leaving is hard.

Section 5: The Operator Difference

Covenant 04 — the named operator — is the most consequential. Most Indian web vendor support is queue-based: you submit a ticket, it gets routed, eventually someone replies, often the someone is different each time. The customer's mental model of the vendor is "a black box that sometimes responds."

Dwize replaces the black box with one human. Their name is in the contract. Their WhatsApp is in the contract. They carry your file end-to-end for the year. They acknowledge inquiries within two business hours, ship in-scope updates within two business days, run the monthly check-in, and handle every escalation. The customer's mental model is "Priya at Dwize" or "Ankit at Dwize" — a real, reachable person.

This single substitution — black box to named person — is what turns a transaction into a relationship. It is also why the covenants are operationally enforceable. Black-box queues will degrade over time as cost pressure mounts. A named operator with a written acknowledgement window cannot.

Section 6: The Pricing Structure That Makes Continuity Real

A vendor who isn't paid for operations cannot do operations. Launch-and-vanish persists partly because the launch fee doesn't fund the year that follows.

Dwize's pricing reflects what is actually being sold:

• Site at ₹10,699/year — A static, mobile-first website on Cloudflare-edge infrastructure, kept maintained for the year by a named operator. ~₹29 per day.
• App at ₹1,49,000/year — Native iOS + Android app on the App Store and Play Store, with OS-compatibility maintenance and 12 OTA updates. ~₹408 per day.
• Store at ₹2,99,000/year — Full Indian commerce platform with Razorpay, ONDC, WhatsApp catalog, GST invoicing. ~₹819 per day.
• Brand at ₹6,99,000/year — Store plus native iOS and Android shopping apps on the same backend. ~₹1,915 per day.

These are operating budgets, not launch-fee equivalents. Spread over the year, they fund hosting, security patching, OS-update compatibility, named-operator time, monthly check-ins, the uptime SLA, and the response-time covenants. The buyer pays for what is delivered for 365 days, not for the launch event.

Section 7: What This Looks Like in Practice

A real buyer comparison after the first 12 months:

Buyer A — went with a freelancer at ₹35,000 for a website. By month 3 the contact form is broken. By month 6 they pay another ₹15,000 to fix it. By month 9 the SSL has expired and they pay another ₹5,000 to renew + reconfigure. By month 12 they have spent ₹55,000, have a half-broken site, and zero ongoing operator.

Buyer B — went with Dwize Site at ₹10,699 for the year. By month 12 they have a maintained website, 12 content updates shipped within 2 days each, 99.95%+ uptime, and a renewal preview locking Year 2 at ₹10,699. They have spent less than 20% of what Buyer A spent and have an operating relationship instead of a series of crises.

Buyer A is the launch-and-vanish customer. Buyer B is the Care Year customer. The structural difference isn't about who is "better" or who tries harder. It is about which contract structure was signed.

Section 8: The Honest Out

Covenant 07 — the honest 30-day out — is the trust mechanism that makes the rest of the Care Year credible.

A vendor who guarantees a year of service has to mean it. The 30-day out gives the buyer a structural way to test that. If the first month feels off — communication is poor, the build is wrong, the operator isn't matching the covenants — the buyer can leave with a pro-rata refund, no questions, no guilt.

This protects both sides. The buyer can sign without fear that they are committing to a bad year. Dwize commits to a relationship knowing that if the early signal is bad, both parties exit cleanly. The covenant filters out the customers who would have churned anyway and aligns incentives for the ones who stay.

In practice, very few Care Years exit during the 30-day window. The covenant exists less because it's exercised often and more because its existence makes the rest of the year credible. The buyer reads the contract appendix and sees: "If this isn't right, I am not stuck." That single sentence does enormous work.

Section 9: Why This Matters for Indian MSMEs Specifically

Indian small businesses have been launched-and-vanished on for two decades. The cumulative trust deficit in the Indian web market is enormous, and it is the single biggest reason MSMEs delay digital adoption.

A buyer who has never been launched-and-vanished on can read a glossy proposal and trust it. A buyer who has been burned twice cannot. They need written commitments, operator names, response-time numbers, refund mechanisms, and exit clauses before they can re-enter the market.

The Care Year is structured for that buyer. Every clause exists because some Indian MSME got burned on its absence in a previous engagement. Same-price renewal exists because annual escalations have caused walkouts. Named operator exists because anonymous queues have caused walkouts. No-lock-in handover exists because data hostage situations have caused walkouts. Each covenant is the answer to a specific previous failure.

For Dwize, the right way to grow in this market is not to make better marketing claims than the launch-and-vanish vendors. It is to write down a contract structure that makes those claims unnecessary. The covenants do the talking.

What to Ask Your Current Vendor

If you already have a website or app and want to test whether you're in a launch-and-vanish situation, send your current vendor these four questions over WhatsApp or email:

1. What is your current uptime over the last 90 days? (Specific percentage, please.)
2. If I send a content change today, when will it be live?
3. What's my renewal price next year, and is it locked?
4. If I don't renew, how do I get my code, content, and domain — at what cost?

If the answers are vague, missing, or threatening, you are in a launch-and-vanish relationship even if the vendor is technically still responsive.

The Care Year exists for the buyer who wants those four answers in writing before they sign. That is the structural difference. Everything else is execution.