Why we built Bidwin on Claude

By Todd Heater · Published 27 July 2026, updated 30 July 2026 · Version 1.3 · An insight paper for UK bid teams

A prospect asked us recently why the whole thing is built around Claude. She had read the site, understood the product, and put a reasonable question: you are asking me to take out a second subscription with a company I did not choose, so tell me why that one.

The answer has less to do with model quality than she expected. It rests on where your files end up, on whether a method can be installed rather than merely written down, and on what we were able to avoid building.

Reason one: your files stay in your own folders

Consider what a bid writer handles in an ordinary week. A tender pack under embargo, an evidence library built up over years, case studies naming real clients and real contract values, and draft responses a competitor would find useful. Where that material goes is not a technicality.

Bidwin is a plugin. You install it into your own Claude account and point it at folders on your own machine. Claude reads and writes only in the folders you have connected, with the permissions you set, and plugins you add yourself are stored locally. Your tender pack and evidence library stay where they already sit, in your own file system and under your own backup arrangements.

The practical consequence is that we do not host your files and never receive a copy of them. There is no Bidwin server holding your evidence library, because there is no Bidwin server. When a licence ends we have nothing of yours to return or delete.

That is a different shape from the typical AI writing tool, where the first step is to upload your material so the vendor’s system can index it. It is a perfectly ordinary way to build software, but it is harder to explain to a client whose confidential procurement documents you hold, and harder still to answer when a tender asks you to describe your data handling.

Reason two: a method that installs

Most AI bid-writing advice amounts to a set of prompts. Someone who is good at bidding works out how to ask well, writes it down and shares it. That is useful but fragile. Prompts may be half-remembered and adapted badly, and two people working from the same prompt library will produce different work without being able to say why.

Claude supports installable plugins that bundle skills, and a skill behaves the same way each time it runs. We were therefore able to build the method itself into the tool. It reads a tender pack and deconstructs it into scored questions with their weightings and word limits, catches the amendment buried in the clarifications log, drafts against your own evidence with every figure traced to a named file, flags any question your evidence does not cover instead of inventing something, and puts the completed pack in front of an independent reviewer.

None of that is a prompt. It is a process with checks in it, developed by Mark Cosens over years of live bids, and installing it is what makes it repeatable by somebody who is not Mark, on a Thursday, with a Friday deadline.

For anyone new to AI there is a second benefit, which may be the larger one. Because a skill carries its own instructions, the person running it does not need to be a prompt engineer to obtain professional output. Typing /bidwin-tender-vet supplies the context, the sequence, the evidence rules and the quality checks that a specialist would otherwise have to know to ask for. A tool that rewards only those already fluent in AI is of limited use to a bid manager with better things to learn.

Reading the whole pack

A tender is rarely a single document, and the marks are often in the join between two of them: a criterion in the scoring annexe that a clarification quietly amended three weeks later. AI tools have a limit on how much text they can hold in view at one time, so a tool working through a long pack in pieces may read both documents and still miss that the second changed the first. Claude’s limit was generous enough to take a pack whole, which is why /bidwin-tender-vet reads every file in your Tender/ folder before it plans anything. Every serious model is improving here, so we expect this to matter less over time.

Reason three: we did not build our own platform

There are some providers who have built their own tools. The respectable reason is a wish to control the product from end to end. The commercial reason is stated less often: a platform is a moat, and once your evidence library, templates and bid history sit inside a vendor’s system, leaving becomes expensive.

We considered what building our own would involve. A document editor, a file browser and a permissions model, accounts and billing, a mobile application, a scheduler, and integrations with Google Drive, SharePoint and Slack, followed by years of maintaining all of it. Each already exists in the Claude desktop app, maintained by a company with considerably more engineers than we have, and our clients are paying for it in any case.

So we did not build it, and Bidwin is the bid method alone. What follows is what the app provides that we would otherwise have had to write, and that clients receive without our charging for it.

Projects and folders that keep work separate. Each tender is its own project, with its own local folder, instructions and memory, and what Claude learns on one bid does not carry into another. Our folder convention of Tender/, Support Files/ and Instructions/ depends on the app’s ability to scope work to a folder and hold it there. A bid manager running four live tenders requires four sealed rooms, and the app provides them.

Draft preview with highlight editing. When Claude drafts a document it opens beside the conversation, and you highlight the sentence you want changed, select Edit with Claude and type the change. Bid managers already work this way, marking up the paragraph in front of them, and it makes review closer to redlining on paper than to describing a paragraph from memory in a chat window.

