Market days run on one record, not five spreadsheets.

It is one shared record that follows a vendor from the first application to the final season report. Vendors apply online, organisers approve or waitlist them, each vendor gets a stall on the map, fees are collected and tracked, permits and insurance expiry dates are watched, and the season closes with a report. It makes sense when the market repeats every week and the manual work of running it has a measurable cost in time, errors, or lost fees.

Buy an existing product when it handles your season with reasonable setup and its pricing makes sense. Several maintained products cover applications, stall maps, payments, and closeout for standard weekly markets. Build custom when your market's rules are themselves the advantage: unusual fee structures, category caps and jurying, multi-market seasons, or connections to your accounting and city permit systems that no maintained product covers cleanly. If the rules of the season are still changing every week, wait and settle them first.

For a small, well-defined task with someone technical managing it, freelancers are often cheaper. The pattern that goes wrong is a non-technical buyer coordinating several freelancers becoming the project manager, the tester, and the person who discovers the pieces don't fit. A software company earns its fee when the work needs coordination across screens, rules, data, and connections: one accountable party, one phase price, and checkpoints against the whole season. If your need is one screen or one fix, hire the freelancer.

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 season 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, and the condition of existing code. The agreed phase is priced in writing before it starts.

Timing depends on scope: a bounded audit or proof of concept is a smaller engagement, while a system with several connections to other systems, data to move over, mobile access for market-day check-in, or formal compliance controls takes longer. The schedule is set once the first workflow and what 'done' looks like are clear, and it should be timed so the first release is ready before applications open for the next season.

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. AI-built prototypes from Lovable, Replit, Bolt, or v0 can be assessed as starting points. 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.

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 market operation, access to the relevant users and systems, timely answers on market 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 vendors see, and what your people use all day: approvals, waitlists, stall changes, fee exceptions, and the season report. 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.

You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the season 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 market.

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.

Yes, and this is one of the first decisions the scope must settle. A season booking bundles every market date into one offer with one price, while single-date booking lets vendors pick the weeks they want. Both can run at the same time against the same stalls, but the fee rules, refunds, and what happens when a vendor skips a week have to be defined for each path before the screens are drawn.

Yes, when each market date is tracked separately. The vendor's stall for that date is freed without touching the rest of their season, and the freed stall can be offered to a standby vendor or sold as a single date. The scope should name who can free a date, whether the fee is refunded or credited, and how the standby list is worked.

Every vendor record carries its documents and expiry dates, and the system watches them. The organiser sees what is missing or about to lapse before the roster is locked, and vendors can upload a renewed document themselves instead of emailing it. The rule to agree in scope is what happens when a document lapses: whether the vendor is blocked from booking, flagged for review, or simply warned.

The roster shows who is coming, who has said they cannot make it, and which stalls are open. An empty stall can be filled from the standby list, and a walk-up vendor can be added on the spot. The scope should define the cancellation and no-show rules: whether a fee still applies, how the standby list is ordered, and who on the team can make the change from a phone on the day.

Market-day check-in has to work where the signal is weakest, so the roster and stall map must stay readable and usable offline, with changes syncing when the connection returns. Any scope that assumes perfect signal at an outdoor market will fail on the first busy Saturday, so offline behaviour is agreed as part of what 'done' looks like, not added later.

Configure an established market platform when its application, stall map, fee, and document model fits your season. Build an extension when one connection or workflow is missing. Own custom software only when the differentiating process, fee model, multi-market season, or cost of constraint justifies build and support. Compare data moving over, adoption by your vendors, roadmap, and total operating cost.