Winery software for grape to glass, in one record.

Winery management software runs a winery from one record: grape intake, fermentation rounds, barrel programs, bottle stock, wine club runs, tasting room sales, and the federal report. It fits estates whose production, cellar work, and club sales live in separate systems and whose staff copy numbers between them by hand. It makes sense when that copying costs real time, creates report errors, or sells wine that is already gone.

Fix the side that costs you the most sleep first. If the federal report is rebuilt by hand every filing period and you dread it, start in the cellar. If the wine is fine but a club run takes three days of checking states and billing cards, start with direct sales. The two sides have different buyers inside the same winery: the winemaker worries about lots, additions, and what the bulk records say, while the person running the tasting room worries about club runs, reservations, and getting an order shipped. Decide which side hurts most before you compare products.

Ask every vendor on the production side to show you the same thing, using a messy month with a blend and a transfer in it: does the report come straight from your lot and bulk records, or does someone copy numbers across by hand? In the US, the Report of Wine Premises Operations, TTB Form 5120.17, falls due on or before the 15th day of the month after the end of the filing period, so the deadline keeps coming round whatever is happening in the cellar. A tasting room system will not necessarily touch this report, so do not assume your sales platform has it covered. Filing periods and requirements vary, and other countries have their own regulators, so check with TTB or your own regulator on what applies to you. This is not legal or tax advice.

You can, but it is the riskiest way to do it. Trying to change both at once, in the same season, is how you end up with two half-finished systems at harvest. The safer order is to fix the side that costs the most sleep, run it through one real vintage or one real club cycle, and then bring the other side onto the same record. If you run a cellar system and a separate sales platform in the meantime, that is fine, as long as you know exactly how stock numbers get from one to the other. Ask both vendors to show you that link, or tell you plainly that there is not one.

Three things are non-negotiable: a way to file the federal report without rebuilding it by hand, a way to take money in the tasting room, and a way to know what you actually have in stock. Start with the production system if the report is the pain, and the sales platform if the club run is the pain. You can delay dedicated wine club software until the club is large enough that the run itself is the bottleneck. For a very small estate, a named production product plus a named sales platform is often the right answer for now. Come back to custom software when the manual work between them costs more than the build.

Build custom when you need the federal report, vineyard block tracking, and wine club management in one system rather than three. Named products are strong on one side each: the best direct-sales platforms run the club, the tasting room, and the online store well but hold thin production records, while the best cellar products track lots, tanks, and barrels well but do not run club billing or the tasting room register. If you pay for both and still run manual data transfers between them, the math tips toward custom once the club is large and the reconciliation work is a standing job. Our guide to how to build winery management software sets out the thresholds and the phased costs in full.

That link is the question most demos skip, and it is the one that decides whether the system works. Every bottle sold in the tasting room or shipped to a club member has to come down from the same stock the cellar counts, or the register will sell wine that is already gone. In a first release, name the one stock record that both sides read, agree which side owns it, and test it with a real club run: billing, pick list, labels, and the stock count after. If the two systems cannot share a stock number, say so in writing and name who reconciles it, and how often.

A club run is one event, not five jobs: member billing with retries for failed cards, a check that each destination state allows the shipment before the label prints, a pick list for the warehouse, shipping labels, and a message to the member. Members get a place to update an address, swap a wine, pause a shipment, or change tier. Every label check runs against a shipping rules table, so a state that changed its rules does not become a shipment that has to be undone. The club cycle is the best first test of a new system, because one real run surfaces every edge case in billing, state checks, pick lists, and labels.

Selling wine into another state is a licensing, tax, and reporting problem before it is a shipping problem. A custom system checks the destination state against a shipping rules table before a label prints, and keeps the check, the order, and the shipment on the same record so a refused delivery can be traced. The rules themselves change, so the system should read them from a maintained table rather than hard-coding them into the screens. Your counsel or compliance adviser owns the reading of the law; the software owns carrying it out the same way every time.

The first paid phase may cover a bounded audit, a proof of concept, a recovery plan, or a small first release. The final price depends on how deep the cellar workflow goes, how many kinds of users it serves, what it needs to connect to, whether data needs moving over, whether phones or tablets are involved, any compliance requirements, and the condition of existing code. The agreed phase is priced in writing before it starts. Our guide to how to build winery management software publishes phased cost ranges for a production and compliance core, a club and member phase, and a wholesale and multi-location phase, so you can see what each stage buys before you commit to it.

Timing depends on scope: a bounded audit or proof of concept is a smaller engagement, while a platform with several system connections, data to move over, tasting room apps, or formal compliance controls takes longer. The schedule is set once the first workflow and what 'done' looks like are clear. One discipline matters more than the calendar: ship the first release to a real club cycle or a real filing period before scoping the next stage, because real use surfaces edge cases that months of specification work will not.

Yes. Takeover is a common first engagement, and it always starts with an audit: where the code lives, how your data is organized, what is tested, which outside services it depends on, who can access what, and how updates go live. Code that is understandable and fit for the next release stays; only the parts blocking reliability get replaced. And if you already paid another vendor and have nothing working, the audit tells you which story you have before you spend more: the most expensive version is the product that looks finished, clean screens and clicking buttons, while underneath nothing is tested and the security checks run in the browser, where anyone can tamper with them, instead of on the server where they hold.

You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the workflow agreed at the start. Progress is reported in plain language: what changed, what's next, and what it costs. Because you own the code, the accounts, and the operating notes throughout, nothing about the work is locked inside our heads. Our job is to make the work checkable; your job is to check it against your business.

You own the code built for you and control where it lives, the cloud accounts, the data, analytics, and third-party subscriptions. Outside services and open-source pieces keep their own licence terms. The operating notes and handover material stay current so another capable team can take over.

Every launch includes post-launch warranty cover for defects in the agreed scope, release support, and small screen corrections. After that, work can continue as another fixed phase or an ongoing product engagement. The code and accounts stay under your control either way.

Security starts with the data, the people, who can see and change what, the systems it connects to, and where it runs. The scope can include access controls, separate testing and live environments, protected passwords and keys, activity logs, backups, recovery plans, and whatever your regulation requires. We write down which protections are included and which evidence your team or an independent specialist must provide. We do not call a product compliant until the technical, operational, and legal requirements are all verified.

We need one person who owns the workflow, access to the relevant users and systems, timely answers on business rules, and someone who can accept or reject each milestone. A weekly working session is usually enough once the scope is stable. Your team should not have to manage developers day to day. The team that scopes your project is the team that does the work: no handoff to another vendor after you sign, and you can talk to the people doing the work directly.

Ask for the quote to name everyone who will use the system, including your own team. Every platform has two products: what customers see, and what your people use all day: approvals, exceptions, refunds, managing users, and a record of who did what. When that second product is quoted as an 'admin panel' on a single line, it becomes the overrun. Our quotes treat your team's screens as their own scope, with their own users. Then the phase names the workflow, what 'done' looks like, the price, and the exclusions, all before paid work starts. You review working software at agreed checkpoints, and when new information changes the scope, you hear the effect on price and timing before anything is approved.