Connectors. Google Drive, SharePoint, OneDrive and Slack allow the evidence base to remain where the organisation already keeps it. For a team this is where the more interesting workflows lie: the bid manager writes while the operations lead adds the latest Ofsted report to the shared drive, and the draft picks it up.

Dispatch. A task can be handed to Claude from a phone and carried out on the desktop, with the finished work collected later, which keeps a bid moving when you are away from your desk. It is in beta, it requires the desktop app to be open, and it is currently available on the Pro and Max plans.

Scheduled tasks. This one is load-bearing for us. Bidwin Watch, our tender opportunity finder, is a scheduled task. It runs to its cadence, searches the live notices, qualifies what it finds against the client’s evidence base and reports what merits a bid. Without scheduling in the platform we would have had to build a server to run it on, which would have meant holding client data and undoing the first reason in this paper.

None of this is our work and we claim no credit for it, which is precisely why it is worth setting out. Every item is development we did not undertake, time we did not spend and cost our clients do not carry. That time went instead into tender deconstruction, evidence discipline, house-style derivation and pre-submission review.

Reason four: a tool built for business use

The character of that feature list is not accidental. Folder permissions, approval modes governing when Claude asks before acting, scheduling, connectors to the systems an organisation already runs, and projects with memory scoped to the job are not the features of a product designed to be entertaining. They are the fundamentals of getting work finished and being able to account for how it was done, which is the direction of travel we needed from a platform.

The pace of release matters as much as the direction. Anthropic issues new models and capabilities regularly, and several of the features described here did not exist when we began. The consequence for a licence holder is that our development effort goes into the bid method while the ground beneath it improves without our involvement. The corresponding risk is that a fast-moving product also changes. Features arrive in beta, and some of those described here are in beta now. Tracking that is part of what a Bidwin licence buys, since we test new models and features and revise our guidance rather than leaving clients to follow release notes.

What we claim, and what would change our mind

Our own drafting comparisons between Claude models produced no clean hierarchy. Our guidance to clients gives a current recommendation that could change. We revise it as new models appear.

What we are describing is an architecture we can explain to a procurement officer without hedging. Other vendors publish their own terms, which you should read for yourself.

The bulk of Bidwin is method, not model. The tender deconstruction, evidence rules, scoring-criteria mapping, house-style derivation and pre-submission review are ours, and they encode how a bid professional works rather than how any particular model behaves. Were another platform to offer the same three things, files that remain in the client’s own folders, a way to install a method as a versioned package, and the workings that spare us building an application, the method would be portable and this paper would be about that platform.

Three developments would prompt us to move. If the local-file architecture changed so that using Bidwin meant handing client material to a vendor’s store, the first reason here would fail. If the plugin model were withdrawn or degraded so that skills could no longer be shipped and versioned reliably, the second and third would go with it. And if a competing platform matched all of it while being materially cheaper or more capable, we would owe our licence holders a conversation about it. A licence holder learning from somebody else that their tooling should have moved a year ago is the kind of thing that ends a working relationship, and properly so.

The cost question underneath the question

Most people asking why Claude are also asking why they are paying two subscriptions.

Bidwin Core costs £349, paid once, and the licence is permanently yours. Claude Pro costs £18 a month and is paid to Anthropic. Take the smallest case, a single tender in front of you now: buy the licence, take one month of Claude Pro, draft the bid and stop the subscription, and the cost is £367. A single tender written by a bid-writing firm typically costs between £3,000 and £6,000. The licence does not lapse when you cancel, so the next time a tender lands you pay for a month and nothing further. Kept running for a year, the total is £565 for one bid professional, whatever number of tenders you put through it.

One qualification is needed. Claude Pro carries a weekly usage allowance as well as a per-session one, and a long pack drafted in haste can reach it and leave you waiting for the cycle to reset. Pacing the work usually settles the matter, and our guide How to get the most from your Claude token usage explains how. Where a deadline will not wait, Pro also allows usage credits to be switched on, continuing at pay-as-you-go rates under a monthly cap you set yourself, which for one busy month is generally cheaper than moving to a larger plan you would then pay for every month afterwards.

We could have concealed the second subscription inside a higher headline price, and we could have built a platform and charged a monthly fee to keep your bid library in it. We decided against both, for the reason that runs through this paper: your account, your files, your control, and a bill you can see.

Common questions

← Back to all resources