Industry
Venue and club systems built from MineCourt, which takes court bookings online today for badminton venues in Ho Chi Minh City.
An engineer reads it and replies within one business day.
Who we build this for
What shapes the work
Every sports venue starts with the same assumption, that booking is a calendar with slots, and every one of them outgrows it in the first season.
Peak and off-peak, weekday and weekend, member and non-member, junior, block bookings, coaching hours, court-specific rates, seasonal adjustments. Each rule is reasonable on its own; together they are a pricing engine, and a spreadsheet of rates will not express them.
A hall that divides into three, a court that shares lighting with its neighbour, a pitch that cannot be booked while the one beside it hosts a tournament. Conflicts are physical, not just chronological.
Brackets, fixtures and the blocks of time they consume have to coexist with ordinary bookings rather than replace them for a week.
An unsold hour is gone. The system has to make open slots findable by players who were not already looking at your site.
Players, coaches, members, receptionists, venue managers, finance, multi-site operators. Permissions and views differ for each.
How we build it
MineCourt is our venue management platform, built around the parts of running a venue that break a calendar with slots, and badminton venues in Ho Chi Minh City take court bookings online on it today. We deploy it for a venue or a group of venues as a platform implementation, and hand it over with the source code.
Pricing is a layered engine: a base rate for each court, then day type, time of day, demand, holidays, special events such as tournaments and leagues, and membership, combined into the price a player pays at checkout.
The booking grid is a reactive Vue.js 3 interface, so a receptionist sees conflicts as they happen rather than after saving.
Membership is the top pricing layer, and members book against a plan with its own quota. The venue store sells products, food and drink at the counter, with stock and orders kept alongside the bookings.
Player tools, venue controls and a role-based permission model, with a hub that connects city sites for operators running venues in more than one city.
What we start from
MineCourt is in production at minecourt.com, where badminton venues in Ho Chi Minh City take court bookings online. The MineCourt platform page shows what is already in the platform and how a deployment is extended, and its role guides go through the platform screen by screen.
Deploying MineCourt with your venues, your pricing rules and your branding sits at the Small to Medium sizes for a deployment, moving to Large where the platform is extended well beyond its defaults, as set out on our pricing page. We build a working demo against your real courts and real rates first, because pricing rules are exactly the thing that looks simple in a demo on sample data.
The source code is yours at handover (why that matters), and development work carries a warranty of one year by default and up to three (what is covered). Ongoing operation is handled under support and maintenance, separately from the warranty. Where a venue needs more than the platform carries, the engineering underneath is our custom web application work: multi-role systems with real workflow, rather than a content site with a form on it.
Your pricing rules, in whatever form they currently exist; a laminated sheet on the reception desk is fine. They are the most useful artefact you have, because they are where a calendar with slots fails and where the scope of your build is really decided. Bring the exceptions too: the standing block booking that never appears in the system, the coach who is invoiced monthly, the rate nobody can explain but everyone honours.
Bring the physical layout as well: which courts divide, which share lighting or access, what cannot be booked while something else is running. Those constraints are the difference between a calendar and a booking system, and they are rarely written down anywhere.
We take these into a requirements session and a mindmap, then build a prototype on your real courts and real rates before anything is priced, so the pricing engine is corrected against reality rather than approved on a diagram. Questions that come up before that are answered on our FAQ page.
Tell us your use case and roughly how many users. We set your case up on the version in production and go through it with you one role at a time, before anything is signed.
