How to win government IT contracts as a small tech firm

Governments are the biggest buyers of software, websites, cloud, IT support and security in almost every country. A large share of that spend goes to contracts under a few hundred thousand dollars, which is the sweet spot for a firm of 2 to 50 people. Most small firms never bid, because the process looks slow and stacked against them. It is slow, but it is far less stacked than it looks once you know where to aim.

This guide walks through the whole route, from deciding whether public work suits you to what to do after you win or lose.

Is public work right for your firm?

Public contracts suit firms that can wait. A first win typically takes 6 to 12 months from your first bid, and payment terms are usually 30 days after an approved invoice. In return, public buyers pay reliably, publish what they want in writing, and often renew contracts for years.

Public work is a good fit when:

• You have two or three finished projects you can describe in detail, with a client willing to act as a reference.
• You can spend one to three days on a good bid without starving paying clients.
• Your work is repeatable: websites, integrations, support, cloud migrations, security assessments and staff augmentation all win often.
• You are prepared to bid five to ten times before judging the results.

It is a poor fit if you need revenue next month, or if all your past work is under NDA with no way to describe it.

Where public IT tenders are posted

Every country has a central portal for national government tenders, and most states, provinces, cities, health bodies and universities post on their own portals or a shared regional one. The biggest are:

Country	Main national portal	Notes
Canada	CanadaBuys	Provinces and cities use BC Bid, the Ontario Tenders Portal, SEAO in Quebec and others
United Kingdom	Find a Tender	Contracts Finder carries lower-value work in England
Australia	AusTender	Digital work also goes through the BuyICT Digital Marketplace
European Union	TED (Tenders Electronic Daily)	Every tender above the EU thresholds; national portals carry the rest
United States	SAM.gov	States, counties and cities each run their own systems

Checking a dozen portals by hand every week is where most small firms give up. StackBid reads them for you and keeps only the tech work. See the country guides for each portal in detail.

Pick tenders you can actually win

The single biggest improvement most firms can make is to bid less often, on better-fit work. Before you write a word, run every tender through a quick bid/no-bid check:

1. Mandatory requirements. Can you meet every pass-or-fail condition today? Certifications, insurance amounts, security clearances, years in business and minimum turnover are the usual blockers. One "no" here ends it.
2. Supplier lists. Is the tender only open to firms already on a framework, standing offer or panel? If so, you cannot bid this time, but note the list and when it reopens.
3. Relevant experience. Do you have past projects close in size and type to this one? Buyers score what you have done, not what you could do.
4. Size. Is the contract small enough that you would be a credible supplier, but big enough to be worth the bid? A rough rule: the annual value should be no more than about a third of your annual revenue.
5. The incumbent. Is this a re-tender of work someone already does well? Award notices tell you. You can still win, but you need a clear reason the buyer should switch.
6. Time. Do you have the days to write it properly before the closing date?

If a tender passes all six, bid. If it fails one, let it go and spend the time on the next. Firms that do this consistently see win rates of one in three to one in five; firms that bid on everything often win one in twenty.

StackBid's "Can we bid this?" check runs the first two steps for you against your firm profile.

Read the tender in the right order

Tender packs can run to hundreds of pages. Read them in this order and you will know within 15 minutes whether to bid:

1. The summary or notice: what, who, where, how much and when.
2. Mandatory requirements: usually a table or a section called "mandatory criteria". Check each one against what you hold.
3. Evaluation criteria: how points are split between price and quality, and what each scored question is worth. This tells you where to spend your writing time.
4. The statement of work: what you would actually deliver.
5. Contract terms: liability caps, intellectual property, insurance and payment terms. Unusual terms are a reason to ask a question, not to give up.
6. Forms and attachments: everything you must sign and return.

Make a compliance matrix as you read: a simple table of every requirement, with a column for where your bid answers it. It is the cheapest insurance against being rejected on a technicality.

Write a bid that scores

Evaluators work through a scoring sheet, often several bids in a row. Make their job easy.

• Answer the question asked, in the order asked. Use the buyer's numbering and headings. If a question has three parts, answer in three parts.
• Mirror the scoring words. If the criteria say "demonstrated experience delivering accessible websites for public bodies", say "We have delivered accessible websites for public bodies, for example…".
• Prove every claim. Name the project, the client, the dates, the size and the result. "We improved page speed" scores less than "We cut median load time from 4.1 to 1.3 seconds for 40,000 monthly users".
• Name your team. Many IT tenders score the people. Give each named person's role, years of experience and two relevant projects.
• Show how you will run the work. A short plan with phases, milestones, risks and how you will report progress is worth more than pages of method theory.
• Keep to page and word limits. Text beyond a limit is often not read.
• Price to the scope. Price exactly what is asked, in the format asked. Do not hide assumptions; list them.

Before you submit, have someone who did not write the bid score it against the evaluation criteria, as the buyer would.

Use questions and addenda

Almost every tender has a window for clarification questions. Use it when something is unclear, a requirement seems to exclude small firms for no good reason, or the contract terms carry risk you cannot accept. Answers are usually shared with all bidders without naming who asked.

Buyers also issue addenda: changes to the documents, deadline or answers to questions. Check for them up to the closing date. Missing an addendum is a common reason bids are rejected.

Get on supplier lists and frameworks

A large part of public IT work never appears as an open tender, because it is awarded through frameworks, standing offers and panels that firms must join first. Examples include G-Cloud in the UK, TBIPS and ProServices in Canada, the BuyICT Digital Marketplace in Australia and GSA Schedules in the US.

Joining is usually a one-off application that reopens every year or two. Note every list that blocks you from a tender, find out when it reopens, and apply. Once you are on, the competitions within it are short and the field is small.

Team up when you can't bid alone

When a tender is too big, or asks for something you lack, you can still take part:

• Subcontract to a larger firm that is bidding. They need specialists, and public buyers often reward primes that involve small businesses.
• Form a teaming agreement or consortium with one or two firms whose skills complement yours, so together you meet the requirements.

Agree in writing who leads, who does what and how the money is split before you write the bid.

After the award

Whether you win or lose, the tender is not over:

• Ask for a debrief every time. Buyers will usually tell you your scores and where you lost points. It is the fastest way to improve.
• Read the award notice. It tells you who won, at what price, and for how long. That date is when the work will come back up.
• If you win, deliver well and keep records. Your first public contract is your best evidence for the next one, and well-run contracts are often extended.

Common questions

How long does it take to win a first government IT contract?

Most small firms win their first public contract within 6 to 12 months of starting to bid, usually after five to ten bids. Picking well-fit tenders and asking for debriefs shortens that.

Do I need certifications like ISO 27001 to bid?

Not for most tenders. Certifications such as ISO 27001, SOC 2 or Cyber Essentials are mandatory on some cloud, security and data contracts. Check the mandatory requirements of the tenders you want before paying for one.

Can a small firm compete with large IT companies on price?

Yes, especially on contracts under a few hundred thousand dollars, where large firms' overheads make them expensive. Most IT services tenders are also scored on quality, which favours firms with directly relevant experience.

Can I bid on tenders in another country?

Often, yes. Trade agreements such as the WTO Government Procurement Agreement open many tenders above set values to foreign suppliers, though some require a local entity, security clearance or local presence. Each country guide covers the rules.

Is it worth answering a request for information (RFI)?

Usually. An RFI cannot win you a contract, but it puts your firm in front of the buyer and can shape the tender that follows so it suits firms like yours.

Next steps

1. Browse open tech tenders and pick three that pass the bid/no-bid check.
2. Read the guide for the country you'll bid in.
3. Keep the procurement glossary open while you read your first tender pack.