Navigate the business side of web development. A complete guide on HSN codes (998314), drafting winning RFPs, and securing high-value development tenders.
Quick answer
Website development services in India are invoiced under HSN code 998314 (IT design and development services); the exact GST rate should be confirmed with your CA or the current GST notification rather than assumed. A good RFP names concrete deliverables, a realistic timeline, an evaluation method, and a budget range, so vendors bid on the same project instead of guessing at it. The mistakes that sink most RFPs are missing technical requirements, vague IP and source-code ownership terms, and deadlines set before anyone scoped the work. Before responding to a tender, a vendor should get scope, payment milestones, and code ownership in writing, not implied.
Key takeaways
- HSN 998314 covers IT design and development services, including website development; confirm the applicable GST rate with a CA rather than relying on a number quoted online.
- A strong RFP states scope, deliverables, timeline, evaluation criteria, and either a budget range or a request for one.
- Vague technical requirements are the single biggest reason web development RFPs attract mismatched bids.
- Source code and IP ownership should be spelled out in the RFP, not assumed to transfer automatically on payment.
- Before responding to a tender, a vendor should confirm scope, payment terms, and whether source code ownership actually transfers to the client.
- Anraone hands over full source code ownership to the client once a project is paid for in full.
What HSN code 998314 covers and why it matters for invoicing
HSN stands for Harmonized System of Nomenclature, a classification system used across GST invoicing in India to identify what a good or service actually is. For website development, custom software builds, and web portal creation, the code used is 998314, which falls under IT design and development services. If you're a business commissioning a website, or a vendor invoicing one, this is the code that should appear on the invoice.
What the HSN code does not settle is the GST rate itself. Rates get revised through GST Council notifications, and getting this wrong on an invoice creates real problems, mismatched input tax credit claims, notices from the department, awkward conversations with a client's finance team. Rather than quote a rate here that could be out of date by the time you read this, the honest answer is: confirm the current rate for HSN 998314 with your CA or the latest GST notification before you invoice. That's a five-minute check that avoids a much longer cleanup later.
One practical note for RFPs and tenders specifically: if you're asking vendors to quote a price, ask them to state their HSN code and confirm GST is being handled correctly on their end. It's a small line in the RFP that filters out vendors who aren't set up to invoice properly, before you've signed anything.
What makes an RFP for web development actually good
Most RFPs we see fail before a single vendor responds, not because the project is unreasonable, but because the document doesn't give vendors enough to price it accurately. A good RFP for a web development project does four things.
It states concrete deliverables. Not "a modern website" but "a business site of roughly 8-10 pages, including a blog, a contact form that routes to our CRM, and a careers page with an application upload." The more specific the deliverable list, the more comparable the quotes you get back.
It sets evaluation criteria upfront. If pricing is 30% of the decision and portfolio relevance is 40%, say so in the RFP. Vendors who know how they'll be judged submit tighter, more relevant proposals, and you avoid the awkward situation of picking a winner on criteria nobody knew mattered.
It gives a realistic timeline. A business site with 8-12 pages typically takes several weeks to build properly once design, content, and revisions are accounted for; a more advanced build with custom functionality takes longer. An RFP that demands a full custom site in two weeks either gets no serious bids or gets bids from vendors cutting corners you won't see until launch.
It states a budget range, or explicitly asks for one. Businesses sometimes worry that naming a budget invites vendors to quote right up to the ceiling. In practice, withholding it wastes far more time: you get quotes spanning a 10x range, none of them comparable, and you're back to square one. Even a wide range narrows the field to vendors who are actually a fit.
Common mistakes businesses make when drafting an RFP
The same three mistakes show up again and again, across industries and budget sizes.
No technical requirements. An RFP that describes the site visually, "clean, modern, easy to use", but says nothing about the CMS, integrations, hosting expectations, or whether the site needs to talk to an existing CRM or ERP, forces vendors to guess. Guesses turn into change orders once the real requirements surface mid-project.
Unclear IP and ownership terms. Who owns the source code once the project is delivered and paid for? Does the client get the codebase, or only a license to use the hosted site? This should be a line item in the RFP and the contract that follows it, not something discovered in a dispute later. Some agencies retain code ownership by default unless a client negotiates otherwise; that's worth asking about before you sign, not after.
Unrealistic timelines set before scoping. Timelines that get fixed in the RFP before anyone has scoped the actual work tend to slip, and the slip usually costs the client more than a realistic timeline would have. It's better to ask vendors to propose a timeline against the stated scope than to dictate one you haven't stress-tested.
What a vendor should check before responding to a tender
Government tenders are typically listed on the Central Public Procurement Portal (CPPP), the Government e-Marketplace (GeM), or state-level e-procurement portals. Enterprise tenders usually come through direct RFPs or vendor empanelment processes. Either way, before a vendor invests time in a response, three things are worth confirming.
Is the scope actually clear? If the tender document is vague on deliverables, that vagueness doesn't disappear after you win, it becomes scope creep during delivery, on a fixed price you already committed to. Ask clarifying questions during the pre-bid stage rather than assuming.
What are the payment terms? Milestone-based payment tied to defined deliverables protects both sides. A single payment on final delivery, with no interim milestones, is a risk worth pricing in or negotiating out.
Does source code ownership actually transfer? This is worth reading carefully rather than assuming. At Anraone, source code ownership transfers to the client once the project is paid for in full, that's our standard practice, and it's the kind of term worth confirming with any vendor before you sign, since it isn't universal across the industry.
For businesses drafting the RFP in the first place, our web development team can help scope a project brief before it goes out, so the technical requirements section isn't left blank. For projects that need to talk to internal systems, our custom software work covers that kind of integration directly.
